BackSwap Banking Malware Analysis

1. Management summary

Backswap is financial banking 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.

The BackSwap banking malware is likely a modification of old Tinba (Tiny Banker) banker trojan as they share significant portions of the source code. The dropper file is distributed as infected binary of  a legitimate freeware such as Filezilla. Once the binary is executed, it copies itself to various locations depending on exact version to ensure persistence over restarts. Unlike traditional banking trojans, no native code is injected directly into browser’s process for purpose of webinjections. BackSwap instead is monitoring the title of browser using unrestricted windows APIs. Once a target website is detected, it deciphers the inject for that target, opens devtools inside the browser by simulating shortcuts and inserts malicious javascript through the clipboard.

The Javascript code then waits for specific elements to appear in the DOM indicating ongoing transaction. Once the beneficiary account is found, it is replaced with the account of the fraudster’s money mule. If the bank displays a payment confirmation, the target account is again replaced to the original to decrease suspicion.

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.

 

2.   Technical analysis

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”

The Javascript webinjection code uses an interesting trick to communicate back to the main binary. The Javascript code is changing the window title of browser by changing the title DOM element. These changes are registered by ASM component, which is monitoring all window title in loop.

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
  

Payload encryption

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:

 

Injection

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.

In another variant of BackSwap, it was found that the code is inserted directly to the URL leveraging “javascript:” protocol. We find these techniques quite creative, because it helped the malware writer not to fight with the browser changing memory layout, function signatures and other things that had to be taken into account when hooking the browser in every other banking trojan we observed so far.

Javascript code

The webinjects we found are being executed asynchronously using the setInterval function. The javascript is not obfuscated and in general quite poorly written. It also leaks some variables to global scope, which indicates development inexperience.

Transaction tampering

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

hervormdegemeentegrootammers[.]nl/docs/tron[.]php
efg-uebach-palenberg[.]de/web_33/includes/o[.]php
debasuin[.]nl/test/php/loop[.]php
vitamunda[.]nl/wp-test/ok[.]php
mecrob[.]cc/bot/gate[.]php
5[.]61[.]47[.]74/batya/give[.]php
103[.]242[.]117[.]248/batya/give[.]php
mta116[.]megaonline[.]in
czcmail[.]com

Samples examples

6b23d4d2a773cb4252be8c039d35092818a5038a1766bb3c7c7beef28064ee62
fc656f3c430ed08888a41b17a31c459352ff7e27fc73b07773196e03fe7801c1
16fe4de2235850a7d947e4517a667a9bfcca3aee17b5022b02c68cc584aa6548
2223a93521b261715767f00f0d1ae4e692bd593202be40f3508cb4fd5e21712b
f51336e862b891f78f2682505c3d38ea7de5b0673d6ef7a3b0907c0996887c22
75d05a39010df2ba1232eba03a76bf515eb5ae1a9fb9d9376cd1ccd6580ca4f6

 

3.   Detection

The nature of this webinject makes it harder to detect, because it does not involve DOM elements observed in traditional financial banking malware injections. Depending on the exact sample and the webinject it may or may not leak javascript variables, which is how some less innovative anti-malware products are detecting webinjects.

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.

Kryštof Hilar