Mobile malware runs on a customer’s personal phone. You did not choose the device, you cannot patch it, you cannot scan it and you will never see it. It is tempting to conclude that an infected phone is the user’s problem. It is not: when malware on that phone moves money out of an account through your app, the loss, the regulatory exposure and the headline all belong to you.
The threat landscape
Banking trojans are now the dominant category of mobile malware, and campaigns are customised for local institutions: overlays built to match specific banks’ login screens, in the local language.
Store review does not filter this out. A dropper carrying the Anatsa trojan was published on Google Play as a document viewer, reached 90,000 downloads and fourth place in its category, then activated its payload six weeks later. The app that passes review is not the app that attacks your customer.
How malware arrives, and what it does
Six routes onto the device, and five of them are outside your control: droppers in official stores, smishing, third-party stores, counterfeit apps and malicious advertising. Only a compromised SDK in your own build is yours to fix. That is the practical case for defending inside the app rather than trying to police the phone.
Once there, modern families are modular. Published analyses of TrickMo describe phishing overlays, keylogging, screen recording, live screen streaming, SMS interception and suppression of one-time-password notifications in a single package. The capability that defeats defences which work well elsewhere is on-device fraud: the attacker operates your app inside the victim’s own authenticated session, so device fingerprinting, IP reputation and behavioural anomaly detection all pass. The only thing wrong is who is holding the phone.
Why your existing controls cannot see this
| Control | Why it misses mobile malware |
|---|---|
| API gateway and WAF | The request is well-formed and correctly authenticated |
| Fraud and risk engines | Device, location and session signals are all genuine |
| Multi-factor authentication | SMS codes are intercepted; push approvals are tapped by accessibility automation |
| App store review | Droppers activate weeks after approval; clones are distributed outside the store |
| Mobile device management | Your customers’ phones are not enrolled and never will be |
| Penetration testing | Tests your app’s own flaws, not a hostile environment around an app that has none |
None of these should be removed. The point is that none of them observe the device at the moment fraud occurs, and the app is the only component that can.
Six features to demand
The full guide continues with how to design a response policy by severity, what to measure as the programme matures, an evaluation checklist you can put to any vendor, and where SecIron fits. Download it below.
