Cleafy security researchers discovered a new banking trojan targeting banks in Europe. They named the new Android malware variant “TeaBot” because it is not related to other banking trojans.
The Android malware abuses Android’s Accessibility Services to overlay legitimate banking apps, intercept user actions and two-factor authentication codes, and perform arbitrary actions.
Cleafy’s Threat Intelligence and Incident Response team discovered the malware in January 2021. By March 29, the researchers detected malicious injections against Italian banks, and Belgium and Netherlands banks by May 2021.
TeaBot Android malware can stream a device’s screen and mimic user interaction
The researchers explained that the primary goal of TeaBot is stealing victims’ banking credentials for fraudulent purposes by abusing Android’s Accessibility Services.
The Android malware achieves a real-time interaction with the compromised device to bypass “new device enrollment” and perform an Account Takeover (ATO).
When TeaBot is successfully installed in the victim’s device, attackers can obtain a live stream of the device screen on demand and also interact with it.
The banking trojan can also send, intercept, and hide SMS messages to bypass two-factor authentication.
Like other Android banking trojans such as Anubis, Cerberus/Alien it overlays banks’ mobile applications to steal login and credit card information. It also observes and intercepts user actions and can perform arbitrary actions.
Unlike other banking trojans like EventBot that observe all installed apps, TeaBot only spied on selected banking applications. Consequently, it downloads specific payloads to perform overlay attacks against specific banks.
“TeaBot, during its first communications with the C2, sends the list of installed apps to verify if the infected devices had one or more targeted apps already installed,” the researchers noted.
Cleafy researchers also discovered that the Android malware sent user interaction information for specific bank apps every ten seconds to the command server. This strategy ensured that there is little traffic between the Android malware and the command-and-control server. The traffic is also partially encrypted with the XOR algorithm.
The researchers also observed that TeaBot requests permissions to read phonebook and phone state, use device biometrics, modify audio settings, display popups over other apps, and delete other applications.
The banking trojan is also capable of logging keystrokes and stealing Google Authentication codes. It can also retrieve window content to steal sensitive data displayed on the screen.
Additionally, the Android malware starts taking screenshots of the infected device’s screen in a loop to create a “Virtual Screen” every time the C2 server sends the “start_client” command with the IP address and the PORT.
TeaBot also installs as an Android service to perform long-running processes such as communicating with the C2 servers in the background. It also requests permission to override the device’s battery optimization to prevent the Android operating system from killing the persistent background process.
TeaBot has a secondary installation stage that delivers a second-stage dynamic payload (.dex) containing the malicious code. Once granted the necessary permissions, the banking trojan also removes its icon from the device to conceal infection.
TeaBot banking trojan is unique and still in active development
The researchers discovered some glitches in the banking trojan’s operation. This discovery suggests that the Android malware was still in its early development stages.
They discovered the presence of some non-functional injections and commands or total lack thereof.
“The partial network encryption and the presence of some not-working injections and commands (or in some cases a lack of injections for specific targeted banks) suggest to us that the TeaBot is still under development,” the researchers stated.
Additionally, the presence of junk code suggested that TeaBot developers were still adding features. However, they supported six European languages: Dutch, English, French, German, Italian, and Spanish.
Although TeaBot is unique, its payloads were detected in other malicious apps disguised as the movie streaming app “TeaTV,” the researchers noted.
The Android malware also spreads through social engineering tactics by persuading users to download fake apps. Threat actors, therefore, renamed the banking trojan as popular apps such as “VLC MediaPlayer”, “Mobdro”, “DHL”, “UPS” and “bpost.”
Although TeaBot currently focuses on European banks, the attackers could easily modify the banking trojan to target other banks globally.
“TeaBot and Flubot both represent the shift in mobile malware from just being a sideline issue to being a mainstream problem just as malware on traditional endpoints,” said Saumitra Das, CTO and Cofounder, Blue Hexagon. “Threat actors realize the true potential of mobile devices and the threat they can pose to the end-user.”
Das noted that threat actors applied ingenious methods to spread malicious apps without using Google Play Store.
David Stewart, CEO, Approov, says that organizations should check the origin of API requests before accepting API transaction requests. He says that organizations should ensure that the apps were not running on emulators or compromised runtimes.
“TeaBot and other Android-based trojans have the potential of stealing user credentials and wreaking havoc with account takeover fraud and identity theft within the banking system,” says Rajiv Pimplaskar, CRO, Veridium. “While currently, these Trojans appear to be localized within certain European countries, for the time being, such attacks can quickly spread regionally and across the globe.”
He advises organizations to ditch homegrown frameworks and the dependence on passwords and adopt stronger and more robust authentication methods.
“A push notification from a bank application using certificates exchanged with the smartphone can be a lot more secure than a username/password combination along with a One Time Passcode (OTP) that’s transmitted over SMS. An authentication hub can be used by consumers based on risk profile along with a variety of non-password-based modern authentication methods like [the] phone as a token, device coupled with native or proprietary biometrics, and/or FIDO2 security keys.”
