« Back to Blog

A Study In Bots: Dexter

By Brian Wallace

During our session Hacking Exposed: The Art of Deterrence at RSA Conference 2014, Stuart McClure and I demonstrated various Art of Deterrence tactics against the Dexter botnet. Dexter is just one of many pieces of malware released recently that targets point of sale (POS) systems and is designed to scrape—and exfiltrate—credit card information. It does this by reading the RAM of processes it has access to, looking for any string that matches the credit card track format and then verifies whether or not the string matches the Luhn algorithm. Lastly, it uploads the information to a command and control server using simple encoding/encryption.


The malware installed on the POS endpoint is referred to as POSGrabber. It’s designed so that it can run as an executable or be injected into another process. After it runs for the first time, it will move itself to a randomly named location in the user’s AppData directory. Next it injects itself into an iexplore.exe process. This makes HTTP communication much less conspicuous.

The RAM scanning process is quite simple. It first enumerates all running processes. After excluding a list of predefined processes, it opens a handle to each process and reads chunks of RAM looking for strings of credit card track information. This format is very well defined. Credit card numbers are then checked to see if they match the Luhn algorithm. This algorithm is used when generating all credit card numbers, and it is likely the malware authors are trying to avoid obtaining fake credit card numbers.


Now that the source code to the POSGrabber has been released, it's very likely that someone will try to write a new version (or versions) of Dexter in order to avoid AV signature detection. Since detection methods used in CylancePROTECT, CylanceV and other Cylance products are not signature-based, we expect to detect Dexter even if changes are made to the underlying code. Our Infinity engine actually detected every sample we located on public and private malware feeds, scoring them as threats with 97 - 100% confidence.



Detection using CylanceV version 2.0 - talk to a Cylance expert for a demo!

As a researcher and botnet hunter, I don’t stop at mere threat detection. I want to be able to pull information from these binaries and hunt down the command and control panel. One could accomplish this by detonating a sample in a sandbox or virtual machine, but here at Cylance we prefer to avoid relying on “sacrificial lambs”. Since certain malware will not function correctly if packed, we can potentially gather configuration information from the binaries statically. This can be done with an open source framework I am developing called BAMF (Botnet Attack Modular Framework). The bamfdetect tool in this framework can statically analyze POSGrabber binaries and extract the command and control hostname and URI.


This framework is experimental but module development is open to the public. It currently can be found here.

Command and Control Communications

POSGrabber communicates with the command and control panel over HTTP. The communication consists of POSTs to a script called gateway.php by default.

All data uploaded to the command and control panel is encoded, and a large amount is “encrypted”. The encryption is trivial to reverse as the key is set by the bot in each POST. A simple XOR-ing is applied to data before it is encoded using this encryption key.

The encryption key is set in the “val” POST parameter and the credit card data is set in the “ump” parameter. The “ump” parameter is not in every query to the command and control as it’s only present when new dump of information is available for upload.

Responses from the command and control panel, which are commands, are stored in the Set-Cookie response header. The commands are encoded and encrypted with the key POSGrabber set in the request. There are five basic commands that can be sent from the command and control server.

  • “scanin” updates the interval that POSGrabber scans for credit cards
  • “checkin” updates the interval that POSGrabber calls back to the command and control panel
  • “uninstall” uninstalls POSGrabber
  • “update” downloads and updates POSGrabber version
  • “download” downloads file at URI and executes it


The command and control panel itself is named CasinoLoader. There have been a few recent updates to the CasinoLoader panel that I haven’t obtained yet, so this analysis is not on the most up-to-date version. The latest version’s updates seems to mostly be interface related.

The panel has three basic features; bot management, dump management, and file upload. The user interface in the version available to me is rather drab. 



The “Dumps Viewer” page shows the credit card tracks. “Bots Control” allows for setting commands for the bots as well as displays information about the bots. The “File Uploader” allows for uploading of files which can then be downloaded by the POSGrabbers.


The upload page allows for any file to be uploaded, including PHP files. This can be exploited by someone with authentication uploading a PHP script which can then be executed by accessing the script location with a browser.

Exploiting Dexter

It should come as no surprise to anyone, but I love finding vulnerabilities in botnet panels. Dexter was no exception. I released a Metasploit module in February 2013 that exploits Dexter to obtain full remote code execution. While this exploit works on the version it was developed for, it may not work on more recent versions. This exploit leverages an SQL injection technique to dump credentials from the database, then automates the login and upload of a PHP file.

There are multiple SQL injection vulnerabilities in the panel. When reviewing the source code, the most obvious is a blind SQL injection vulnerability in gateway.php.



The decoded/decrypted value of the “page” POST variable is immediately used in a SQL query unsanitized. No value from this query is directly returned to the client, so it must be exploited blind. There are a few tools to exploit blind SQL injection, but none I know of will support encrypted and encoded parameters without some configuration. SQLMap (http://sqlmap.org/), an open source SQL injection tool, is the best candidate for this.


In order to base64 encode parameters, we need to use the base64encode tamper script. For the encryption, we could write our own tamper script, but in this case we don’t need to. Since the encryption is set by the bot, we can set a null encryption key making the encryption an identity function.  This key is “AA==” when base64 encoded.

For a SQL injection with output returned, we need to attack the following code which appears later in gateway.php.


With SQL injection, we can return any data we want to extract through the same interface used to send commands to the bots. Here is a proof of concept:



When we base64 decode “JHRlc3Q7Iw==” we get “$test;#”, the value we injected.  We can use this exploit to dump the entire database—from credentials to bot information. A proof of concept script can be found here.

Vulnerable Virtual Machine

In general, I’ve found that information is much easier to retain if it can be applied in the real world. Not everyone is a self-proclaimed botnet hunter, and it is not suggested (or recommended) that anyone try to exploit live botnets. For these reasons, I have put together another vulnerable virtual machine, which allows for aspiring botnet hunters and security enthusiasts to try their hand at attacking a Dexter command and control panel. It can be downloaded here http://download.vulnhub.com/botchallenges/MurderingDexter.zip or here https://www.dropbox.com/sh/c8upyofkw23rm6k/Z-ZBkSb_1v/MurderingDexter.zip 

- Brian Wallace AKA @botnet_hunter