In today’s mobile-first world, malware authors are adapting rapidly, and few demonstrate this better than the Anatsa malware, also known as TeaBot. Disguised as legitimate utility apps and distributed through the Google Play Store, Anatsa is a dangerous Android banking trojan designed to steal credentials, hijack accounts, and perform unauthorized transactions with alarming stealth.
What Is Anatsa?
Anatsa is a mobile banking trojan that primarily targets Android users. First observed in 2021, it has evolved to include multi-stage payload delivery, anti-analysis capabilities, and targeted credential harvesting. Unlike simple trojans, Anatsa behaves like a complex, modular Remote Access Trojan (RAT) capable of advanced operations including keylogging, screen overlays, and real-time financial fraud.
In this campaign, Anatsa was hidden behind fake but functional PDF reader and QR code reader applications. These apps amassed over 70,000+ downloads, increasing credibility and reach. Once installed, the apps retrieved a second-stage payload from remote command-and-control (C2) servers, using encrypted and obfuscated URL strings.
These droppers were clean at first glance, and no malicious code was present in the initial APK. However, post-installation, they contacted remote servers to download malicious payloads disguised as app updates. The success of this campaign highlights the continuous challenge of malware infiltration in official app marketplaces.
Infection Chain: From Play Store to Full Compromise
The campaign begins with dropper apps on the Google Play Store, disguised as innocuous tools such as PDF editors, QR scanners, and cleaner utilities. These apps are built to appear clean and pass initial static and behavioral analysis
These apps serve as droppers, i.e., a deceptive first stage whose primary mission is to fetch and execute a second-stage malicious payload, usually delivered as an encrypted .dex file from an actor-controlled command-and-control (C2) server.
Once the dropper receives the second stage, it dynamically loads this payload using Android’s DexClassLoader or PathClassLoader mechanisms, which allow apps to load additional Java classes at runtime. This dynamic code loading is a key indicator of malicious activity, as it enables the malware to conceal its core logic from static scanners until the last moment.
The payload then leverages Java reflection, specifically “java.lang.reflect.Method.invoke()”, to obfuscate execution further and avoid detection by conventional behavioral monitoring tools. But Anatsa doesn’t stop there. It abuses Android’s AccessibilityService, an API designed to help users with disabilities, to spy on screen content, steal keystrokes, and even automate UI interactions like clicking buttons or pasting stolen credentials into banking apps.
One of Anatsa’s most dangerous capabilities is its use of WebView combined with JavaScriptInterface, which enables it to render fake login pages inside an app, indistinguishable from the real ones, and capture user credentials without needing direct access to the original app. This phishing method is extremely effective because it keeps users within the malicious app, avoiding detection from external security tools.
However, Anatsa is not reckless. Before unleashing its full functionality, it performs environment checks to evade detection by sandboxes and emulators used by security researchers. It inspects system properties like Build.MODEL, Build.MANUFACTURER, Build.FINGERPRINT, and more to identify common test environments like Genymotion, Android SDK emulators, VirtualBox, and NoxPlayer. If such properties are found, or if the device is from a non-targeted region, the malware stops execution immediately. Target countries include Germany (DE), Spain (ES), Finland (FI), Portugal (PT), the United Kingdom (GB), and a few others.
Anatsa checks several “android.os.Build” properties to identify if the device is a sandbox, emulator, or test setup.
Sample Code:private static boolean checkBuildConfig() {return Build.MANUFACTURER.contains(“Genymotion”) || Build. MODEL.contains(“google_sdk”) || Build. MANUFACTURER.toLowerCase().contains(“secret”) || Build. MODEL.toLowerCase().contains(“droid4x”) || Build.MODEL.toLowerCase().contains(“secret”) || Build.MODEL.contains(“Emulator”) || Build. MODEL. contains(“Android SDK built for x86”) || Objects.equals(Build. HARDWARE, “goldfish”) || Objects.equals (Build. HARDWARE, “vbox86”) || Build.HARDWARE. toLowerCase().contains(“nox”) || Build. FINGERPRINT.startsWith(“generic”) || Objects.equals (Build.PRODUCT, “sdk”) || Objects.equals (Build. PRODUCT, “google_sdk”) || Objects.equals (Build. PRODUCT, “sdk_x86”) || Objects.equals (Build. PRODUCT, “vbox86p”) || Build. PRODUCT.toLowerCase().contains(“nox”) || Build.BOARD.toLowerCase().contains (“nox”) || (Build. BRAND.startsWith(“generic”) && Build.DEVICE.startsWith(“generic”)); }A few sandbox techniques it checks for:
Build.MODEL == “Android SDK built for x86”Default Android emulatorBuild.HARDWARE == “vbox86”VirtualBox-based emulatorBuild.MANUFACTURER.contains(“Genymotion”)Genymotion emulatorBuild.MODEL.toLowerCase().contains(“droid4x”)Droid4X emulatorBuild.HARDWARE.toLowerCase().contains(“nox”)NoxPlayer emulatorBuild.PRODUCT in [“sdk”, “google_sdk”, “sdk_x86”, “vbox86p”]Standard emulator product namesBuild.FINGERPRINT.startsWith(“generic”)Generic Android emulator fingerprintThese properties are typical for emulators, so if detected, malware execution is stopped as attackers don’t want to get analyzed by researchers on emulators; hence, they stop the operation there to give out fewer behavioural hints.
Anatsa also uses geofencing based on the device’s network country, determined using the getNetworkCountryIso() method, to restrict its malicious operations to only certain geolocations. This not only reduces its footprint but also allows it to avoid drawing unnecessary attention in countries with aggressive malware tracking operations.
Anatsa filters targets based on device manufacturer and geography (Spain, Thailand, Slovakia, Slovenia, Sierra Leone, Bulgaria, United Kingdom, Finland, Hungary, Ireland, Germany, Portugal).
Sample Code:String country = tm.getNetworkCountry Iso().isEmpty() ? “uat” tm.getNetworkCountryIso();if (Build.VERSION.SDK_INT != 32 && isManufacturerGood () && ! checkBuildConfig()) {if (!country.startsWith(“es”) && !country.startsWith(“th”) && !country.startsWith(“sk”) && !country.startsWith(“si”) && !country. startsWith(“sl”) && !country.startsWith(“bg”) && !country.startsWith(“gb”) && !country.startsWith(“fi”) && !country.startsWith(“hu”) && !country. startsWith(“ie”) && !country.startsWith(“de”) && !country.startsWith(“pt”))To make analysis harder, some Anatsa APKs are tampered at the ZIP structure level, with malformed manifest files and invalid ZIP headers. This breaks down automated analysis pipelines and makes reverse engineering more painful.
After the APK is loaded, the malware requests various permissions, including SMS and accessibility options, which are commonly associated with mobile banking trojans.
The malware conceals the final DEX payload within the asset files. During runtime, the payload decrypts the DEX file using a static key embedded within the code.
Upon execution, the malware decodes all encoded strings, including the C2 communication. The malware establishes communication with the C2 server to carry out various activities, such as registering the infected device and retrieving a list of targeted applications for code injections.
In order to steal data from financial applications, Anatsa downloads a target list. Upon receiving a list of financial application package names, the malware scans the victim’s device to check if any of these targeted applications are installed. Once the malware identifies the presence of a targeted application, Anatsa communicates this information to the C2 server. In response, the C2 server provides a fake login page for the banking application.
The fake login page is loaded within a JavaScript Interface (JSI) enabled webview, which is designed to deceive the user into providing their banking credentials. Once the victim enters their credentials, that data is sent back to the C2 server.
Insights and Takeaways
Anatsa is a good example of how Android malware has matured, from blunt tools to surgically precise modular payloads with multiple layers of evasion. Its dropper-based architecture, dynamic loading, and accessibility abuse represent a sophisticated blend of tactics that make detection and remediation difficult without a layered, behavior-focused defense strategy.
From a defender’s perspective, Detection strategies must include monitoring for:
- Unusual use of DexClassLoader or reflective method calls
- Requests for AccessibilityService outside legitimate use cases
- The presence of JavaScriptInterface attached to WebViews with remote control features
- Country-based geofencing logic in apps
- Invalid APK structures or malformed manifests
- Unnecessary app permissions
Conclusion
Anatsa serves as a reminder that threat actors continue to find new and creative ways to weaponize mobile platforms. Whether it’s evading Google Play’s security layers or blending into legitimate-looking user flows with WebView phishing, the sophistication of Android malware like Anatsa highlights the need for proactive mobile threat detection, user education, and developer vigilance.
References