Task Hijacking StrandHogg (Part 2)

In Part 1 of this series, we covered the foundational mechanics of the StrandHogg vulnerability, how task affinity manipulation works at the Android OS level, and why this attack is dangerously silent. If you missed it, go back and read Part 1 before continuing here.

This second and final part moves into the advanced territory: deeper exploitation scenarios, real-world attack chains, ADB-based simulation commands for security researchers, detection strategies, and the defensive hardening that every Android developer and security team must implement. If your organization builds or ships Android applications, the content in this post directly concerns your attack surface.

Want a professional team to test this against your own apps? Redfox Cybersecurity offers specialized mobile pentesting services that cover StrandHogg, intent-based attacks, and the full OWASP Mobile Top 10.

Recap: What StrandHogg Actually Does

Before going further, a quick reset. StrandHogg (CVE-2020-0096 for StrandHogg 2.0, originally disclosed in 2019) is a task hijacking vulnerability in Android that allows a malicious application to position itself visually on top of a legitimate application. The victim opens their banking app. The malicious app intercepts the task stack. The user sees a pixel-perfect fake login screen. Credentials are harvested. No root required. No special permissions needed to trigger the base attack.

The name comes from a Viking tactic of raiding coastal villages without warning. The analogy holds. The attack is opportunistic, fast, and leaves little trace.

How StrandHogg 2.0 Escalated the Threat

The original StrandHogg relied on static manifest manipulation using taskAffinity and allowTaskReparenting. It was powerful but detectable through static analysis of the AndroidManifest.xml file.

StrandHogg 2.0 changed the game by moving the attack into runtime. Instead of relying on manifest attributes, StrandHogg 2.0 exploits Android's multitasking system using reflection-based dynamic class loading. This means the malicious activity can be launched programmatically without any suspicious static configuration visible during app review.

Key Differences Between StrandHogg 1.0 and 2.0

StrandHogg 1.0 is manifest-driven. The taskAffinity is set in XML. The allowTaskReparenting flag is set to true. Analysis tools can flag this during static review or Play Store scanning.

StrandHogg 2.0 is runtime-driven. The attack leverages startActivities() with crafted Intent arrays. No suspicious manifest attributes are required. The malicious overlay is dynamically loaded, making static analysis largely ineffective. This version affects all Android devices running Android 9.0 (Pie) and below that have not been patched with the May 2020 security update.

Advanced Exploitation Walkthrough

Setting Up the Attack Environment

For security researchers and pentesters reproducing this in a controlled lab, the following setup is recommended.

You will need Android Studio with an AVD (Android Virtual Device) running Android 8.1 or 9.0, ADB installed and accessible in your PATH, a target application (a test banking app or any app with a login flow), and a crafted malicious APK with the hijacking logic.

Install your target application first:

adb install target_banking_app.apk


Install the malicious hijacker APK:

adb install strandhogg_poc.apk


Verify both packages are installed:

adb shell pm list packages | grep -E "com.target|com.malicious"


Triggering the Task Hijacking Manually

To simulate the attack sequence, you can push the malicious app to the foreground at the moment the target app is launched. This mimics the scheduled JobScheduler or BroadcastReceiver trigger that a real attacker would use.

Launch the target app:

adb shell am start -n com.target.bankingapp/.MainActivity


Immediately trigger the malicious activity to overlay:

adb shell am start -n com.malicious.hijacker/.PhishingActivity \
 --activity-task-on-home


Check the current task stack to confirm reparenting:

adb shell dumpsys activity activities | grep -A 5 "TaskRecord"


You should see the malicious PhishingActivity sitting at the top of the task stack that belongs to the target application. From the user's perspective, they are still inside their banking app.

Inspecting Task Affinity Abuse

To confirm that task affinity is being manipulated in a StrandHogg 1.0-style attack, dump the activity manager state and look for mismatched affinities:

adb shell dumpsys activity | grep -i "taskAffinity"


For a deeper look at the full back stack:

adb shell dumpsys activity activities | grep -E "Hist|Task|Affinity"


If the malicious app's activity is listed within a task that carries the target app's package name as its affinity, the hijack is confirmed.

Extracting Credentials Captured by the Overlay

In a real attack, credentials are silently exfiltrated via an HTTP POST to a remote server. In a controlled research environment, you can log captured input to logcat instead:

adb logcat -s StrandHoggPoC:D


This will surface any debug output from the malicious activity, including simulated form submissions.

Looking for a team that can run these tests safely and responsibly against your applications? Redfox Cybersecurity's pentesting services include full mobile application assessments with detailed exploitation evidence and remediation guidance.

Real-World Attack Chain: From Install to Credential Theft

Understanding the full kill chain helps defenders build the right detection logic.

Stage 1: Initial Foothold

The malicious app is distributed through a third-party app store, a phishing link, or bundled inside a repackaged legitimate app. It requests minimal permissions (no SYSTEM_ALERT_WINDOW needed for StrandHogg) to avoid raising suspicion.

Stage 2: Monitoring Foreground Activity

The malicious app registers a JobScheduler or uses AccessibilityService (if granted) to monitor which application is currently in the foreground. When the target app (banking, email, VPN) is detected, the attack fires.

ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
List<ActivityManager.RunningTaskInfo> tasks = am.getRunningTasks(1);
String topActivity = tasks.get(0).topActivity.getPackageName();

if (topActivity.equals("com.target.bankingapp")) {
   launchPhishingOverlay();
}


Note: getRunningTasks() was deprecated in Android 5.1 but still partially functional on older devices. Attackers targeting StrandHogg-vulnerable devices (pre-Android 10) can still leverage this.

Stage 3: Overlay Injection

The launchPhishingOverlay() method starts the crafted activity with the same task affinity as the target. The user sees no launch animation. The fake screen appears to be part of the legitimate app.

