Mobile Malware Deep-Dive: Android and iOS Trojan Ecosystems

Android Trojan Families: From Anubis to Modern Accessibility Abusers

The Android banking trojan landscape has undergone generational shifts since Anubis first appeared in 2017. Anubis (AndroidOS_Anubis) established the foundational template: overlay attacks combined with keylogging via accessibility services, distributed through droppers on compromised websites and SMS phishing campaigns. Its command-and-control (C2) infrastructure relied on simple HTTP requests to hardcoded domains, making takedowns effective but temporary.

EventBot, emerging in early 2020, introduced modular architecture and cryptographic evolution. Unlike Anubis's static configuration, EventBot employed RC4-encrypted C2 communications with dynamically retrieved keys from Twitter profiles or GitHub gists—legitimate infrastructure abused for resilience. The malware harvested credentials from over 200 financial applications across the US and Europe, targeting crypto wallets with particular aggressiveness. EventBot's DEX manipulation techniques included multi-layer string obfuscation using reflection-based API resolution, requiring analysts to trace through Class.forName() and Method.invoke() chains to reconstruct original intent.

FluBot represented a paradigm shift in propagation mechanisms. Leveraging the contact-list exfiltration and SMS-sending capabilities of infected devices, FluBot achieved worm-like self-propagation through smishing messages containing package delivery lures. Technically, FluBot employed aggressive native layer evasion: core functionality resided in ARM64 .so libraries loaded via JNI, with DEX-level code serving merely as a loader. The native libraries implemented anti-analysis checks including:

// Simplified representation of FluBot's native anti-debug
#include <sys/ptrace.h>
#include <unistd.h>

int anti_debug_ptrace() {
    if (ptrace(PTRACE_TRACEME, 0, NULL, NULL) == -1) {
        // Being traced: terminate or alter execution
        return 1;
    }
    return 0;
}

void check_frida() {
    // Scan /proc/self/maps for Frida gadget or agent
    FILE *maps = fopen("/proc/self/maps", "r");
    char line[512];
    while (fgets(line, sizeof(line), maps)) {
        if (strstr(line, "frida") || strstr(line, "gum-js")) {
            // Frida detected: crash or loop
            __builtin_trap();
        }
    }
    fclose(maps);
}

TeaBot and its successors exemplify the modern accessibility services abuse crisis. TeaBot's overlay engine dynamically generates WebView-based phishing screens from JSON templates retrieved from C2, enabling rapid targeting of new banking applications without requiring APK updates. The malware registers as an accessibility service with the BIND_ACCESSIBILITY_SERVICE permission, then abuses AccessibilityNodeInfo traversal to:

  • Read screen contents across all applications
  • Inject click events (ACTION_CLICK, ACTION_SET_TEXT) to bypass MFA
  • Intercept notification content for SMS OTP exfiltration
  • Prevent uninstallation by intercepting settings navigation

Contemporary variants have escalated to "accessibility service ransomware," where the malware locks the device by continuously injecting home button presses and overlaying opaque windows, demanding payment through the same infrastructure.

APK Deobfuscation and DEX Manipulation: Analytical Approaches

Analyzing modern Android trojans requires navigating sophisticated obfuscation. Commercial packers like Jiagu, Bangcle, and custom implementations employ DEX encryption, dynamic code loading, and control flow flattening. The deobfuscation pipeline typically proceeds through several stages.

Stage 1: Packer Identification and Dynamic Extraction

For DEX-encrypted samples, runtime extraction via Frida remains the most reliable method when static analysis is blocked:

// Frida script for DEX extraction from memory
function hook_dexclassloader() {
    var DexClassLoader = Java.use("dalvik.system.DexClassLoader");
    
    DexClassLoader.$init.implementation = function(dexPath, optimizedDirectory, librarySearchPath, parent) {
        console.log("[+] DexClassLoader loading: " + dexPath);
        // Extract decrypted DEX from optimizedDirectory after load
        this.$init(dexPath, optimizedDirectory, librarySearchPath, parent);
    };
}

function dump_dex_from_maps() {
    var module = Process.findModuleByName("libart.so");
    // Locate dex file structs in memory, extract via /proc/self/mem
    // Implementation varies by Android version and ART version
}

