Antidot Banking Trojan “scandar” Campaign

This sample is a confirmed variant of the Antidot Android banking trojan. Antidot masquerades as a Google Play Services update, abuses Android Accessibility services to gain full device control, and deploys a fullscreen WebView overlay over targeted banking and cryptocurrency applications to silently steal credentials. The campaign identifier “scandar” was found plaintext in assets/sudoport.txt — likely used as a runtime decryption seed or C2 initialisation key. MFA does not protect against this attack: credentials are captured at the overlay level before any MFA prompt is seen.

The sample arrived as a MalwareBazaar-format ZIP — a password-protected archive named with the SHA256 hash of its contents, using the standard community password infected. Extraction via 7z revealed a single Android APK of the same hash name: 7.0 MB, timestamped July 2025, bearing APK v2+v3 signing and confirmed as a legitimate Android package by the classes.dex + APK Signing Block markers.

◈ Evidence Hashes

The first thing that breaks every automated analysis tool is the encryption. When we opened the APK as a ZIP archive, Python’s zipfile module reported all four critical files as AES-256 encrypted. No standard decompiler — apktool, jadx, baksmali — can touch an APK when its DEX and manifest are encrypted at the ZIP level. This is the primary anti-analysis layer. The second layer is 206 fake ZIP entries with deliberately malformed path names designed to crash tools that parse them naively.

◈ Encrypted Core Files

• 🔒classes.dex — AES-256 encrypted, 9.0 MB. The entire malicious Java payload. Cannot be decompiled without runtime key.
• 🔒classes2.dex — AES-256 encrypted. Secondary DEX likely containing overlay target list and Firebase configuration.
• 🔒AndroidManifest.xml — AES-256 encrypted. Hides package name, declared permissions, activities, services, and broadcast receivers.
• 🔒resources.arsc — AES-256 encrypted. Compiled resource table — hides string resources, UI elements, and app metadata.

The APK is signed with a generic Android Debug certificate — CN=Android Debug, OU=Android, O=US. This is a self-signed certificate with no developer identity, no Play Store association, and no way to attribute the app to any organisation. Combined with the B4A (Basic4Android) build framework — a BASIC-like Android development tool popular among threat actors precisely because fewer automated analysis pipelines are tuned for it — this sample is engineered to slip through standard fingerprinting.

• 1Certificate extracted: META-INF/ANDROIDD.RSA → openssl pkcs7 decode → CN=Android Debug, OU=Android, O=US, C=US
• 2B4A confirmed: binary string b4a found at raw APK offset 4,674,457. B4A layout file .bal present in assets.
• 3APK signing scheme: v2 + v3 (X-Android-APK-Signed: 2, 3) — modern signing standard, validates correctly on Android 7+.

With the DEX encrypted, we focused on the 206 unencrypted entries — metadata files, Firebase property files, Kotlin builtins, and most importantly, the two asset files. The unencrypted infrastructure tells a clear story: Firebase for C2, OkHttp3 for REST calls, Kotlin coroutines for async communication, and a B4A layout file that hands us the entire overlay architecture on a plate.

◈ Notable Unencrypted Components

assets/viewportal.bal is a B4A binary layout descriptor — the visual blueprint of the malware’s attack interface. Unlike the encrypted DEX, this file is stored unencrypted and can be parsed with a gzip decompressor. What it reveals is the complete overlay attack mechanism: a single WebView component named link, set to fill 100% of screen width and 100% of screen height, with JavaScript fully enabled. This is the fake login page engine.

◈ Layout File Parse

• ●Component name: link — the WebView object. Named to look innocuous in code references.
• ●Width: SetLeftAndRight(0, 100%x) — fills 100% of screen width. No frame, no border, no title bar.
• ●Height: SetTopAndBottom(0, 100%y) — fills 100% of screen height. The overlay IS the entire screen.
• ●javaScriptEnabled: true — confirmed in the binary section. The fake page can run arbitrary JS, capture form input, call native methods.
• ●zoomEnabled: true — the fake page zooms to match device DPI, making it indistinguishable from the real app.
• ●AutoScaleAll — the layout scales to any Android screen size automatically. Works on phones and tablets.

Antidot uses a two-stage social engineering approach. Stage one tricks the victim into installing the APK and granting Accessibility permissions. Stage two uses those permissions to silently overlay target apps and exfiltrate credentials. The entire flow is automated and requires no interaction from the attacker after the APK is deployed.

◈ Attack Stages

