BNM mobile-banking security expectations
Bank Negara Malaysia's Risk Management in Technology Policy Document, paragraph 10 series, sets the supervisory bar for licensed financial institutions offering mobile banking. Beyond the generic requirements (information assets, access controls, cryptography, logging) the policy contains expectations specific to mobile channels: device-binding, secure storage of credentials and authentication factors, anti-tamper and anti-debug controls, root/jailbreak detection, secure transport, server-side enforcement of all controls, and incident-response readiness for mobile-specific compromise scenarios.
The supervisory pattern across recent BNM thematic reviews has been to drill down on transaction authorisation, out-of-band confirmation strength (OTP, push-to-approve with cryptographic binding), screen-overlay and accessibility-service abuse risks, and the integrity of the mobile-app distribution channel. Examiners expect annual penetration testing of every customer-facing mobile application, with explicit MASVS-aligned scope.
OWASP MASVS framework
The OWASP Mobile Application Security Verification Standard (MASVS) v2.x is the canonical assessment framework for mobile-app security. It defines verification controls grouped by category — Storage, Crypto, Auth, Network, Platform, Code, Resilience, Privacy. Two assurance profiles apply to banking workloads:
- MASVS-L1: Standard security baseline — appropriate for most mobile applications.
- MASVS-L2: Enhanced security baseline — appropriate for applications handling sensitive data; the realistic minimum for retail banking and e-money in Malaysia.
- MASVS-R: Resiliency-against-reverse-engineering controls — appropriate where the threat model includes attackers with physical access and the ability to repackage. Essentially mandatory for Malaysian banking apps in 2026 given the volume of real-world repackaging attacks.
Our mobile-banking pentest scopes default to MASVS-L2 + MASVS-R coverage, mapped to the Mobile Application Security Testing Guide (MASTG) test cases. Deliverable lists every control verified, every control failed, and the remediation path per finding.
iOS-specific risks
- Keychain misuse: Sensitive credentials and tokens stored in the iOS Keychain with overly permissive accessibility attributes (kSecAttrAccessibleAlways instead of kSecAttrAccessibleWhenUnlockedThisDeviceOnly), or stored in NSUserDefaults / property lists where they have no protection at all.
- Insecure Data Protection class: Files written without NSFileProtectionComplete are readable via filesystem access on a jailbroken device.
- App Transport Security exceptions: NSAllowsArbitraryLoads = YES in Info.plist, or domain-specific exceptions that disable TLS validation for ‘just one API endpoint’.
- URL scheme hijacking: Custom URL schemes (mybank://) registered without verification can be hijacked by malicious apps installed alongside.
- Pasteboard leakage: Sensitive data (account numbers, OTPs) copied to the system pasteboard and visible to other applications.
- Inadequate jailbreak detection: Detection logic that checks for one or two indicators (existence of /Applications/Cydia.app) is trivially bypassed via Frida or Liberty Lite. Multi-signal detection with server-side attestation is the baseline.
Android-specific risks
- Android Keystore misuse: Keys stored without StrongBox or hardware-backed attestation, accessibility constraints not set, biometric-bound keys configured without setUserAuthenticationRequired.
- External-storage data leakage: Sensitive data written to /sdcard or other world-readable locations.
- Exported components: Activities, Services, Broadcast Receivers and Content Providers exported (android:exported="true") without permission gates, allowing other apps to invoke them.
- WebView vulnerabilities: JavaScript bridges (addJavascriptInterface) exposing Java methods to attacker-controlled HTML, mixed-content allowed, file:// URL access enabled.
- Insecure deep links: Intent filters that accept arbitrary URI parameters and trigger sensitive actions without confirmation.
- Screen-overlay attacks (tapjacking): Mitigation via setFilterTouchesWhenObscured and FLAG_SECURE on sensitive screens.
- Accessibility-service abuse: Banking apps must detect when an unauthorised accessibility service is enabled and warn or refuse to launch — the dominant Android-banking-trojan vector in Southeast Asia.
- Root detection: Multi-signal root detection paired with Google Play Integrity API attestation. Single-signal checks (existence of su binary) are insufficient.
Biometric authentication bypass
Biometric authentication (Touch ID, Face ID, Android BiometricPrompt) is widely used as the second factor for login and transaction authorisation. The implementation pitfalls are predictable:
- Decorative biometrics: The app prompts for biometric but does not bind any cryptographic operation to the result. A Frida hook that replaces the success callback bypasses the prompt entirely.
- Server-side acceptance of client-asserted biometric success: The app sends "biometric_success: true" to the server. The server trusts it. An attacker with the API token bypasses biometric entirely.
- Biometric-bound key without setUserAuthenticationRequired: Android Keystore key configured to require biometric on creation but not on use — the binding does not enforce.
- Cross-device transaction approval without device binding: Approving a transaction on Phone A authorises it on Phone B because the server has no concept of which device is which.
The correct pattern is biometric-gated cryptographic operation: the biometric prompt unlocks a hardware-backed key which signs a server-issued challenge containing the transaction details. Any tampering invalidates the signature.
Screen-overlay attacks and root/jailbreak detection
Screen-overlay attacks remain the dominant mobile-banking-fraud vector in Malaysia. The Android-banking-trojan family (Cerberus, Anubis, Hydra and successors) waits for the legitimate banking app to launch, then overlays a credential-capture screen. Defences are layered: FLAG_SECURE on credential and transaction screens (also blocks screenshots and screen-recording malware), detection of unauthorised accessibility services, runtime overlay-detection callbacks, and Google Play Integrity API attestation for app authenticity.
Root and jailbreak detection should be multi-signal, server-validated, and treated as risk-signal not access-gate — block sensitive transactions on rooted devices but allow read-only access with elevated monitoring. Server-side attestation (Play Integrity, Apple App Attest) is the authoritative source; client-only detection is bypassable.
API + backend integration testing
A mobile-banking pentest is incomplete without the backend API testing it depends on. Server-side enforcement is the iron rule — every control the mobile app implements client-side must also be enforced server-side. Our mobile engagements always include the backing API in scope, run alongside the techniques in our API pentest article. Common findings: BOLA on transaction-history endpoints, server-side acceptance of client-supplied risk signals, missing rate-limiting on OTP endpoints, weak session-rotation on token refresh.
Tooling — MobSF, Frida, Objection, Burp Pro
- MobSF (Mobile Security Framework): Static + dynamic analysis for both iOS and Android. The first tool we run — fast static analysis surfaces low-hanging fruit (insecure storage, exposed components, weak crypto).
- Frida: Dynamic instrumentation framework. The workhorse for runtime hooking — bypassing certificate pinning, instrumenting biometric callbacks, modifying root-detection responses.
- Objection: Frida-based runtime mobile-exploration toolkit. Pre-built scripts for common bypasses (SSL pinning, jailbreak/root detection), interactive shell.
- Burp Suite Professional: Wire-level interception. Paired with Frida-based pinning bypass for both platforms.
- jadx / apktool / class-dump: Decompilation and binary analysis.
- iLEAPP / ALEAPP: Forensic artefact analysis for filesystem dumps.
- Genymotion / Corellium: Cloud-based test devices including iOS — invaluable for iOS-side testing without managing physical jailbroken devices.
Engagement structure for a Malaysian bank
A typical mobile-banking pentest is a 3-4 week engagement: static analysis and architecture review (week 1), dynamic instrumentation and runtime testing on jailbroken iOS and rooted Android (week 2), backend API integration testing and biometric/transaction-flow testing (week 3), reporting and verification re-test scoping (week 4). Deliverable mapped to MASVS v2.x, BNM RMiT clauses, and the customer's internal risk taxonomy. See our mobile application penetration testing service, our financial services practice, and our RMiT compliance practice.
For execution: see our mobile application penetration testing service, financial services practice, and our RMiT compliance practice.