Android Tapjacking Vulnerability

Every tap on your Android screen carries trust. You tap "Allow," "Confirm," or "Install" because you believe you are interacting with a legitimate interface. Tapjacking is the art of breaking that trust silently, without triggering a single security alert, without leaving an obvious trace, and without the victim ever realizing what happened.

For security teams, mobile developers, and enterprises running Android applications, tapjacking is not a theoretical risk. It is an actively exploited vulnerability class that has compromised banking apps, VPN clients, and enterprise MDM profiles. If your mobile application has never been tested against tapjacking, there is a real chance it is vulnerable right now.

What Is Android Tapjacking

Tapjacking is a UI redress attack on Android where a malicious overlay application captures touch events intended for the legitimate application running beneath it. The attacker places a transparent or semi-transparent layer over a sensitive UI element, such as a permission dialog, a payment confirmation, or a settings toggle, and the user's tap registers on the malicious layer before being passed through to the target.

The result is that users unknowingly authorize actions they never intended to authorize. This might mean granting the attacker's app access to the camera, enabling device administrator privileges, approving a fund transfer, or silently installing a payload.

Android's architecture has made this class of attack surprisingly persistent. The SYSTEM_ALERT_WINDOW permission, historically required for overlay attacks, has been progressively hardened, but developers and security researchers continue to find new bypass paths, particularly across fragmented Android versions and custom OEM skins.

How Tapjacking Works: The Technical Mechanics

The Overlay Mechanism

At its core, tapjacking relies on Android's legitimate overlay system, originally designed for features like floating chat bubbles, screen readers, and accessibility tools. A malicious app requests the SYSTEM_ALERT_WINDOW permission (or exploits a path that does not require it on older API levels) and then draws a WindowManager layer over another app's activity.

The key flags that make this dangerous are:

WindowManager.LayoutParams params = new WindowManager.LayoutParams(
   WindowManager.LayoutParams.MATCH_PARENT,
   WindowManager.LayoutParams.MATCH_PARENT,
   WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY,
   WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE |
   WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL |
   WindowManager.LayoutParams.FLAG_WATCH_OUTSIDE_TOUCH,
   PixelFormat.TRANSLUCENT
);


With FLAG_NOT_TOUCH_MODAL and FLAG_WATCH_OUTSIDE_TOUCH, the overlay receives touch events without stealing focus from the underlying activity. This is exactly the configuration an attacker uses to silently monitor and intercept taps.

FilterTouchesWhenObscured

Android introduced a partial mitigation called filterTouchesWhenObscured. When this attribute is set on a View, Android drops touch events if the view is obscured by another window. However, this protection is opt-in, not default, which means any application that does not explicitly implement it remains exposed.

A vulnerable view looks like this:

<Button
   android:id="@+id/btnGrantPermission"
   android:layout_width="wrap_content"
   android:layout_height="wrap_content"
   android:text="Grant Permission" />


A hardened view looks like this:

<Button
   android:id="@+id/btnGrantPermission"
   android:layout_width="wrap_content"
   android:layout_height="wrap_content"
   android:text="Grant Permission"
   android:filterTouchesWhenObscured="true" />


The difference is a single attribute. Yet most applications ship without it.

The setFilterTouchesWhenObscured Method in Code

The same protection can be applied programmatically:

Button grantButton = findViewById(R.id.btnGrantPermission);
grantButton.setFilterTouchesWhenObscured(true);


For sensitive activities, you can also use the FLAG_SECURE window flag, which prevents screenshots and signals to Android that this window should not be overlaid:

getWindow().setFlags(
   WindowManager.LayoutParams.FLAG_SECURE,
   WindowManager.LayoutParams.FLAG_SECURE
);


Real-World Tapjacking Attack Scenarios

Scenario 1: Permission Hijacking

The most common tapjacking scenario involves triggering a permission request in a target app (camera, microphone, contacts, location) and placing an overlay that misleads the user about what they are approving. The user thinks they are tapping "Dismiss" on an advertisement. In reality, they are granting microphone access to the attacker's application.

Scenario 2: Device Administrator Activation

A more severe variant targets the Device Policy Manager screen. If an attacker can overlay the "Activate" button on the device admin activation dialog, they gain elevated control over the device including the ability to lock it, wipe it, or enforce policies. This is a common technique used in Android ransomware.

