sandrathomas HexMobSuite, Mobile Application Security, Uncategorized

Inside a Mobile Banking App Breach: A Forensic Walkthrough of What Goes Wrong

Inside a Mobile Banking App Breach: A Forensic Walkthrough of What Goes Wrong

Key takeaways

  • Modern mobile banking compromises are chained, not single-exploit events: lure → dropper → accessibility-service abuse → overlay attack → credential theft → device takeover → fraudulent transaction.
  • The Android banking trojan ecosystem in 2024–2026 is dominated by Anatsa, Crocodilus, TrickMo, Hook, Octo, Godfather and their forks. ThreatFabric documented Crocodilus expanding from Spain/Turkey to 8 countries including India, Brazil, Argentina, Indonesia and the US within months of its March 2025 disclosure.
  • Most pre-breach indicators are detectable by mobile application security scanning: insecure storage, weak certificate pinning, missing root detection, hardcoded secrets, vulnerable SDKs, exported activities.
  • The forensic post-mortem after a banking app breach almost always identifies findings that a current MASVS v2.1 + Mobile Top 10 2024 scan would have caught pre-release.

A mobile banking app breach in 2026 is rarely a movie scene of a lone hacker exploiting a zero-day. It is a chain of small failures, each individually defensible, that combine to enable a fraudulent transaction. The point of forensic analysis after the fact is to reconstruct that chain. The point of mobile application security testing before the fact is to break the chain before the attacker assembles it.

This post walks through a composite, anonymised attack chain based on real public research from ThreatFabric, Cleafy, Zimperium, Kaspersky and Group-IB on mobile banking malware in 2024–2025. Every stage has a defensive control that breaks it. Every defensive control is something a competent mobile application security testing programme should be enforcing.

Stage 1 The lure

The attacker doesn’t start with the app. They start with the user.

Common 2024–2026 distribution patterns documented by ThreatFabric and others:

  • Bogus Facebook ads mimicking banks and e-commerce platforms (used by Crocodilus operators against Polish targets in 2025)
  • Fake “Google Chrome update” prompts delivering droppers (a TrickMo signature)
  • “Bonus points” claim apps lured through social media promotions
  • Sideloaded banking app updates distributed through smishing links
  • Web browser update prompts redirecting from compromised legitimate sites
  • Online casino apps as a lure in some Spanish/Turkish campaigns

The user is convinced to install an APK from outside the Play Store. The dropper uses session-based installation to bypass Android 13+ restrictions on installing from unknown sources Crocodilus, for example, masqueraded as “quizzical.washbowl.calamity” while presenting itself visually as Google Chrome.

What this stage tells us: the attacker has full control of what runs on the device. The bank has zero opportunity to intervene at this stage from inside the legitimate banking app. The defence shifts to detection of post-installation conditions on the device.

Stage 2 Accessibility-service abuse

The dropper installs the banking trojan and immediately requests Accessibility Services permission. Once granted, the malware can:

  • Read the contents of any other app’s screen
  • Inject taps, swipes and text into any other app
  • Capture text entered into any field
  • Detect when the user opens specific apps (the banking app trigger)
  • Display overlay windows on top of other apps

This is where the bank’s own mobile app starts to become relevant. Several controls in the legitimate banking app can detect this state and refuse to operate.

Public research and product documentation describe controls in this category:

  • Accessibility-service-aware refusal: app refuses to launch sensitive flows if non-allowlisted accessibility services are active
  • Overlay-detection: app refuses to display sensitive screens if another app has FLAG_LAYOUT_SHOW_WALLPAPER style overlay capability
  • Screen-recording detection: refuse to display credentials or balance data if any active recording is detected
  • Process-list anomaly detection: refuse if known malware package names are present (a moving target Google’s own work on this, including the September 2025 detection of suspicious accessibility-service activity during banking app launches, is the right model)

CBUAE Notice 2025/3057 has formalised expectations in this area for UAE banks: client-side controls including RAT (Remote Access Trojan) detection, screen-share session-kill, and rejection of sensitive flows in compromised states are now an explicit regulatory expectation.

Stage 3 Overlay attack and credential theft

This is the canonical banking trojan attack pattern. The malware monitors accessibilityEvent for the launch of the banking app’s package name. When it detects the launch, it overlays a perfectly-rendered fake login screen on top of the real one. The user types credentials. The malware captures them.

The most-targeted apps in 2024–2025, per ThreatFabric and Cleafy reporting on TrickMo, Crocodilus and Hook variants, have included major banking apps across Europe (HSBC, Lloyds, ING), the Americas, and increasingly Asia-Pacific. The target lists are dynamic fetched from C2 servers and tailored to the geography of the infected device.

Crocodilus added a sophisticated wrinkle: a black screen overlay that conceals the actual fraudulent transaction in progress on the device, plus muted audio so the victim doesn’t notice notification sounds. The user thinks the device is locked or restarting; the malware is actually approving a withdrawal.

