Overlay phishing is the use of a fake screen placed over a legitimate mobile app to harvest credentials or transaction approvals. The user believes they are interacting with the real application while the malware captures inputs or alters what is shown.
How overlay phishing works
Overlay phishing is effective because it sits on top of a trusted mobile experience and steals the moment when the user is most likely to comply. The overlay can mimic login fields, payment prompts, consent dialogs, or security warnings, making the malicious layer look like part of the app itself.
This matters because the attacker is not always trying to defeat the app’s backend directly. Instead, the goal is to capture what the user types, presses, or approves before the legitimate application can authenticate, authorize, or record the action.
Why overlay phishing is dangerous
The technique is dangerous on both mobile and identity boundaries. If the fake screen captures passwords, one-time codes, session confirmations, or transaction approvals, the attacker can move from simple credential theft into account takeover, payment fraud, or unauthorized approval flows. A good overview of the broader phishing patterns that make these lures convincing is available in the Phishing Guide.
Overlay attacks are especially effective when users are already conditioned to expect in-app authentication or urgent prompts. They exploit trust in the device state, the app’s appearance, and the user’s habit of approving quickly without checking whether the prompt is genuine.
Where organisations are exposed
Exposure is highest when mobile devices can run untrusted apps, accessibility abuse, or screen-overlay malware without strong device controls. Organisations also face greater risk when mobile apps contain high-value actions such as payments, token approvals, password resets, or support workflows that can be socially engineered through a convincing overlay.
Exposure review should focus on whether sensitive workflows are reachable from compromised endpoints, whether approval steps are visible only on the device, and whether users can be tricked into entering secrets into a lookalike layer. Identity-safe design helps here: phishing-resistant authentication and strong session protection reduce the usefulness of stolen inputs, which is why the NIST Digital Identity Guidelines are so relevant to this problem.
Defences and response
Defence works best when the app, the device, and the authentication method all deny the attacker something useful. User education alone is not enough. Organisations need controls that make the genuine prompt harder to imitate, reduce the value of captured credentials, and make abnormal approvals easier to spot in logs and transaction records.
For systems that rely on strong authentication and session assurance, the control intent aligns with the NIST SP 800-53 Rev 5 Security and Privacy Controls around identification, authentication, and monitoring, while the operational threat path can be mapped with the MITRE ATT&CK Enterprise Matrix.
After suspected use of an overlay phish, organisations should review authentication logs, approval events, and any unusual device or session behaviour. If the attack may have captured reusable secrets, the response should include credential rotation, session invalidation, and review of any transactions or consent grants made during the suspicious window.
How to reduce the chance of successful overlay phishing
Prevention is strongest when mobile app design, identity controls, and detection all work together. Use step-up checks for high-risk actions, avoid asking for unnecessary secrets inside the app flow, and make transaction details visible in a way that is difficult for an overlay to spoof. Where approvals depend on tokens or session state, the relevant hardening should include the same credential and lifecycle discipline discussed in the Ledger Connect Kit npm compromise 2023 and the Dropbox GitHub breach 2022, where stolen or abused access enabled downstream compromise.
Detection should look for unusual overlay permissions, suspicious accessibility-service use, and repeated failures or reversals in sensitive approval flows. If the organisation already treats phishing as a material access-risk vector, the same governance lens used in the CoPhish OAuth phishing via Copilot Studio is useful here: the payload may be different, but the trust abuse pattern is the same.
Risk and Threat Considerations
Overlay phishing creates a direct compromise path from a trusted mobile interface to secret capture or fraudulent approval. The main danger is not just stolen credentials, but the attacker’s ability to make the victim authorise actions they believe came from the legitimate app.
Failure mechanism: Malware draws a convincing fake screen over the real app, captures input before it reaches the genuine workflow, or alters what the user sees so the approval looks normal.
Impact: Attackers can steal credentials, hijack sessions, approve transactions, or trigger account actions that appear user-authorised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Overlay phishing targets credentials and user authentication prompts. |
| Recommendation — Use phishing-resistant authenticators and reduce reliance on secrets that can be captured from fake screens. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Mobile overlays commonly steal organizational user credentials and approvals. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Reviewing suspicious approvals and log patterns is central after overlay abuse. | |
| Recommendation — Enforce strong user authentication and harden high-risk approval flows against impersonation. Correlate approvals, authentications, and session events to identify malicious or unusual activity. | ||
| MITRE ATT&CK | T1056 — Input Capture | Overlay phishing captures typed secrets and approvals through deceptive UI layers. |
| T1112 — Modify Registry | Not applicable | |
| Recommendation — Map suspicious mobile input capture activity to T1056 and investigate for credential theft. | ||
Practitioner Guidance
Why practitioners should care: Overlay phishing is an identity and transaction integrity problem as much as it is a malware problem. Security teams should treat it as a trust-boundary failure in the mobile approval path, not just as a user-awareness issue.
What to watch for: Unusual app-overlay permissions, accessibility abuse, repeated suspicious prompts, or approvals that do not match expected user behaviour deserve immediate review. The practical question is whether the real app can still be trusted to collect the user’s intent without interference.
Related resources from NHI Mgmt Group
- Why do Android overlay attacks create such a high phishing risk for mobile apps?
- What are the signs that an Android app is vulnerable to overlay-based phishing?
- What happens when mobile banking Trojans combine phishing with app overlay attacks?
- What is phishing-resistant authentication and how does it relate to NHI security?