The Dexter trojan
Dexter is a well known trojan, it is oriented to steal credit card information in the POS systems. Despite samples of its earlier versions were spotted in December 2012, a new version known as Dexter v2 or Stardust was discovered on December 2013. Among the Stardust features there are: locate the tracks of credit card’s magnetic stripe into memory, and key logging functions. In this article we are going to analyze the communication techniques between the trojan and its command and control (c&c) panel.
Stardusts employs POST requests to send the data. The POST parameters are encrypted with using XOR with a key is created during the malware installation and then encoded using base64. However, the XOR key is sent within the POST parameters with just plain Base64, so it could be considered as simple data obfuscation. To each request, the server replies in a cookie,that may contain commands to control the trojan (update, uninstall, force a memory check, etc).
The function, that creates the request body, collects certain data from the machine and generates the POST string:
The parameters are added to request_body by using the function encode_param(char *param, char *value, char* request_body), which encodes the parameters values with XOR and Base64, adding the cyphered string to the request_body. At last, the XOR key coded only using Base64, is attached in the val parameter.
The XOR encoding function shows design flaws, despite it is enough to hide the strings, it is not enough from cryptographic point of view.
The generated encryption key is 5 bytes long, however the use of the XOR function reduces the effective length to just 1 byte. The main loops are the following:
string[i] ^= xor_key[j];
Due to the commutative property of the XOR, the inside loop could be expressed as:
string[i] ^= xor_key ^ xor_key ^ xor_key ^ xor_key ^ xor_key
What is the same as:
xor_value = xor_key ^ xor_key ^ xor_key ^ xor_key ^ xor_key;
string[i] ^= xor_value;
That, in practical terms, changes the length ot the XOR key to a 1 byte value.
Back again in the communication analysis, in the case of the strokes.log file exists, which is generated by the keylogger is decrypted with the same xor_encode function, but this time a special key located within the file’s first 4 bytes. Once the file has been decrypted, the request parameter ks is generated and encoded with the same XOR key used in the rest of the parameters.
The first time it communicates with the dropzone adds the parameters unm,cnm,query and spec with the user, host name, OS version and architecture (“32 bits” or “64 bits”) of the infected machine.
After send the request, it reads the response cookie, cyphered in the same fashion as the request and process the reply looking for commands.
It may send an empty reply using the string: ‘#$’
The accepted commands for the malware are:
- checkin: forces the credit card data submission
- scanin: forces a memory scan looking for credit card data
- uninstall: uninstalls the trojan
- download: downloads a file from an specified URL
- update: downloads a new version of the malware and installs it
The usage of cookies to send the answer from the server, is an original trick to hide the trojan communications during a dynamic analysis or while inspecting network traffic. Even through the POST parameters should be enough for an IDS to detect the presence of the trojan.