Scenario 3: Payment Confirmation Overlays

Banking and fintech applications are high-value targets. An attacker overlaying a fund transfer confirmation screen can cause users to approve transfers they have never reviewed. Combined with social engineering (a popup claiming the user has won a prize), this attack requires minimal technical sophistication.

Scenario 4: VPN and Accessibility Service Abuse

Attackers have used tapjacking to silently enable malicious accessibility services, which then log keystrokes, intercept SMS OTPs, and exfiltrate credentials. Similarly, overlaying the VPN permission dialog allows an attacker's app to route all device traffic through an attacker-controlled server.

How to Test for Tapjacking Vulnerabilities

If you manage an Android application and want to determine your exposure, here is a practical testing workflow. This is also the foundation of what professional mobile application penetration testers execute during an engagement.

Want these tests run against your application by certified experts? Explore Redfox Cybersecurity's Mobile App Pentesting Services and get a detailed vulnerability report.

Step 1: Set Up a Test Environment

Use Android Studio with an emulator running API 27 or lower for maximum attack surface, as older API levels have fewer restrictions on overlay permissions.

# Create an AVD with API 27
sdkmanager "system-images;android-27;google_apis;x86"
avdmanager create avd -n tapjack_test -k "system-images;android-27;google_apis;x86"
emulator -avd tapjack_test


Step 2: Build or Deploy the Tapjacking PoC App

A minimal tapjacking proof-of-concept application requests the overlay permission and draws a colored transparent view over the screen. The Tapjacking tool from the Android security research community is a solid starting point.

git clone https://github.com/GautamViki/Tapjacking-ExportedActivity
cd Tapjacking-ExportedActivity
./gradlew assembleDebug
adb install app/build/outputs/apk/debug/app-debug.apk


Step 3: Identify Exported Activities in the Target APK

Exported activities in your target app are the primary attack surface. Use apktool or aapt to enumerate them:

apktool d target_app.apk -o target_output
grep -i "exported" target_output/AndroidManifest.xml


Or use aapt directly:

aapt dump badging target_app.apk
aapt dump xmltree target_app.apk AndroidManifest.xml | grep -A2 "activity"


Any activity with android:exported="true" that presents sensitive UI (permission dialogs, payment confirmations, account actions) should be considered a tapjacking candidate.

Step 4: Launch the Target Activity Directly

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


If the activity launches without authentication checks, an attacker can trigger it programmatically and then overlay it.

Step 5: Run the Overlay and Observe Behavior

Launch the tapjacking PoC app over the target activity and attempt to interact with the underlying sensitive controls. If the tap is processed by the underlying view without dropping the event, the application is vulnerable.

To verify whether filterTouchesWhenObscured is effective, check the Android system log:

adb logcat | grep -i "obscured"


A protected application will log touch filtering events when an overlay is detected.

Step 6: Test with Drozer (Optional, Advanced)

Drozer is a comprehensive Android security assessment framework that can enumerate attack surfaces, test exported components, and simulate inter-application attacks.

# Install Drozer agent on device
adb install drozer-agent.apk

# Connect Drozer console
adb forward tcp:31415 tcp:31415
drozer console connect

# List attack surface
run app.package.attacksurface com.target.app

# List exported activities
run app.activity.info -a com.target.app

# Start a specific exported activity
run app.activity.start --component com.target.app com.target.app.SensitiveActivity


Mitigation Strategies for Developers

Apply filterTouchesWhenObscured Globally

Rather than applying the attribute view-by-view, enforce it at the activity level using a custom base activity:

public class SecureBaseActivity extends AppCompatActivity {
   @Override
   protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       getWindow().setFlags(
           WindowManager.LayoutParams.FLAG_SECURE,
           WindowManager.LayoutParams.FLAG_SECURE
       );
   }

   @Override
   public boolean dispatchTouchEvent(MotionEvent ev) {
       if ((ev.getFlags() & MotionEvent.FLAG_WINDOW_IS_OBSCURED) != 0) {
           // Touch event received while window is obscured - reject it
           return false;
       }
       return super.dispatchTouchEvent(ev);
   }
}


All sensitive activities should extend SecureBaseActivity.

Restrict Activity Export

