System Forensics

All your artifacts are belong to me.

Zeus v2 Malware Analysis – Part I

So i’m new to this whole malware thing, but it’s pretty damn fun. I’ve been reading more and more about it over the past couple months.

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.


One of the first things I needed to figure out was which piece of malware to take a look at. I needed (wanted) to pick a piece of malware that’s pretty well known and well documented online. This way I can reference discussions about it and have a place to go if (read: when) I get stuck.

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.

Lab Setup:

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.


Dependency Walker
OllyDbg Plugins (AdvancedOlly, HideOD, OllyDump, and OllyScript)
ImmunityDebugger for those Python lovers
Resource Hacker
IDA Pro Free Version (Version 5)
ProcessHacker as a replacement for Procexplorer
listdlls command line

I also have all the tools provided in the Malware Analyst’s Cookbook and DVD book, which you can actually download from the Malware Cookbook GoogleCode website.

So now that my lab is configured let’s get started.

Simple Static Analysis:

Like I mentioned above I went online and pulled down a copy of Zeus v2.

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 submitted it to virustotal, which is a great site btw and right away you see 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:

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.

4. 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? [1]. 

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.

Some of the 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. [2] 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. [2] 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. [2] 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 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.

Behavioral/Dynamic Analysis:

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. [3] 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[4]

It appears to be possibly using the CurrenvtVersion\Run key for persistence, or at least part of its persistence.

HKU\S-1-5-21-[…snip…]-1000\Software\Microsoft\Windows\CurrentVersion\Run\{D[…snip…5}: “C:\Users\malware_win7x86\AppData\Roaming\Uhso\uron.exe”

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

At first it appears to go out to (IP:, 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 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, 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.


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.

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.

In either case I wanted to highlight a couple of the items I saw so you can get a feel for what it would be like to review such an artifact if you happened upon a live production system. This would be VERY helpful if you were performing an actual investigation AFTER the fact. We saw the artifacts being created on the fly. An individual that comes across a system infected with Zeus wouldn’t have that luxury. As you can see from the screen shot above you can see some of the created artifacts that you could investigate further. Likewise with extracting the registry hives and running regripper against them. I was running CaptureBat at Regshot at the time, so I sort of got those artifacts real time.

More to follow… Part II.


[1] Windows Authenticode Portable Executable Signature Format
[2] Practical Malware Analysis
[3] Windows Sysinternals Administrator’s Reference
[4] Dropbox link for Regshot –

Comments are currently closed.

9 thoughts on “Zeus v2 Malware Analysis – Part I

  • PatRafter says:

    Good work, Patrick. Hello lot of information for a first try. The exe being dropped has a random name to evade some of the silly AVs detecting malware based on the path and the filename. The exe dropped actually has extra information including computer name, unique ID, etc.

    The most interesting bit is decrypting the cfg file, which will be dropped if C&C was not blocked. Given that it’s Zeus v2, it uses RC4 and visual encryption (simple reverse cycling XOR) to code any network traffic. You can find which financial organisations the variant targets, what HTML/javascript will be injected to steal the online banking credentials, to lure 2FA customers, or to inject/manipulate transaction, etc.

    I expect you will get a top job if you continue walking down this avenue. Apply for some of the UK banks, for instance :)

    Keep it up!


  • @g0dmoney – In reference to your comment, your post never made it on here, but ill answer it as I saw you mention it on reddit. marco0009 is correct. I was able to grab the batch file and it does not actually try and shutdown the VMWare box. I’ve updated the post to reflect this.

  • g0dmoney attempted to ask this question, but for some reason it didn’t post:

    “I posted to him a question about how he determined the batch file was associated with something trying to detect and kill his VM, and he’s either deleted it or denied the post, which I find odd personally. It was a valid question IMO, I was just curious since I’ve never analyzed zbot, but perhaps its just something it’s done historically so its an assumption.”

    To answer this: Simply put, I misread the prefetch file, which is the main reason I post. I’m looking for feedback. I do this at my house and don’t have the option to ask co-workers or anything. I do this blind with no prior experience. These types of questions help everyone grow.

    Thanks for you post g0dmoney!

  • belvatrix says:

    Great job for your first analysis. It was very in-depth and informative. It really has me intrigued. I just started down this track as well and don’t do it in my current job.

    I’ll be following along and looking forward to your next report.

  • Hey, nice site you have here! Keep up the excellent work!

    Function Point Estimation Training

  • PE00 says:

    Really good! Thanks. I also like PeStudio ( to analyze PE Images.

  • phatik says:

    Hey, nice site you have here! Keep up the excellent work!

    Function Point Estimation Training

  • […] via the batch file, but it’s highly possible it is. I’ve included the .bat file from my original analysis so you can see what that looked […]