Thursday, December 30, 2010

Sample Analysis 1: Dynamic Analysis

For this portion of the analysis, I began by loading and taking a snapshot of my windows XP VM. The snapshot will allow me to revert later to a clean state.

Next I started up Regshot to take a baseline of the system. For this I used the option '1st shot and save."

I then started Process Explorer, TCP View, and Capture Bat and launched the malware specimen. The below screen shots will describe the results of each tool.

Process Explorer shows us that this piece of malware spawns the processes; mshta.exe, cmd.exe, at.exe, at.exe, etc.The malware quickly spawned and terminated several at.exe processes over and over.


TCP View shows us the mhsta process going out on UDP port 1052

Capture is a command line tool that that runs and displays changes made to the system as they happen. It is a tool that you must be actively monitoring at all times or output to a text file to detect changes made. In this case it caught several changes including the malware application launching a cmd prompt and deleting the same cmd prompt.

Next I used Reg Shot to take another shot of the VM. I then compared it to the first shot to reveal changes made. This showed several interesting things, including the malware adding itself to Internet Explorere as a Browser Helper Object (BHO).


While continuing to explore this specimen, the program broght up a very official looking window 'labeled Microsoft security essentials alert," that reported that process monitor was a trojan. A similar message appeared when I attempted to run task manager. The malware would not let either utility actually load. This may fool some users, but in this case I do not have security essentials installed on my virtual machine. This malware also terminated Process Monitor, for me how very helpful ;-) The screen shot below shows this very official looking window.


Next I decided to see what the AT scheduled tasks were all about. The various AT jobs have mshta.exe go out to crazyraccoonshow.com with 21 different jobs. Each job is set to run at different times, but on the same daily scheule. So, next I decided to try one of my favorite utilities, Fileinsight. Fileinsight is a graphical utility that is free from McAfee labs that includes a light weight debugger, script editor/viewer, and a graphical version of wget for windows.
Fileinsight was unable to get any results from the site. The web sites seem to to be either looking for specific mshta properties or the site has already been taken down, as I was unable to pull any content.

Since I already tried to pull the web code with File Insight, I next loaded up wireshark on my VM and my virtual machine copy of REMnux. I like REMnux a lot due to the fact that it has most analysis tools for Linux bundled into a pre-built environment.
Note: REMnux is a custom Linux distribution maintained by Lenny Zeltser, available at zeltser.com.
After starting Wireshark, and starting two of AT tasks, I began to see a lot of DNS lookups to various hosts such as update.celtro.dns1.us. Since this still did not tell me anything particularly useful, I set my windows VM's gateway to the IP address of my REMnux machine and then turned on the fakedns script on REMnux. I then went back to Wireshark and noticed that now that the malware was able to resolve DNS entries, it was attempting to communicate outbound with HTTPS to the same URL's, only the destination ports were cycling upward starting at 1045 and incrementing up by 1 each time it did not get a response. I also noticed that the malware was attempting to create another session using a random TCP port to port 80. This was interesting, but again didn't yield a whole lot of information, so next I setup a netcat listener using the command: nc -l -p 80
For those unfamiliar with Netcat, it is a generic listener. In this case the command I issued launched netcat and set it to listen (-l) on TCP port 80 (-p 80).
I did this to see if this traffic was really encrypted or if it was just using the source port pf 443 as a way to hide in normal traffic. I continued to wait to see if the malware process would eventually reach my listener. After noticing nothing in my netcat window, I decided to connect to my listener via telnet. My netcat listener was in fact receiving my telnet transmission. After several minutes I was still not seeing data on Wireshark. At this point I realized that the malware was doing a series of HTTPS requests followed by a series of HTTP requests.
Unfortunately since I was unable to decode what this particular malware was doing in it’s network communications, I stopped my analysis. I had found out that this particular malware was a fake AV tool that probably holds your system for ransom. This was sufficient information for me. Another thing to note on the behavior; this malware did not seem to be very persistent as I was able to terminate it without it automatically restarting.
At this point, our dynamic analysis is essentially over, if you wanted to keep your results to further analyze the logs, etc., you would need to copy the log data from your analysis tools to your host machine. I suggest copying the text and pasting it to a new document on your host machine, as transfering any files off of your infected VM is a risk. After you have obtained any needed data, you should revert your VM to your snapshot to ensure that you are back to a clean state.





Sunday, December 5, 2010

Sample Analysis 1 Static Results

The following is the static analysis details that I found with the Sample Analysis 1 binary that we posted previously. If you have done static analysis of this file as well, follow along and see if you found similar details. We attempt to get as detailed as possible, but we do have day jobs so there may be things inside the malware that we do not discuss. This is meant more to analyze the sample until we are happy that we understand the basic functionality of the malware.

Sample Analysis 1 Report:

MD5: 49d7498e4543027046795d076e47f1ac
Fuzzy hash:12288:AHlawHGMpk7lZWnIoWbq47TxC1+HK12XsfQJZUM0SsoSmjCbcZRcHPM:AHlnH47leIA4Y1D2XkmZ5dOaCHP
Virus Total Results: Show us 37 out of 41hits as a malicious file. Most of the descriptions call this fakeAV, surprise :)
Bin Text: When opening the file in BinText, it gave an error saying there was a problem reading the string resource file. The file may be compressed or in a non standard format. Looking though the strings that did show, didn't reveal much, though I did see references to the Delphi programming language. We also see some information mentioning use of the registry.

