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:

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 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.

No comments:

Post a Comment