How to Exploit Android Activities

Exported Android activities remain one of the most consistently exploitable components in mobile application security assessments, largely because developers frequently expose more of their app's internal navigation than they realize. An activity marked exported without proper access controls can allow another application, or an attacker with local access to the device, to launch privileged screens, bypass authentication flows, or trigger sensitive functionality directly. This guide covers how to identify and exploit vulnerable Android activities during an authorized assessment. Mobile application assessments run by Sagefox Cybersecurity treat activity exposure as a standard part of the Android attack surface review for every engagement.

Understanding Android Activities and Exported Components

What Makes an Activity Exported

An Android activity becomes exported, meaning accessible to other applications on the device, either explicitly through the android:exported="true" attribute in the manifest or implicitly by declaring an intent filter without setting the attribute to false. On devices running Android 12 and above, any component with an intent filter must explicitly declare its exported status, which has reduced but far from eliminated this class of finding.

Why Exported Activities Are a Security Concern

• They can be launched directly by any other application installed on the same device, bypassing the intended navigation flow of the app itself
• They may expose functionality meant only to be reached after prior authentication or state validation within the app
• They can sometimes be used to bypass login screens entirely if a post-authentication activity does not independently verify session state
• Malicious apps can use exported activities as an entry point for phishing overlays or intent-based data injection

Setting Up the Environment for Activity Testing

Preparing the Test Device

Testing exported activities requires a device or emulator with ADB access and the target application installed.

adb devices
adb install target_app.apk

Extracting and Reviewing the Application Manifest

The first step in any activity-focused assessment is pulling the manifest to identify every declared activity and its exported status.

apktool d target_app.apk -o target_app_decompiled/
cat target_app_decompiled/AndroidManifest.xml | grep -A 5 "activity"

Identifying Exported Activities

Reviewing the Manifest for Explicit and Implicit Exports

Within the decompiled manifest, look for activities explicitly marked as exported, as well as any activity declaring an intent filter without an explicit exported attribute on older target SDK versions where the implicit default still applies.

xml

<activity android:name=".AdminPanelActivity" android:exported="true">
   <intent-filter>
       <action android:name="android.intent.action.VIEW" />
   </intent-filter>
</activity>

An activity like this, named suggestively and marked exported, is an immediate priority for further testing.

Enumerating Exported Activities Directly on the Device

Rather than relying solely on manual manifest review, the Android package manager can enumerate exported activities directly for an installed application.

adb shell dumpsys package com.target.app | grep -A 3 "Activity Resolver Table"

Launching Exported Activities Directly

Basic Activity Launch with am start

Once an exported activity is identified, launching it directly bypasses whatever navigation flow the application intended.

adb shell am start -n com.target.app/.AdminPanelActivity

If this activity was intended to be reachable only after prior authentication and administrative role verification within the app's normal flow, successfully launching it directly with no prior context confirms a genuine access control bypass.

Passing Extras to Manipulate Activity Behavior

Many activities expect data passed through intent extras, and testing how an activity behaves when given unexpected or malicious extra values can reveal further issues beyond simple unauthorized access.

adb shell am start -n com.target.app/.TransferFundsActivity \
 --es "recipient_account" "attacker_account_123" \
 --ef "amount" 5000.00

If this activity processes the transfer without validating that the request originated from the application's own authenticated internal flow, it demonstrates that critical business logic can be triggered directly through an exposed intent interface.

Bypassing Authentication Through Exported Activities

Identifying Post-Authentication Activities

Reviewing the application's normal navigation flow, either through manual use or by tracing activity transitions with a tool like Frida, identifies which activities are only meant to be reached after a successful login.

javascript

Java.perform(function() {
   var Activity = Java.use("android.app.Activity");
   Activity.onResume.implementation = function() {
       console.log("Activity resumed: " + this.getClass().getName());
       this.onResume();
   };
});

Running this script while navigating through the application normally builds a map of the expected activity flow, which then highlights any post-login activity that might be independently reachable without that flow ever occurring.

Testing Direct Launch of a Post-Authentication Screen

adb shell am start -n com.target.app/.AccountDashboardActivity

If this succeeds and displays account information or functionality without the app ever validating that a login previously occurred within the current session, this is a direct authentication bypass, since the activity itself is trusting that it will only ever be reached through the proper flow rather than independently verifying session state.

Exploiting Data Leakage Through Intent Extras

Activities That Log or Expose Sensitive Intent Data

Some activities process sensitive data passed through intent extras and inadvertently expose it, either through logging, insecure storage, or by passing it along to a subsequent unprotected activity or broadcast.

