Skip Navigation
BlackBerry Blog

A Study In Bots: Dexter

/ 03.14.14 / 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.

POSGrabber

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.

Detection

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.

 

dexter-01

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.

Dexter-02

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

CasinoLoader

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. 

Dexter-03

 

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.

Dexter-04

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.

Dexter-05

 

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 (https://sqlmap.org/), an open source SQL injection tool, is the best candidate for this.

Dexter-06

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.

Dexter-07

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:

Dexter-08

Dexter-09

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 https://download.vulnhub.com/botchallenges/MurderingDexter.zip or here https://www.dropbox.com/sh/c8upyofkw23rm6k/Z-ZBkSb_1v/MurderingDexter.zip 

- Brian Wallace AKA @botnet_hunter

Samples

f092d0574c8d1a7ec0cee4b0378f1af3
0d670dffb324e71c1ab0e8c379485d21
fbb5c4897660aaadb2939f6107e7fffe
a577b713802bb9e66ef61a5329d989b4
aab22d3b625ce47256fc47587e1a7cb6
7fc81f2d74909a0b5a58d198f5dd84bd
075da801c47aa5a84c2d7038430f3342
024a647984c7a8e00e0d3bee45d3eaf2
d631d7001316140ae975da38311c8580
72b3b5a40e547c1b50964b3c0bf0261e
da6683959d5735c68944c75eef73887a
e8210b08b359784ae6605242b3e2407a
7448bf7136c5e81305c1d1f668902807
59a461e2dfac26b792f28f7d5d80b024
742fe13ef5fc4472f8aa8b8e0659e18e
3b946b4c5195383e3333d93870b891dc
347babe73944f5c99304344c4db2a53d
9eee5677a479ea82f07309a2f69128d8
e7426b51a805d27437786792f7aefe35
d4db9fbd8458ae4c169d2ac7f2624717
4a92416a8132568000ae808ad2d38211
018b5ab3082149587486d1b190c4f4ba
27b31aa6616ad2f57fb04b49cfb39b8c
683b8c7b9c69f83d58fc2a543d0e0ccc
0f57029353e105db9dc4f6026354e7bc
6f2d0a3383122acee38b24a222f93ab2
457dcb37c45556505338dd9186813012
da98e6c0d497ba45aa6566d2eaabd2b5
270ff20fdb72f5f60ca33812f9965c69
5ce8a7ba22f42f7742c5cbc3574374a4
8e632d17dac996de69b56fb6dfa3c54d
1a08124fd4ab3d13cdb225ed9e00b6ad
f85e592e7ab26a5b9400905e8a23b7ee
7aeef8ee3e37b53eda7447b197f01ffe
eb96b357ce0f7b9ce6be007d24deeb0d
d1a156c63dc0217402b0eb767d78e950

 

Brian Wallace

About Brian Wallace

Lead Security Data Scientist at Cylance

Brian Wallace is a data scientist, security researcher, malware analyst, threat actor investigator, cryptography enthusiast and software engineer. Brian acted as the leader and primary investigator for a deep investigation into Iranian offensive cyber activities which resulted in the Operation Cleaver report, coauthored with Stuart McClure.

Brian also authors the A Study in Bots blog series which covers malware families in depth providing novel research which benefits a wide audience.