When I dropped this file into PEiD, I see the possible reason for BinText to complain. It looks like our sample is packed with UPX.

I then tried to unpack this just using the standard UPX package available from Sourceforge. The command line used is upx.exe -d <filename>. This appeared to unpack successfully. I did want to note here that when you unpack a UPX packed file it just unpacks the copy of the file you ran it against. This means you no longer have the packed version. If you want to save the packed file for some other reason, make a copy before you do this.

Now I put the file back into PEiD. Now we see Borland Delphi 6.0 - 7.0. This looks like we now have removed the packing.


Just for kicks, I want to dump this unpacked file back into BinText to see if there are any new strings to be seen. This time when I dropped the file in BinText, no errors! There are a ton of readable strings now! This sample seems like it has a ton of options. Looking through the strings, one major thing I notice is there are a lot of functions with GUI context such as OnMouseActivate, OnMouseDown, OnMouseUp,  and PopUpMenu.

I also see a lot of references to web browser. This application seems to be very GUI driven. There are still some obfuscated strings in the unpacked version so at this time, I'll take the file into Ollydbg.

This sample has some protection schemes even though we have unpacked it. I have been jumping around in Ollydbg in order to find some way to bypass them. I have attempted to use the HideOD plugin. I also noticed some SEH calls that would terminate the application. To fix these things I told Ollydbg to ignore exceptions. You do this by going into the Options menu, then choose Debugging Options. Click the exception tab. Put a check in all of the options. At the bottom, you will see a section called ignore also following custom exceptions or ranges. Click the Add range button and enter 00000000 as the beginning and FFFFFFFF as the ending address. Your screen should look like the following:

For the HideOD plugin, we navigate to the Plugins menu, HideOD then choose options. Enable all of the options. You screen should look like the following:

 You will want to restart Ollydbg for this to take. Once Ollydbg is open, you should be able to get a little further into the program.I started stepping over instructions and keeping an eye on the stack for interesting data. At memory location 403CE6 I found myself stuck in a loop. I looked through the loop and found TEST EBX, EBX followed by a JMP SHORT. If this is equal, then it will jump. I changed to stepping into (F7), until this test. At that point I double clicked the EBX register in the registers window. For those of you who aren't familiar with Ollydbg, this is the window on the upper right of the screen. I change the value of EBX to 00000000. This got me out of the loop.

After stepping further into the code, I noticed the ASCII text of Microsoft Security Essentials Alert on the stack.
After some time I kept finding myself at 7C92A2F5. This was decrementing EAX then jumping if not zero. I noticed that EAX had a value of 1 so I change this to 0. This seemed to get me past that loop as well.

This seems to have allowed me to get further along. While stepping into instructions I noticed a file created called agtyjkj.bat in the stack section. This file contained the following code:

:dsfgdfh
del "C:\Documents and Settings\installer\Desktop\adobeflashplayerv10.0.32.20.exe"
if exist "C:\Documents and Settings\installer\Desktop\adobeflashplayerv10.0.32.20.exe" goto dsfgdfh
del "C:\Documents and Settings\installer\Application Data\agtyjkj.bat"

This code looks like it tries to delete the original file and if it doesn't exist any more then it removes the bat file. While in that directory, I noticed another new file named hotfix.exe a quick hash of the file shows that it's the same as our original but renamed.

This also goes to show that sometimes even when you are doing static analysis, it might be more helpful to do a little dynamic analysis as well. This is especially true when you have a sample like this that has protections and obfuscation.

I decided at this time to dig through the stack section in Ollydbg to see what else might be learned from there. For those of you that might not be familiar with Ollydbg this is the window in the lower right hand side. I found a reference to at.exe as can be seen below:

If your not familiar with at.exe, this is the command line equivalent to the task scheduler. Depending on how this is called, these items may or may not show in the Scheduled Tasks folder in the control panel. If they don't, you can see them by issuing the at command on the command line. It turns out, that these are showing in the Scheduled Tasks. It looks like this sample created quite a few (possibly 72 tasks).

Looking at these tasks, we see mshta.exe being used to call some random urls. Most look like  http://funnyraccoonshow.com/gspwjg.php?fjfnsl=815400370451178. MSHTA.exe is used to allow execution of .hta files. It looks like these tasks are set to run just about every hour. Without going further in dynamic analysis I would assume this is where the html comes from for the fake AV application. It looks like our sources at Virus Total were probably correct in their categorization.

That is about all I have time for today. I hope you saw from this analysis that it isn't always necessary to know assembly to statically analyze code. This is one of those samples where dynamic analysis would probably reveal more easier, but we see that we were able to come to the same conclusion just by looking at the code. Sure I used a little assembly to get out of some loops, but there were no ground breaking techniques done just simple register modification thanks to Ollydbg for allowing us to do so.

You can look for Jamy's post on what he found from dynamic analysis to come soon. In the mean time, we are trying to come up with a way to get these samples to you guys if the sites are taken down before you get them. I hope to have a solution before the next sample post.