Sign up to our newsletter
The latest security news direct to your inbox
The Carberp cybercrime group was one of the first groups to make massive use of specialist malware designed to target remote banking systems and fraud operations against major Russian banks. Many members of major Carberp groups have already been arrested (All Carberp botnet organizers arrested), but the Carberp malware family is still active and evolving. ESET Virus Radar statistics show the regions most affected by Carberp infection during the last month in the map below.
The region most affected by the Carberp family is still Russia. If we look at the history of detections we see that the time when the Carberp group was most active was in the spring and summer 2012. After mass arrests in the summer of 2012, the botnet is not stopped altogether but detections go down.
Carberp still holds the NumberOne position in banking fraud incidents in Russia and Ukraine. In this blog post we focus on the latest code updates to the bot and its additional plugins.
With the latest Carberp dropper we detected the technique for code injection into a trusted process characteristic of Power Loader (Gapz and Redyms droppers based on Power Loader code). During the first steps of execution the dropper tries to open one of the shared section objects and appends shellcode to the end of the section from the following list:
The next steps are the same as the technique used by Gapz except for small changes in the code already described in one of my previous blog posts (Win32/Gapz: steps of evolution).
The final stage is to inject code into the trusted system process explorer.exe in order to bypass security software detection and execute the following infective steps from trusted process address space.
This technique is not new and the use of Shell_TrayWnd injection was already described on some closed Russian forums a few years ago. But the first time we’ve detected it in the wild was with the Win32/Gapz dropper based on Power loader code.
I’ve already discussed java code modification for banking clients for another trojan family – Win32/Spy.Ranbyus – at the end of December 2012 (Win32/Spy.Ranbyus modifying Java code in RBS Ukraine systems). Ranbyus modifies the JVM (Java Virtual Machine) at runtime in order to track the code execution of banking software. Carberp modifies banking software on java using the open source library Javassist (Java Programming Assistant), making possible bytecode manipulation on the fly (during the runtime process). Carberp modifies java bytecode in one of the most popular remote banking systems, BIFIT’s iBank 2.
During analysis of a recent sample of Carberp I found the following strings mentioning iBank 2 client software and interesting wording referring to patching the java code:
After playing with the active client for iBank2 on the infected machine an additional module AgentX.jar (detected as Java/Spy.Banker.AB) was downloaded. After successfully downloading the Java/Spy.Banker module the next step would be to download the Javassist library. Java/Spy.Banker is a special component of Carberp for modifying payment documents on the fly.
The decompiled java class for modifying the code of the iBank2 client looks like this:
After modifications to iBank2 the attackers can control all payments made with this banking software. BIFIT’s iBank2 does not check the integrity of its own code and after modification the remote banking software is still working correctly and can transfer money. But in this case money transactions are sent to Carberp cybercrime group.
Java/Spy.Banker has functionality for bypassing one-time password (OTP) security checks. The decompiled java class for bypassing OTP is presented here:
Decompiled code for confirmation fraud payment with OTP looks like this:
AgentX is not a typical malware component and does not modify the system itself but uses the legitimate library for code modification. It’s hard to recognize malicious activity in AgenX.jar without manual analysis of this module. At the time of writing AgentX.jar module have very low detection rate.
In the last week information has appeared about the TeamSpy targeted attack on government services and companies (CrySyS Lab report). TeamSpy uses modified components of the TeamViewer software. ESET has already been detecting malicious software using TeamViewer as a backdoor component since 2010 (Sheldor-Shocked). Win32/Sheldor has been used by the Carberp cybercrime group for manual money transfers on infected machines since 2010. The Carberp group also uses other legitimate software for remote access to infected machines. In the following table we present all the legitimate software used by the Carberp group and found on C&Cs as plugins.
The use of legitimate software by cybercrime groups as the way to get a remote connection to an infected machine is really hard to detect as unequivocally malicious activity. In the case of Win32/Sheldor and Win32/RDPdoor some modifications are made to the original components but Mipko and Ammyy are used unmodified. In this scenario it would be inappropriate to detect this legitimate software as malicious, but this software has been really active in many banking fraud cases in the last year.
In this blog post I have summarized the latest changes in Carberp cybercrime group activity. The most interesting changes relate to Java/Spy.Banker (AgentX.jar), and most popular banking software in Russia and Ukraine is susceptible to exploitation through java code modification. Another interesting observation is the increasing use of legitimate software as backdoor components for gaining remote access. It’s difficult to balance effective detection in these cases against the possibility of false positives, especially as attackers change the software they use for remote access every few months.
Aleksandr Matrosov, Security Intelligence Team Lead
SHA1 hashes for analyzed samples:
Win32/TrojanDownloader.Carberp.AM – 41b34ac34a08a7fda4de474479f81535bf90bd70
Java/Spy.Banker.AB (AgentX.jar) – 5a5b9a4f844872e36db872fab3b70f55a9bd4dd5
Ammyy.plug – 23ced1aeb7f0e2d43dadcd1a0e9e1a3eadf36732
Author Aleksandr Matrosov, ESET