iOS URL scheme hijack → OAuth code theft

§ Context

Assumed environment: target app uses an OAuth flow that returns to a custom URL scheme (myapp://oauth/callback). A rogue app declares the same scheme. iOS < 14 doesn't disambiguate.

§ Steps

1. 01
   Sideload / TestFlight to victimInitial Access

   T1078— Valid Accounts
2. 02
   Victim initiates OAuth — callback hits rogueExecution

   T1204— User Execution
3. 03
   Exchange code for tokens at providerLateral Movement

   T1550— Use Alternate Authentication Material
4. 04
   Capture authorisation codeCredential Access

   W-OAUTH-MISCONFIG— OAuth — redirect_uri Misconfig
5. 05
   Identify target's URL schemeReconnaissance

   MOB-APK-REVERSE— APK Reverse Engineering
6. 06
   Build rogue app with matching schemeInitial Access

   MOB-IOS-URL-SCHEME— iOS URL Scheme Hijack

§ References

• T1078Valid Accounts
• T1204User Execution
• T1550Use Alternate Authentication Material

§ Frequently asked

What is the "iOS URL scheme hijack → OAuth code theft" attack path?

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. It chains 6 steps drawn from real-world offensive-security techniques.

What starting position does this attack require?

The first step is Sideload / TestFlight to victim (T1078) — a initial access primitive. Assumed environment: target app uses an OAuth flow that returns to a custom URL scheme (myapp://oauth/callback).

What is the final impact of this kill-chain?

The final step lands on Build rogue app with matching scheme (MOB-IOS-URL-SCHEME), which falls under Initial Access. 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 techniques3

  OAuth redirect_uri misconfig → account takeover

  Provider accepts loose redirect_uri matching (wildcard, partial, open-redirect chain). Steal the authorization code by redirecting it through an attacker host.

• Shared techniques2

  Trusted updater hijack → wormable destructive payload (NotPetya / M.E.Doc)

  Compromise a niche third-party vendor (regional tax software, niche industry tooling). Push a malicious update; every customer auto-installs it. Payload spreads via SMB + Mimikatz, wipes drives.

• Shared techniques2

  SAML signature wrapping (XSW) → impersonate admin

  Capture a legitimate SAML response. Re-arrange the XML so the IdP's signature still validates against the original assertion, but the SP parses an attacker-injected assertion claiming Admin.

• 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

  Malicious browser extension → cookie harvest → ATO

  Publish a useful-looking extension (ad-blocker / PDF reader). It quietly reads cookies + localStorage from sensitive sites and ships them to the attacker.

• Shared techniques2

  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.