Introduction: The chicken and egg problem

Most banks lack clear visibility into how many fraud cases and losses are driven by mobile malware. This creates a classic chicken‑and‑egg problem: without dedicated mobile malware detection, cases cannot be accurately identified or attributed; without hard data, it is difficult to justify investment in such tooling. Existing fraud reporting frameworks compound the issue.

“Unauthorised fraud” is often a catch‑all category that blends very different modus operandi, including account takeover, card‑not‑present fraud, and mobile malware attacks. At the same time, fraud prevention models still draw a line between social engineering and technical compromise—a distinction that no longer reflects today’s reality.

Modern fraud campaigns increasingly operate in the grey area between user manipulation and device takeover (DTO). Apps are sideloaded, victims are persuaded to install apps, approve permissions, or follow instructions that appear legitimate. From there, malicious software takes control inside the customer’s own device, executing fraud from an environment that looks trusted and familiar.

This convergence is not accidental. It reflects a deliberate shift by attackers toward mobile platforms, where device trust, user familiarity, and fragmented controls intersect. The result is what can be described as the Malware Gap: a structural blind spot between fraud controls designed for user behaviour and those designed for device context.

Fragmented defences, coherent attackers

Most organisations have invested sensibly in fraud prevention, but along organisational lines rather than attacker logic.

• Scams and social engineering are addressed with transaction monitoring, behavioural analytics, customer education, and reimbursement processes.
• Device manipulation is handled through Device Intelligence, Runtime Application Self Protection (RASP), includingemulator detection, rooting or jailbreak checks, and basic integrity signals.
• Account misuse is mitigated through behavioural analytics, anomaly detection, and velocity controls.

Each control stack is mature in isolation. The problem is that mobile malware campaigns span all of them.

A campaign may begin as social engineering, transition into technical compromise, and end as fully automated fraud. When controls are not designed to share intent and causality, attackers move through the gaps between them.

Why Device Intelligence and Behavioural Analytics still fall short

It is tempting to assume that combining technologies across device and behaviour should close most gaps. In practice, this combination still misses a critical dimension.

Device protection & RASPs are primarily descriptive. It answers questions such as:

• Is this a real device, is it the device we’ve seen before?
• Is it rooted, jailbroken, or emulated?
• Does its configuration look unusual?
• Is something messing with the runtime?

It does not answer whether the device is under malicious control.

Behavioural analytics focus on interaction patterns:

• How does the user type, swipe, or navigate?
• Are actions consistent with historical behaviour?

Mobile malware is designed to operate within those expectations. Banking trojans regularly execute actions using the accessibility framework, overlays, or remote control modules that preserve human‑like timing and interaction patterns. Transactions originate from the victim’s own device, often during an authenticated session, making behavioural deviations subtle or absent.

The result is fraud that looks legitimate until it is financially visible.

The Mobile Malware Gap

The Mobile Malware Gap emerges at the point where fraud detection assumes a trustworthy endpoint.

Mobile malware today is:

• Distributed through official app stores after passing initial vetting
• Dormant during reputation‑building phases
• Activated dynamically by campaign, geography, or target list
• Capable of overlay attacks, credential theft, session hijacking, and fully automated transactions

Malware authors have found many ways around device controls:

• Well‑documented banking trojans such as Anatsa (and dozens of later families) demonstrate a repeatable pattern: benign app publication, delayed weaponisation, selective targeting, and cyclical activity designed to evade detection.
• Others are circumventing Device Security altogether, by Side Loading the app, such as Xenomorph and Herodotus. BTMOB actually corrupts itself to bypass inspection.
• Malware using the Ghost Tap mechanism, such as PhantomCard and RatOn, incorporate NFC Relay techniques, moving cashouts to (often unmonitored) POS channels.

Because the malware operates inside or around the trusted device boundary, controls that rely on device legitimacy or user familiarity fail to recognise the threat.

Anatomy of a typical mobile malware campaign

