Banking Trojans in recent years are losing popularity among cybercriminals. One of the reasons is the development of technologies to protect anti-virus vendors and web browser developers. It is difficult to carry out an attack with the help of a banker, therefore many virus makers are switching to simpler and more profitable tools: encryptors, miners, cryptocurrency theft software.
Many, but not all. We have discovered a new family of bankers, which uses a new technique to manipulate the browser. Instead of complex code injection into the browser process to monitor its activity, malware intercepts Windows events in a message waiting cycle to check the values of objects related to banking operations.
Having found work with online banking, malware injects malicious JavaScript into a web page — via the developer’s console in the browser, or directly into the address bar. Operations are performed without the knowledge and participation of the user. Simple at first glance, the scheme allows you to bypass the advanced mechanisms to protect browsers from complex attacks.
Introduction
We first noticed this cyber group in January 2018, when it distributed its early workings — for example, a program to steal cryptocurrency by substituting the wallet address in the clipboard. The group was engaged in cryptocurrency for several months, after which it released the first version of the banker - from March 13, the ESET anti-virus products detect it as Win32 / BackSwap.A.
On the graph below you can see a sharp jump in detection compared with previous projects, according to our statistics. The authors improve the banker and release new versions almost every day (with breaks for the weekend).
Figure 1. Detections of Win32 / BackSwap.A and related previous projectsDistribution and execution
Win32 / BackSwap.A is distributed in spam emails containing an obfuscated JavaScript downloader from the Nemucod family as an attachment. Currently these mailings are targeted at users from Poland.
We often found
another well-known Win32 / TrojanDownloader.Nymaim boot loader on the victim machines, probably spreading in the same way. Currently, we do not know if this is a coincidence or a family is related to each other.
The payload is delivered as a modified version of a legitimate application, partially rewritten by a malicious component. The application used for the modification changes regularly - we observed TPVCGateway, SQLMon, DbgView, WinRAR Uninstaller, 7Zip, OllyDbg and FileZilla Server in this capacity.
The application is modified in such a way that it switches to the malicious code after its initialization. To do this, the authors add a pointer to the malicious component to the
_initterm() function table, the inner part of the C language library runtime, which initializes global variables and other parts of the program before calling the main () function.
Figure 2. Array of _initterm pointers of a legitimate application, at the end of which a pointer to the banker shellcode is addedThe method resembles trojanization; the difference is that in our case the original application stops working after the initialization of the Malvari. The purpose of the method is not masking from the user, but rather countering detection and investigation. Analysts find it more difficult to detect this banker, since many reverse engineering tools, such as IDA Pro, show the original main () function as the legitimate start of application code. Not the fact that the analyst at first glance will notice something suspicious.
The payload is a position-independent binary code object with embedded data. The character strings are stored in plain text, which allows you to sweep the already unobtrusive traces, since all the required Windows APIs are searched for in the course of working with hashing. At the beginning of the work, malware provides persistence by copying itself to the startup folder, and then proceeds to the functions of the banker.
Traditional Injection Techniques
An ordinary banker to steal funds from the victim’s account via the online banking interface introduces itself or a special module into the address space of the browser process. For a number of reasons, this is not an easy task. First of all, the injection can be intercepted by an antivirus product. In addition, the bit depth of the module being implemented must match the browser bit depth - a 32-bit module should not be embedded in a 64-bit process and vice versa. As a result, the attack requires two versions of the same module - 32- / 64-bit.
After a successful injection, the banking module must detect the functions related to the browser and intercept them. It needs the functions responsible for sending and receiving HTTP requests in plain text format before encryption and after decryption, respectively. The complexity of the search functions varies from browser to browser. In Mozilla Firefox, they are exported by the nss3.dll library, and their addresses are easy to find by their well-known names. Google Chrome and other browsers on the Chromium platform hide these features. This forces virus writers to invent special schemes aimed at a specific browser version and change tactics when new versions are released.
If the functions are found and the interception is completed (and it was not detected by the anti-virus solution), the banker can modify the HTTP traffic or redirect the victim to sites that mimic the legitimate online banking resources by forging certificates. Such methods are used by well-known banking Trojans
Dridex ,
Ursnif, Zbot, Trickbot, Qbot and many others.
New browser manipulation method
Win32 / BackSwap.A implements a completely different approach. Banker uses elements of the Windows GUI and simulates user input. The method may seem trivial, but it is effective because it allows you to solve the known problems of a traditional injection. First, the malware does not interact with the browser at the process level. Due to this, there is no need for special privileges and circumvention of antiviruses that protect against the usual injection. The second advantage for attackers is that the banker does not depend on the browser architecture or on its version; one code works for everyone.
Malware tracks the URL of a page you are visiting by setting event hooks for a specific range of relevant events available through the Windows message loop, such as EVENT_OBJECT_FOCUS, EVENT_OBJECT_SELECTION, EVENT_OBJECT_NAMECHANGE, and several others. The handler searches for URL values by searching for string objects that begin with HTTPS, obtained by calling the
get_accValue method from the
IAccessible event interface.
Figure 3. Reception used to get the URL of the current page in the browser. These addresses are obtained by checking the substring [ht] tp [s] (highlighted in red)Win32 / BackSwap.A then searches for the bank-related addresses and window titles in the browser, indicating that the user is preparing a money transfer.
Figure 4. The banker searches for lines of code related to specific banks. The first line is the title of the window, the second is the part of the URLUpon detecting the required, the banker downloads malicious JavaScript corresponding to a specific bank, and injects it into the browser. Inject is produced in a simple but effective way.
In older samples, Win32 / BackSwap.A inserts a malicious script into the clipboard and simulates pressing a key combination to open the developer console (CTRL + SHIFT + J in Google Chrome, CTRL + SHIFT + K in Mozilla Firefox), then inserts the contents of the buffer (CTRL + V) and “presses” ENTER to execute the contents of the console. Then the malware repeats the key combination to close the console. At this time, the browser window becomes invisible - a normal user will likely think that the browser is frozen for a few seconds.
In the new versions of the scheme improved. Instead of interacting with the developer’s console, the malicious script is executed directly from the address bar through a
special JavaScript protocol , a little-used function that most browsers support. The banker simulates pressing CTRL + L to select the address bar, DELETE to clear the field, “enters” the characters in “javascript” by calling SendMessageA in a loop, and then inserting a malicious script using the CTRL + V combination. The script is executed after "pressing" ENTER. At the end of the process, the address bar is cleared to remove traces of compromise.
In Figure 5, you can see part of the injected code in the console. First, Win32 / BackSwap.A determines the browser by checking the class name of the selected window (marked in blue). Malicious JavaScript is copied to clipboard (marked in red). Then the transparency value of the browser window changes to "3", which makes it invisible (marked in purple). Green highlights the part related to the
ToggleBrowserConsole function, which turns the console on and off.
Figure 5. Script injectWin32 / BackSwap.A supports attacks on Google Chrome and Mozilla Firefox, Internet Explorer is supported in recent versions. The method is suitable for most browsers with a developer console or the ability to execute JavaScript code from the address bar (standard browser functions).
Three browsers prone to compromise have an interesting
protection feature designed to prevent
Self-XSS attacks : when a user tries to paste copied text starting with “javascript:” into the address bar, the protocol prefix is deleted and must be entered again manually to execute the script. Win32 / BackSwap.A bypasses this obstacle by simulating the prefix character-by-character input into the address bar before pasting the copied malicious script.
Another security tool is implemented in Mozilla Firefox. The browser does not allow copying scripts to the default console; instead, it shows a notification of possible risks and forces the user to first manually enter the phrase “allow pasting” to allow the insertion of the copied characters. To bypass this security measure, Win32 / BackSwap.A provides for executing a shell command (Figure 6), which makes changes to the
prefs.js configuration
prefs.js and removes this protection.
Figure 6. Shell command, removing the protection from pasting the script to the Firefox consoleJavaScript Malicious Code
Win32 / BackSwap.A uses a special script for each of the target banks. Since all banks have different sites, the code is different and has different variables. The scripts are injected into the pages on which, according to the banker, the money transfer is being prepared. The embedded scripts secretly replace the recipient’s account number with another one, and when the victim sends the transfer, the money will go to the attacker's account. Countermeasures against unauthorized transfers (two-factor authentication) are powerless, as the account holder confirms the transfer of funds.
The authors of Win32 / BackSwap.A have written scripts for working with five Polish banks: PKO Bank Polski, Bank Zachodni WBK SA, mBank, ING and Pekao. Operators remove some banks from the list of targets - in most new versions there are three banks left: PKO BP, mBank and ING. In older versions, attackers transfer the recipient’s account number from C & C servers on hacked WordPress sites. In the new versions, the numbers are stored in the malicious scripts themselves. Accounts change frequently - a new account number is used in almost every new campaign.
Banker is interested in transfers in a certain range - as a rule, from 10,000 to 20,000 Polish zlotys (168,000–337,000 rubles). The script not only replaces the recipient's account number, but also replaces the input field with a fake one - the user sees the correct number and is unaware of anything.
Figure 7. A piece of malicious code in javascript. Areas marked in red are responsible for verifying the transfer amount and replacing the recipient’s account numberConclusion
Win32 / BackSwap.A proves that in the confrontation between the security industry and virus writers do not always need a new sophisticated technique and tactics. Browsers enhance protection against code injection, so Malvar authors switched to other attack methods, and only one is implemented in Win32 / BackSwap.A.
ESET anti-virus
products detect the threat as Win32 / BackSwap.A.
ESET specialists reported to developers of compromised browsers a new attack method.
Iocs
9BC4C1D5403DDD90712CE87225490A21D1EDC516 JS/Nemucod.EAN trojan
CF5A74C268661501156663F74CD5E20603B0F261 Win32/BackSwap.A trojan
6251F9AD0E5F551AC4A6B918EF366E86C4CCFDC4 Win32/BackSwap.A trojan
2DC9760A7C6E9D261C73EFB7B2604840734BC058 Win32/BackSwap.A trojan
A68901D0D8C1247FF280F9453E3AE45687C57566 Win32/BackSwap.A trojan (JavaScript)