1. Malware Analysis: Initial Steps
Malware Symptoms
The first step in my investigation was finding out the symptoms that the program causes. My friend told me when he first ran the program, it induced a Blue Screen of Death, but nothing out of the ordinary occurred when he rebooted the computer. This told me 2 things about the malware:
Since the “virus” caused a Blue Screen of Death, this means it messed up somewhere. Malware aims to cause as little disruption as possible, since events such as a blue screen can alert the user to the fact that something is wrong.
The malware programmer is not advanced. A seasoned malware author would not be foolish enough to cause a BSOD. BSODs are usually caused by mistakes such as null pointers, and other memory reference issues. By understanding the author, you can better understand his work.
Just from the fact that the virus caused a Blue Screen of Death, I learned a lot about the program and its author. By better understanding the malware and author, I can take educated guesses regarding its level of complexity, as well as motivation and goals.
File Information Gathering
After looking at the symptoms, I next took a very brief look at parts of the program itself. I ran all of this on a Linux system in order to prevent accidental infection. Even then, I ran the tests on a non work related computer, and one that was isolated from all networks. Like all other cases involving malware analysis, it pays to be careful. The last thing you want to happen is to accidentally infect yourself, only to spread it to your other, more important computers. Later, I end up using VMware for this very reason.
File: I first run the “file” utility to figure out what exactly I’m dealing with. The results showed this:
w89e85t5.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit Mono/.Net assembly
The output tells me a few things. First, it is a portable executable, meaning it is made for maximum portability. In the context of this malware analysis, this makes sense, because the malware author is going to want to have this run on as many computer types as possible. The second half of the output shows us that it is made to run on 32 bit computers, and is was made using Mono with the.Net Framework.
Another useful tool in malware analysis is a program called PEiD, which scans an executable for signs of being packed. Packers are utilities used in order to obfuscate the executable, making it more difficult for reverse engineers to disassemble the malware using programs such as IDA Pro. PEiD returned a result of ”Microsoft Visual C# / Basic.NET”, confirming that.NET was used in creating the malware. The Visual C# portion also gave me some more information regarding the language used to create the virus.
2. Malware Analysis: Virtual Computer System
After finding some preliminary information regarding the malware, I next wanted to move onto something a little 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 risk of infecting other computers on network
- “Sandbox” environment
- View the malware in its native habitat
However, there are also a few negative points associated with running malware in virtual computers:
- Some malware can be aware that it is running under a virtual machine
- Malware can attempt to exploit and break out of the virtual machine
- If networking access isn’t cut, worms can attempt to compromise other systems on the network
That being said, I felt confident that the benefits outweighed the risks. From before, I had a feeling that this individual piece of malware was not advanced, so the risk of it detecting that it was in a virtual machine and actually exploiting it seemed slim. However, I was running the VM on top of Linux, so even if it did break out, it wasn’t in the system it was designed 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 set it up with a NAT connection, so that VMware will send the requests through the host machine to the actual hardware. However, I made sure to keep disconnected from the network at all times. This is critical! The last thing you want to do when analyzing a worm is to unleash it on your own systems.
With the virtual machine set up, I moved everything into position, including using Wireshark to sniff traffic from VMware, which uses traffic on the vmnet8 interface.
3. Malware Analysis: Network Traffic Analysis
The initial running did not show very much of anything. No Blue Screen of Death was encountered, and very little network data was sent. Here’s what Wireshark showed:
The packets clearly show the malware attempting to generate a connection with 23U.NO-IP.INFO from the DNS requests it is making. Since it isn’t receiving a reply, we aren’t getting anything more than that for now. A WHOIS search ended up showing no results for this domain. My instincts were telling me that this was most likely some type of script kiddie attempt at a botnet. So, I tried looking a little further into the network traffic. Since I wasn’t going to get anywhere without contacting the server itself, I tried connecting the virtual machine to the network. Under the careful eye provided by Wireshark, I watched what exactly this malware was doing. Take note that this isn’t the preferred method, but I had taken all other computers on my network down for the duration of this little experiment. Here’s what Wireshark shows now:
Now that the malware can sent packets to and receive packets from the server it is attempting to connect to, I was able to see exactly what this specific program was attempting to do. I uploaded the packet capture file above. Packets 1-8 show some type of connection being set up between the remote server and our victim computer. Packet 9 appears to show a password being sent to the remote server, with the password being “\google_cache2.tmp”. Then, packet 17 shows a goldmine of information: it appears to be the welcome message of an IRC channel. Bingo! The malware is an IRC botnet recruiter. To get more information, I looked at the TCP stream:
:FBI.GoV NOTICE AUTH:*** Looking up your hostname…
:FBI.GoV NOTICE AUTH:*** Couldn’t resolve your hostname; using your IP address instead
PASS \google_cache2.tmp
NICK NEW{EpicBot-AUT|XP}085587
USER 1854 “” “TsGh”:1854
:FBI.GoV 001 NEW{EpicBot-AUT|XP}085587
:FBI.GoV 002 NEW{EpicBot-AUT|XP}085587: M0dded by uNkn0wn Crew
:FBI.GoV 003 NEW{EpicBot-AUT|XP}085587
:FBI.GoV 004 NEW{EpicBot-AUT|XP}085587: uNkn0wn – iD@ uNkn0wn
:FBI.GoV 005 NEW{EpicBot-AUT|XP}085587
:FBI.GoV 005 NEW{EpicBot-AUT|XP}085587
:FBI.GoV 005 NEW{EpicBot-AUT|XP}085587
:FBI.GoV 422 NEW{EpicBot-AUT|XP}085587:MOTD File is missing
JOIN #Cheese#
:NEW{EpicBot-AUT|XP}085587!1854@192.35.222.192 JOIN:#Cheese#
PING:FBI.GoV
PONG:FBI.GoV
So, from this we can see that the IRC channel password is “\google_cache2.tmp”, our victim’s nickname is NEW{EpicBot-AUT|XP}085587, the channel we join in #Cheese#. All this from the Wireshark traffic analysis!
Now, being the adventurous person I am, I was curious about this botnet. So, I took it upon myself to attempt to connect to the IRC and have a loot for myself, hopefully talking the author of the malware himself. So, I headed on a web IRC client so that the botnet master wouldn’t be able to see my own IP address and possibly launch a DDos attack against me. I logged in using the password and other information found from the packet capture file. I logged in and waited. Every now and then, I would see a user issue commands taking the form of “UDP “. I assumed that 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 like this:
Me: Hello? Anyone there?
Botmaster: lulz you arnt too smart
Botmaster: u shoulda used a vpn
Me: Don’t worry, I’m using an web IRC, so I’m good. So what exactly is going on here?
At this point, I was booted from the chat. I figured my work was done, so I didn’t bother reconnecting. A few days later, I checked back in, and the IRC channel and the host itself went down. I figure he thought he was caught, and just shut everything down.
4. Malware Analysis: Conclusions
All in all, my first wild malware analysis proved rather interesting. I was able to take the unknown file and run a few basic utilities to find out what exactly it was hiding. This gave me a pretty good idea of what the program was capable of, and from here I ran it in a confined system to see it in action. Further investigation brought me to an IRC botnet channel, where I actual chatted with the botmaster. Not bad for a first try. Anyway, all of the techniques I used in this example are applicable to 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 is doing, and instead you will end up needing to reverse engineer the file. Reversing malware can be extremely time consuming, especially if the file was obfuscated using an exe packer. Good luck with your own endeavors, and I hope this helped!
