These techniques work together to capture both credentials and transaction data while bypassing normal user expectations. SMS interception steals one-time codes, overlays trick users into entering secrets into fake pages, and keylogging captures additional credentials and messages. Combined, they increase the chance of account takeover even when one collection method is blocked or incomplete.
Why This Matters for Security Teams
Android banking trojans succeed when they can observe, redirect, and complete the same workflow a legitimate banking app expects. SMS interception removes a common second factor, overlays capture credentials in a way that looks normal to the user, and keylogging fills the gaps by collecting anything the other two methods miss, including recovery codes, account numbers, and session-adjacent inputs. That layered collection is what makes these families resilient rather than simply noisy.
This matters because mobile fraud is rarely won by a single stolen secret. Banking apps, SMS-based verification, and user-entered credentials are often spread across separate trust assumptions, so attackers combine techniques to collapse those boundaries in one infection chain. ENISA Threat Landscape style analysis is useful here because it consistently shows that threat actors prefer overlapping techniques that increase success when one control blocks only part of the flow. In practice, many security teams first notice this pattern only after customers report an apparently valid login that was actually assembled from multiple stolen inputs.
How It Works in Practice
These trojans are built to maximise capture probability across the whole banking journey, not just at login. SMS theft defeats one-time passwords and transaction confirmation codes, overlays sit on top of trusted apps to harvest credentials or approve actions, and keylogging records whatever the attacker did not already catch, such as passphrases, PINs, and message content. Together, they create redundancy: if the user changes a password, the malware may still harvest the OTP; if the OTP flow changes, the overlay or keylogger may still capture the next useful secret.
The practical advantage is that each technique covers a different failure point in the user interaction chain. Overlays are effective when users rely on visual trust and do not verify the active window. Keylogging is effective when an app reuses fields, displays sensitive text, or allows copy-paste and accessibility-driven input paths. SMS interception is effective when the attacker can suppress or read incoming messages before the user notices. That combination also helps evade partial defenses, because a bank may block one path while leaving another available.
- SMS interception is most valuable when authentication still depends on texted codes.
- Overlays matter most when the app does not strongly bind the user to a verified transaction context.
- Keylogging adds coverage when the attacker wants credentials, recovery data, or secondary secrets beyond the login form.
A useful way to think about the attack is as chained data collection, where each method increases the odds that at least one credential path survives the user experience. OWASP API Security Top 10 is not about mobile malware specifically, but its emphasis on broken authorization and abuse of trusted flows maps well to the way trojans exploit legitimate banking interactions. These controls tend to break down when the bank still treats SMS and app UI as separable trust signals rather than parts of one transaction path.
Common Variations and Edge Cases
Tighter mobile fraud controls often increase user friction, so banks have to balance convenience against the need to bind authentication to the actual device, app state, and transaction context. That tradeoff becomes sharper when the user base includes older Android versions, accessibility services, or legacy SMS-based recovery flows.
Some trojans lean more heavily on overlays, while others emphasise accessibility abuse, notification capture, or SMS forwarding depending on device permissions and OS restrictions. Best practice is evolving, but the central pattern remains the same: attackers choose the mix that preserves coverage after one technique fails. In environments that use app-based push approvals, the same family of malware may shift from password theft to transaction manipulation rather than abandoning the campaign.
Another edge case appears when the bank has already reduced SMS dependence. Even then, overlays and keylogging can remain effective against first-run enrolment, profile changes, beneficiary additions, and support workflows, because those steps often expose higher-value actions than day-to-day login. The answer therefore changes by stage of compromise, not just by authentication method.
Risk and Threat Considerations
The material risk is account takeover through layered credential capture and transaction interception. These trojans are dangerous because they do not depend on a single weakness, they exploit the overlap between human trust, mobile UI trust, and weak second-factor handling.
Failure mechanism: The malware intercepts SMS codes, renders a fake login or payment screen over the real app, and logs additional input so that one stolen factor can compensate for another that is blocked or missing. That creates a resilient abuse path across login, enrolment, and payment confirmation.
Impact: The attacker can authenticate as the customer, approve fraudulent transfers, change recovery details, and keep access even if one credential is rotated, because the compromise covers multiple stages of the user journey.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | SMS theft and overlays abuse access paths that should be tightly controlled. |
| Recommendation — Restrict and review access paths for banking actions and step up controls for high-risk events. | ||
| MITRE ATT&CK | T1056.001 — Keylogging | The question explicitly includes keylogging as a core malware technique. |
| T1113 — Screen Capture | Overlay abuse targets user input and visible banking context on the screen. | |
| Recommendation — Detect keylogging behavior and correlate it with credential theft activity. Hunt for screen overlay abuse and validate that sensitive input is bound to the real app. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The attack chain breaks authentication and access assurance across the mobile banking flow. |
| DE.CM — Security Continuous Monitoring | Mobile trojans require monitoring for suspicious input capture and UI abuse. | |
| Recommendation — Strengthen authentication binding and require stronger assurance for transaction approval. Monitor for anomalous mobile behaviors that indicate credential capture or app tampering. | ||
Practitioner Guidance
What to prioritise: Treat SMS, overlays, and keylogging as a single mobile fraud pattern rather than separate symptoms. Detection should focus on whether the device can independently verify app integrity, input context, and message handling before the bank trusts any second factor.
What to verify: Confirm that high-risk actions cannot be completed with SMS alone, that overlay detection or runtime integrity checks are enforced where feasible, and that transaction approval is bound to the specific payee and amount rather than only to a generic session.
Decision rule: If a compromise path can still succeed after the user changes the password or receives a fresh OTP, the control set is too weak for mobile banking risk. At that point, step up to stronger device binding, fraud analytics, and transaction-level verification.
Practitioner takeaway: The important judgement is not whether one malware technique is blocked, but whether the entire banking flow can still be trusted when the device is already hostile.
Related resources from NHI Mgmt Group
- Why do compliance gaps often increase business and financial risk at the same time?
- How should teams govern hybrid Active Directory and Entra ID at the same time?
- Why do role-based access models often lead to over-privilege over time?
- Why do SMS and email one-time passwords remain risky for enterprise access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
