IBM X-Force research recently analyzed a new Android banking Trojan that appears to be targeting users in countries that speak Spanish or Portuguese, namely Spain, Portugal, Brazil and other parts of Latin America. This Trojan, which was created atop an existing, simpler SMSstealer.BR, was supplemented with more elaborate overlay capabilities. That portion of the malware was coined “Banker.BR”.
At this time, the malware is being spread by messages that lead users to a malicious domain controlled by the attackers. Users are told that they need to download the most recent version of a supposed security app required for mobile banking. If they click to download the update, they unwittingly launch the download from a legitimate file sharing platform.
Since this app downloads from a third-party source, an action not authorized by default on Android devices, a note shown to the potential victim instructs them on how to enable side-loading through the device’s Settings menu.
Figure 1: New banking malware asks users to enable side-loading
In its current state, this malware can enable phishing via an overlay attack, thereby stealing users’ online banking credentials, it can allow the attacker to take over users’ bank accounts, and it can enable the theft of two-factor authentication (2FA) codes sent via SMS. These elements can help attackers complete fraudulent transactions from victims’ bank accounts.
A New Codebase
According to our analysis, Banker.BR’s code is entirely new and does not rely on previously leaked code or existing mobile malware. While our team has seen earlier versions of this Trojan, which only featured a basic SMS stealer, this blog focuses on the new, and more elaborate, feature of the overlay malware capability — a tactic common to most Android banking malware.
At first, this malware was only able to steal SMS messages, and attackers using it likely obtained user credentials from other sources, such as phishing attacks and underground credential vendors. As it evolved, it added the overlay attack feature to bring the phishing phase into the infected device as well.
While it has the same capabilities as other malware in this class, it lacks the ability to pull overlay images from its command-and-control (C&C) server in real time, calling on embedded screens in its own resources on the device, which is less agile than methods used by other malware.
While most apps are implemented in the Java/Kotlin programming languages, which are part of the Android studio development essentials platform, Banker.BR’s is programmed in the B4X programming language. B4X is a modern version of Visual Basic that’s part of a suite of rapid integrated development environments (IDEs) used in the creation of applications for Android and iOS operating systems. It is not often used in the creation of malware apps.
Lack of Anti-Research Features
We noticed some features that are not presently a part of this malware’s overall deployment:
- The malware is not packed or obfuscated, making it easier to reverse-engineer, although the use of a niche IDE does create overhead code that can be more challenging to reverse.
- Unlike similar malware, before installing on the device, this new Trojan does not verify whether it is being run in a virtualized environment or check if it is being debugged. In that sense, it lacks anti-research features, which makes it easier to analyze.
- We have not been able to find any proxy capabilities or any call manipulation features.
Persistence on the device is established by using a receiver with a broadcast. The receiver is an Android component that allows apps to register for notifications about system and app events. In this case, the malware app registers to be notified about the ACTION_BOOT_COMPLETED system event, which is sent out once the system completes a new boot process.
When the notification arrives, the malware runs itself without the user’s intervention.
Malicious Permission Granting
Banker.BR abuses the Accessibility service to grant itself the permissions it requires without asking the user and without the victim’s knowledge. This is achieved by programmatically clicking the “Allow” button on system screens that request the user to allow or deny runtime permissions.
The malware does this faster than a human can, thus not giving users a chance to react or to deny the malware from receiving the permissions it asks for. Banker.BR can further grant itself additional permissions once it has allowed the initial ones.
Figure 2: Auto approval of permissions
The permissions sought by this malware include:
- Read phone state
- Camera access
- Read contacts
- Read and receive SMS
- Write to external storage
Figure 3: Banker.BR permission list
Exfiltrating Device Information and SMS Content
After installation, the malware collects some device information and sends it to the attacker’s C&C, which is a domain address hardcoded into the malware. This information includes the following:
- Phone number
- International Mobile Equipment Identity (IMEI)
- International Mobile Subscriber Identity (IMSI)
- SIM Serial Number (SSN)
- Unique Bot ID randomized by the malware for each device
When active, the malware can also steal and exfiltrate SMS messages, which allows it to grab 2FA codes sent to the user by their bank or other service providers. The malware registers a receiver to handle newly received SMS (SMS_RECEIVED) on runtime, and not in Manifest, which enables the malware to keep this function invisible to the user.
Figure 4: Banker.BR SMS control
Active in the Background and Taking Action on Trigger
Banker.BR remains silently active in the background of a device, monitoring the applications the user opens as it awaits a target app to be launched.
Abusing the Accessibility service on the device, a relatively common way for Android malware apps to keep tabs on which app is running in the foreground, it waits for a match with the goal of launching overlay screens at the right time and context to fool the user into tapping their credentials into the overlay.
Figure 5: Malware awaits targeted apps to be launched
This is achieved by listening for onaccessibilityevent and event type TYPE_WINDOW_STATE_CHANGED, which would mean that the user’s interface had changed.
Next, the malware calls the function _acs_onactivitynameretrieved, which will verify if the activity’s name matches one of its targets. If a match is detected, the malware will call on the corresponding overlay screen to match that bank app’s look and feel.
Figure 6: Banker.BR targeted apps with bank names blurred (Source: IBM X-Force)
The overlay screen would typically feature the bank’s logo and ask for the user’s sign-in credentials.
Unlike other malware in this class, the overlay screens are embedded into the malware and not retrieved from the attacker’s C&C server in real time. This is a less agile method that does not allow for on-the-fly updates to fake screens but rather requires a malware update to deliver changes. It also exposes all the available screens to outsiders analyzing the malware.
Figure 7: Sample overlay screen requiring the user to enter their account sign-in credentials
At this time, the targets we have observed for this new malware are focused on banks in Brazil. In some cases, major banks targeted by this app also operate in other parts of the world, namely Spain, Portugal and across Latin America, which could be indicative of the attackers’ current location or origins.
Malware of this type is extremely simple to redirect to other regions by changing the target list and embedded screens, thereby modifying its attack turf and potential targets. It can target banks but can also be used to target the user credentials of any other app on the device or for stealing payment card data under the guise of a Google Play store request.
IBM X-Force researchers note that Banker.BR is seeing continued development with new screens being added for additional targeted banks and expected code enhancements in the coming months.
Indicators of Compromise (IoCs)
SHA-256 of earlier versions — SMS stealer only
SHA-256 of later versions — complete overlay malware