• 1Delivery: APK distributed via smishing, malvertising, fake app stores, or third-party download links. Never distributed via Google Play.
• 2Fake lure page: On launch, displays a convincing “Google Play Services update required” screen in the device’s own language (9 confirmed languages). Victim sees familiar branding.
• 3Permission harvest: Victim clicks “Update” → redirected to Android Accessibility Settings. Told they must enable a “service” to complete the update. Victim enables it.
• 4Full device control: Accessibility permission grants the malware the ability to read all screen content, inject input events, intercept notifications, and monitor all app launches.
• 5C2 check-in: Firebase FCM connection established. Attacker receives device registration. Can now push commands: which apps to overlay, when to fire, what to capture.
• 6Overlay trigger: Malware monitors for target banking/crypto app launches. When target opens → fullscreen WebView (link) fires instantly, covering the real app.
• 7Credential capture: Victim enters credentials into the fake login page. Data sent to C2. Malware dismisses overlay, real app continues — victim has no idea anything happened.
• 8Persistence: BOOT_COMPLETED broadcast receiver ensures malware restarts on device reboot. Continues operating silently until detected or removed.

Antidot is not a single-purpose credential stealer. It is a full-featured Android RAT with banking trojan specialisation. The capability set confirmed below comes from a combination of static string analysis on this sample and published Antidot threat intelligence from Cyble, IBM X-Force, and SecurityWeek.

Most banking trojans use HTTP/WebSocket C2 — connections that stand out in network traffic and can be blocked at DNS or IP level once the C2 server is identified. Antidot’s use of Firebase Cloud Messaging (FCM) as its primary C2 channel sidesteps almost all of those defences. FCM is Google infrastructure. Blocking fcm.googleapis.com breaks every legitimate Android app that uses push notifications — including the banking apps Antidot is targeting.

• 1Traffic blending: C2 commands arrive as Firebase push notifications. Indistinguishable from legitimate app notifications at the network layer.
• 2No suspicious outbound: When idle, the malware makes zero suspicious connections. Standard network monitoring sees only periodic FCM heartbeats — normal Android behaviour.
• 3Shared infrastructure: All Firebase traffic goes through fcm.googleapis.com. You cannot block the attacker’s project without blocking all FCM traffic.
• 4Firebase SDK versions: messaging v23.1.0, installations v17.1.0, analytics — current stable versions. No version-based detection signal.
• 5Project ID hidden: The Firebase project ID, which would identify the attacker’s Google account, is embedded in the encrypted DEX. Not recoverable via static analysis.

The following IOCs were extracted via static analysis. C2 domains, Firebase project ID, and overlay target application list are embedded inside the AES-256 encrypted DEX and could not be recovered without dynamic analysis. Runtime extraction via Frida is recommended to complete the IOC set.

• 1Assume all credentials are compromised — immediately revoke and reset all banking, corporate, and email passwords entered on that device since the APK was installed.
• 2Contact your bank immediately — request a temporary block on the account and review recent transactions for unauthorised activity.
• 3Factory reset the device — do not attempt to manually remove the APK. Antidot’s Accessibility permissions allow it to resist removal. Full wipe is the only reliable remediation.
• 4Revoke active sessions on all accounts that were accessed from the infected device — banking, email, corporate SSO, crypto exchanges.

• 1Mobile Threat Defence (MTD): Deploy Lookout, Zimperium, or Pradeo on all corporate-managed Android devices. MTD would catch this at install via permission pattern analysis before the Accessibility grant happens.
• 2MDM sideloading policy: Enforce DISALLOW_INSTALL_UNKNOWN_SOURCES via your MDM (Intune, Jamf, VMware Workspace ONE). Antidot is never distributed via Play Store — sideloading is the only install vector.
• 3Firebase FCM blocking on corporate Wi-Fi: If BYOD Android devices access sensitive systems on your network, consider blocking fcm.googleapis.com and *.firebaseio.com at the network edge. This cuts the Antidot C2 channel on your network.
• 4Submit APK hash to your MTD vendor for detection rule creation: SHA256 4be8d630...45fa2.
• 5Submit to Google: Report to [email protected] with the SHA256 hash and campaign name “scandar”. This feeds Google Play Protect and Android Safe Browsing detection.

Antidot cannot function without Accessibility permission. That permission requires the victim to manually navigate to Settings and enable it. This is the single chokepoint in the entire kill chain — and it is entirely social-engineered. The countermeasure is simple awareness.

• ⚠Google Play Services NEVER updates via a pop-up. Updates happen automatically and silently through the Play Store. Any app claiming to be a “Google Play Services update” that asks you to do anything is malicious.
• ⚠Accessibility permissions are extremely sensitive. No legitimate banking, social, or utility app needs Accessibility access. If any app asks for it, deny it and uninstall the app.
• ⚠Only install apps from Google Play. Side-loaded APKs from links in SMS, email, WhatsApp, or websites are the primary Antidot delivery vector.