Steal Application Access Token: URI Hijacking

Adversaries may register Uniform Resource Identifiers (URIs) to intercept sensitive data.

Applications regularly register URIs with the operating system to act as a response handler for various actions, such as logging into an app using an external account via single sign-on. This allows redirections to that specific URI to be intercepted by the application. If an adversary were to register for a URI that was already in use by a genuine application, the adversary may be able to intercept data intended for the genuine application or perform a phishing attack against the genuine application. Intercepted data may include OAuth authorization codes or tokens that could be used by the adversary to gain access to protected resources.[1][2]

ID: T1635.001
Sub-technique of:  T1635
Tactic Type: Post-Adversary Device Access
Platforms: Android, iOS
Contributors: Leo Zhang, Trend Micro; Steven Du, Trend Micro
Version: 1.0
Created: 01 April 2022
Last Modified: 06 April 2022


ID Mitigation Description
M1013 Application Developer Guidance

Developers should use Android App Links[3] and iOS Universal Links[4] to provide a secure binding between URIs and applications, preventing malicious applications from intercepting redirections. Additionally, for OAuth use cases, PKCE[2] should be used to prevent use of stolen authorization codes.

M1006 Use Recent OS Version

iOS 11 introduced a first-come-first-served principle for URIs, allowing only the prior installed app to be launched via the URI.[1] Android 6 introduced App Links.

M1011 User Guidance

Users should be instructed to not open links in applications they don’t recognize.


On Android, users may be presented with a popup to select the appropriate application to open the URI in. If the user sees an application they do not recognize, they can remove it. When vetting applications for potential security weaknesses, the vetting process could look for insecure use of Intents. Developers should be encouraged to use techniques to ensure that the intent can only be sent to an appropriate destination (e.g., use explicit rather than implicit intents, permission checking, checking of the destination app's signing certificate, or utilizing the App Links feature). For mobile applications using OAuth, encourage use of best practice. [5][6]