Defensive controls a competent banking app should have:

  • Anti-overlay protection: API checks for WindowManager overlays, refusal to render sensitive screens when overlays are present
  • Custom IME for credential entry: input field that doesn’t go through standard keyboard infrastructure, harder to keylog
  • Tamper-resistant SecureKeyboard implementations (used by some major Indian and GCC banks)
  • Out-of-band confirmation for transactions above a threshold (push notification to a different device, hardware token)

Stage 4 Insecure storage exploitation

Even if the user catches on and reports the overlay, the malware has already done two things:

  1. Captured credentials
  2. Read the local data of the banking app if the banking app stored anything sensitive in unprotected local storage

This is where the pre-release scanning would have caught the attack chain.

Common findings in mobile banking app pentests that enable this stage:

  • Unencrypted SharedPreferences containing session tokens, recent transaction lists, KYC fragments
  • NSUserDefaults / Keychain entries on iOS without device-bound encryption
  • SQLite databases in /data/data/<package>/databases/ with sensitive data unencrypted
  • Cached API responses in /data/data/<package>/cache/ with no purge logic
  • Backup-included flag set true on Android, allowing accessible backups of full app data
  • Logcat-friendly error messages including auth tokens, full PII, transaction details

Every one of these is detected by static + binary scanning. Every one maps to MASVS-STORAGE controls. None require runtime exploitation to identify.

Stage 5 Pinning bypass and dynamic instrumentation

If the malware has root or has otherwise compromised the device, it will attempt to bypass certificate pinning so that traffic can be intercepted, modified or replayed. Tools used in real attacks documented in 2024–2025: Frida, Objection, Magisk modules for SSL pinning bypass.

This is also where Frida-resistance and anti-debugging in the legitimate banking app matter:

  • Apps that don’t enforce runtime certificate pinning (just configuration in network_security_config.xml is insufficient the runtime must verify)
  • Apps that use a TrustManager override that disables validation in debug builds and accidentally ships to production
  • Apps without anti-Frida detection (gum-js-loop thread detection, ptrace checks, etc.)
  • Apps without root detection beyond superficial checks (RootBeer-class libraries are the baseline; serious banking apps go further)

Pre-release scanning catches the static evidence: no pinning configured, weak pinning configuration, anti-debug missing, root detection absent. The runtime exploitation is then trivial.

Stage 6 C2 exfiltration and fraudulent transaction

With credentials captured and pinning bypassed, the malware initiates the fraudulent transaction. Three patterns:

  1. In-app fraud on the user’s own device. Malware uses captured credentials to log in (often during the original session, while the user is still confused by the overlay), initiates a transfer, intercepts and auto-approves any 2FA push that arrives.
  2. Out-of-band fraud from the operator’s infrastructure. Captured credentials and OTPs (extracted via accessibility logging from Google Authenticator, Microsoft Authenticator and similar apps) are exfiltrated to C2 and used from a different device.
  3. SIM swap-supplemented fraud. Captured KYC fragments enable a SIM swap, which then enables full account takeover via SMS-based authentication paths.

Crocodilus added an automated seed-phrase collector for cryptocurrency wallets, using a parser to extract seed phrases and private keys of specific wallets illustrating that the same architecture applies to fintech beyond traditional banking.

What forensics typically shows after the fact

When a regional bank engages a DFIR firm after a wave of fraudulent transactions traced to mobile compromise, the consistent forensic findings include:

  • The attack chain spans days, not minutes. Initial dropper installation, observation period, overlay deployment when the banking app is opened, exfiltration over hours.
  • The malware is not in the Play Store. Sideloaded or installed from a malicious link. Google Play Protect, the bank’s own integrity attestation, and the app’s environment checks all had opportunities to detect.
  • The legitimate banking app on the user’s device is untouched. The malware does not modify the legitimate APK; it overlays it. This is why “the bank’s app is fine” is a useless statement after a breach.
  • The C2 infrastructure is short-lived. Attackers rotate domains and infrastructure aggressively. Threat intel on the infrastructure has limited shelf life.
  • The user’s behaviour is rational, not stupid. “Why did the user install a malicious APK?” is a question that misses the point. The user was lured by sophisticated social engineering specifically designed to bypass their judgement.

The pre-breach indicators a current scan would catch

If the bank’s mobile application security testing programme had been continuous and current at the time of the breach, the following would typically have been flagged:

