DATE
March 27, 2026
Android security has always been a complex battlefield. While most users worry about phishing links and malicious app stores, there exists a class of vulnerabilities that operates at the operating system level itself, requiring no special permissions, no root access, and no user interaction beyond opening an app. StrandHogg is one such vulnerability, and it remains one of the most quietly dangerous task hijacking techniques in the Android threat landscape.
This is Part 1 of a two-part series. Here, we break down the mechanics, the history, the real-world attack scenarios, and the technical building blocks that make StrandHogg work. In Part 2, we will cover detection, mitigation, and advanced exploitation patterns.
If your organization develops or deploys Android applications and has not yet assessed your attack surface for task hijacking vulnerabilities, now is the time. Redfox Cybersecurity offers professional mobile pentesting services that identify exactly these kinds of deeply embedded threats before adversaries do.
To understand StrandHogg, you first need to understand how Android manages app tasks and the back stack.
In Android, every application runs within a "task," which is essentially a stack of Activity objects. When a user opens an app, Android creates a task for it. When the user navigates between activities inside that app, each screen is pushed onto the stack. When they press back, activities are popped off.
The Android system allows developers to control this behavior through the taskAffinity attribute and launchMode settings in the AndroidManifest.xml file. These were designed to give developers flexibility in how their apps handle multi-window scenarios, deep links, and activity transitions.
Task hijacking is the exploitation of these controls to insert a malicious activity into the task stack of a legitimate application. The result: the user opens a trusted app, but what appears on screen belongs to the attacker.
StrandHogg was first publicly disclosed in December 2019 by Norwegian security firm Promon. The name comes from an Old Norse term for a military tactic where raiders would attack coastal towns, take hostages, and demand ransom. The analogy is precise: the attack hijacks legitimate processes and holds user trust hostage.
The vulnerability was found in the Android multitasking system and was confirmed to affect all versions of Android at the time of disclosure, including Android 10. What made this particularly alarming was that it had already been exploited in the wild. Researchers identified 36 malicious applications on the Google Play Store that were actively exploiting StrandHogg to steal banking credentials.
A year later, in 2020, a second and more severe variant was disclosed, referred to as StrandHogg 2.0 (CVE-2020-0096). Unlike the original, StrandHogg 2.0 did not require the taskAffinity attribute to be set in the manifest, making it harder to detect through static analysis and significantly more dangerous in terms of scope.
Understanding both variants requires a firm grasp of Android's activity management internals, which we will walk through in detail below.
Every Android Activity has a taskAffinity attribute. By default, this is set to the package name of the application. Activities with the same affinity are grouped into the same task. This is standard behavior.
The problem arises when an application explicitly sets its taskAffinity to match that of another, legitimate application. When this is combined with specific launchMode settings, Android's task manager becomes a weapon.
Android provides four primary launch modes for activities:
standard: Default mode. A new instance is created each time.
singleTop: If the activity is already at the top of the stack, no new instance is created.
singleTask: The activity is created in a new task, or brought to the front if it already exists in a task with matching affinity.
singleInstance: Similar to singleTask, but no other activities can join the same task.
The combination of singleTask launch mode and a spoofed taskAffinity is the heart of the original StrandHogg attack.
There is another attribute that plays into StrandHogg scenarios: allowTaskReparenting. When set to true, an activity can move from one task to another when that task comes to the foreground. This was designed for legitimate use cases, such as an email app composing a message that then moves to a mail client's task. In the hands of an attacker, it provides yet another mechanism to reattach malicious activities to trusted app tasks.
Here is how a StrandHogg attack unfolds in practice, from installation to credential theft.
An attacker creates a malicious Android application. This app may appear completely benign: a flashlight app, a QR scanner, a utility tool. It requests minimal permissions to avoid raising suspicion during installation, whether from the Play Store or a third-party APK. The malicious logic is embedded in the manifest configuration, not in permissions or obvious code behavior.
The key section of the malicious AndroidManifest.xml looks like this:
<activity
android:name=".MaliciousActivity"
android:taskAffinity="com.targetbank.app"
android:launchMode="singleTask"
android:allowTaskReparenting="true">
</activity>
By setting taskAffinity to the package name of the target application, the malicious activity is now configured to be treated by Android as belonging to the same task as the legitimate banking app.
The attacker's app registers a broadcast receiver or foreground service that monitors for when the target application's task comes to the foreground. When the user attempts to open the banking app, the malicious app fires its own activity first. Because Android's task manager sees the malicious activity as belonging to the same task (due to the spoofed affinity), it inserts the malicious activity at the front of the stack.
A simplified version of this trigger looks like the following:
// Inside a BroadcastReceiver or Service in the malicious app
Intent intent = new Intent(context, MaliciousActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent);
Combined with the manifest configuration above, this causes Android to place MaliciousActivity at the front of the target app's task.
The user sees what appears to be the banking application's login screen. In reality, they are looking at a pixel-perfect clone built by the attacker and running inside MaliciousActivity. Every element, the logo, the input fields, the color scheme, replicates the original.
When the user enters their credentials, those values are transmitted to the attacker's server. The malicious activity then closes itself or redirects to the real application, creating the illusion of a failed login. The user tries again on the real app, this time successfully, and has no idea what just happened.
This kind of attack is indistinguishable to the end user. No warning dialog appears. The app appears in the correct position in the recents screen. The URL bar is not visible. There is nothing to indicate the screen is not genuine.
If your Android application handles sensitive user data, credentials, or financial transactions, it is worth asking whether your current security posture would catch this. Redfox Cybersecurity's mobile application pentesting services are built specifically to surface vulnerabilities like StrandHogg before they are weaponized against your users.
Promon's 2019 research confirmed active exploitation in the wild. The 36 malicious applications they identified were designed to target users of 60 leading financial institutions globally. The attack did not require any special permissions. The apps had already been installed and, in some cases, had passed Google Play's automated review.
The attack was notable for several reasons:
It worked across all Android versions available at the time of disclosure. There was no patch that users could apply immediately. The malicious apps were already on the Play Store, meaning the traditional advice of "only install apps from official sources" provided no protection. The attack required no root access, no exploitation of native code, and no kernel-level vulnerability.
This is exactly the kind of threat that static code review and traditional penetration testing approaches miss. The vulnerability is not in the code logic itself but in the manifest configuration and the interaction between the attacker's app and the Android task system.
One particularly insidious aspect of the original StrandHogg vulnerability was that a malicious app could use it to request dangerous permissions on behalf of a legitimate app. Because the malicious activity appeared visually identical to the legitimate app and was running within the same task context, any permission dialogs that appeared would seem to come from the legitimate application.
An attacker could construct a scenario where the user believes they are granting microphone or camera access to their banking app, when in reality, those permissions are being granted to the malicious application. This is a highly effective social engineering primitive because it exploits existing user trust in a specific application.
The permission abuse chain might look like this from an attacker perspective:
// In the malicious activity, request permissions normally
if (ContextCompat.checkSelfPermission(this, Manifest.permission.RECORD_AUDIO)
!= PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(this,
new String[]{Manifest.permission.RECORD_AUDIO}, REQUEST_CODE);
}
The user sees a permission prompt. The prompt visually appears to be associated with the trusted banking app they believe they just opened. They grant the permission. The malicious app now holds microphone access under the guise of the trusted application's task.
Google patched the original StrandHogg (CVE-2019-2215 adjacent task manipulation) and StrandHogg 2.0 (CVE-2020-0096) in Android security updates. However, several factors mean this class of vulnerability remains highly relevant for security practitioners and development teams alike.
First, Android fragmentation is severe. Billions of devices worldwide run Android versions that have never received these patches. Devices in emerging markets, budget segments, and enterprise fleets are routinely years behind on security updates. The StrandHogg patch is irrelevant on an unpatched device.
Second, the techniques pioneered by StrandHogg have informed a generation of Android malware development. Even where the specific CVEs no longer apply, the conceptual framework of task hijacking, abusing Android's multitasking model to overlay trusted interfaces with malicious ones, continues to be adapted and evolved by threat actors.
Third, many Android applications remain misconfigured in ways that increase their susceptibility to task-based attacks. The taskAffinity and allowTaskReparenting attributes are not reviewed in most standard code audits, and developers frequently overlook the security implications of launch mode configurations.
For organizations deploying Android applications at scale, a thorough review of manifest-level security posture is not optional. Engage Redfox Cybersecurity's pentesting team to conduct a comprehensive assessment that includes task hijacking vectors, manifest misconfiguration review, and real-world simulation of overlay attacks against your applications.
To summarize the ground covered in this first part of the series:
StrandHogg is a task hijacking vulnerability rooted in Android's legitimate multitasking architecture, specifically the taskAffinity, launchMode, and allowTaskReparenting attributes. Attackers exploit these to insert malicious activities into the task stack of legitimate, trusted applications.
The attack requires no special permissions, no root access, and is invisible to the end user. It was actively exploited in the wild against banking applications before public disclosure. The original variant and its successor, StrandHogg 2.0, affected all Android versions at the time and relied on fundamentally different mechanics, making the second variant significantly harder to detect through static analysis.
Billions of devices remain unpatched or vulnerable to derivative techniques inspired by StrandHogg. The threat is not historical. It is present, and it is actionable for any motivated attacker targeting Android users in 2025.
In Part 2 of this series, we will go deeper. We will cover the specific mechanics of StrandHogg 2.0 and how it differs from the original at the code level. We will walk through detection strategies for both variants, including dynamic analysis approaches and how to instrument an Android device to catch task hijacking in action. We will also cover mitigation recommendations for developers, including manifest hardening, activity lifecycle controls, and how to test your own applications for susceptibility.
Until then, if you are responsible for the security of an Android application or a mobile-first business, this is the right time to act rather than wait for Part 2. The techniques described in this article are not theoretical. They have been used against real users, in real applications, with real financial consequences.
Contact Redfox Cybersecurity today to schedule a mobile application security assessment. Our team specializes in Android and iOS penetration testing, including manifest-level vulnerability review, overlay attack simulation, and comprehensive mobile threat modeling built for the way attackers actually operate.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.jpg)
.avif)
