Posted by: realsecurity | August 28, 2008

Analysis of a dll injector – Trojan.Win32.Inject.dnz

For my first real foray into reverse engineering, I decided to pick something small and easy to analyse.  Even though this level of analysis isn’t needed for such a simple piece of malware, it makes for a great sample to learn on.

The file is t.exe (MD5 – E276F2C49D194DEF764A383482ECBD03).

Virus total results

Anubis report

Threat Expert report:

Sunbelt sandbox report: didn’t produce any results.


We first start by checking to see if the file is packed to obscure it’s contents. According to PEiD, the file is not packed.

To confirm this we can quickly check the file’s ascii strings. As shown below, several strings are visible. The strings that begin with a period are the different segments that reside inside the executable. In the screenshots I am using the strings shell extension from the iDefense malware analysis pack.

Already we’ve found some clues, it references a dll called shell32.dll and a CLSID

Here’s a nice definition for CLSID

As we continue to look through the file, several more interesting strings pop up, including an IP address, more dlls and a function called WriteFile.

We’ll now start looking at the exe in a debugger (ollydbg).


After loading the file in olly, it’s easy to spot calls to windows API functions as they are highlighted in red. shell32.dll is referenced at 004022E5. The GetTempPathA call seems pretty self explanatory, so we’ll set a breakpoint on it (F2). To run the program until the breakpoint, hit F9.


We then step over (F8) the instruction and GetTempPathA will be executed. To single step into a instruction, use F7.


This function has populated the variable ConcatString with the location of the currently logged in user’s temp directory. The StringToAdd variable contains the name of the dll we saw in the strings output. Can you guess what lstrcatA does? Again, pretty self explanatory, this function concatenates two strings together.

Executing lstrcatA results in the following being stored in the EAX register.

Slightly further down, we encounter another similar block of code which is preparing another file


Continuing on in the code, CreateFileA (self explanatory) is called with as the file name. This will create a new file called in the below directory


With the file created, data will now be written to it. The following writes the full path to t.exe into the file using the WriteFile function.


We may now navigate to the directory and view the file’s contents just to double check what happened.

Looking back at the debugger, we’ve reached the end of the first code brach. There are 3 more code branches (CALLs) that get executed before the process is terminated (ExitProcess)

Stepping into the first call at 402387 opens a registry key and writes the value shell32.dll to it. InprocServer32 executes a dll on system startup. This is how the malware will start on system boot.


The 3rd call (at 00402392) is also interesting, it checks for the SeShutdownPrivilege which allows the logged in user to shutdown or reboot the PC. If the logged in user has this privilege, the malware will wait 120,000 miliseconds (2 minutes) and then call the the ExitWindowsEx function with EWX_REBOOT as the argument.  This will restart the machine.


So far we have learned: t.exe writes two dlls to the user’s temp directory. It creates a new registry key that allows shell32.dll to start on boot, and then restarts the machine. Simply looking at this piece of malware using behavioral techniques might be frustrating to an analyst since their VM would magically reboot without any notice.


We now have a new file to analyze, shell32.dll. In order to debugg a dll with olly, we need to fool the debugger into thinking the dll is an exe. Joe Stewart goes over how to do this in one of his articles. With the dll loaded, we may begin debugging.

One of the first things it does, is look at the following registry key. This key contains the path to execute your default web browser and then executes it shortly after using WinExec.



With the browser running (IE in this case), the malware creates a new running thread inside iexplore.exe using CreateRemoteThread. This thread will execute shell32.dll.


We can look at the newly loaded IE process and view the dll’s it has running. There are now two shell32.dll files, 1 legit and the second is our malware.


Now that we understand that the file gets injected into IE, we can better understand the following critical series of instructions. shell32.dll must get run on two separate occasions. The first occurs when the computer is rebooted and the malware is first loaded. The second is when the same dll is injected into IE. Each instance results in different braches of code being executed.

The following instructions are what governs which branch of code to execute. Whenever the malware is executed, it will reach the lstrcmpiA function at 00401823. It compares the string2 “explorer.exe” against string1 “shell32.dll”. When a system first boots, explorer.exe is one of the first files to load, as it is related to the Windows GUI. Explorer.exe will be the process that executes the dll for the first time via the CLSID described above. When the computer first starts and shell32.dll is run, both string1 and string2 will be equal. The comparison function at 00401829 will return 0 (the strings are equal) and the jump at 0040182C will be taken. When the dll is loaded into IE, the calling process will not equal “explorer.exe”, a non 0 result will be returned and the jump will not be taken.

