Banking malware is now shaping its input to get past behavioral checks. A protected banking app gives fraud teams a second, independent view of the same session.

In October 2025, ThreatFabric published research on Herodotus, an Android banking trojan built for device takeover.[1] Its operators control an infected phone remotely through Android's Accessibility Service, the feature that screen readers and other assistive tools depend on. They can open the victim's banking app, tap through its screens, and fill in transfer details.

Herodotus enters text without touching the phone's keyboard: it sets characters directly into the app's text fields, one at a time, with a random pause of between 0.3 and 3 seconds before each one. ThreatFabric judged the pauses an attempt to make automated input look like a person typing, so it slips past fraud checks that flag machine-speed entry.

The researchers saw active campaigns in Italy and Brazil, and found overlay pages prepared for financial organizations in the US. Systems that only measure input timing might be fooled, they noted, but systems that model each customer's individual behavior would still see an anomaly.

The more useful lesson is about intent. Malware authors now design their tools around the evidence fraud systems collect.

Two views of the same session

Your fraud stack already knows a great deal about a mobile banking session. Identity intelligence links it to an account holder. Device intelligence recognizes the phone. Behavioral analytics compares how the customer types and swipes with how they usually do. Transaction monitoring weighs the payment against the account's history.

All of that describes the customer and their interaction. Herodotus goes after that layer directly, by changing how its interaction looks.

Runtime protection inside the banking app describes something else: the condition of the app itself while it runs. A protected app is in a position to detect that it's been modified, that another app is setting text in its fields or tapping through its screens, that something is reading or mirroring the screen, or that an overlay is covering it. Herodotus can make its input look human. It still has to deliver that input through the cccessibility service, into the app.

ThreatFabric's conclusion points the same way. It describes behavioral biometrics as a strong indicator of suspicious activity, best used within a layered approach that also considers the device environment. With both views in play, an attacker has to fool the behavioral model and the app's own protection at the same time.

missing layer in mobile fraud protection-01_edited

Attackers already work inside the session

Promon's Security Research team has seen the same toolkit up close. Early in 2026, the team analyzed a Coretax-themed Android remote-access trojan circulating in Indonesia and published the results in our Q2 2026 App Threat Report.[2] The malware mirrors the victim's screen to the operator, harvests credentials through the Accessibility Service, draws fake overlays over the banking app, and uses emulated input to log in and start a transfer. While it works, the victim's screen can appear black, as if the phone were switched off.

From the bank's side, the requests come from the customer's own phone, in an authenticated session. The customer has no idea a transfer is under way.

Other attackers go after the link between a detection and the fraud it should explain. In September 2026, Group-IB described how operators of the Gigabud banking trojan, one of the families often identified in Coretax-themed scams, install a second app called Vwork.[3] Vwork clones a banking app into an Android work profile, and the fraudulent transactions then run from the clone. To the bank, they can appear to come from a new device, with no obvious connection to malware already detected on the phone. Group-IB found samples built for this technique aimed at several countries, including Brazil, Colombia, and Mexico.

A detection only helps if it's attached to the app instance that's doing the transacting, and to the session the bank is assessing. Vwork is designed to make that attachment fail.

What changes when the fraud team see it

Picture a customer who signs in on their usual phone and adds a new payee. The amount they send next fits their history. Identity, device, and transaction checks all agree, and the payment looks routine.

Now suppose the protected app detects another app setting text in the payee fields while the details are entered. The signal points at the session, and possibly at a customer who's being targeted. It gives the fraud team a reason to look again before the money moves: hold the payment, or confirm the payee through a channel the phone doesn't control.

Timing decides which of those options is open. In-app protection acts on the phone straight away, but a signal still has to reach the fraud platform and be matched to the session. If it arrives after the payment is approved, it supports the investigation and any follow-up on the account.

Context matters too. Accessibility switched on for a screen reader describes the phone. Text injected during a payee change describes this session.

missing layer in mobile fraud protection-03

Why the source of the signal matters

Evidence from inside an app is only as reliable as the app's own protection. Malware runs on the same phone, and an attacker who can modify the app can also try to switch off its detections or change what it reports.

Attackers know this. When Promon's Security Research team examined a repackaged copy of a bank's app used in a Coretax attack, they found its protections against accessibility abuse and screen mirroring had been removed before the malware went to work.

Promon Shield for Mobile™ is embedded into the app post-compile and protects it against tampering, repackaging, and runtime interference. Promon describes the protected execution space this creates inside the app as a Trusted Runtime Environment (TRE). The phone stays outside the bank's control. The TRE gives the bank a protected place within it to detect threats and produce signals its fraud team can rely on. In a controlled simulation of a Coretax attack, Promon showed Shield for Mobile blocking untrusted screen readers, screen mirroring, and emulated input.

The TRE covers the protected app and the evidence it produces. The rest of the phone, and what the customer intended, remain for the fraud team to judge alongside everything else it knows.

Read more on the TRE: Build it. Prove it. Then release the data: Runtime trust for the browser

Joining the two views

Banks don't need to replace their fraud platforms to use runtime evidence. It works best alongside the intelligence they already rely on.

That's the idea behind the strategic alliance between LexisNexis Risk Solutions and Promon announced on July 1, 2026. It combines access to LexisNexis® ThreatMetrix® digital identity, device, and behavioral intelligence with Promon Shield in-app protection and Promon Insight trusted telemetry. As Grayson Clarke, Chief Commercial Officer at LexisNexis Risk Solutions, put it: "Fraud prevention is increasingly dependent on understanding the full context of a digital interaction."[4]

Promon Insight carries Shield's detections out of the app. It turns them into structured, timestamped signals that can be routed into the fraud and security tools your teams already use. Your fraud policy stays yours. Runtime signals give it more to work with when it decides whether an authenticated action deserves a second look.

missing layer in mobile fraud protection-02

Seeing the session from both sides

Behavioral models will keep improving, and malware authors will keep adapting to them. Protected evidence from inside the app changes the attacker's task. Looking human to the fraud model is no longer enough when the app itself can report how the input arrived.

Before you add runtime signals to a fraud decision, check that they're fit for it. Our guide, How to evaluate runtime signals from mobile banking apps, sets out five tests. To see how Promon protects banking apps and turns runtime detections into fraud signals, explore mobile app fraud prevention.

References

[1] ThreatFabric, New Android Malware Herodotus Mimics Human Behaviour to Evade Detection, 28 October, 2025.

[2] Promon, App Threat Report Q2 2026: Coretax Android Banking Malware, 7 July, 2026.

[3] Group-IB, Vwork: Weaponized Open-source Software as an Addon for Gigabud, 9 September, 2026.

[4] LexisNexis, LexisNexis Risk Solutions and Promon Align to Strengthen Mobile Fraud Prevention, 1 July, 2026.

See what's happening inside your app
Give your fraud team trusted runtime signals to complement existing fraud intelligence. Learn how Promon helps protect mobile banking sessions against tampering and interference.
Book a meeting