What happens when mobile banking is used on a device with a malicious message-forwarding app?

Why a Message-Forwarding App Changes the Banking Risk Profile

A banking session is only as trustworthy as the device that carries the authentication step. When a malicious message-forwarding app is present, the attacker is no longer trying to guess the customer’s password in isolation. They are exploiting the mobile device as a credential relay, which can turn a normal login flow into a fraud-enabling one even when the bank’s server-side checks still appear to pass.

That matters because one-time passwords and transaction confirmations are often treated as proof of user presence, yet forwarded messages can make that proof unreliable. A stolen or redirected OTP can be enough to satisfy a weak second factor and allow the attacker to complete a payment under the victim’s identity. For organisations that rely on SMS or message-based verification, the issue is not just account takeover but the false confidence created by a “successful” authentication event. In practice, many teams discover the compromise only after an apparently legitimate payment has already cleared, rather than through intentional fraud detection.

For a broader view of how identity-bound access can be abused when trust is misplaced in a workflow, OWASP Non-Human Identity Top 10 is useful where device-side or delegated access patterns matter.

How the Attack Works Across the Device, Message Channel, and Bank

The malicious app does not need to break the bank’s controls directly. It focuses on the mobile device, where it can read incoming messages, observe notification previews, intercept accessibility events, or forward content to a remote endpoint. In practical terms, that means the attacker may obtain the OTP before the customer sees it, or the app may auto-forward it fast enough that the attacker can replay it within the token’s short validity window.

Once the attacker has the code, the rest of the sequence can look ordinary. The victim may still open the banking app, the bank may still see the correct username and the expected second factor, and the transaction may still present as authorised. The failure occurs because the second factor has been reduced to something the device can leak, rather than something only the legitimate user can produce. This is why message-based verification is fundamentally weaker than phishing-resistant authentication methods that bind the authentication ceremony to the real device and the real session.

• The app captures or forwards incoming messages containing OTPs or payment approvals.
• The attacker uses the code before it expires, or combines it with a live session already obtained elsewhere.
• The bank sees a valid authentication path, while the true control failure sits on the endpoint.
• Fraud analytics may miss the issue if they rely too heavily on “correct OTP entered” as a trust signal.

Where this guidance breaks down is when the mobile device is already deeply compromised, because at that point message interception can be only one of several simultaneous abuse paths.

When the Standard Answer Is Not Enough

Tighter authentication often increases friction, so organisations have to balance usability against the reality that OTP delivery over the same compromised device is not strong assurance. That tradeoff becomes sharper when the victim’s banking app, message app, and notification channel all live on one endpoint. The control is not failing because it is absent, but because it is co-located with the attacker’s collection point.

There are also edge cases where forwarding is not the whole story. Some malicious apps rely on notification access rather than full SMS access. Others combine forwarding with screen overlays, accessibility abuse, or session hijacking so that the OTP is only one step in a broader compromise. In those cases, the practical question is not “Was the OTP stolen?” but “What trust boundary did the app cross, and what else on the device can it observe or alter?”

Guidance versus consensus: there is broad agreement that SMS OTP is weaker than phishing-resistant methods, but there is less consensus on how much residual risk remains acceptable for low-value transactions. That decision depends on the account type, transaction value, recovery process, and whether the bank can detect device integrity failure quickly enough to block abuse before funds move.

Risk and Threat Considerations

The material risk is account takeover through device-side interception of authentication material. A malicious message-forwarding app can convert a supposedly user-held second factor into attacker-held access, which undermines both login assurance and transaction approval.

Failure mechanism: The app abuses device permissions, notification access, or message-reading capability to capture OTPs and forward them to the attacker in near real time. The bank then validates a code that was not exclusively available to the customer, so the authentication ceremony remains formally correct but substantively compromised.

Impact: Attackers can authorise payments, add payees, or complete other high-trust actions while the bank records an apparently legitimate session. This can also delay detection, because logs may show successful authentication rather than obvious credential theft.

Practitioner Guidance

What to prioritise: Treat message-based OTP as a degraded control on any device that can install third-party apps, especially when the same device handles banking and messaging. The important judgement is not whether OTP works technically, but whether it still provides independent user possession in the real operating environment.

What to verify: Confirm whether the bank can distinguish a clean authenticator from a compromised endpoint through device integrity checks, behavioural signals, or step-up challenges on sensitive actions. If the only evidence of legitimacy is “the code was correct,” the control is too weak for meaningful fraud resistance.

Decision rule: If the customer workflow depends on the same phone for both receiving and approving access, treat that phone as a single point of failure and escalate to stronger phishing-resistant methods for higher-risk transactions. If the environment cannot support that, reduce transaction scope or add compensating review before approval.

Practitioner takeaway: The real control failure is not the OTP itself, but the assumption that the device delivering it is separate from the attacker’s collection path.

Related resources from NHI Mgmt Group

• What breaks when mobile banking apps treat device integrity as a binary control?
• Why do mobile permissions become a governance problem once a malicious app is installed?
• What breaks when mobile device management is limited to app blacklisting?
• How should organisations govern mobile SDKs that collect app and device data?