When running this dll in a debugger, these two strings will never be equal. In order to follow this branch of code, you would need to set the value of the EAX register to 0 manually before executing the jump instruction. When EAX is 0, the dll performs it’s injection routine into IE. When EAX is not 0, the dll performs it’s download routine.


When the strings do not match (shell32.dll is called by iexplore.exe) the code flows to where we see the malware try and connect out. The malware creates a socket, gets an IP and calls the connect function. This portion of code will connect us to (not visible in the screenshot below, the IP gets populated at instruction 0040149B). Unfortunately the site is down as of this writing, so I can’t see the whole interaction. You could always redirect this traffic in a lab and run netcat to intercept the communication, but I’d already spent enough time on this piece of malware.


Lastly, the malware connects using send and receive functions from WS2_32.dll and presumably write the new data onto the machine’s drive.


This was quite a long article for my first post, but I wanted to go into more detail than less. We were lucky that this malware was not packed as that would have made analysis much more difficult. Most of this information could have been gathered from simply looking at it’s strings, but that would not have given us real insight into how it does what it does.

Lessons learned:

The sandbox results do not tell us about the attempted connection to This is probably because the site is down and the sandbox sites could not reach out and communicate. In several malware investigations, I have run across machines that have been compromised with malware for so long that the C&C they were communicating with had been shutdown. If the malware wasn’t actively trying to call home, reversing the binary might be the only way to find out who the compromised machine WAS talking to in the past. An investigator would need this information to look through firewall/proxy logs to better understand the situation.

Now that we know about SeShutdownPrivilege, we can be on the lookout for this function referenced in other malware. When performing a behavioral analysis, take into consideration that your machine could reboot itself. Set a breakpoint on ExitWindowsEx if present to prevent the reboot.

Downloader trojans can download code from hostile sites using a variety of methods, this is simply one of them. With the dll being injected into IE we know that this activity would be allowed through a corporate proxy. The malware is essentially browsing the Internet just like a normal user.

Lastly, when performing an investigation we’ve learned to look for strange dll’s injected into common processes, such as IE.



  1. VERY interested. Not a programmer myself by career, but always digging down into my OS’s, and trained since I was 15..

    I will follow the path you have set out here learn, much clearer than anyting i have found outside of private (an very expensive) seminars.

    I am VERY interested in I have a spare and old machine running Windows server 2003. Its my mps player. Its ports were cut down to a total minimum. To do that I accessed some ex-colleagues in a major countrie’s DOD. I was given the doc, and managed to cut everything down to less than 3 ports open, then shielded them by a very good software firewall, IE was never used except for update. It has always been kept up-to-date on a weekly basis.

    Now I am supposed to have an “infection” on this machine. On reboot it tries to connect to But there is nothing in any scan I have tried (Kasprksy, AVG, Boclean running) that tells me I have an infection. HJT is clean, nothing unknown. IceAword shows what I would expect, the firewall hooks(Comodo). But some how, on this inocent little machine, some bastard has managed to find a way n. Connections are zero, the entrie domain of to is excluded from internet transactions. But it keeps trying, and I can’t see from where. But I WILL get it. I WILL find the fucker who did it, and more importantly, I will find out how to protect the 353 machines I live with better.

    Thanks for the post dude. You are obviously way beyond me in coding, but you gave me a huge leg up. Most of the real gurus seem to target the corporate networks and megabucks. Most fail, but they leave a trail behind of people who don’t believe.

    Mine is MY network. I rent it out for a pittance (cost plus) to local bands and smal companies. It a good deal for them and I get to learn a lot. 10 years on no, 3 OS’s.

    Thanks! I’ll get the bastard one way or another. I had a company in Iran who rented space for a fashion company. So I checked all their jvs for problems (only jvs allowed on my sites), it was clean.

    Then I found a leak going upstream, found the site that was drawing it. They were distributing KP (CP CHild-porn) from one of my servers and hadn’t paid a cent! So I wnt to windows update and the firewall updateand fixed that.

    You are so ahead of the game that my minor problems are “under the horizon”, but your musings on-line have helped my brain re-engage. Now I don’t groan and hang my head down nad say “fuck it, who cares”. I jump up and say to myself “last post you made is for her friends” Then I look at the calendar and realise i graduated 2 years ago. It’s OK.

    I’ve changed from monitoring 0 to monitoring 65%

    Thanks a bunch. I got a lot of reading to do now!

    Real meaty post. Even though you introduced it as a taster.

    God bless!

    When I find out who, I’ll hang the bones on the door as I leave!

  2. The content has been a valuable piece of information.
    Three cheers!!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: