Activity Hijacking

How Activity Hijacking Works

Activity hijacking exploits the way Android hands off screens between apps. An attacker inserts a malicious activity into the task flow so the user sees an interface that looks legitimate, but the interaction is actually being captured by the attacker-controlled screen.

This is not just a visual trick. The security issue is that the operating system may allow the attacker’s activity to sit inside a trusted user journey, which makes the attack effective even when the user believes they are still inside the intended app.

Why Activity Hijacking Is Dangerous

The main danger is that the user’s decision point is no longer protected by the app they think they are using. That can expose credentials, recovery codes, payment approvals, or other sensitive actions that depend on the user trusting the visible interface.

The risk is amplified when the targeted flow includes authentication prompts, approval dialogs, or consent screens. In those cases, the attacker is not only stealing input, but also hijacking a trust boundary that the victim expects to belong to the original application.

Common Attack Conditions and Abuse Paths

Activity hijacking typically depends on weaknesses in task and activity handling, plus UI assumptions that were safe in earlier Android designs or in poorly hardened apps. Attackers look for flows where a screen transition, overlay-like behaviour, or back-stack confusion can be turned into a fake step in the journey.

Because the technique lives inside normal app navigation, it can blend in with routine user behaviour. That makes it especially useful for credential theft, approval theft, and deceptive capture of one-time actions that should have been bound to the real app context.

Defensive Checks and Safer App Design

Defending against activity hijacking means treating the user journey as part of the security boundary. App teams should harden sensitive flows so the intended activity remains the one the user is actually interacting with, and they should assume that navigation state can be manipulated if the platform and app controls are weak.

Security review should focus on the most sensitive screens first: sign-in, consent, recovery, and payment approval. Where the platform or app cannot guarantee a trustworthy transition, the safer design choice is to reduce reliance on that transition for high-value actions and to add stronger reauthentication or context binding.

Risk and Threat Considerations

Activity hijacking is dangerous because it turns a normal Android navigation path into a credential or approval theft opportunity. The attacker does not need to break the user’s trust visually, only to insert a convincing screen at the right moment in the task flow.

Failure mechanism: The app or platform accepts an attacker-controlled activity into a trusted transition sequence, so the victim enters secrets or confirms actions on the wrong screen.

Impact: Stolen credentials, unauthorized approvals, and fraudulent user actions can follow, especially when the hijacked screen targets login, consent, or transaction flows.

Practitioner Guidance

What to watch for: Review any Android flow where a sensitive action depends on a screen transition, back-stack change, or return path. Those are the places where user expectation and actual execution can diverge.

Governance implication: Security ownership should sit with the app team for sensitive user journeys, not just with mobile platform policy. If a flow can be abused to capture credentials or approvals, it deserves the same scrutiny as any other authentication or transaction path.

Related resources from NHI Mgmt Group

• How do security teams know browser hijacking is happening rather than ordinary user activity?
• How should security teams monitor AI agent activity without disrupting developers?
• How can SOC teams use identity context to improve response to agent activity?
• What is the difference between activity metrics and risk metrics in IAM?