adb logcat | grep -i "password\|token\|session"

Launching an exported activity with test data and monitoring the device log for that same data appearing in plaintext reveals a logging-based data exposure that a malicious app on the same device could also observe.

Crafting a Malicious Intent from a Proof-of-Concept App

For a complete demonstration of impact, building a minimal proof-of-concept application that programmatically launches the vulnerable exported activity illustrates exactly how a real malicious app installed on the same device could exploit the finding without any special permissions.

java

Intent intent = new Intent();
intent.setClassName("com.target.app", "com.target.app.AdminPanelActivity");
intent.putExtra("bypass_auth", true);
startActivity(intent);

Testing for Task Hijacking and Activity Overlay Risks

Reviewing launchMode Configuration

Certain launchMode configurations, particularly singleTask combined with a predictable or missing taskAffinity, can create conditions for task hijacking, where a malicious application positions its own activity within the legitimate app's task stack to intercept user input intended for the real application.

xml

<activity android:name=".LoginActivity" android:launchMode="singleTask" android:taskAffinity="com.target.app.task">

Reviewing every activity's launch mode and task affinity configuration against known task hijacking patterns is a necessary check beyond simply confirming export status.

Documenting Exported Activity Findings

Demonstrating Real Impact, Not Just Theoretical Exposure

A finding stating "activity X is exported" without demonstrating what an attacker can actually achieve by launching it understates the risk and gives the development team little to act on. Every exported activity finding should be paired with a concrete demonstration, such as a bypassed authentication check or a business logic action triggered without proper validation.

Mapping Exported Activities to Business Impact

Prioritizing findings based on what the exposed activity actually allows, rather than treating every exported activity as equally severe, gives development teams a realistic sense of urgency. An exported settings screen that only displays non-sensitive preferences carries far less risk than an exported activity that processes financial transactions or displays personal account data.

This kind of impact-focused, prioritized reporting is central to how mobile findings are communicated in assessments through Sagefox Cybersecurity, ensuring development teams receive findings they can act on rather than a flat list of exported component names.

Remediating Exported Activity Vulnerabilities

Setting Exported to False Where External Access Is Not Required

Any activity that does not genuinely need to be launched by another application should explicitly set android:exported="false", removing external access entirely rather than relying on the platform's default behavior.

xml

<activity android:name=".AdminPanelActivity" android:exported="false" />

Enforcing Custom Permissions for Activities That Must Remain Exported

Where an activity genuinely needs to remain accessible to other applications, protecting it with a custom signature-level permission ensures only applications signed with the same certificate, typically other apps from the same developer, can successfully launch it.

xml

<activity android:name=".SharedFeatureActivity"
   android:exported="true"
   android:permission="com.target.app.permission.INTERNAL_ACCESS" />

Validating Session State Independently Within Sensitive Activities

Rather than relying entirely on export restrictions, sensitive activities should independently verify that a valid, current authentication session exists before rendering any protected content or processing any protected action, providing a defense-in-depth layer even if an export misconfiguration is later introduced.

java

if (!SessionManager.isAuthenticated()) {
   startActivity(new Intent(this, LoginActivity.class));
   finish();
   return;
}

Common Mistakes When Testing Android Activities

Relying Solely on Automated Manifest Analysis

Automated tools flag exported activities reliably, but they cannot determine which ones represent genuine business risk versus benign functionality intentionally exposed for legitimate inter-app communication. Manual review of what each exported activity actually does remains necessary.

Overlooking Implicit Exports on Older Target SDK Versions

Applications targeting older Android SDK versions may still rely on the pre-Android-12 implicit export behavior, where any activity with an intent filter becomes exported by default regardless of an explicit attribute. Testing should account for the specific target SDK version rather than assuming modern explicit declaration behavior applies universally.

Failing to Test with Realistic Intent Extras

Simply confirming that an activity can be launched without testing what happens when it receives unexpected, malicious, or boundary-case intent extra values misses a significant portion of the potential impact, particularly for activities that process business logic based on that input.

Key Takeaways

Exported Android activities represent a consistently exploitable attack surface precisely because they sit at the boundary between an application's intended internal navigation flow and the broader Android inter-app communication system. Identifying which activities are exported, testing what they actually allow when launched directly or with manipulated intent data, and demonstrating concrete impact through proof-of-concept exploitation gives development teams the clear, actionable findings needed to properly scope down exported components and add defense-in-depth session validation.

If your organization needs a thorough Android application assessment that goes beyond a manifest scan into real exploitation of exported components, the team at Sagefox Cybersecurity can help identify what your app actually exposes and how to lock it down.