Stage 2: JNI/Native Layer Evasion Countermeasures

Malware increasingly migrates sensitive operations to native code. The JNI boundary becomes both an evasion technique and an analytical chokepoint. Analysts must:

  • Trace RegisterNatives calls to identify dynamically registered methods
  • Hook JNI_OnLoad to intercept library initialization
  • Use QEMU-based emulation (via Unicorn Engine) when ARM-specific behavior matters
  • Account for ABI selection tricks (deliberate crashes on x86 emulators to detect analysis environments)

Modern variants implement "native code splitting," where function bodies are encrypted and decrypted per-call using keys derived from device-specific properties (Build.SERIAL, ANDROID_ID), frustrating static analysis and hash-based detection.

iOS Exploitation Pathways: Beyond the Walled Garden

iOS malware operates under fundamentally different constraints. The platform's code signing, sandboxing, and review processes historically imposed significant barriers. However, determined adversaries have developed multiple infection vectors with varying prerequisites and prevalence.

Enterprise Certificate Abuse

The Apple Developer Enterprise Program (D-U-N-S required, $299/year) provides certificates for internal app distribution outside the App Store. Malware operators have systematically abused this mechanism: by obtaining fraudulent enterprise registrations or compromising legitimate certificates, they distribute trojanized applications. Notable cases include the AceDeceiver family, which exploited design flaws in Apple's FairPlay DRM to install malicious apps without any certificate—purely by manipulating the authorization code flow between iTunes and devices.

Enterprise-distributed malware typically presents as "cracked" premium apps, modified games with "cheats," or pornographic content—applications Apple would reject from the App Store. Users must explicitly trust the enterprise certificate in Settings, but social engineering effectively overcomes this friction.

Sideloading: Regulatory Disruption

The EU's Digital Markets Act (DMA), enforceable from March 2024, mandates that Apple permit alternative app marketplaces and sideloading on iOS devices in Europe. This represents the most significant structural change to iOS security since its inception. Apple has implemented the entitlement with characteristic restrictions: notarized review for alternative marketplaces, Core Technology Fee for high-install apps, and geographic gating via device region detection.

For malware operators, sideloading reduces but doesn't eliminate barriers. Alternative marketplaces must still implement notarization, and Apple's malware scanning persists. However, the attack surface expands: marketplace compromises, developer account takeovers, and social engineering of marketplace operators become viable. The geographic fragmentation (EU-only sideloading) complicates global campaigns but enables targeted operations.

Jailbreak-Dependent vs. Non-Jailbreak Attacks

Jailbreak-dependent malware (Pegasus, earlier iOS trojans) achieves deep system compromise through kernel exploitation, granting root access and disabling code signing verification. Such malware implants at the kernel or daemon level, achieving persistence across restores unless firmware is fully reflashed. The attack chain for NSO Group's Pegasus exemplified this: Safari WebKit RCE → local privilege escalation → kernel vulnerability → jailbreak → installation of persistence daemon and data exfiltration agent.

