by Jordan Pan and Song Wang
Last year, we saw the Fanta SDK malware target Russian bank Sberbank users and employ unique defensive measures. Now, another bank malware family has appeared, targeting even more Russian banks while using new and evolved obfuscation techniques. This family is named FakeBank, and so far the related samples we have collected number in the thousands. These samples show that the malware targets not only Sberbank, but also other Russian banks like Letobank and the VTB24 bank. Our samples have random package names and pose mostly as SMS/MMS management software to lure users into downloading them. The table below shows the samples’ names:
|App names||English Translation of Russian Names|
|ММС – Пoсланиe||ММС – Send|
|ММС – Сообщениe||MMC– Message|
|CМC – Фотo||CМC – Photo|
|СMС – Соoбщение||СMС – Composition|
|СMC – Послание||СMC – Message|
Table 1. Names of the banking malware samples
Actually, these advertised SMS management capabilities are turned against the victim. The malware intercepts SMS in a scheme to steal funds from infected users through their mobile banking systems.
The banking malware have spread mainly across Russia and other Russian-speaking nations. The table below shows a list of detections per country.
Figure 1. Top countries where samples were detected; there were detections in other countries but they totaled less than 1%
Intercepting SMS leads to transferring funds
The malicious app can control an infected user’s open and close network function and also silently connect to internet. This means that it can send information to its command and control server (C&C) without the user’s knowledge. It also inspects the device for anti-virus software, and if detected, will exit without executing any malicious behavior. This is a tactic that helps it remain unreported and under the radar.
The malware also steals information from the device and uploads it to the C&C server. The sensitive data collected includes: users’ phone numbers, a list of installed banking apps, the balance on any linked bank card, and even location information.
Figure 2. Captured network packet
Figure 3. The app collects the balance of whatever card is connected to the app
To further guarantee the success of the data collection, the malware forbids the user from opening the device settings, likely to prevent uninstallation. Some samples we detected also required admin privileges from the user, which gives the malware even more access to the device.
Figure 3. Once the malware is installed, the icon appears on the device screen and asks for permissions
Figure 4. Once the user approves this request, the icon disappears and the malicious behavior starts
The malware goes further and even takes over the user’s SMS. First it replaces the default SMS management program with its own and hides the icon. This way it can upload and analyze any SMS received and even delete any messages locally. This means that any verification or query from the bank to the user can be intercepted and removed. It can even call an assigned phone number, send specified SMS, and steal call logs and contact lists.
Most significantly, all this access to the device’s SMS gives the malware an avenue to silently steal money from users’ bank account. Since users bind their bank accounts to their device and receive notifications on the same device, the malware can intercept sensitive account information. It can then reset bank account passwords through received security code messages and start transferring money.
FakeBank also stops the user from opening the target bank’s legitimate app, to prevent any modifications to the relationship between the bank card number and your phone number. We can assume that the malware developer is very familiar with the bank message format and transfer process, as all the payment SMS notifications are noted and scrambled by C&C.
It is worth noting that the National Institute of Standards and Technology (NIST) officially discouraged the use of SMS as a method of two-factor authentication. Mobile users should choose other means of authentication if it is offered by the apps and services they use.
One malicious payload, with evolved obfuscation
One of the notable elements of this malware is the way it hides its payload. The malware has different behaviors that make it harder for infected users to get rid of it, and for security solutions to detect it.
It actually uses three different methods to obfuscate the malicious payload. The techniques range in complexity and the developers seem to be taking a multilayered approach to avoid exposure.
- The first layer of obfuscation is a common shell protection, which is a frequently used technique. There are actually some open source tools or services that provide shell protection to APKs. But it is also easy to reverse. A single standard memory dump will allow someone to get the real meaningful code.
- In the next layer, the malware developers use reflection (a means for an application to collect information or manipulate itself) to invoke all the system calls. This is simply a confusion tactic to make the code harder to understand. The malware also encrypts all of its strings, including the class name and functions, and joins them as a file in the assets folder. They typically use standard encryption methods like (DES/BASE64) or a simple bit operation. Below are some snippets of code illustrating the techniques:
Figure 5. Code to reflect invoke system calls, showing basic string obfuscation for class name and method name before decryption
Figure 6. Code to reflect invoke system calls, showing basic string obfuscation for class name and method name after decryption
The malware uses runtime decryption to find specific strings. The code below shows how it locates exact strings through an index for concrete functions which reference an encrypted file in the assets folder.
Figure 7. This function hides the icon of the malicious app
- The entire procedure described above is running in a native .SO file. This means that the code is more flexible. Also to deobfuscate it, dynamic analysis and a hook are needed.When the malware app loads a .SO file, it will decrypt it and generate the strings in the memory.
Figure 8. How the malware decrypts and generates the string
Again, the malware finds the exact string through an index and uses a native call for the concrete function.
Figure 9. This function again hides the icon; it’s the same function as Figure 5.
Though the first technique is easily resolved, the others are problematic methods of obfuscation. Layering all these techniques in one sample shows that the developers are more committed to evading detection and experimenting with different techniques to achieve success.
Looking into the C&C infrastructure
The malware has registered numerous C&C domains and many of the domain names are recent, with some still alive. These C&C domains have common IP addresses (220.127.116.11 and 18.104.22.168) that are located in Poland Warmia-Masuria. Other IP addresses (22.214.171.124 and 126.96.36.199) are located in Russia.
These C&C address have the same format: hxxp://[domain]/[random str]/index.php.
Based on the Whois information for C&C domain, we found that most are registered under the same company. This company is known to be connected to other fraudulent domains, and has been outed by other news sources. It is possible that the registrar has set up privacy protection for the registrants of fraud domains.
Users should be wary of downloading apps from untrusted sources. And devices should also be equipped with comprehensive mobile security that can mitigate mobile malware. Trend Micro Mobile Security Personal Edition and Mobile Security Solutions detect all related threats in this attack. And Trend Micro’s Mobile App Reputation Service (MARS) covers Android and iOS threats using leading sandbox and machine learning technologies. It can protect users against malware, zero-day and known exploits, privacy leaks, and application vulnerability. For a list of the IOCs related to this threat please see the appendix for this post.