BackSwap Banking Malware Analysis
Backswap is financial malware whose activity has been discovered in 2018. Throughout the year, several campaigns have emerged in Poland, Spain, Czech Republic and other European countries.
The malware’s modus operandi significantly differs from what we have observed so far among banking trojans, successfully evading detection of many “third party” security solutions tailored for end-user protection, however we can confirm, that ThreatMark AFS 2018 can detect all known variants of BackSwap using behavioral traits detection technique.
Most of binaries we analyzed had hardcoded CC servers, however there was also one variant with DGA (domain generating algorithm). In all cases, disconnecting malware from CC was enough to disrupt its functionality.
This document presents technical details and findings discovered by ThreatMark Security Operation Center.
The first binary which comes to system is infected version of 7zip, Filezilla or OllyDbg. The file itself contains the whole code of the original binary and the malicious code is started either by the entry point directly being modified, or by another entry registered in the initterm table (table containing the list of initialization routines for C++ runtime).
Once the file is executed, it copies itself to C:\Users\reversing\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\tasklist.exe and is again executed.
The Malware itself was written directly in x86 assembly. The code is position-independent. To load libraries, the code first calculates offset to LoadLibraryA, then it imports the library and goes through all marked exports in that library calculating hashes of function names. Once the desired hash is found, it’s pushed to a custom “IAT” table.
BackSwap is also utilizing interesting approach of storing strings, probably not only to make PIC working, but also to increase the difficulty of reverse engineering. When the CALL instruction is executed, it pushes the address of instruction right after EIP to stack as return address. This is exactly what BackSwap is exploiting – if the code requires some string/static data, there is a sequence of CALL pointing to the actual CALL (e.g. to library) followed by a hardcoded string. By operating this way, hardcoded strings are pushed to the stack. This technique is particularly tricky for static analysis because most of the tools were unable to understand, that it shouldn’t try to translate these strings to Opcodes.
JS to ASM “bridge”
Once a new window is found, it’s reported to the command and control server. The Malware then checks, if the browser window is one of the hardcoded ones, if so it prepares the payload for the webinjection.
We have found out that the webinjects which were under our analysis, informed the binary in the following situations:
- User has logged in
- Second factor SMS was retyped
- Malware has successfully changed beneficiary account
- Malware has changed back to the original account number in list of processed payments
The Webinject is located in the rcdata section of the PE file. Each resource represents one webinject for one banking application. The inject itself is encrypted with static XOR key.
The actual key varies from build to build, however the code always contains some strings, such as “function” and the key is not particularly large, therefore the key can be brute-forced using a simple Python code such as this:
BackSwap employs several webinjection techniques. All of them could be considered being “self XSS” type of inject. The first version of the malware was using the clipboard and developer console to ship and execute the final webinject code.
The binary first modifies the “devtools.selfxss.count” property in “perf.js” file to mark that the user has already read the warning about self xss and dismissed this warning.
After that, BackSwap unpacks the webinject and executes it using developer tools in the browser. The malware sends shortcut to open devtools and then either pastes the code using clipboard or sends one character at a time and finally sends enter.
The main functionality of the code is to look for the payment form in the DOM tree and to modify the beneficiary account.
Before the actual replacement, the scripts check whether the payment amount is in the desired range. For example, for the hardcoded range of Polish version of BackSwap goes from 10000 to 20001 PLN. Once these checks pass, the malware changes the input by setting .value variable of the object corresponding to the DOM element.
In different variants, this was done right before the submission, or after detecting that the account number has the right format. In the former case, a new element was created posing as original, and the original having the right “name” property to be used by the browser when urlencoding postdata remained hidden and was holding the money mules account number.
C&C servers used
However, it’s not a problem for ThreatMark AFS – the very specific behavior of this malware can be detected by our user behavior profiling module and the large variety of client-side checks and hooks performed by the malware provides enough data for our back-end machine learning. Both malicious behavior and specific webinjections made it possible for us to be able to easily adapt the system to detect all known variants of the BackSwap malware.