Deeplink abuse → in-app account takeover
Exported activity registers a custom URL scheme that triggers an OAuth-style 'confirm reset' action without validating the source — phishing URL clicks reset another user's password.
§ Context
Assumed environment: target Android app declares an exported activity with an intent-filter for a custom scheme (myapp://...). The activity processes parameters without checking caller identity.
§ Steps
- 01Account takeoverInitial AccessT1078— Valid Accounts
- 02Lure victim to click the linkInitial AccessT1566— Phishing
- 03App fires privileged internal actionPrivilege EscalationW-IDOR— Insecure Direct Object Reference (IDOR)
- 04Reverse the APKReconnaissanceMOB-APK-REVERSE— APK Reverse Engineering
- 05Locate exported activity + deeplink handlerInitial AccessMOB-DEEPLINK-ABUSE— Android Deeplink / Intent Abuse
- 06Craft malicious deeplink URLPrivilege EscalationMOB-INTENT-INJECT— Intent Injection / Pending Intent Abuse
§ References
- T1078Valid Accounts
- T1566Phishing
§ Frequently asked
- What is the "Deeplink abuse → in-app account takeover" attack path?
- Exported activity registers a custom URL scheme that triggers an OAuth-style 'confirm reset' action without validating the source — phishing URL clicks reset another user's password. It chains 6 steps drawn from real-world offensive-security techniques.
- What starting position does this attack require?
- The first step is Account takeover (T1078) — a initial access primitive. Assumed environment: target Android app declares an exported activity with an intent-filter for a custom scheme (myapp://.
- What is the final impact of this kill-chain?
- The final step lands on Craft malicious deeplink URL (MOB-INTENT-INJECT), which falls under Privilege Escalation. From here, an operator typically pivots into post-exploitation or maintains persistence.
- How can defenders detect or prevent this attack?
- Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.
§ Related dossiers
- Shared techniques2
FIDO2 caBLE hybrid → phone authenticator hijack
Attacker phishing site shows the legitimate FIDO2 QR. Victim scans with their phone authenticator. The link completes the WebAuthn ceremony in the attacker's browser — they're now signed in as the victim.
- Shared techniques2
BLE eavesdrop + replay → smart lock open
Smart lock uses BLE Just-Works pairing + plaintext 'unlock' opcode. Sniff once with a nRF52 in monitor mode, replay later from a $10 device.
- Shared techniques2
Exported ContentProvider → private data leak
App exports a ContentProvider for legitimate inter-app integration but forgets to enforce grantUri / signature permissions — a rogue installed app reads private auth tokens.
- Shared techniques2
WebView XSS → JS bridge → native code exec
WebView loads partially-attacker-controlled content (e.g. injected referral param) and exposes addJavascriptInterface — XSS in the page calls the bridge to run app-level code.
- Shared techniques2
iOS URL scheme hijack → OAuth code theft
Multiple apps register the same custom URL scheme — a rogue app installed alongside the target receives the OAuth callback containing the authorisation code, then exchanges it for tokens.
- Shared techniques2
AITM phishing (Evilginx) → M365 session theft → mailbox exfil
Reverse-proxy phishing kit intercepts the entire login flow including MFA. Stolen session cookie → access M365 mailbox / SharePoint without retriggering auth.