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
was
out
the

in all, my first wild malware analysis proved rather interesting. I

able to take the unknown file and run a few basic utilities to find
what exactly it was hiding. This gave me a pretty good idea of what
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!
Article courtesy of kevin at Technology-Flow.com
http://technology-flow.com
Article Source: http://EzineArticles.com/expert/Kevin_Barsi/1035610
Article Source: http://EzineArticles.com/6293947