Research Update Enhanced src/mobile-pentesting/android-app-p...

src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md

@@ -74,14 +74,45 @@ The vulnerability reported in the **Caller ID (caller.id.phone.number.block)** a
 
 ---
 
+### StrandHogg 2.0 (CVE-2020-0096) – Reflection-based task hijack
+
+Google’s May-2020 security bulletin fixed a more advanced variant dubbed **StrandHogg 2.0**.  The exploit **does not rely on `taskAffinity` at all**; instead it uses *reflection* to dynamically insert the attacker’s activity at the top of *every* running task, completely bypassing the “shared-UID” restriction introduced by Android 11.
+
+Key points:
+
+* A zero-permission malicious app can, once opened, iterate over running tasks and call hidden APIs to **re-parent** its own activity into any task.
+* Because the activity is inserted after run-time, neither `launchMode` nor static manifest analysis can detect the attack in advance.
+* Patched by back-porting a check into **Android 8.0/8.1/9** (May 2020 SPL).  **Android 10 and later are not affected.**
+
+Detection on pre-patched devices can be performed with `adb shell dumpsys activity activities` and watching for suspicious activities whose package name differs from the task’s *affinity*.
+
+Mitigation for legacy devices is the same as classic Task Hijacking **plus** run-time verification (e.g. calling [`ActivityManager#getRunningTasks`](https://developer.android.com/reference/android/app/ActivityManager#getRunningTasks(int)) and validating your own package name).
+
+---
+
 ## Detection & Exploitation checklist
 
-1. Pull `AndroidManifest.xml` from the target APK and check that each `<activity>` (or the global `<application>` element) contains `android:taskAffinity=""` (empty) **or** a customised value.
-2. If not, craft a malicious app:
-   - `android:taskAffinity` = victim package name.
-   - Provide a `MAIN/LAUNCHER` intent so the user can open it once.
-   - Optionally call `moveTaskToBack(true)` to hide immediately.
-3. Let the victim open their legitimate application → hijack.
+1. **Static review** – Pull `AndroidManifest.xml` from the target APK and check that each `<activity>` (or the global `<application>` element) contains `android:taskAffinity=""` (empty) **or** a customised value.  Tools such as:
+   ```bash
+   # Using apkanalyzer (Android SDK)
+   apkanalyzer manifest print app.apk | grep -i taskaffinity
+
+   # Using AXMLPrinter2
+   java -jar AXMLPrinter2.jar AndroidManifest.xml | grep taskAffinity
+   ```
+2. **Dynamic review** – On the device open the target app and list tasks:
+   ```bash
+   adb shell dumpsys activity activities | grep -A3 "TASK" | grep -E "Root|affinity"
+   ```
+   A task whose root affinity equals the victim package but whose top activity belongs to a *different* package is a red flag.
+3. Craft a malicious app as described above, or use **[Drozer](https://github.com/WithSecureLabs/drozer)**:
+   ```bash
+   drozer console connect
+   run app.activity.start --component com.victim/.MainActivity --action android.intent.action.MAIN
+   run app.activity.info com.victim
+   ```
+
+---
 
 ## Mitigation
 
@@ -90,6 +121,14 @@ Developers should:
 * Explicitly set `android:taskAffinity=""` at the `<application>` level (recommended) **or** give each activity a unique, private affinity.
 * For highly sensitive screens, combine the above with `android:launchMode="singleInstance"` or modern [`setLaunchMode`](https://developer.android.com/reference/android/content/pm/ActivityInfo#launchMode) protections.
 * Upgrade the app’s `targetSdkVersion` and enforce **Android 11** behavioural changes where tasks are not shared across packages by default.
+* Target **Android 12 (API 31) or higher** so that the mandatory `android:exported` attribute forces developers to audit every externally-reachable component.
+* Consider run-time self-defence: periodically query `ActivityTaskManager` to ensure that your top activity’s package matches your own.
+
+---
+
+## Related UI-Hijacking techniques
+
+Task hijacking is often combined with or replaced by **tapjacking** (overlay-based UI deception).  The 2025 **TapTrap** research showed that fully transparent *animation-driven* activities can bypass the overlay-touch restrictions introduced in Android 12–14 and still trick users into granting dangerous permissions.  While TapTrap is not strictly *task* hijacking, the end-goal (phishing clicks) is identical – so modern assessments should check for both attack surfaces.
 
 ---
 
@@ -99,5 +138,7 @@ Developers should:
 - [https://blog.takemyhand.xyz/2021/02/android-task-hijacking-with.html](https://blog.takemyhand.xyz/2021/02/android-task-hijacking-with.html)
 - [Android Manifest Misconfiguration Leading to Task Hijacking in Caller ID app](https://github.com/KMov-g/androidapps/blob/main/caller.id.phone.number.block.md)
 - [https://medium.com/mobile-app-development-publication/the-risk-of-android-strandhogg-security-issue-and-how-it-can-be-mitigated-80d2ddb4af06](https://medium.com/mobile-app-development-publication/the-risk-of-android-strandhogg-security-issue-and-how-it-can-be-mitigated-80d2ddb4af06)
+- [Promon – StrandHogg 2.0 (CVE-2020-0096) technical write-up](https://promon.io/resources/downloads/strandhogg-2-0-new-serious-android-vulnerability)
+- [USENIX 2025 – TapTrap: Animation-Driven Tapjacking on Android](https://www.usenix.org/conference/usenixsecurity25/presentation/beer)
 
 {{#include ../../banners/hacktricks-training.md}}