Deep Link Exploitation

Abusing an app's URI scheme or App Link handling to trigger unintended behavior: opening internal activities, injecting parameters, stealing OAuth tokens, or redirecting the user to attacker-controlled content.

MITRE ATT&CK

ID	Technique	Tactic
T1635.001	Steal Application Access Token: URI Hijacking	Credential Access

T1635.001 covers registering competing URIs to intercept OAuth tokens and authorization redirects, which is functionally equivalent to deep link hijacking.

Requirements

Requirement	Details
Permission	None
Condition	Target app handles custom URI schemes or deep links without proper validation

How Deep Links Work

Android apps register to handle URIs via intent filters:

Custom URI Schemes

<activity android:name=".DeepLinkActivity" android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="myapp" android:host="action" />
    </intent-filter>
</activity>

Any app can trigger this with myapp://action/some-path.

App Links (Android 6+)

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="https" android:host="example.com" android:pathPrefix="/app" />
</intent-filter>

App Links use HTTPS and require domain verification via /.well-known/assetlinks.json. When verified, the app handles the URL directly without a chooser dialog.

Attack Patterns

Custom Scheme Hijacking

Custom URI schemes (myapp://, mybank://) are not verified. Any app can register an intent filter for the same scheme. If two apps handle myapp://callback, the system shows a chooser or picks one based on priority.

This is critical for OAuth flows: if a banking app uses mybank://oauth/callback?code=XXX as its redirect URI, a malicious app registering the same scheme can intercept the authorization code.

WebView URL Loading

If the target app loads deep link URLs into a WebView without sanitizing:

myapp://webview?url=https://evil.com/phishing.html

The app opens attacker-controlled content inside its own WebView, potentially with access to JavaScript interfaces or the app's cookie store. See WebView Exploitation.

Intent Parameter Injection

Deep links often map URL parameters to intent extras:

myapp://transfer?to=attacker&amount=1000

If the app doesn't validate the source of the intent, it may process this as a legitimate internal navigation.

App Link Verification Bypass

App Link verification depends on /.well-known/assetlinks.json being properly configured. If:

• The file is missing or misconfigured
• The app doesn't set android:autoVerify="true"
• Verification fails silently

Then the link falls back to being a regular deep link (chooser dialog), and scheme hijacking applies.

Fragment / Path Traversal

Some apps use the URI path to navigate internal screens:

myapp://screen/admin/settings

If path validation is weak, an attacker may reach internal activities not meant for external access.

Real-World Cases

Target	Vulnerability
OAuth redirect hijacking	Malicious app intercepts OAuth callback, steals authorization code, gains account access
Banking app deep links	Direct navigation to transfer screens with pre-filled parameters
WebView-based apps	URL parameter loads external content inside the app's WebView context
Payment apps	Deep links to payment confirmation screens with attacker-controlled amounts/recipients

8kSec's deep link and WebView exploitation guide provides a hands-on walkthrough using the InsecureShop vulnerable app, demonstrating URL validation bypass techniques such as verifying authority instead of full domain name, allowing suffix-based bypasses. Oversecured's research has documented deep link vulnerabilities across Google, Samsung, TikTok, and banking applications, often chaining deep link exploitation with content provider access or WebView loading for full compromise.

Platform Lifecycle

Android Version	API	Change	Offensive Impact
1.0	1	Custom URI scheme intent filters	Any app can register to handle any URI scheme
6.0	23	App Links with domain verification via assetlinks.json	Prevents scheme hijacking for verified HTTPS links; custom schemes remain unverified
12	31	Stricter App Link verification	Unverified links open in browser by default; misconfigured assetlinks.json falls back to chooser
12	31	Components with intent filters must explicitly declare android:exported	Developers often set exported="true" to resolve build errors, leaving deep link handlers exposed
13	33	Restricted settings prevent sideloaded apps from registering as default handlers	Does not affect already-installed apps or Play Store-distributed malware

Families Using This Technique

Family	Usage	Details
Vultur	Malvertising via deep links	Uses deep links in malvertising redirects to trigger APK downloads
Brokewell	Fake update pages	Deep links route victims to fake Chrome update landing pages
Hook	C2-directed navigation	Uses deep links to navigate victims to specific banking app screens

Deep link exploitation is more commonly observed in app-to-app vulnerability research than in standalone malware. Malware more typically abuses deep links as part of phishing delivery chains rather than as a primary attack technique.

Detection During Analysis

Static Indicators

• Custom URI schemes (non-HTTPS) in intent filters
• Deep link handlers that pass URL parameters to WebView, database queries, or navigation logic without validation
• OAuth redirect URIs using custom schemes instead of App Links
• Missing android:autoVerify="true" on HTTPS intent filters
• Absence of source validation in deep link handling activities

Dynamic Indicators

• Intent delivery via adb shell am start triggering unexpected activity navigation
• URL parameters passed through to WebView without sanitization
• OAuth authorization codes leaked to non-target apps via scheme interception