The pseudo-HTTP protocol uses any proxies discovered by the HTTP proxy monitoring thread or added by the adminka command. The backdoor also searches for proxy configurations to use in the registry at HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings and for each profile in the Mozilla Firefox configuration file at %AppData%\Mozilla\Firefox\\prefs.js.
Source Code Of CARBANAK Backdoor Discovered
Recently, 64 bit variants of the backdoor have been discovered. We shared details about such variants in a recent blog post. Some of these variants are programmed to sleep until a configured activation date when they will become active.
In all Mandiant investigations to date where the CARBANAK backdoor has been discovered, the activity has been attributed to the FIN7 threat group. FIN7 has been extremely active against the U.S. restaurant and hospitality industries since mid-2015.
"Having source code sounds like cheat-mode for malware analysis. Indeed, source code contains much information that is lost through the compilation and linking process," said FireEye security researchers Michael Bailey and James T. Bennett.
In July 2018, there was a false alarm that the Carbanak code leaked on the now-defunct Mal3all hacking forum. After further analysis, it was revealed that the leaked source code was the RatoPak malware, which belonged to the Corkow group, a different cyber-crime gang that targets banks and operates on the same model set up by Carbanak way back in 2014.
The source code of a backdoor associated with the prolific FIN7 threat actor has emerged on VirusTotal alongside builders and other tools from the group, FireEye security researchers reveal.
To analyze the code, which is in Russian, a script that would create a prioritized vocabulary list was used (available on GitHub), which resulted in a 3,400+ word vocabulary list. This allowed the researchers to read comments in the code and helped with the translating of the Carbanak graphical user interfaces found in the source code dump.
The source code analysis revealed that, while in simpler backdoors a single function is in charge with receiving commands from the command and control (C&C) server and passing them to the correct function, Carbanak is completely different. It uses the Windows mechanism called named pipes to control threads, processes, and plugins.
In June 2017, we published a blog post sharing novel information about the CARBANAK backdoor, including technical details, intel analysis, and some interesting deductions about its operations we formed from the results of automating analysis of hundreds of CARBANAK samples. Some of these deductions were claims about the toolset and build practices for CARBANAK. Now that we have a snapshot of the source code and toolset, we also have a unique opportunity to revisit these deductions and shine a new light on them.
The POSLogMonitorThread function is only executed in Sample A, while the blizkoThread function is only executed in Sample B (Blizko is a Russian funds transfer service, similar to PayPal). The POSLogMonitorThread function monitors for changes made to log files for specific point of sale software and sends parsed data to the C2 server. The blizkoThread function determines whether the user of the computer is a Blizko customer by searching for specific values in the registry. With knowledge of these slight differences, we searched the source code and discovered once again that preprocessor parameters were put to use. Figure 7 shows how this function will change depending on which of three compile-time parameters are enabled.
This is not definitive proof that operators had access to the source code, but it certainly makes it much more plausible. The operators would not need to have any programming knowledge in order to fine tune their builds to meet their needs for specific targets, just simple guidance on how to add and remove preprocessor parameters in Visual Studio.
In this example, a CARBANAK sample found in the wild was using protocol version 4 when a newer version had already been available for at least two months. This would not be likely to occur if the source code were kept in a single, central location. The rapid-fire fine tuning of template binaries using preprocessor parameters, combined with several samples of CARBANAK in the wild implementing outdated versions of the protocol indicate that the CARBANAK project is distributed to operators and not kept centrally.
The source code revealed the names of commands whose names were previously unidentified. In fact, it also revealed commands that were altogether absent from the samples we previously blogged about because the functionality was disabled. Table 1 shows the commands whose names were newly discovered in the CARBANAK source code, along with a summary of our analysis from the blog post.
The msgbox command was commented out altogether in the CARBANAK source code, and is strictly for debugging, so it never appeared in public analyses. Likewise, the ifobs command did not appear in the samples we analyzed and publicly documented, but likely for a different reason. The source code in Figure 10 shows the table of commands that CARBANAK understands, and the ifobs command (0x6FD593) is surrounded by an #ifdef, preventing the ifobs code from being compiled into the backdoor unless the ON_IFOBS preprocessor parameter is enabled.
At the time of our initial CARBANAK analysis, we indicated that command 0xB0603B4 (whose name was unknown at the time) could execute shellcode. The source code reveals that the command (whose actual name is tinymet) was intended to execute a very specific piece of shellcode. Figure 12 shows an abbreviated listing of the code for handling the tinymet command, with line numbers in yellow and selected lines hidden (in gray) to show the code in a more compact format.
The end of the file is misaligned by five missing bytes, corresponding to the dynamically assembled mov edi preamble in the tasking source code. However, the single-byte XOR key 0x50 that was found in the source code did not succeed in decoding this file. After some confusion and further analysis, it was realized that the first 27 bytes of this file are a shellcode decoder that looked very similar to call4_dword_xor. Figure 13 shows the shellcode decoder and the beginning of the encoded metsrv.dll. The XOR key the shellcode uses is 0xEF47A2D0 which fits with how the five-byte mov edi instruction, decoder, and adjacent metsrv.dll will be laid out in memory.
Ironically, possessing source code biased our binary analysis in the wrong direction, suggesting a single-byte XOR key when really there was a 27-byte decoder preamble using a four-byte XOR key. Furthermore, the name of the command being tinymet suggested that the TinyMet Meterpreter stager was involved. This may have been the case at one point, but the source code comments and binary files suggest that the developers and operators have moved on to simply downloading Meterpreter directly without changing the name of the command.
FIN7 used Carbanak between 2014 and 2016. The group is responsible for attacking more than 100 banks all over the world and stealing well over $1 billion through their cash transfer systems. On April 19, 2017, Carbanak's source code was uploaded to VirusTotal, from Russia.
Since Nick Carr found the two archives in 2017, FireEye researchers spent 229 hours analyzing Carbanak's binaries and source code. Including work before finding the code, the researchers spent 469 hours on Carbanak; this effort led to unprecedented insight into the malware and its functionality, and enabled learning about plugins that had not been seen before.
"Having source code sounds like cheat-mode for malware analysis. Indeed, source code contains much information that is lost through the compilation and linking process," says Michael Bailey, one of the researchers that analyzed the source code.
Malware analysts are accustomed to working with binary files, the version that is built to be understood by computers. The source code of an application is its human-readable version and offers much more information that is lost during the compilation process.
UPDATE: The article has been edited to clarify that the file size was for the uncompressed archives, to detail the time spent by the researchers analyzing Carbanak and its source code, and correct information about the researcher who learned enough Russian vocabulary to understand the comments in Carbanak's source code and to translate the graphical user interfaces.
Nick Carr, senior manager of the advanced practices team at FireEye, based in Milpitas, Calif., found the Carbanak source code in two RAR archives on VirusTotal in August 2017, approximately four months after the code was uploaded. FireEye did not say who uploaded the two files, but Carr said via Twitter that the uploader was from Russia and hinted it could have been a member of the cybercrime group behind Carbanak.
From the source code's discovery until mid-2018, Michael Bailey, staff reverse engineer for FireEye's FLARE team, spent nearly 230 hours analyzing the 100,000 lines of code, including some time spent learning the Russian language in order to "minimize my use of other analysts' time."
In a blog post describing the analysis process, Bailey wrote that although having the source code "sounds like cheat-mode for malware analysis," the Carbanak component used to handle command and control (C2) was an example of how difficult the code was to parse.
Bailey said the Carbanak source code showed the threat actors put in "significant investments in throwing malware analysts off the scent of this backdoor." And beyond obfuscation techniques, the code analysis also found that Carbanak was designed to alter evasion techniques based on the antivirus product installed on a system.
d0d94e66b7