Non-jailbreak attacks operate within the constrained iOS sandbox, relying on:

  • Supervised device abuse: MDM enrollment for enterprise control, repurposed for malicious control
  • Configuration profile manipulation: Installing root certificates and VPN configurations to intercept traffic
  • App extension exploitation: Abuse of notification service extensions or keyboard extensions for data access
  • URL scheme hijacking: Registering for sensitive URL schemes (bankapp://, sso://) to intercept legitimate app launches

The XCodeGhost incident demonstrated supply-chain compromise of the non-jailbreak ecosystem: modified XCode distributions injected malicious code into compiled applications, distributing through the legitimate App Store to hundreds of millions of devices.

Banking Trojan Architectures: Overlay to ATS Evolution

Mobile banking trojans have evolved through distinct architectural generations, each increasing automation and reducing victim interaction requirements.

First-Generation: Static Overlay Attacks

The original overlay model hardcoded target application package names and displayed generic phishing WebViews when those apps were foregrounded. Limited by static assets, easily fingerprinted by security products.

Second-Generation: Dynamic Overlay with Remote Templates

TeaBot and contemporary Android trojans implement dynamic overlays. The C2 delivers JSON templates specifying:

{
  "target_package": "com.bank.target",
  "trigger_activity": "com.bank.target.LoginActivity",
  "overlay_layout": "base64_encoded_layout",
  "form_fields": [
    {"id": "username", "type": "text", "hint": "Username"},
    {"id": "password", "type": "password", "hint": "Password"},
    {"id": "submit", "type": "button", "action": "exfil_and_dismiss"}
  ],
  "c2_endpoint": "https://legitimate-service.firebaseio.com/logs.json"
}

The Firebase endpoint exemplifies legitimate infrastructure abuse—traffic to *.firebaseio.com blends with countless legitimate applications, complicating network-based detection.

Third-Generation: ATS (Automated Transfer Systems)

ATS represents the current frontier, minimizing victim awareness by automating fraudulent transactions. After credential capture, the trojan maintains session persistence and initiates transfers autonomously:

  1. Victim logs in legitimately; trojan captures session token
  2. C2 schedules transfer via push or polling mechanism
  3. Trojans abuse accessibility services or inject JavaScript via compromised WebView to execute transfer
  4. MFA challenges intercepted from notifications and submitted automatically
  5. Transaction confirmation screens suppressed or rapidly dismissed

The Medusa trojan family implements sophisticated ATS with "live session takeover"—RAT capabilities allowing real-time operator interaction with the victim's banking session, blending automated and manual fraud.

MDM Bypasses and ARM-Specific Anti-Analysis

Mobile Device Management systems present obstacles for both corporate security and malware operators. Advanced Android trojans implement MDM bypass techniques:

  • Device admin escalation race: Registering as device owner before corporate MDM enrollment, granting superior policy precedence
  • Accessibility service privilege escalation: Using WRITE_SECURE_SETTINGS via accessibility to disable MDM components
  • Work profile isolation escape: Exploiting cross-profile vulnerabilities in Android's multi-user implementation

ARM-specific anti-analysis leverages architectural features absent from x86 analysis environments:

Technique Purpose Detection Method
__arm__ conditional compilation Different behavior on ARM vs. emulated x86 Cross-architecture differential execution
NEON/SIMD fingerprinting Hardware capability probing QEMU incomplete NEON implementation
Cache timing side-channels Emulator detection Statistical timing analysis
PAC/BTI pointer authentication Exploit mitigation, also anti-tampering PAC-aware dynamic instrumentation

Real Infection Chain Walkthrough: TeaBot Variant "Toddler"

The following walkthrough synthesizes observed behaviors from 2023-2024 TeaBot campaigns:

Initial Access: SMS phishing message purporting from national postal service: "Your package delivery failed. Reschedule: [shortened URL]"

Stage 1 Dropper: Downloaded APK ("DeliveryApp.apk") requests SMS permissions and accessibility services under guise of "notification mirroring." DEX contains minimal functionality; primary payload encrypted in assets/raw.dat with AES-256-GCM, key derived from device fingerprint and hardcoded salt.

Stage 2 Native Decryption: libnative-lib.so implements:

  • Emulator detection via hardware property queries
  • Frida detection via /proc/self/maps scan
  • DEX decryption and InMemoryClassLoader instantiation

Stage 3 C2 Registration:

  • Generates ECDH key pair; derives shared secret with C2 public key embedded in native library
  • Registers device with C2 via Discord webhook (webhook URL rotated weekly, distributed through Telegram channel)
  • Exfiltrates: contact list, installed applications, SMS history, device banking apps present

Stage 4 Accessibility Abuse:

  • Obtains BIND_ACCESSIBILITY_SERVICE through persistent social engineering prompts
  • Begins AccessibilityEvent monitoring for target banking applications
  • On trigger: inflates WebView overlay from C2-retrieved template, captures credentials
  • Intercepts NotificationListenerService events for OTP extraction

Stage 5 Persistence:

  • Registers BOOT_COMPLETED receiver
  • Schedules JobScheduler work to restart service if killed
  • Disables Google Play Protect via accessibility-injected settings navigation
  • Prevents uninstallation by intercepting package removal intents and redirecting to home screen

The Discord webhook C2 exemplifies infrastructure abuse evolution: messages appear as routine channel traffic, webhook deletion by Discord only disrupts single nodes, and the platform's CDN serves as reliable payload hosting with global edge distribution.