1. Malware Analysis: Initial Steps
The 1st step during my investigation was discovering the symptoms how the program causes. My friend explained when he first ran this software, it induced a Blue Screen of Death, but nothing out of the ordinary occurred when he rebooted the pc. This said 2 reasons for the malware:
Since the “virus” caused a Blue Screen of Death, this implies it smudged somewhere. Malware aims to cause only a small amount disruption as you can, since events for instance a blue screen can alert the person that something is wrong.
The malware programmer is not advanced. A seasoned malware author couldn’t survive foolish enough to cause a BSOD. BSODs are generally a result of mistakes like null pointers, along with other memory reference issues. By understanding the author, you can better understand his work.
Just from the fact the virus caused a Blue Screen of Death, I learned a lot about the program as well as author. By better knowing the malware and author, I can take educated guesses regarding its a higher level complexity, in addition to motivation and goals.
File Information Gathering
After exploring the symptoms, I next took a very brief examine aspects of this system itself. I ran all of this on the Linux system in order to prevent accidental infection. Even then, I ran the tests over a non work related computer, and something which was isolated from all networks. Like other cases involving malware analysis, it’s good to be careful. The last thing you want to happen is to accidentally infect yourself, and then spread it to your other, more valuable computers. Later, I end up using VMware for this very reason.
File: I first run the “file” utility to understand precisely what I’m dealing with. The results showed this:
: PE32 executable for MS Windows (console) Intel 80386 32-bit Mono/.Net assembly
The output tells me a couple of things. First, this is a portable executable, meaning it’s designed for maximum portability. In the context of this malware analysis, this will make sense, for the reason that malware author will wish to have this run on as numerous computer types as is possible. The second half of the output shows us that it can be made to are powered by 32 bit computers, which is was developed using Mono with Framework.
Another useful tool in malware analysis is really a program called PEiD, which scans an executable for signs of being packed. Packers are utilities found in order to obfuscate the executable, rendering it more challenging for reverse engineers to disassemble the malware using programs for example IDA Pro. PEiD returned a direct result ? “Microsoft Visual C# / “, confirming was employed in creating the malware. The Visual C# portion also gave me more info on which accustomed to create the herpes virus.
2. Malware Analysis: Virtual Computer System
After finding some preliminary more knowledge about the malware, I next wished to begin something a bit more risky, namely running the malware under a virtual computer. Rerversing malware under virtual systems has several benefits:
No worry of affecting production computers No likelihood of infecting other computers on network “Sandbox” environment View the malware in its native habitat
However, additionally, there are a couple of negative points linked to running malware in virtual computers:
Some malware might be aware that it can be running within a virtual machine Malware can try and exploit and get out of the virtual machine If networking access isn’t cut, worms can try and compromise other systems on the network .
That being said, I felt confident that this benefits outweighed the potential risks. From before, I had thoughts this individual part of malware was not advanced, and so the chance of it detecting that it was in a virtual machine and exploiting it seemed slim. However, I was running the VM in addition to Linux, so even if it did break out, it wasn’t inside the system it had been meant to exploit (Windows).
I started up VMware on Ubuntu, and loaded a Windows XP disk image. The most important step is setting up the network correctly. I work it which has a NAT connection, to ensure that VMware will send the requests over the host machine towards the actual hardware. However, I made certain to keep disconnected through the network at all times. This is critical! The last thing you wish to do when analyzing a worm is to unleash it on your own systems.
With the virtual machine build, I moved everything into position, including using Wireshark to sniff traffic from VMware, which uses traffic about the vmnet8 interface.
3. Malware Analysis: Network Traffic Analysis
The initial running did not show quite definitely of anything. No Blue Screen of Death was encountered, and incredibly little network data was sent. Here’s what Wireshark showed:
The packets show the malware wanting to generate vital with from your DNS requests it can be making. Since it isn’t getting a reply, we are really not getting anything further than that for the time being. A WHOIS search ended up showing no results just for this domain. My instincts were telling me that this was more than likely some form of script kiddie attempt at a botnet. So, I tried looking just a little further to the network traffic. Since I wasn’t acquiring anywhere without contacting the server itself, I tried connecting the virtual machine for the network. Under the careful eye supplied by Wireshark, I watched what precisely this malware was doing.
Take note until this is not the preferred method, but I had taken all other computers on my network down throughout this little experiment. Here’s what Wireshark shows now:
Now that this malware can sent packets to and receive packets from the server it really is wanting to connect with, I was able to view just what this kind of program was attempting to do. I uploaded the packet capture file above. Packets 1-8 show some kind of connection being create between your remote server and our victim computer. Packet 9 appears to show your password strength being sent for the remote server, with the password being “\google_”. Then, packet 17 shows a goldmine of knowledge: it appears to become the welcome message of the IRC channel. Bingo! The malware is an IRC botnet recruiter. To get more information, I checked out the TCP stream:
: NOTICE AUTH:*** Looking up your hostname…
: NOTICE AUTH:*** Couldn’t resolve your hostname; with your IP address instead
USER 1854 “” “TsGh”:1854
: 001 NEWXP085587
: 002 NEWEpicBot-AUT085587: M0dded by uNkn0wn Crew
: 003 NEWXP085587
: 004 NEWEpicBot-AUT085587: uNkn0wn – [email protected] uNkn0wn
: 005 NEWEpicBot-AUT085587
: 005 NEWEpicBot-AUT085587
: 005 NEWXP085587
: 422 NEWEpicBot-AUT085587:MOTD File is missing
:[email protected] JOIN:#Cheese#
So, because of this we could see that this IRC channel password is “\google_”, our victim’s nickname is NEWEpicBot-AUT085587, the channel we join in #Cheese#. All this from your Wireshark traffic analysis!
Now, being the adventurous person I am, I was interested in learning this botnet. So, I took it upon myself to try to connect towards the IRC where you can loot for myself, hopefully talking the article author from the malware himself. So, I headed with a web IRC client so that this botnet master couldn’t survive able to find out my personal IP address and perchance launch a DDos attack against me. I logged in utilizing the password and also other information found through the packet capture file. I logged in and waited. Every now and then, I would view a user issue commands using kind of “UDP “. I assumed he was directing his bots to DDos the victim with UDP packets. Eventually, I actually started typing, and caught the botmaster’s attention. The conversation went something similar to this:
Me: Hello? Anyone there?
Botmaster: lulz you arnt too smart
Botmaster: u shoulda used a vpn
Me: Don’t worry, I’m having an web IRC, so I’m good. So precisely what is occurring here?
At this point, I was booted through the chat. I figured my work was over, so I didn’t bother reconnecting. A few days later, I checked back, along with the IRC channel and also the host itself occurred. I figure he thought he was caught, and merely shut everything down.
4. Malware Analysis: Conclusions
All in most, my first wild malware analysis proved rather interesting. I was able to take the unknown file and run several basic utilities to learn precisely what it had been hiding. This gave me a decent thought of what this system was able to, and came from here I ran it inside a confined system to view it in action. Further investigation brought me to an IRC botnet channel, where I actual chatted with the botmaster. Not bad to get a first try. Anyway, all in the techniques I found in this example are applicable along with other malware samples. The important thing it to be cautious, and be patient. Often times, simply watching network traffic won’t completely reveal what a worm or trojan does, and instead you will wind up the need to reverse engineer the file. Reversing malware can be extremely time intensive, especially if the file was obfuscated having an exe packer. Good luck with your own endeavors, and I hope this helped!