Pre-breach indicator MASVS v2.1 control Mobile Top 10 2024
Unencrypted SharedPreferences containing session tokens MASVS-STORAGE-1 M9 Insecure Data Storage
No certificate pinning MASVS-NETWORK-1 M5 Insecure Communication
Pinning configured statically but not enforced at runtime MASVS-NETWORK-1 M5 Insecure Communication
No root / jailbreak detection MASVS-RESILIENCE-3 M7 Insufficient Binary Protections
No accessibility-service-aware controls in sensitive flows MASVS-PLATFORM-1, MASVS-RESILIENCE-1 M7 Insufficient Binary Protections
android:allowBackup="true" MASVS-STORAGE-2 M9 Insecure Data Storage
Hardcoded API keys / OAuth secrets in binary MASVS-CODE-2 M1 Improper Credential Usage
Vulnerable SDK (e.g., outdated WebView, vulnerable analytics SDK) MASVS-CODE-2 M2 Inadequate Supply Chain Security
Missing anti-tamper / anti-debug MASVS-RESILIENCE-2 M7 Insufficient Binary Protections
Logcat-leaking auth tokens MASVS-CODE-1 M1 Improper Credential Usage
Weak crypto (MD5, SHA-1, AES-ECB) MASVS-CRYPTO-1 M10 Insufficient Cryptography
Insecure deep-link handling allowing intent injection MASVS-PLATFORM-2 M4 Insufficient Input/Output Validation

This is not exhaustive. It is the working list of pre-breach indicators that turn up in real banking app forensic reports against attack chains documented in public research throughout 2024–2026. Every one of them is detectable pre-release.

Regulatory fallout

A breach affecting customers triggers parallel regulatory clocks. For a UAE bank: CBUAE notification, NESA / SIA reporting, UAE PDPL breach notification (if personal data was involved). For a Saudi bank: SAMA notification under the Cyber Security Framework. For an Indian bank: CERT-In notification within 6 hours of becoming aware (April 2022 Directions), RBI supervisory notification under the Master Direction on IT Governance, and from May 2027, DPDP notification to the Data Protection Board within 72 hours and to affected Data Principals. For any bank with cross-border customers: GDPR notification if EU residents are affected.

These clocks run in parallel and none substitute for any other. The bank’s incident response plan needs to be designed for the regulatory clock, not the technical investigation clock.

Recommended controls what to actually deploy

If you are a bank, fintech or payments company with a mobile app, the practical control set is:

Code-level (MASVS-STORAGE, MASVS-CRYPTO, MASVS-CODE):

  • Encrypt all local sensitive data with platform-bound keys (Android Keystore / iOS Keychain)
  • AES-256-GCM, never AES-ECB, never MD5/SHA-1
  • No hardcoded secrets use server-side fetching or build-time substitution with restricted-scope keys
  • android:allowBackup="false", android:debuggable="false" in production
  • ProGuard/R8 with security-focused rules

Network-level (MASVS-NETWORK):

  • Certificate pinning with runtime enforcement
  • Public-key pinning preferred for cleaner rotation
  • TLS 1.2 minimum, prefer TLS 1.3
  • No TrustManager overrides, ever

Authentication-level (MASVS-AUTH):

  • Biometric authentication with hardware-backed key invalidation on biometric change
  • Out-of-band 2FA for transactions above threshold (push to separate device, hardware token)
  • Custom IME for credential entry on sensitive flows
  • Refuse to render sensitive screens with active overlays / accessibility services

Resilience-level (MASVS-RESILIENCE):

  • Root / jailbreak detection (multiple techniques, not just one library)
  • Anti-Frida / anti-debug
  • Tamper detection (signature verification on app startup)
  • Runtime integrity (Play Integrity API on Android, DeviceCheck / App Attest on iOS)

Privacy-level (MASVS-PRIVACY):

  • Per-purpose consent capture
  • Audit log of consent actions
  • No third-party SDKs that leak personal data without your control

Continuous testing layer:

  • Static + binary scan on every CI build
  • Continuous monitoring of Play Store / App Store published versions
  • SBOM generation per release
  • Quarterly manual pentest minimum
  • Threat-intel-driven re-scan when new banking trojan techniques disclosed

What to do this quarter

If you operate a banking or fintech mobile app:

  1. Run a baseline scan. Free, 30 minutes. [link to /free-scan]. Compare findings against the pre-breach indicators table above.
  2. Audit your accessibility-service controls. This is the single highest-impact gap in most banking apps. Crocodilus, Anatsa, TrickMo and Hook all hinge on accessibility abuse.
  3. Verify your pinning is runtime-enforced. Static configuration is insufficient. Trace the actual TLS handshake.
  4. Review your local storage end-to-end. SharedPreferences, NSUserDefaults, SQLite, cache directories, log files every place data lives.
  5. Brief your DFIR team on the regulatory clocks. CERT-In 6 hours. CBUAE notification. DPDP 72 hours from May 2027. SAMA notification. Build a matrix.

A mobile banking app breach is rarely a single failure. It is the assembly of several small failures into a chain. Continuous mobile application security testing is what breaks the chain at the points where breaking it is cheap. After-the-fact forensics is what breaks it at the points where breaking it is expensive and where the bill arrives in the form of fraud losses, regulatory penalties, and customer trust that doesn’t come back quickly.

HEXMobileSuite is the mobile application security platform from Hiesen Cyber Security, with continuous monitoring of Play Store / App Store published versions and signed evidence per scan. Get a free banking app scan at hexmobsuite.hiesencyber.com.