A vulnerable app often relies on sensitive screens that do not block overlays, accepts touch input without checking whether the view is obscured, or uses custom authentication flows that can be visually copied. Risk is highest when the app handles passwords, PINs, card data, or permission prompts and lacks runtime checks for overlay presence.
How overlay phishing succeeds on Android
Overlay-based phishing works when an app allows another window or screen layer to sit on top of a sensitive prompt, then accepts user input without proving the visible UI is the real UI. The weakness is usually not the visual imitation alone, but the app’s failure to detect obscured touches, reject interaction while covered, or protect high-risk flows such as login, payment, and permission approval.
The most telling sign is that the app treats screen visibility as trustworthy. If a malicious app can draw above it, the user may believe they are entering credentials or approving a legitimate action when the input is actually captured elsewhere. That is why sensitive journeys need explicit overlay checks, not just cosmetic warnings.
High-risk examples include authentication screens, card entry, PIN prompts, and permission dialogs. These surfaces are attractive because a successful overlay attack can convert a moment of user trust into credential theft, transaction fraud, or unauthorized privilege grant. For a practical attack example involving token theft and phishing-style abuse, see CoPhish OAuth Token Theft via Copilot Studio.
Android app teams should also treat any custom authentication flow as a signal to examine whether the UI can be faithfully copied. If the flow depends on visual familiarity rather than a hardened system dialog, the attacker often needs only a convincing lookalike and a permissive overlay posture to succeed.
Signals that the app is exposed
Look for screens that remain interactive even when another window partially covers them, because that often means the app is not checking whether the view is obscured. If the user can still tap through overlays, or if the app never blocks input on top of a password, PIN, or approval screen, the attack path is likely open.
Another sign is inconsistent handling across the app. A developer may protect the main login screen but leave recovery, reauthentication, one-time code entry, or consent prompts unprotected. In practice, attackers target the weakest step in the journey, not the most obvious one.
Misleading custom UI is also a warning sign. If the app uses its own credential form, biometric fallback, or permission-like prompt instead of relying on stronger platform patterns, it becomes easier to imitate. Overlay phishing does not require code execution inside the app, only a believable surface and a user who thinks the surface is legitimate.
Where the app is part of a broader access or transaction workflow, the same visual trust problem can expose downstream systems and data. The phishing screen is only the entry point; the real impact is often account takeover, payment abuse, or unauthorized action after the attacker captures the user response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 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 | CIS Control 6 — Access Control Management | Overlay phishing exploits weak control over sensitive UI actions. |
| Recommendation — Restrict high-risk actions to verified, protected interaction paths. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Sensitive Android flows depend on trustworthy user interaction and access decisions. |
| PR.PT — Protective Technology | Overlay checks and input blocking are protective technology measures against phishing overlays. | |
| Recommendation — Protect authentication and approval flows from UI impersonation and tampering. Implement runtime protections that detect and block obscured interaction. | ||
| OWASP Agentic AI Top 10 | A1 — Agent Goal Hijacking | Phishing-style UI deception hijacks user intent through a fake interaction layer. |
| Recommendation — Constrain deceptive interaction surfaces that can redirect user decisions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Overlay phishing often targets credentials, tokens, and approval prompts. |
| Recommendation — Protect credential-entry paths with runtime checks and least-exposed UI design. | ||
Practitioner Guidance
What to verify: Confirm whether sensitive screens reject obscured touches and whether the app blocks input when overlays are present. Test login, payment, PIN, and permission paths separately, because protection is often uneven across flows.
- Exercise the app with a known overlay present and verify the app denies the interaction rather than merely warning the user.
- Inspect custom authentication and consent flows for copyable layouts, weak visual cues, and missing runtime overlay checks.
- Prioritise remediation on any screen where a single successful tap can expose secrets, approve access, or authorise a high-value action.
Common mistake: Treating overlay phishing as a pure user-awareness issue. Training helps, but it does not remove the core condition, which is that the application allowed an untrusted layer to intercept a trusted decision.
Practitioner takeaway: The app is vulnerable when it trusts what the user sees more than whether the UI is actually unobscured. Harden the highest-value screens first, because that is where a single overlay interaction becomes a real compromise.
Related resources from NHI Mgmt Group
- What are the signs that an Android app may be using overlays or activity injection for fraud?
- What are the signs that browser-based phishing detection is failing?
- What are the signs that Android file sharing code is vulnerable to path traversal?
- What are the signs that an organisation is still vulnerable to credential-based attacks?