A simplified but representative campaign follows these steps:

• App store entry: Attackers publish a legitimate‑looking utility app—often a PDF reader, cleaner, or scanner—via an official app store. The app functions as advertised and accumulates thousands of installs, reviews, and ratings.
• Side Loading: Alternatively, victims are social engineered into Side Loading Mobile Malware onto their device, bypassing Device and Appstore security controls.
• Delayed weaponisation: A later update introduces malicious code, often through a loader or dropper mechanism.
• Dynamic targeting: Command‑and‑control infrastructure delivers target lists by bank, region, and time window.
• On‑device execution: Malware abuses accessibility services, overlays, and screen capture to steal credentials or automate transactions.
• Authorisation Compromise: Malware authorises a transaction on behalf of the victim, or tricks the victim into authorisation.
• Fraud execution: Transactions are initiated from the customer’s own device, during valid sessions, using legitimate credentials.

At no point does the device necessarily “look suspicious” in a generic sense. It remains a “trusted device”, and Device ID’s, network ID, IP adresses, and Geolocation don’t change.

What traditional controls see – and miss

The common failure mode is clear: controls see effects, not causes.

Malware Device Intelligence: adding intent and attribution

Malware Device Intelligence operates at a different layer. Instead of asking whether a device is “normal,” it asks whether malicious capabilities are present and active.

This includes:

• Recognition of known malware families and variants
• Detection of generic malicious behaviours (overlay engines, accessibility misuse, dynamic C2 interaction)
• Classification of devices as compromised rather than merely “unfamiliar”

This shifts detection earlier in the attack lifecycle, before financial loss occurs, and enables campaign‑level visibility rather than case‑by‑case reaction. This pre-empts fraud.

Synergy: where signals become meaningful

Malware intelligence isn’t a replacement, it’s a multiplier. Its value emerges when combined with existing signals:

• Device intelligence & RASPs provide environmental context
• Behavioural analytics highlight interaction anomalies
• Malware intelligence explains why the risk exists
• Transaction monitoring quantifies financial risk

Together, these signals allow organisations to distinguish between:

• A genuine customer under stress
• A coerced customer following instructions
• A compromised device executing malware‑driven fraud

This distinction is operationally critical, particularly in reimbursement regimes and customer communication.

Why Threat Intelligence is non‑optional

Mobile Malware Campaigns evolve quickly, move across geographical regions, and target different brands over time. In other words, mobile malware is:

• Fast-evolving
• Campaign-driven
• Highly regionalised

Static detection logic fails quickly. Appending Malware Aware Detection & Threat Intelligence enables:

• Continuous enrichment of SDK detections
• Rapid response to new variants
• Cross-institution pattern recognition

Without intelligence feeding the detection layer, SDKs become blind to the next campaign wave—often within weeks. Intelligence is the only way to pre-empt campaigns.

Conclusion: closing the gap requires seeing the attack path

The malware gap exists because fraud stacks were built around clearly defined scenarios, not hybrid scenarios with hostile code operating inside user devices. The Mobile is the Crime Scene. Many malware campaigns evade a combination of Behavioral Analysics and Device Intelligence.

As fraud continues to shift toward mobile and device takeover:

• Behavioural signals alone are insufficient
• Generic device intelligence & RASP lack intent
• Malware-aware intelligence becomes foundational

Closing the Mobile Malware Gap is not about adding another score—it is about seeing the attack path clearly, end to end, and acting before fraud becomes indistinguishable from legitimate behaviour.

ThreatFabric’s Malware Fraud offering

ThreatFabric offers Full Malware Device capabilities in any Fraud Prevention stack, by adding intent, campaign level attribution, malware classification, and malware capabilities to detection. These functions are built on Threat Intelligence, and synergize with Device Intelligence and Behavioural Analytics – to cover modern malware fraud campaigns, hybrid campaigns and anything imaginable in the foreseeable future.