Rombertik is a Trojan horse that’s been making apocalyptic headlines of late. All the column inches generated were mainly due to reports suggesting that the malware is specifically targeting security researchers by “trashing the user’s computer if it detects it’s being analyzed.”
This, of course, sounds like a doomsday scenario for security researchers like us so we took a closer look at this threat to see what all the fuss was about. What we discovered is that Rombertik is not actually targeting security researchers at all. Instead, the destructive payload is a rather crude and buggy implementation of a draconian digital rights protection mechanism designed to prevent unlicensed use. Intrigued? Let’s find out more.
Rombertik is actually a newer version of an underground crimeware kit known as Carbon FormGrabber or Carbon Grabber for short (detected by Symantec as Infostealer.Retgate). It was created by a commercial criminal enterprise. The product is sold on underground forums to cybercriminals who don’t have the skills to create their own malware.
Figure 1. An earlier version of Carbon Grabber (aka Rombertik) advertised for sale on a forum
The problem for those providing Carbon Grabber through the underground business model is that they encounter the same issues of piracy and unauthorized use as any normal commercial software business does. So what is the malware provider to do?
Legitimate software vendors often add protection mechanisms that prevent the software from being used without a license, but that’s usually the extent of the “damage” caused to digital pirates. In the cybercrime world, things are a bit more cut throat.
The primary purpose of Carbon Grabber is to steal information and provide back door access to a compromised computer. The destructive routines contained in this new version of Carbon Grabber can wipe the Master Boot Record (MBR) and encrypt most file types on the compromised computer. When the destructive routine is completed, it renders the computer unusable and can potentially cause an irrecoverable loss of data.
Much of the discourse has been about the destructive routines and their implied effects on the computers compromised by it, but the destructive functionality is not something that regular customers of Carbon Grabber have access to. Instead, this code is set up to only spring its trap if the Trojan detects that a user is trying to tamper with its code to make it do something it wasn’t licensed to do. Let’s take a closer look at how this nasty surprise can be triggered.
Setting a trap for script kiddies and n00bz
Each copy of Carbon Grabber is built and licensed for a particular user. It is built to only contact a predefined command-and-control (C&C) server as specified by the paying customer. It does this by embedding the address of the C&C server within its own binary code.
For any novice cybercriminals who have managed to get a copy of the malware and would like to use it without paying, they could, with just some basic skills, identify the C&C address and attempt to change it to point to another address of their choice by simply hacking the binary file itself.
However, if they were foolish enough to do this, they would unwittingly trigger the destructive protection mechanism. This is probably intended as punishment for the attempt to subvert the malware and explains why the Trojan will display the following message after the destructive payload is triggered.
Figure 2. Message from the makers of Carbon Grabber to would be pirates
So this is what happens if you try to subvert Carbon Grabber and fail. But is there a way for somebody to do it successfully? As it turns out, the protection is not water tight and there is a way around it because of an implementation error on the part of the malware developer.
Avoiding the trap
Let’s take a closer look at how the protection mechanism works and by doing that, we can see where the error lies. Examining the binary of the malware, we can see that the malicious payload has three resources in its PE file body which are defined as the following:
Resource ID=3EE (size=0x494)
RSA public/private key BLOB pair, version 2, CALG_RSA_KEYX type
Figure 3. RSA key BLOB from first resource
Resource ID=3E ( size=0x100)
RSA encrypted C&C server URL
Figure 4. RSA encrypted URL from second resource
Resource ID=3F0 (size=0x00F)
String "/don1/gate.php"
Figure 5. URL path contained in the third resource
The private portion of the RSA key is used to decrypt the second resource which becomes the following URL:
“www.x[REMOVED]s.org.in”
Figure 6. Decrypted URL in memory
The threat hides the hash of the RSA key in the compiled time field of the PE header. This hash value is compared with the hash of the key being used. If the hashes match, then everything continues as normal. However, if the script kiddie tries to replace the RSA key with a different one, the resulting hash will not match the hash stored in the compiled time field and this will then trigger the destructive payload. From our analysis, this is the only scenario that will trigger the destructive payload.
The code below shows the hashing loop in action:
Figure 7. The hashing loop and the trigger for the destructive payload
So we know now that changing the RSA private key to a different key will not work because it will trigger the destructive payload. How else can an attacker subvert this mechanism? If the corresponding public key was available then an attacker would not need to change the RSA private key. They could just leave the private key in place, encrypt a new URL with the public key, and place the newly encrypted URL in the correct resource (Figure 4) and everything will work fine.
Leaving the keys under the digital doormat
Let’s take a closer look at the provided RSA key data in the resource and see what else we can find.
Figure 8. A closer look at the first resource containing the public/private key
As we can see, the first resource is actually the PUBLICKEYSTRUC structure. The first byte of this structure indicates the type of data that it contains. In this case, the first byte has a value of 0x7 which indicates the blob contains a public/private key pair.
Is it possible that the malware developer made a basic error and included the public key needed to crack the protection mechanism within the threat binary itself? This is like leaving the house key under the door mat. We checked if the public key corresponded to the included private key and it turns out that it does! We were able to encrypt a different C&C URL using the public key and decrypt it using the included private key. This means that if somebody wanted to repurpose a copy of the Trojan without paying for a new one, they could do so using this method without triggering the destructive payload.
Punishing the cheapskates
So based on our analysis, we don’t believe that this functionality is designed as an anti-analysis feature to thwart the efforts of security researchers. Instead, this looks like it is the malware developer’s way of punishing the naive cheapskates who may be trying to use this software for free. There’s no denying the damage that this threat can cause, it really is very destructive, but this is no indiscriminate wiper Trojan.
Mitigation
Symantec and Norton products protect customers against Rombertik through the following detections:
AV
IPS
- System Infected: Infostealer.Retgate Activity 2