What is the difference between overlay attacks and activity injection on Android?

Why This Matters for Security Teams

Overlay attacks and activity injection are often discussed as user-interface tricks, but the security impact is broader: both can defeat trust signals that mobile apps rely on to protect credentials, session tokens, and step-up authentication flows. On Android, the difference matters because an overlay may only obscure the real screen, while activity injection can present a fuller counterfeit experience that is harder for users and some controls to distinguish from the genuine app.

That distinction affects mobile fraud detection, secure authentication design, and incident triage. If a team only looks for screen overlays, it may miss the more invasive case where a malicious activity or embedded WebView mimics the entire interaction path. For defenders, the practical question is not just whether a fake screen appears, but whether the attacker has inserted themselves into the application flow at the point where secrets are entered or approvals are granted. Guidance on mobile abuse patterns aligns with broader attack taxonomy used by the MITRE ATT&CK Enterprise Matrix, which helps teams map the behaviour to detection and response steps.

In practice, many security teams encounter these techniques only after phishing-resistant controls or fraud monitoring have already been bypassed by a convincing handset-level impersonation.

How It Works in Practice

An overlay attack usually depends on the Android permission model and the user’s ability to continue interacting with the legitimate app beneath a deceptive layer. The malicious app may request overlay-related privileges, then render a nearly identical prompt over a login screen, payment approval page, or consent dialog. If the user enters credentials or taps confirm, the attacker captures the response without needing to fully replace the original interface.

Activity injection is more aggressive. Rather than merely covering the screen, the attacker starts a fake activity or a WebView that replicates the target app’s style, copy, and input sequence. This can be done through abused intents, malicious app components, or a compromised app bundle that invokes imitation screens at the right moment. The result is a more complete deception because the user sees an interaction flow that feels native to the app, not an obvious pop-up.

• Overlays are strongest when the goal is to steal a single credential or approval action.
• Activity injection is stronger when the goal is to capture a full login, MFA, or payment journey.
• Both techniques become more dangerous when the app trusts visual state more than process integrity or device attestation.
• Detection often needs app telemetry, suspicious activity launches, accessibility abuse signals, and behavioural fraud analytics together.

Mobile defenders should also track how these behaviours appear in current advisories and incident write-ups, including the CISA cyber threat advisories, because attacker tradecraft often shifts from simple overlays to more reliable session hijacking and UI imitation. These controls tend to break down when Android apps depend on WebView-based login flows and accept user input without strong runtime integrity checks.

Common Variations and Edge Cases

Tighter anti-fraud controls often increase friction, requiring organisations to balance user experience against stronger assurance. That tradeoff is especially visible on Android because some legitimate apps use overlays for accessibility, chat heads, or in-app guidance, and some enterprise workflows rely on embedded WebViews for convenience. Best practice is evolving, and there is no universal standard for when a WebView or overlay should be treated as hostile by default.

One common edge case is accessibility tooling. A defensive team can misclassify legitimate assistive features as malicious if it relies only on overlay detection. Another is rooted or heavily modified devices, where both overlay abuse and activity injection become easier to conceal and harder to attribute. A third edge case is agentic or AI-assisted fraud, where an attacker may use automation to time the fake screen to the genuine user journey. That kind of orchestration is better understood through broader campaign analysis, such as the Anthropic — first AI-orchestrated cyber espionage campaign report, which shows how automation can improve coordination even when the interface trick itself is simple.

For hardening, teams should prefer phishing-resistant authentication, device integrity checks, and app-side validation of risky actions rather than trusting what the user sees alone. The most brittle environments are consumer Android fleets with inconsistent patching, side-loaded apps, and WebView-driven auth flows that lack runtime attestation.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection and traditional injection attacks?
• What is the difference between prompt injection risk and identity abuse in agents?
• What is the difference between activity metrics and risk metrics in IAM?
• What is the difference between prompt injection and credential theft for agents