Every activity in your AndroidManifest.xml should have its export status explicitly defined:

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


If an activity must be exported (for deep links or inter-app workflows), add strict intent-based authentication checks at the entry point.

Validate Calling Package

For exported activities that accept intents from trusted apps only, validate the calling package at runtime:

String callingPackage = getCallingPackage();
if (callingPackage == null || !callingPackage.equals("com.trusted.app")) {
   finish();
   return;
}


Target Modern API Levels

Applications targeting API 31 and above benefit from stricter overlay restrictions. Google has progressively tightened the conditions under which TYPE_APPLICATION_OVERLAY windows can receive or intercept touch events. Keeping your targetSdkVersion current is a meaningful layer of defense.

android {
   compileSdk 34
   defaultConfig {
       targetSdk 34
   }
}


Why Tapjacking Persists in the Android Ecosystem

Despite years of awareness, tapjacking remains a viable attack for several reasons.

Android fragmentation is the primary culprit. Hundreds of device manufacturers ship custom Android builds with varying API levels. An application that is hardened on Android 13 may still run on devices running Android 8 in enterprise environments, corporate MDM deployments, or budget device markets. The attacker simply targets older OS versions where restrictions are weaker.

The opt-in nature of the primary mitigation is the second issue. No Android OS version has made filterTouchesWhenObscured the default for all views. Developers who are unaware of the attack vector simply never implement it. This is a systemic gap in the Android security documentation pipeline.

Third, accessibility service abuse has created a parallel tapjacking pathway that does not depend on the traditional overlay mechanism at all. Once a malicious accessibility service is active (enabled through a separate tapjacking event), it can observe and manipulate UI elements across all apps, eliminating the need for visual overlays entirely.

If you are unsure whether your mobile application is protected against tapjacking and related UI redress attacks, Redfox Cybersecurity's security engineers can assess your application end-to-end. View our Pentesting Services to get started.

Tapjacking in the Context of Mobile Penetration Testing

Tapjacking is one component of a comprehensive mobile application security assessment. In a professional engagement, it is evaluated alongside:

• Insecure data storage (cleartext credentials in SharedPreferences or SQLite)
• Improper session management and token handling
• Exported content providers and broadcast receivers
• Insecure inter-process communication (IPC)
• Reverse engineering resistance and root detection bypass
• Network traffic interception and certificate pinning analysis

The OWASP Mobile Application Security Verification Standard (MASVS) includes tapjacking-related controls under the Resilience category, specifically around testing whether sensitive views are protected against overlay attacks.

Organizations that skip mobile penetration testing often discover these vulnerabilities only after exploitation, which at that point means incident response, regulatory notification, and reputational damage, all of which are substantially more expensive than prevention.

Who Is Most at Risk

Any Android application that presents a UI element requiring user action on a sensitive operation is theoretically vulnerable. In practice, the highest-risk categories are:

Financial services applications handling fund transfers, loan approvals, or account modifications. Healthcare apps processing consent forms or prescription actions. Enterprise applications managing device enrollment, VPN activation, or policy acceptance. Social platforms with permission-heavy onboarding flows requesting contacts, camera, or location. Identity and authentication apps where a single tap can approve account access.

If your application falls into any of these categories and has not been tested for tapjacking within the past twelve months, the risk is material and immediate.

Wrapping Up: Tapjacking Is Exploitable, Fixable, and Testable

Android tapjacking is not a headline-grabbing zero-day. It is a quiet, understated vulnerability that attackers use precisely because it lacks the drama that prompts urgent patching. A single line of XML can leave your users authorizing actions they never intended. A single unchecked filterTouchesWhenObscured attribute can hand an attacker device administrator access.

The fix is straightforward. The detection is systematic. What stands between a vulnerable application and a hardened one is a structured security assessment by engineers who know exactly where to look.

Redfox Cybersecurity specializes in mobile application security, Android and iOS penetration testing, and comprehensive vulnerability assessments for enterprises and product teams. Whether you are preparing for a compliance audit, hardening a new release, or investigating a suspected compromise, the team at Redfox Cybersecurity delivers actionable findings, not checkbox reports.

Engage Redfox Cybersecurity's Pentesting Services today and find out exactly where your Android application stands before an attacker does.

‍