Stage 4: Credential Harvesting and Dismissal

The victim enters their username and password. The malicious activity captures this input, sends it silently to a remote endpoint, and then finishes itself, returning the user to the real application. The user has no idea anything happened.

Stage 5: Persistence

Some advanced implementations use allowTaskReparenting to ensure the malicious activity re-inserts itself whenever the task is resumed, allowing repeated credential harvesting across multiple sessions.

Detection Techniques for Analysts and Developers

Runtime Detection on Device

Android 10 and above restrict background activity launches significantly, which breaks the core StrandHogg mechanism. However, for applications that must support older Android versions, in-app detection is necessary.

Check whether your activity was started by a suspicious caller:

@Override
protected void onResume() {
   super.onResume();
   if (isTaskRoot() == false) {
       ActivityManager am = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
       List<ActivityManager.RunningTaskInfo> tasks = am.getRunningTasks(10);
       for (ActivityManager.RunningTaskInfo task : tasks) {
           if (!task.baseActivity.getPackageName().equals(getPackageName())) {
               // Suspicious task found, terminate session
               finish();
           }
       }
   }
}


Static Analysis with Apktool

Decompile any suspicious APK and review the manifest for StrandHogg 1.0 indicators:

apktool d suspicious_app.apk -o output_dir
cat output_dir/AndroidManifest.xml | grep -E "taskAffinity|allowTaskReparenting"


Any non-empty taskAffinity pointing to another app's package name combined with allowTaskReparenting="true" is a high-confidence indicator.

Dynamic Analysis with Frida

For StrandHogg 2.0 detection where static analysis fails, use Frida to hook startActivities() at runtime:

frida -U -n com.suspicious.app -l hook_startActivities.js


Your hook script should intercept the Intent[] array passed to startActivities() and log the component names being targeted. If a legitimate app's activity name appears in the intent chain, this is strong evidence of a hijacking attempt.

Hardening Android Applications Against Task Hijacking

Fix 1: Set a Unique taskAffinity

Set each activity's taskAffinity to an empty string to prevent it from being lured into a foreign task:

<activity
   android:name=".MainActivity"
   android:taskAffinity=""
   android:launchMode="singleInstance" />


Fix 2: Verify Caller Identity in onResume

As shown above, validate task root status on every resume. If the activity is not the task root and the task base is a foreign package, terminate immediately.

Fix 3: Upgrade Target SDK

Setting targetSdkVersion to 28 or higher and testing against Android 10+ restricts background launches. Google enforces stricter launch controls on apps targeting API level 29+.

Fix 4: Use FLAG_SECURE for Sensitive Screens

While this does not prevent the overlay attack directly, FLAG_SECURE prevents screenshotting and screen recording of sensitive activities, limiting one class of data exfiltration:

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


Fix 5: Certificate Pinning and Integrity Checks

Even if an overlay captures credentials, a secondary layer of certificate pinning and app integrity checks (using Google Play Integrity API) can block the exfiltration step.

If your development team needs guidance implementing these controls under real-world pentesting pressure, Redfox Cybersecurity's mobile security services include both offensive simulation and defensive hardening consultation.

Why Automated Scanners Miss StrandHogg 2.0

This is the part that most development teams underestimate. Google Play Protect, standard SAST tools, and even many MDM solutions will not catch a well-crafted StrandHogg 2.0 implementation. Here is why.

The malicious activity has no suspicious manifest attributes. The dynamic intent construction happens at runtime and leaves no static fingerprint. The app requests no unusual permissions. The overlay does not use SYSTEM_ALERT_WINDOW. On a visual scan of the installed app, everything looks clean.

This is precisely why dynamic analysis and professional penetration testing are irreplaceable. Automated tools solve known signatures. Human-driven pentesting finds behavioral anomalies.

Industry Impact and Notable Cases

When StrandHogg was first publicly disclosed by Promon in December 2019, researchers found evidence that 36 malicious apps in the wild were actively exploiting it, targeting customers of 60 of the world's top 100 banking applications.

The attack was not theoretical. It was deployed. Credentials were stolen. Accounts were drained. And for months, neither the banking apps nor their security teams had any visibility into the attack vector.

The May 2020 Android security patch addressed the core OS-level vulnerability for StrandHogg 2.0 (CVE-2020-0096), but the patch requires device manufacturers to push updates. Hundreds of millions of unpatched devices remain in active use globally, particularly in markets where older Android devices dominate.

For any organization with a mobile customer base, the question is not whether StrandHogg is still relevant. The question is whether your application has been tested against it.

Bringing It All Together

Task hijacking through StrandHogg represents a category of Android vulnerability that sits at the intersection of OS design decisions and application-level trust assumptions. The Android task stack was built for user experience, not adversarial manipulation. Attackers found the gap. Some exploited it at scale before defenders caught up.

Part 1 gave you the foundations. This second and final part has walked you through advanced exploitation with concrete ADB and Java commands, the full attack chain from installation to credential theft, detection logic for developers and analysts, hardening measures your team can implement today, and the critical limitation of automated scanning tools against dynamic attack variants.

The most important takeaway is that these vulnerabilities do not announce themselves. They require active testing to surface.

If your organization ships an Android application and has never had it tested for task hijacking, overlay attacks, intent sniffing, or the broader OWASP Mobile Top 10 attack surface, now is the time to close that gap.

Redfox Cybersecurity offers end-to-end mobile application penetration testing services designed to find exactly these types of vulnerabilities before attackers do. The team performs both static and dynamic analysis, simulates full attack chains in controlled environments, and delivers actionable remediation reports your developers can implement immediately.

Do not wait for a breach to validate your mobile security posture. Book a mobile pentesting engagement with Redfox Cybersecurity today and find out exactly where your application stands.