The begining of spring seems to be an unsuccessful period of the year for cybercriminals in Eastern Europe. There is recent news referring to a neutralization of a group of hackers by joint cooperation between the Security Service of Ukraine with the Federal Security Service of the Russian Federation (FSB) on the web. These hackers are responsible for the infamous Trojan called Carberp.

Due to this recent information, we are allowed to say that Carberp was as a mainstream Trojan that monitored the environment of infected computers and exploited remote banking systems. It was a robust modular malware that improved its capabilities by drive-by-downloaded dynamic libraries – plugins. It was not only successfully grabbing money from victim's bank accounts but also the attention of security experts both in an industrial and an academic sphere (an example of a paper). Therefore there are plenty of references on the web considering the methods of a system invasion, protection by polymorphic outer layers and a persistence of the Trojan. We will try to fill in some gaps in the picture.

Carberp started its progress approximately in autumn 2010. Later in spring 2011 it was split into two main branches regarding the form of HTTP requests. The first one used the RC4 cipher to encrypt data exchanged with C&C and it posted requests in the form:

This one faded away along with the arrest of cybercriminals in March 2012. The second one was based on RC2 cipher and it generated hits with avast! shields in the wild during the last weeks. Let's see how it talked with C&C.

Communication protocol

A typical HTTP post looked like

with a content of the form like this:

where ‘kfq’ is a randomly generated string which is concatenated with the equality sign and an encoded message. Unsafe characters in the encoded message are escaped with the percent sign. Let's write this particular example after decoding:

and let's extract the first 4 symbols after the first equality symbol concatenated with the last 4 symbols (ignoring the tailing equality symbol ) as a string. It is used as a cryptographic salt for RC2 decryption and denote it szSalt, i.e. szSalt = ‘u/FPbTeN’. Then the proper encrypted message equals (denote it szEncMsg):

After the decryption on the server-side it would be read like ‘botuid=wtfuck0780E8ABE9244C0B4’ where ‘wtfuck’ is a constant encrypted in Trojan’s body and ‘780E8ABE9244C0B4’ is a particular hash of victim’s environment. Every sample of Carberp contained another constant - a key, denote it szKey, e.g. szKey = ‘mt19YrKTaSH3kCVA’.

Decryption of the content is performed in the following steps:

Step 1) Extraction of the proper encrypted message and the variable szSalt. Transformation of ‘+’ to ‘>’ and ‘/’ to ‘?’.

Step 2) Decoding of szEncMsg to a buffer au8EncMsg_Debase64

Step 3) Decrypting of the buffer au8EncMsg_Debase64 to a buffer au8EncMsg_Debase64_DeRC2 using RC2 with the salt szSalt and the key szKey

If the downloaded content is an encrypted executable or a configuration file then there is another step:

Step 4) Decrypting the buffer au8EncMsg_Debase64_DeRC2 using a custom algorithm decryptBJB(..) that has already appeared in early stages of Carberp. A magic string "BJB" is in the header and it is followed by a key length, a key string and a main ciphered data.

One of the early requests going to C&C is the wish for available plugins. After a successful connection a list of plugins is saved in "%AppData\<hash sequence>\wndsksi.inf" in an encrypted form. Ignoring the first 20 bytes and using the mentioned decryptBJB algorithm with the key "GDlet64E" one could get something similar to:

This list shows only a subset of plugins available for the bot. The following diagram estimates the evolution of available plugins and the time when they appeared for the first time:

Detailed analysis of plugins

Plugins from early stages of development are well known (miniav.plug, stopav.plug, passw.plug) and the yellow ones seemed to be obsolete in recent versions of the bot. File ddos.plug exports the only function called ‘StartHTTP’ and contains a list of various HTTP referrers and domain names. The name of plugin indicates it's potential in a distributed denial-of-service attack.

The orange group contains cyberplat.plug, sb.plug (evolved from early sbtest.plug version) and ifobs.plug that try to exploit Cyberplat, iFOBS and Sberbank payment processing systems. Last month a download of a java archive called AgentX.jar together with an encrypted data file rt.ini ((two steps of decryption one of which is RC4 with the key "123%esr2#221@#" ) was implemented in the Carberp module. They are dropped into the application directory of an e-banking system called IBank. The plain ini file could look like (observe that C&C servers of the bot):

The archive is a successor of previously used archives patching a Java code on the fly called Agent.jar, AgentPassive.jar and AgentKP.jar. They all had a potential to fraudulently interact with a victim's payment processing. A text document uid.txt containing id of the running instance of the bot was created and declared a sign of infection.

The light blue group represents utilities enhancing remote spying activities of the Trojan. File vnc.plug is an executable that enables remote access to an infected computer via remote framebuffer protocol (RFB). Additionally, it contains an embedded library inj_x86.dll (inj_x64.dll respectively) which provides a user mode rootkit functionality that masks processes started remotely (on "secret_desktop") on victim's desktop:

The green group is all about the plugin bot.plug which has most of the functionality of the main Carberp module in the form of a dynamically linked library exporting three functions: SetBotParameter, Start and SFFD (the latter injects its own code into explorer as the main module does). It is produced by a generator called Bot builder:

After a request of its download it is stored in an encrypted form in %AppData% directory for later use. It could be remotely reactivated by a command installfakedll from a C&C server which leads to a drop of fake.dll into to the Internet Explorer program directory under various confusing names (e.g. sqmapi.dll, browsui.dll). A function of this library is the decryption of stored bot.plug followed by calls of bot's exports Start and SFFD.

One of the files additionally requested is called config.bin. It is a set of JavaScript web injects performing an attack to various internet banking systems in Russia and Ukraine. Injects are triggered by particular masks in a web browser (example of a bank targeted is in the bracket):

• 'banking.pivdenny.com' (Pivdennyi)
• 'ibank.svyaznoybank.ru' (Svyaznoybank )
• 'online.rsb.ru' (Russian Standard Bank)
• 'bsi.dll?T=RT_1Loader.Load' (OJSC Nordea Bank)
• 'ifobsClient/ifobstoday' (iFOBS Online Banking System, OTP Bank Ukraine)
• libertyreserve (LibertyReserve)
• privatbank (PrivateBank Ukraine)

To demonstrate a concept of injects on the mask "google.com" just observe the process of its creation in the following steps: Chosing data before and data after a desired replacement of HTML code and filling the space with own code, then displaying how a source code appears in the configuration file and finally how it changes a content of a web page:

Carberp on Android

At the end of 2012, three malicious Android applications were mentioned in connection with Carberp (nicknamed Caberp-in-the-Mobile by security researchers) that tried to extend it’s fraudulent activities to mobile devices (a triple represents application name, it's MD5 hash and a detection by avast! engine):

These apps posted HTTP requests in the form:

with the domain that was also used as C&C by the branch of Carberp using RC4 encryption. The conclusion is that these apps are probably not connected with the bot we have analyzed.

Sources

Finally MD5 of some selected samples with the detections of avast! engine:

Acknowledgment

Sincere gratitude goes to my colleague Jaromír Hořejší for cooperation on this analysis.