23 03 2012
Zeus v2 Malware Analysis – Part I
In either case I want to learn more about malware analysis (in turn also learning more about DFIR), and since I don’t do it at my current job, my next best thing is to perform the analysis at home. I also seem to have no life anymore.
It’s really the only thing I have in order to add a few resume bullets, so I can hopefully get into this line of work (DFIR/Malware) in the near future.
I decided on the first item on malwaredomainlist(dot)com. In this case it said, “Zeus v2 trojan”. I proceeded to download the .exe file and called it good.
First things first.
Here is the lab setup I am going to be using for the analysis. My actual VMWare lab is much larger, but I wanted to keep it smaller for learning purposes.
Some people say to use Linux as the physical host, but I picked Windows because I don’t know what a compromised Linux machine looks like. I have a decent idea what a compromised Windows box looks like so I find that although “Linux is traditionally more secure, it’s technically not if I can’t tell if/when its compromised”. If I don’t know what “normal” is then it’s not really possible to spot something “abnormal”. When you look at it that way I don’t really consider it more secure.
In addition to some anti-virus stuff (Panda and Norton) running, I also configured my Windows firewall on the host machine to prevent In/Outbound communication to/from .2.x. I also have some excluded download locations and what not where I store some of the malware that i’m looking at. All and all it’s isolated, and im not doing any personal searching, etc. on that box. I used fake usernames, etc., installed a minimal amount of products, and used fake email addresses to register some of the tools I loaded in the event that some of them stored any information in the registry someplace I wasn’t aware of.
So yeah, there is my personal justification as to why I picked Windows as my host.
The purpose of the REMnux3 box will be to host INETSIM for services, run Wireshark, Honeyd, etc. Obviously the Windows boxes will be used to analyze the malware and will also act as “carriers”.
Here is a quick list (in no specific order) of the tools I have pre-installed on both Windows machines. I have shortcuts to my desktop to make it easier. I suggest you do the same. These tools are just ones that I see referenced multiple times in various books/blogs that I have read/looked at. These are all free and Google will provide you will all of them. If you can’t find something let me know and i’ll see if I can help you out.
OllyDbg Plugins (AdvancedOlly, HideOD, OllyDump, and OllyScript)
ImmunityDebugger for those Python lovers
IDA Pro Free Version (Version 5)
ProcessHacker as a replacement for Procexplorer
listdlls command line
So now that my lab is configured let’s get started.
Simple Static Analysis:
Next I proceeded to take a md5 hash (50ea80fd625cfbb549d4cfd60056268a) of the exe file I downloaded.
You can see that here:
Once I had the md5 I decided to run a few checks online to verify that I did indeed have a copy of Zeus.
I then checked the Zeus tracker site and got some better information, and also was able to verify that it was indeed a Zeus file.
After pulling the md5 and verifying that we did have a copy of Zeus I decided to go ahead and fire up PEview. Portable Executable View (PEview) allows you to view the structure and content of a 32-bit PE. It supports EXE, DLL, OBJ, LIB, DBG and some others. It’s a free tool and from what I have read a pretty good one.
Here are a few items we can add to our information bucket that we got from using PEview:
1. It was compiled on 2011/02/26 Sat 13:37:24 UTC (or that’s what they want you to believe). The malware was reported on 3/13/2012, so it is possible that its a valid compile date.
2. It appears to be packed by UPX (“Ultimate Packer for eXecutables”) so we can use this information when we attempt to unpack the exe file.
3. It’s machine description is for i386.
Let’s look at some other items now.
Let’s start up Dependency Walker and see what functions they are calling. According to the Dependency Walker website, “Dependency Walker builds a hierarchical tree diagram of all dependent modules. For each module found, it lists all the functions that are exported by that module, and which of those functions are actually being called by other modules.”
So you can see some of the functions that are going to be imported by Kernel32.dll. Normally you would see more of them listed if the file wasn’t packed. Let’s try and Unpack this using the UPX tool since we saw from PEView that it was packed using UPX.
So here we are running UPX against our ssl.exe file and attempting to unpack the file. It says it Unpacked the file so let’s start up Dependency Walker again and see what we can’t see for functions this time around.
Here is what Dependency Walker shows after we unpacked the ssl.exe file:
As you can see (sort of) there are now 22 Functions listed vs. the original 6 when the file was still packed. Now we can actually take a decent look and what’s being imported. This was a similar case for the Advapi32.dll and User32.dll, but I didn’t list all of them to conserve space.
I thought this was interesting as it indicates the possible use of a signed certificate of some kind, which would make sense given that we saw the Certificate Table while looking at the output from PEview. Other than that I didn’t see too much in the strings search. Most of the other strings that came up we have already seen in the output of PEview and Dependency Walker.
I did see a few references to, “StarNet Communications Corp.”, “Tee Gaily Baron”, and “Offend Sin Baron”.
I took a look at StarNet Communication’s website and they claim, “X-Win32 remains as one of three leading commercial PC X server solutions along with Hummingbird Exceed and Attachmate’s Reflection X.”
At this point my static analysis skills pretty much lack so I don’t know what else I could get from this section without diving into the debuggers, etc., but before I do that I am going to move onto the behavioral side of things and see if I can find anything useful.
At this stage I think I am ready to perform some behavioral analysis and actually run the piece of malware in my lab so I can get a better idea of what it does. I am going to go ahead and revert back to a clean VMWare instance just in case something was run while I was using any of those tools above. Nothing should have, but I want to ensure a clean slate.
I am going to start off with a few tools running before I execute the malware:
I am going to start up Procmon and then hit Ctrl-E, which will unlink it (pause it), and then Ctrl+X, which will clear the screen of any previous activity. This will reduce the amount of activity until I am ready to execute, which will make filtering the output much easier.
I am also going to start up Procexplorer and Regshot. I will simply watch process explorer to see if I can spot any activity after running the piece of malware. I find it useful at this stage (right before execution) to set up VMWare to capture a video, which enables to the capability to go back and look at process explorer in more detail since processes start/exit rather quickly in front of your eyes. I will use regshot to snap a registry shot before and after I execute the malware to see what has changed in the registry.
The last tool I have running is apateDNS, which allows me to see what (if any) DNS requests are being made after I execute the malware. I have the DNS server pointed to my REMnux3 machine, where I also have Wireshark and INETSIM running.
Here was some interesting activity from Process Explorer:
So in this fist image we wee Process ID: 2936 – ssl.exe. The Purple/Violet color within procexplorer indicates a packed image meaning that it might contain executable code in compressed form, encrypted form, or both.  I guess this would make sense if it was a packed executable by way of UPX. Process Explorer uses heuristics to help identify this.
It’s also creating a New Object PID 2892 (depicted in Green Highlight). In this case it’s uron.exe.
I also mentioned that I was running RegShot before/after I executed the ssl.exe file. Rather than take up a page of blog space I went ahead and posted the entire contents of the reg shot here. 
And the manufacturer for this startup item is none other than, StarNet Communications Corp., of which we saw reference to in the strings search we did.
After running this malware a few times I have noticed that it changes process names, and also the exe files that it creates. The only thing I can think of was that it changes based on time? I'm not sure. When I revert back to a clean VMWare nothing else would have changed on the system except the times of day. I guess this is something we can look at in more detail later? Maybe it's because I am running it in a VMWare machine? Possibly some type of anti-VMWare process that's run to make things harder to analyze? It doesn't change location, just names so maybe it's intended to change. In either case that's something we will have to look at later.
Let's do some more looking.
I was curious what cmd.exe actually was doing so I went ahead and looked in the Windows Prefetch directory and noticed some interesting things.
UPDATE: 27MAR2012: I was able to get a copy of the .bat file after walking the exe through via OllyDbg, and grabbed it before it was deleted. Here are the contents:
As you can tell it doesn't actually do anything to the VMWare instance like I had mentioned previously. I have since removed that section of text. It only appears to delete the file that was originally executed.
Thanks to g0dmoney for asking the question and marco0009 (via reddit) for also confirming that it does not actually modify anything with VMWare, which lead me to go back and take a closer look. Again, this is the reason I post. I want/need feedback to grow. I appreciate it, and others do as well. - If your comments don't get posted let me know. g0dmoney mentioned he tried to post, but it never posted. I don't have it setup for me to approve them. They just post... Email it to me and I can post it worst case....
I noticed that it created another .exe file when reviewing the regshot output and decided to go take a look at it:
C:\Users\malware_win7x86\AppData\Roaming\Uhso\uron.exe (The exe name is different because I ran this at two different occasions, and it changes its name again). In the picture, it's called umadm.exe, but it's stored in the same location, just different folder\file names. This appears to be a fake certificate. Maybe this relates back to the Certificate Table entry in the PE Header.
Network wise I am not seeing too much internally.
I was running inetsim and had it configured to resolve this particular address, but after the initial hand shake I didn't see much else. I'm new to INETSIM, but I configured the static DNS to be dns1.nsdnsrv.com and also attempted to feed static.htmls to the request, but maybe there is some kind of checksum going on, because I kept getting a RST when it attempted to pull down the static.htmls file.
Again, i'm pretty new to this so I can't say for sure.
In addition to the above I saw multiple requests to ocsp.verisign.com, which makes sense since we did see some reference to Verisign in the strings search we did within BinText.
I was going to include this in Part II, but after doing all the memory forensics it just didn't "fit" so I decided to come back here and add it to Part I. It fits this section better.
Here is the command I used to extract the $MFT and build the body file:
After extracting the body file I went ahead and moved the bodyfile over to my SIFT Workstation where I proceeded to run mactime against it to make it more "human readable".
Here is what some of the output looks like:
I didn't really see anything we didn't already know while reviewing the $MFT. After reviewing the output of Regshot, CaptureBat, Procmon, etc. everything was pretty apparent.
More to follow.....in Part II.