Blogs & Stories

SpiderLabs Blog

Attracting more than a half-million annual readers – is the security community’s go-to destination for technical breakdowns of the latest threats, critical vulnerability disclosures and cutting-edge research.

The Dexter Malware: Getting Your Hands Dirty

A very interesting piece of malware that targets Point ofSale systems has recently surfaced in the malware community. As a guy whofrequently reverses malware that targets card data (aka. Track data), thiscaused me to take notice. Before I jump into the really interesting bits of themalware, I'd like to offer a few links to those that have already taken a lookat this stuff. Seculert specificallywere the ones that originally discovered, and named, the Dexter malware.

So if you either haven't gotten a chance to read the abovearticles, or simply would like a refresher, here's what the malware does in anutshell.
  • Injects itself into iexplore.exe
  • Ensures the iexplore.exe process restarts in theevent that it is manually stopped
  • Ensures persistence via writes to the 'Run'registry key
  • Scrapes track data through a very common method
  • Has a command and control structure with aremote host

That last bullet in particular really caught my eye. I can'tremember the last time I saw a piece of malware that targeted Point of Salesystems that had a nice C&C structure to it. And that is where our storyreally begins…

So in looking at the underlying assembly of the malware, itbecomes apparent that this sample is planning on talking to as many as sevendifferent domains. It's also apparent that it's going to communicate over HTTP,via a POST request. Looking at the traffic that gets generated, we seesomething similar to the following:

Screen shot 2012-12-12 at 4.13.18 PM

Now you might be thinking to yourself, "Geez, that's a lotof …stuff". And you'd be right. So lets break down that nice blob of datathat's being sent over the wire. In total, we see the following ten differentvariables:

  • page
  • ump
  • unm
  • cnm
  • query
  • spec
  • opt
  • view
  • var
  • val

I'm going to focus on the last variable ('val') first, mainly because it's the easies to decode, and because it's one of the mostimportant. We see that 'val' has a value of 'ZnJ0a2o=', which I'm sure you'veall guessed by now is Base64 encoded. Once decoded, we see this value change to'frtkj'. You might be thinking that this is also garbage, but it is, in fact, akey that is used to encode the remaining text in the POST request.Specifically, we see the following occur when each variable's data is decoded:

  1. The data is Base64 decoded
  2. Each character in the decoded string is xoredsequentially against each character of the key we previously identified. InRuby, it looks something like this:


This results in the original content.

Know how this works, we can whip up a quick script to decodethe entire string.

Screen shot 2012-12-12 at 4.49.02 PM

We can now easily determine when a number of the variable discoveredactually contain.

  • page: Mutex string
  • ump: Track data
  • unm: Username
  • cnm: Hostname
  • query: Victim OS
  • spec: Processor type
  • opt: Unknown
  • view: List of all running processes on thevictim
  • var: Some unique string. Appears to be constantfor this sample
  • val: Random key that changes every time themalware restarts

So at this point we can see how the malware is communicatingoutbound to its master. However, that's only half of the puzzle. How is themalware receiving commands?

Well, the answer to that question comes in the form of theresponse Cookie. Specifically, the malware will set the 'response' cookie usingthe same technique (only in reverse) that we just witnessed. So basically, theserver takes the key from before, XORs each byte of the string against eachcharacter in the key, and Base64 encodes it. Dexter will then parse this data,and look for one of the following variables:

  • update- (Updates the malware with the specifiedargument)
  • checkin: (alters the delay between times themalware attempts to make POST requests to the master host)
  • scanin: (alters the delay between times the malware scrapes memory for trackdata)
  • uninstall (completely removes the malware)
  • download- (downloads and execute the specified argument)

I should point out that each variable has to start with thecharacter '$' in order for the malware to look at it. We can see how thesevariables are checked in the following decompiled code:

Screen shot 2012-12-12 at 9.48.26 PM

So at this point we can get a pretty clear picture of howthis malware operates over the wire. The details of how this malware has gottenon these victim machines is still unclear, but please ensure that you aretaking the necessary precautions to protect your system, with a specialemphasis on Point of Sale boxes. Because really, nobody wants to becomeDexter's next victim.

Recent SpiderLabs Blog Posts