Based on demand, we are going to start posting samples that we analyze to offensivecomputing.net so everyone can download the sample even if the site or system that we grab it from has been taken down. You can navigate to that site and search for the MD5 hash of the file. We will include the information at the beginning of each post. You will need to create a free account with them to search for malware.
This month's sample can be retrieved here: 882ced9c6987b919fdbbbe5221cbfbe2
Filename: free-zoo-video.45262.exe
MD5: 882ced9c6987b919fdbbbe5221cbfbe2
This sample was an interesting one to analyze. I initially had some trouble trying to get this running in my dynamic lab environment. When I would open the executable, it would run for about 30 seconds and it appeared to just die.
I started Regshot on a clean snapshot in my VMWare environment. I ran the executable file and let it run for about a minute. After that, I took our second snapshot in Regshot to see what changed. This must have been the cleanest result I have ever seen from the output of Regshot.
I thought to myself, either this file isn't being run from where it needs to be run from, or it knows it's being analyzed. My initial instinct is to jump into static analysis and figure this out, but alas, I'm on dynamic duty this time so I'm going to try a different method.
I ran the file again while watching the process with Process Monitor. I was trying to get a feel for things it might be looking for or wanting. It seemed to read a ton of registry keys. Some of them were related to winsock and TCP/IP parameters. I thought to myself, maybe this thing wants some network connectivity.
I configured my lab host to go out to the real Internet. I will caution you here to make sure this is controlled. Some analysts will even recommend against this but I have found it can reveal things when having trouble with a sample such as this. If you do this make sure you have complete control over the access it has and have the ability to remove it's access should anything bad start to happen.
Ahh, looks like we are getting closer. After providing this thing some network connectivity it attempted to do more. Unfortunately it crashed pretty quick after execution.
Did I mention this sample was a real pain? I resorted to removing VMWare tools from my lab machine in order to see if it realized it was being analyzed. This is fine because I can always revert back to snapshot to get the tools back. That's the beauty of virtual environments! After rebooting I double clicked the file again and bingo. Looks like we are running now.
I ran Regshot again for the first shot. Seeing how this sample seems pretty aware of stuff, I didn't want to keep it running in case it realized I was using it. So instead of keeping Regshot running, I choose to take the first shot and save. I can stake a second shot if it runs and compare it with the loaded first shot.
After about 30 seconds I got a Java pop up which can be seen the screen shot below:
I decided to open Process Explorer and see what is going on. I noticed that I now have three new processes running. Mt2.exe, MVawia.exe and Mt1.exe. These are showing in fuchsia color in Process explorer, which by default means they are packed. Another interesting note is that it says Adobe Player Setup. I don't have automatic updates going so that is indeed interesting.
I started by taking a look at Mt2.exe. I looked on the strings tab and it shows UPX0 and UPX1 near the top. This would be a good indicator that this binary is packed with UPX. It could be there to throw us off, but it could be legit as well. I didn't see any TCP/IP connections from this binary so I decided to move on to the next new process.
Moving on to Mvawia.exe. Viewing the strings tab on this guy I also see UPX0 and UPX1. We can assume that this sample is packed as well. One thing different about this one was the existence of TCP/IP connections. It added and removed a ton of connections, this thing is busy.
I now took a look at Mt1.exe. Like the others, the strings of this file show UPX0 and UPX1 as well. There were no network connections on this file either. I also wanted to mention that one nice feature of Process Explorer is that when you are on the Strings tab, you can choose to view the strings from Image (on disk) or in memory. When the sample is run in memory, it has to be unpacked, so if you choose that option, you will often find more strings that are readable which may give you more clues as to what this thing is doing or capable of. Another thing that was interesting is that there was a child process to this one called ctfmon.exe.
Ctfmon.exe is a real Windows application. It is generally used to monitor active windows and assist functions for alternate input devices such as text to speech or others. The odd thing here is that it is running as a child process of these rather than then ctfmon.exe which is generally a child of explorer.exe.
While I was writing this section and letting the processes run, I noticed a command line pop up for a second and disappear. I also noticed that a new child process of one of these binaries was the Windows help center. Unfortunately my egress filtering (which I forgot to turn off while giving this sample access to the Internet) stopped whatever it was going to do. I quickly shut that off and decided to let it run a little longer and see if it would happen again.
As if on command after I wrote that last sentence, an IE windows popped up taking me to www.restasis.com, an ad for a Prescription Eye Drops for Dry Eyes. Soon after that the Restasis site popped up another window to show me their fancy new commercial, but oh no! I need the latest Adobe Flash to view it. OK, I'll bite.
I installed the Flash player, but I don't see any video! How rude! I closed the window out and decided to let things run on their own for a little longer. One thing I forgot to show is that the IE instance was loaded under an svchost.exe process rather than a child of explorer.exe. Another sign that we got something funky going on.
I let things run a bit longer and nothing was really happening. It could very well be that I was not waiting long enough. However, I decided I wanted to launch IE manually and see if anything changed there. Ahh! MSN wants me to install a new Adobe Flash player now. Before I could click to install, a popup from www.vuwl.com/pop.html came up. I choose to run the new Flash player and let IE run by itself for a bit.
Nothing seemed to be going on so I decided to do some light browsing and see if I see anything else that is odd. I browsed to www.google.com and nothing really seemed odd. I decided to try a bank site. I went to www.suntrust.com and this site wants me to run adobe flash player as well. I'll allow it. I may come back to this later and watch network traffic as I enter my, wink wink, real credentials.
I tried to go to another bank. I decided to Google for M&T bank. I click the link to go to their online banking page but I was redirected to glimpse.com which wanted me to run some Adobe Flash content.
I decided to try one more site before leaving. I navigated to bankofamerica.com and wouldn't ya know, I need to allow Flash content there as well.
At this time I decided to take my second snapshot with Regshot to see what has changed. I choose to load the 1st shot from my desktop where I saved it.
I then took my second shot and hit the compare button. The bad thing about browsing around while doing a regshot is that there is going to be a lot of noise in the file. We have some indicators in which to sift through the data for though.
At this time I think I have seen enough on the real internet. I'm going to fire up Lenny Zeltser's new distro REMnux to launch a sniffer and see what I can see on the wire. My current theory is that this is a click fraud or similar sample, but with the basic dynamic analysis that I'm doing, I can't tell if that is the only capability.
I set the IP address to of my Windows host to my host only networking in VMWare. I set the default gateway as my REMnux box which will be running fakeDNS to start as well as wireshark to see what this sample may be requesting. You start fakeDNS in REMnux by typing fakedns. This will prompt you for your sudo password which is malware for this distro.
You start wireshark in REMnux by typing wireshark. This will also prompt you for your sudo password as the alias is really sudo wireshark. Again, type malware. Go to the capture menu and choose start capture, or you can also hit control + E.
I see a ton of traffic already. The first DNS request I see is for alljplanet.com. Of course our fake DNS server gave up a good response and then I see a request on port 80. You will see a RST, ACK in the response though, because we are not listening to port 80.
I'm going to take a sidebar here for a second. Some may ask why didn't I just fire up DNS server, web server, mail server, IRC server etc. for the sample before I started my analysis. One thing I recently learned from a very, very wise man (Lenny Zeltser) in his SANS 610 course is to give the sample a little bit at a time. This way you can control what it is doing at a granular level and mold your lab as you progress in your analysis. I used to just throw the kitchen sink at samples, but then I would dread sifting through the data overload. Thus, I recommend and have started following this advise as it has allowed me to filter what I am seeing to more relevant data.
Back to the regularly scheduled program :)
I noticed in our fakeDNS responses a number of DNS queries.
I'm guessing at this point that we want port 80 traffic on these due to what I have seen thus far. What I'm going to do at this point is fire up a netcat listener to see if I can glean any information out of the requests. I know I could use Apache, or some other web server, but I'm going to start with netcat since it is so easy to use.
To do this, I bring up another xterm window and type sudo nc -l -p 80. This tells netcat to listen (-l) on port 80 (-p 80). This should show any request that comes to port 80. (Don't forget sudo! You need to use this because you are opening a privileged port and that needs root access)
We did get a successful capture of what was going on. As you can see in the following screen shot, we have HTTP Post to the site alljplanet.com. The data is not in clear text. Our next job would be to figure out what the data contains. Another interesting thing to note is that the user agent here is saying it's IE 6.0 when I am running IE 8.0 on my lab machine. It is also saying that the Windows version is Windows NT 5.0 which corresponds with Windows 2000, when I am running Windows 5.1 which is XP. These are all indicators of compromise (IOC), which could be use to search for or detect/block on in your systems and IDS/IPS devices.
At this point the requests seemed to have slow down a bit. I tried to kick start them by opening the browser and going to some of the sites that I tried when it had a live connection to the Internet to see if that would get things moving. It did not seem to help. I decided to let it run it's course.
After waiting for a bit, I decided to kill the netcat listener and start it again. One thing about the Linux netcat is that it tends to hang after one session. The Windows version allows for a -L which will continue to listen for other sessions.
It looks like the data in the post for every site is the same. My first guess is that application/x-www-form-urlencoded is encoding the values of what is being posted so I'd like to decode that to see if I can see what is being sent.
The interesting data that remains a mystery is the data= section of this POST. I attempted to decode this with base64, unicode, and urldecode methods but to no avail. At this point I think this could just be the API key that is used for tracking when ads are clicked.
I'm feeling stronger now that this sample is doing some sort of click fraud. I don't know all of the sites that are being called, but one interesting request made is for netflix.com which could be evidence of pretending to click an ad but it could be something else as well. Again, these requests aren't being seen on the Windows GUI while I am on it. The requests are coming from an IE instance that is running under svchost.exe rather than under explorer.exe process as it should be.
That is about all the time I can devote to this sample at this time. I'm pretty sure that it is a click fraud sample at least. As I mentioned before, it may have other capabilities, but I do not see evidence of these through dynamic analysis alone. I would probably revert to static analysis at this point, but that is Jamy's job this time. Check out his post and see what he found.
Showing posts with label Dynamic Analysis. Show all posts
Showing posts with label Dynamic Analysis. Show all posts
Sunday, January 23, 2011
Sample Analysis 2: Dynamic Analysis
Sunday, October 31, 2010
Dynamic Analysis part 2
Welcome to the second installment of the dynamic analysis section of out blog. In the last post, I discussed why you should use a VM solution and made some recommendations on choosing one. In this post, I will go over some information on building out a the VM's themselves, including recommended operating systems and tools to install.
When considering what virtual machines to install, you must consider what tools you will be running and what operating system the malware is targeted at. For this reason, you will most likely end up with various Microsoft Windows installations along with a few Unix variants, most likely Linux. I will not cover installations themselves as there are plenty of instructions out there for installing operating systems. I will also cover a few classes of tools and make some recommendations for each category.
For your Windows VM's, I recommend having both a current Windows 7 install and an older Windows XP installation. The reason for 7 is that malware is starting to directly target Windows 7, as it is starting to gain critical mass in enterprise and general user environments. For most situations, Windows XP will be sufficient though. Windows will be used both as an analysis platform and the place where you run most of your malware samples.
In regards to Linux, you will primarily be using the VM's for analysis or to provide target services for your malware samples. At this point you might be asking, what is a service for malware? A service in this context is just like any other IT service, such as an IRC or FTP service. Many types of malware use legitimate protocols such as FTP or IRC as transports for communication. While performing dynamic analysis, you want to offer up the services the malware is looking for, as a way to go deeper into your analysis. Pretty much any Linux will work well for these duties, as a result I recommend choosing the distribution that you are most familiar with.
Next I will cover recommended tools. The main classes of tools for dynamic analysis are process monitors, file monitors, and network monitors.
Process Monitors are used to monitor running processes on the system where you are running the malware. These tools tell you such things as memory in use, files open, CPU use, drivers used, and DLL's in use. Two of my favorite process monitor tools are System Internals Process Monitor and Process Hacker. Both tools provide very similar information, however I personally think Process Hacker does a better job than Process Monitor of showing you sub-processes spawned by execution of a file.
File Monitors are tools used to detect changes in files on disk. The primary use of file monitors as it relates to malware analysis is to detect changes to operating system files such as the windows registry or configuration files. The tools I generally recommend for this this task are Tripwire/AIDE and Capture Bat/Regshot. Tripwire and AIDE are general File Integrity scanners, they work by taking an MD5 has of all the files on a system, when a file changes they detect the change by comparing the new MD5 to the original. Capture Bat and Regshot work by taking an initial snap shot of the contents of specific files on the disk and comparing them to a later snapshot. Capture Bat and Regshot are both manual tools that require the user to take the first and second snapshots, and then require you to tell the tools to compare the snapshots.
The last class of tools I will cover are network monitors. Network monitors are tools that either capture packets on the wire or monitor TCP/IP sockets on the lcoal system. My favorite tools in this are are Wireshark and TCP View. Wireshark is a packet capture tool that runs in promiscuous mode on a network interface and captures all packets going across the wire. TCP View on the other hand sits on a local system and lists the TCP/IP ports that are open and the processes that have them open.
This post wraps up our basic analysis station configuration. In the next couple of weeks, I will show how these tools can be used to begin to perform dynamic analysis on sample malware. Stay tuned!
When considering what virtual machines to install, you must consider what tools you will be running and what operating system the malware is targeted at. For this reason, you will most likely end up with various Microsoft Windows installations along with a few Unix variants, most likely Linux. I will not cover installations themselves as there are plenty of instructions out there for installing operating systems. I will also cover a few classes of tools and make some recommendations for each category.
For your Windows VM's, I recommend having both a current Windows 7 install and an older Windows XP installation. The reason for 7 is that malware is starting to directly target Windows 7, as it is starting to gain critical mass in enterprise and general user environments. For most situations, Windows XP will be sufficient though. Windows will be used both as an analysis platform and the place where you run most of your malware samples.
In regards to Linux, you will primarily be using the VM's for analysis or to provide target services for your malware samples. At this point you might be asking, what is a service for malware? A service in this context is just like any other IT service, such as an IRC or FTP service. Many types of malware use legitimate protocols such as FTP or IRC as transports for communication. While performing dynamic analysis, you want to offer up the services the malware is looking for, as a way to go deeper into your analysis. Pretty much any Linux will work well for these duties, as a result I recommend choosing the distribution that you are most familiar with.
Next I will cover recommended tools. The main classes of tools for dynamic analysis are process monitors, file monitors, and network monitors.
Process Monitors are used to monitor running processes on the system where you are running the malware. These tools tell you such things as memory in use, files open, CPU use, drivers used, and DLL's in use. Two of my favorite process monitor tools are System Internals Process Monitor and Process Hacker. Both tools provide very similar information, however I personally think Process Hacker does a better job than Process Monitor of showing you sub-processes spawned by execution of a file.
File Monitors are tools used to detect changes in files on disk. The primary use of file monitors as it relates to malware analysis is to detect changes to operating system files such as the windows registry or configuration files. The tools I generally recommend for this this task are Tripwire/AIDE and Capture Bat/Regshot. Tripwire and AIDE are general File Integrity scanners, they work by taking an MD5 has of all the files on a system, when a file changes they detect the change by comparing the new MD5 to the original. Capture Bat and Regshot work by taking an initial snap shot of the contents of specific files on the disk and comparing them to a later snapshot. Capture Bat and Regshot are both manual tools that require the user to take the first and second snapshots, and then require you to tell the tools to compare the snapshots.
The last class of tools I will cover are network monitors. Network monitors are tools that either capture packets on the wire or monitor TCP/IP sockets on the lcoal system. My favorite tools in this are are Wireshark and TCP View. Wireshark is a packet capture tool that runs in promiscuous mode on a network interface and captures all packets going across the wire. TCP View on the other hand sits on a local system and lists the TCP/IP ports that are open and the processes that have them open.
This post wraps up our basic analysis station configuration. In the next couple of weeks, I will show how these tools can be used to begin to perform dynamic analysis on sample malware. Stay tuned!
Sunday, October 17, 2010
Intro to Dynamic Analysis Part 1
Curt has covered static analysis quite well and briefly mentioned dynamic analysis. At this point you are probably wondering what is dynamic analysis? Simply put, it is the act of running the code and observing what happens.
Infecting a system with malware from the wild can be very dangerous. A malware infection on your system can cause everything from destruction of personal data to bot infection, to performance degradation, and all the way to complete data loss. At this point you might be saying, “I already know it is dangerous, but I need to analyze malware.” Many of us in the information security world have that same need whether it is for job duties or personal research to learn about threats in the wild, my goal is to give you some insight into building a malware analysis lab environment to start your dynamic analysis.
The first technology needed to start your own malware analysis, and I feel the most important, is a virtual machine (VM) environment. A VM environment provides several advantages over a physical environment including, configurable resources, advanced disaster recovery, and isolation.
Virtual environments are based on the concept of resource sharing and reutilization. This means that once a virtual environment is installed onto a physical system, you will have the ability to configure as many VM’s as you want by slicing up the physical systems resources. In addition, the VM environment kernel, also known as the hypervisor, allows all the VM’s to share memory and processor time. In practical use, this allows a research to for example have multiple Windows installations on a single system with only 2 GB of RAM, where as in a physical environment the same 2 GB system would only allow one installation.
Virtual environments provide several advantages over physical environments when it comes to disaster recovery. The most important advantage for malware analysis is the ability to snap shot. Snapshotting is the ability to capture the system configuration a specific point in time and to gracefully rollback to a snap shot. The advantage here is that a malware researcher can run malware in a live environment to determine what the malware does, then once done roll the system back to a clean state. Before virtual environments researchers had to rebuild their lab machines using install media to go back to a clean environment.
The last advantage that VM environments provide us is isolation. The resource sharing and control of virtual environments also gives us the capability to easily isolate machines from one another. With this capability we can easily take a machine we want to run malware on an isolate it from other systems. In the case of a bot net, we could add a system to the virtual environment to simulate the command and control function, while only allowing the command and control and our original infected host to communicate.
There are several good VM tools available both commercially and free. Which one you should use is completely up to you. My only recommendation is to look at either VMWare’s tools or Sun’s Virtual Box, both tools support the use of .vmdk files which means that you can use many of the pre-built virtual appliances available on the net.
look for part two, in which I will go over setting up your malware analysis VM.
Infecting a system with malware from the wild can be very dangerous. A malware infection on your system can cause everything from destruction of personal data to bot infection, to performance degradation, and all the way to complete data loss. At this point you might be saying, “I already know it is dangerous, but I need to analyze malware.” Many of us in the information security world have that same need whether it is for job duties or personal research to learn about threats in the wild, my goal is to give you some insight into building a malware analysis lab environment to start your dynamic analysis.
The first technology needed to start your own malware analysis, and I feel the most important, is a virtual machine (VM) environment. A VM environment provides several advantages over a physical environment including, configurable resources, advanced disaster recovery, and isolation.
Virtual environments are based on the concept of resource sharing and reutilization. This means that once a virtual environment is installed onto a physical system, you will have the ability to configure as many VM’s as you want by slicing up the physical systems resources. In addition, the VM environment kernel, also known as the hypervisor, allows all the VM’s to share memory and processor time. In practical use, this allows a research to for example have multiple Windows installations on a single system with only 2 GB of RAM, where as in a physical environment the same 2 GB system would only allow one installation.
Virtual environments provide several advantages over physical environments when it comes to disaster recovery. The most important advantage for malware analysis is the ability to snap shot. Snapshotting is the ability to capture the system configuration a specific point in time and to gracefully rollback to a snap shot. The advantage here is that a malware researcher can run malware in a live environment to determine what the malware does, then once done roll the system back to a clean state. Before virtual environments researchers had to rebuild their lab machines using install media to go back to a clean environment.
The last advantage that VM environments provide us is isolation. The resource sharing and control of virtual environments also gives us the capability to easily isolate machines from one another. With this capability we can easily take a machine we want to run malware on an isolate it from other systems. In the case of a bot net, we could add a system to the virtual environment to simulate the command and control function, while only allowing the command and control and our original infected host to communicate.
There are several good VM tools available both commercially and free. Which one you should use is completely up to you. My only recommendation is to look at either VMWare’s tools or Sun’s Virtual Box, both tools support the use of .vmdk files which means that you can use many of the pre-built virtual appliances available on the net.
look for part two, in which I will go over setting up your malware analysis VM.
Subscribe to:
Posts (Atom)