Trojan.Clampi is one of the hottest malware around, and as such, received a fair amount of media coverage, as well as technical reports describing some of its functionalities. As part of our ongoing blog series, we will be discussing interesting and rarely presented aspects of Clampi. Today, we’ll introduce an important aspect of Clampi: the network communication.
First of all, if you’re not familiar with this malware already, Clampi is a Trojan horse whose main purpose is to steal private information: user passwords, login credentials, software licenses, credit card numbers, bank account information, etc. Note that Clampi’s operations are performed by helper modules, downloaded by the main executable, and stored in the Windows registry.
Once the threat is installed on a computer, it connects to one of the gateway servers listed in the registry value “GatesList” (located in the subkey HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Settings), initially set up during the malware installation.
These so-called “Gates” gateway servers run the Nginx Web server, and they collect the information that Clampi gathers from its compromised host. Connecting to TCP port 80 and adhering to the standard HTTP protocol makes it easy for the threat to bypass firewall software and other restrictions that may apply in corporate networks.
The communication model is fairly simple. The client queries the server using a POST request that contains stolen information or asks the server “What do I do next?” The server then sends a standard HTTP/200 response.
Clampi’s POST requests are in plain ASCII, and have the following structure:
- The [OPERATION] field is a single character in the set (‘i’,’a’,’c’,’d’,’u’).
- The [CLIENT_ID] field is 16 characters long, and contains a unique, per-session, random ID identifying the compromised computer.
- The [DATA_CHUNK] contains the payload. It is encoded with a variation of the Base64 algorithm. It is also encrypted using the well-known Blowfish ECB symmetric encryption algorithm with a 56-byte key—the longest key usable by Blowfish. Using reverse engineering techniques, we were able to decode and decrypt the payload.
This is illustrated in the following screenshot, which shows a standard “initiate” packet.
Initially, the client sends two queries, “o=i” (Initiate) and “o=a”, to set up the connection with the Gate. The Initiate query contains a chunk of 256 bytes, most likely the encoded session key used for Blowfish encryption later on. The “o=a” operation is more obscure.
Interestingly, these two operations occur only once per session. If the connectivity with the gateway breaks (for example, because of a connection timeout), an “o=u” (perhaps Update) operation will be sent by the client. The Blowfish key exchange will not take place again, even if the client talks to a different gateway than when the key was established. This also applies to the Update payload. It looks as though either the gateway servers work in a peer-to-peer fashion, exchanging client information, or a higher-level parent server is in charge of coordinating the existing sessions taking place between the gateways and their clients.
After these two exchanges, an encrypted tunnel is established. From then on the data chunks will be encrypted using Blowfish. Fortunately, we were able to recover the key to decrypt the traffic. It is worth noting that the data chunks, once decrypted, contain the MD5 hash of the payload they carry. This prevents a third party from tampering with the packets.
Typical exchange then consists of “o=c” (Contact) and “o=d” (Data) queries. A Contact query does not contain a data chunk, but only comes with the client ID. It simply tells the server “I’m alive, what do I do?” The server’s answer to a Contact query contains a four-byte ID that identifies the transaction that’s about to take place as well as code that instructs the client what do next.
In this example, the connection ID is 0x41E. The following code instructs the client to tell the server what malicious modules it has loaded. The client will reply with a Data query, indicating it has no module loaded except the ‘KERNEL’, probably a codename for Clampi’s main executable:
Typically, the server will then instruct the client to load other modules. If the client doesn’t have them already, they will be sent in a latter HTTP response. After a while, you may see an exchange like this:
The “present modules” list seems bigger this time. In fact, these modules contain the core of Clampi functionalities, which will be detailed in upcoming blog posts.
However, having the modules loaded doesn’t mean they’re active. It seems there are certain types of server responses to instruct the client to execute a module. For instance the SOCKS module, which acts as a socks proxy, is activated during the following exchange:
The server asks the client to activate the SOCKS module (response #171 to query #169). The client obeys and sends the response #182, which contains the value 0x95B9. It is the listening port the SOCKS module is listening to! The server’s reply—all zeros—terminates this transaction.
Stolen data is sent in Data queries as well. For instance, passwords and login credentials stolen by the PROT module will be sent in a Unicode, binary-ASCII encoded form such as:
Online banking login information is sent in a similar fashion. In the instance below, the data posted to the banking site is intercepted from inside the browser (before SSL encryption) and sent to the gateway server with other metadata items such as the Referer, the Host, or the HTTP method:
H=Referer: https://online.bankof[REMOVED].com/ib/securehtm/boc-ib/ebanklogin.htm\r\nAccept-Language: en-us\r\nContent-Type: application/x-www-form-urlencoded\r\n
By using standard HTTP and strong encryption, coupled with a modular approach of the client’s functionalities, Clampi’s communication model is simple, yet very efficient.
In an upcoming blog, we’ll be discussing each of the modules in more depth. One of the first will be the “LOGGER” module used by the threat to monitor banking sites.