I wanted to pick a piece of malware that's pretty well known and well documented online. Sample will be Zeus v2 - 50ea80fd625cfbb549d4cfd60056268a.
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 small(er) for learning purposes.
The purpose of the REMnux box will be to run INETSIM, run Wireshark, Honeyd, etc.
Obviously the Windows boxes will be used to analyze the malware and will also act as "carriers".
Tools (not a definitive list)
- IDA Pro
- Dependency Walker
- ImmunityDebugger for those Python lovers
- Resource Hacker
So now that my lab is configured let's get started.
Simple Static Analysis
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 submitted it to virustotal, which I don't suggest you do in your work place.
You see here it's a 31/43 detection ratio.
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:
- 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.
- It appears to be packed by UPX so we can use this information when we attempt to unpack the exe file.
- Authenticode signatures are specified in the Certificate Table entry in the optional header data directory, which this is. Authenticode is a digital signature format that is used to determine the origin and integrity of software binaries. So I guess this file contains a signed certificate to lead us to believe its authenticity and consider it a "trusted" binary? .
Let's look at some other items now.
I am looking at the Section .rsrc (Resource) IMPORT Directory Table, which is a section within the PE file that contains all the resources for the module/executable to run. In this case it's saying that Kernel32.dll, Advapi32.dll, and user32.dll are required by the ssl.exe file that I downloaded previously.
Why are these dlls interesting?
- Kernel32.dll - Provides functionality to access/manipulation of memory files and hardware.
- Advapi32.dll - Service Manager and Registry.
- User32.dll - Displaying and Manipulating Graphics.
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.
Functions of interest
Kernell32.dll - GetModuleHandleA, which can be used to locate and modify code in a loaded module or to search for a good location to inject code.  GetModuleFileName, which will return the filename of a module that is loaded in the current process. Malware can use this function to modify or copy files in the currently running process.  OpenMutexA, which opens a handle to a mutual exclusion object that can be used by malware to ensure that only a single instance of malware is running on a system. Basically they don't want multiple instances running at the same time.  NOTE The letter A at the end of the functions indicate that the function accepts ASCII string parameters. You might also see a W, which means it accepts wide (unicode) character strings.
Advapi32.dll - GetUserNameA and GetAuditedPermissionsFromAclW could point to some type of Enumeration attempt. Another couple interesting ones are CreateServiceA and CreateProcessAsUserW. CreateProcessA gives us a pretty good idea that this program will create a process. This is something to keep and eye on when we finally get to executing the program. ProcExplorer might be a good tool to see this activity.
User32.dll - Some of the functions of interest are GetDesktopWindow, GetKeyboardState, etc., which indicates that this might have some kind of keylogging or screen capturing capability.
After looking at Dpendency Walker I went ahead and opened up BinText to perform a string searche against the ssl.exe file.
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.
In this image we see a new object being created, PID 2956 WinMail.exe We also still see that ssl.exe and uron.exe are still alive.
Lastly, we see WinMail.exe ending (red = Deleted Objects). We also see ssl.exe and uron.exe as deleted objected, but we also see PID 2784 - cmd.exe being created by ssl.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. It appears to be possibly using the CurrenvtVersion\Run key for persistence, or at least part of its persistence.
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.
This was kind of interesting, because the TMP2275A93c.BAT file was created, and then later executed on the machine. It's also deleted after it executes from what I can tell.
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 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 random). 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. At first it appears to go out to dns1.nsdnsrv.com (IP: 188.8.131.52), which actually matches the information I got from the Zeus tracker.
The full request URI is: http://dns1(dot)nsdnsrv(dot)com/static.htmls
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.
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.
That's pretty much all of the network information I was able to obtain by running it within my enclosed network.
File System Forensics (by way of $MFT)
I decided to go ahead and execute Zeus on my VMWare Windows 7 machine and then extract the $MFT by way of Sleuth Kit.
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.