Mobile Banking App Pentest: What It Actually Finds

Banking trojans no longer steal credentials and walk away. They sit on the device, overlay the legitimate banking screen, intercept the second factor, and complete the transaction while the customer watches a spinner. Mobile banking app penetration testing exists to confirm whether the runtime controls inside the app actually hold against that tradecraft, or whether they only look present in the binary. This is where automated tooling stops and where a human tester starts.

The pressure on financial-sector security teams is concrete. In Zimperium’s 2026 Mobile Banking Heist Report, the research team notes that “throughout 2025, Zimperium’s zLabs tracked 34 active malware families targeting 1,243 financial brands across 90 countries.” Independent corroboration came in May from Securelist’s Q1 2026 mobile statistics, where the research team reported that “the Trojan-Banker category was the prevalent mobile malware threat with a 52.96% share of total detected applications.” The OWASP MAS team is convening MAScon this week (Vienna, June 25 to 26) with a dedicated session on recent mobile app security incidents from real-world cases. The practitioner conversation has moved past whether banking apps are targeted. It has moved to what a test should actually prove.

How Banking Trojans Reach Exploitable Conditions

The modern banking trojan operates as a banking trojan mobile app companion: a separate application installed via sideload, phishing, or accessibility-service abuse, that lives alongside the genuine banking app and waits for it to launch. The trojan watches for the package name, draws a fake screen on top of the legitimate UI, captures what the user types, then dismisses itself so the user proceeds to the real app. By the time the second factor lands, the malware already has the credentials and an active session in its own client.

The exploitable conditions sit inside the app, not inside the operating system. Three classes recur:

• Weak runtime integrity. The app starts on a rooted or jailbroken device, or under a hooking framework, and continues anyway. The user is never warned and the back-end never sees a posture signal.
• Token storage that survives a rooted dump. Session tokens, refresh tokens, or device-binding secrets stored in places a tester with shell access can read in seconds.
• Network controls that look like pinning but are not. A pin set in code that the runtime can swap out, or a fallback path that disables pinning when the first attempt fails.

These are the conditions Zimperium’s tracked families exploit at scale. The question for the security owner is not whether the controls exist in the codebase. The question is whether they hold when an attacker is actually trying.

What Automated Scanners Cannot See at Runtime

Static analysis catches the absence of a control. It does not catch a control that is implemented but bypassable. A scanner sees CertificatePinner in a Kotlin file and reports “pinning enabled.” A tester confirms whether that pinner survives a runtime hook, whether a fallback path silently disables it, or whether the app accepts a user-installed CA on Android 7 and above when the network security config quietly opts in.

The same pattern appears across the MASVS surface. Insecure storage findings depend on what is in SharedPreferences and Keychain at runtime under a real user flow, not on what the source code declares. Deeplink hijack depends on which intent filters the app actually exports and what the receiving activity does with untrusted input. Root and jailbreak detection depends on whether the check fires before sensitive code paths or after them. A previous CTDefense piece on what a mobile app pentest actually tests laid out the scanner-versus-runtime divide in detail. The argument lands harder in a banking context, where the controls a scanner sees in the binary are the same controls the trojan is built to defeat.

What a Human-Led Mobile Pentest Actually Surfaces

A mobile banking app penetration test scoped against banking-trojan tradecraft produces findings that a checklist tool will not generate. The pattern, across recent CTDefense engagements in the financial sector, looks like this:

• Certificate pinning bypass paths. The tester confirms whether pinning is genuine by installing a custom CA, attaching a runtime hook to the pinning library, and replaying API traffic through an intercepting proxy. If the proxy sees plaintext requests, the protection is decorative, and the same technique that mature trojan families automate in the wild works against it.
• Token and PII recoverable from local storage. The tester pulls the application sandbox from a rooted test device and inspects SharedPreferences, internal databases, the Android Keystore wrapper, and on iOS the Keychain and NSUserDefaults. Insecure storage mobile banking findings tend to cluster here: refresh tokens written in plaintext, device-binding identifiers stored next to user PII, debug logs that never get stripped from release builds.
• Deeplink and intent-filter abuse. The tester enumerates exported activities, content providers, and custom scheme handlers, then crafts deeplinks that trigger sensitive flows from outside the app. In several engagements, a single deeplink reached the in-app browser with an attacker-controlled URL, opening a phishing surface inside a trusted app.
• Runtime integrity bypasses. Root detection, emulator detection, and anti-hooking checks are each tested for order of operations and for whether they can be flipped with a Frida script. A check that runs after the secret has already been loaded into memory is no check at all.
• Backend authorization at the mobile API layer. A pentest goes past the client and exercises the mobile API directly. Mass-assignment, broken object-level authorization, and weak rate-limiting on OTP endpoints are common, and they are invisible to a scanner that only looks at the APK or IPA.

None of this requires reproducing live malware. It requires a tester with a rooted device, an instrumentation toolkit, and the methodology to walk the same paths a trojan would walk.

The MASVS Controls That Block These Attack Paths

The framework structuring the test is the OWASP Mobile Application Security Verification Standard. The OWASP MAS team describes MASVS as the document that “establishes baseline security and privacy requirements for mobile apps,” and the categories map cleanly onto trojan attack paths.

• MASVS-NETWORK covers TLS configuration and certificate pinning. This is the OWASP MASVS security requirements category that determines whether a trojan with a compromised CA on the device can read the app’s API traffic.
• MASVS-STORAGE covers what the app keeps on disk and where. This is the category that decides whether a rooted dump yields a usable session.
• MASVS-PLATFORM covers exposed components, deeplink handling, and inter-process communication. Hijacked deeplinks and over-permissive intent filters fail here.
• MASVS-RESILIENCE covers runtime integrity, anti-tampering, and detection of hostile environments. This is where overlay attacks, accessibility-service abuse, and hook-based session theft are supposed to break down.

MASVS is a verification standard, not a checklist. The control is satisfied only when a tester has confirmed at runtime that the implementation cannot be bypassed by the same techniques attackers use. A scanner can confirm the code is there. A pentest confirms the code does its job.

Why Fintech Teams Need Runtime-Level Assurance

The buyer question in a board pack is usually some form of: does our mobile app survive the threats reported in this quarter’s fraud-loss summary. The honest answer requires a fintech mobile app security assessment that goes past the binary. The MASVS controls that block screen-overlay and session-hijack paths are only verifiable by a tester who can actually instrument the runtime. Scanner output confirms the binary exists. A pentest confirms it can be bypassed, or that it cannot.

CTDefense delivers human-led mobile engagements scoped against this threat model. The team works from MASVS as the baseline, then layers banking-trojan tradecraft on top: pinning bypass against the current Android network security config behaviour, sandbox extraction against the latest Keystore wrapper patterns, deeplink fuzzing against the actual export manifest. Findings come back tied to the MASVS category, with a remediation path the mobile team can act on inside one sprint. For organisations that ship both platforms, the team runs Android penetration testing and iOS penetration testing in parallel so the controls can be compared across runtimes rather than retrofitted.

Banks, payment companies, and fintech platforms looking at the Zimperium figures and the Securelist mobile share would benefit from running the same exercise this quarter, before the next public incident makes the conversation reactive. The controls that block the attacks the report describes are the same controls a runtime pentest can verify in the next two weeks.