Merge pull request #2980 from HackTricks-wiki/research_update_src_mobile-pentesting_android-app-pentesting_android-enterprise-work-profile-bypass_20260929_181543

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

Author: carlospolop

src/mobile-pentesting/android-app-pentesting/android-enterprise-work-profile-bypass.md

@@ -1,80 +1,143 @@
-# Android Enterprise Work Profile Required-App Replacement
+# Android Enterprise Work Profile Required-App Replacement and Provisioning Race
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Attack surface
+## Work Profile attack surface
 
-Android Enterprise Work Profiles are implemented as **secondary Android users** (BYOD example: user `0` = personal, user `1` = work). Each user has independent `/data/user/<id>` trees, system apps, Play Services instances and policy objects maintained by the MDM. When an MDM such as **Microsoft Intune** marks an app as *required* for the Work Profile, the **Work-Profile Play Store (Finsky)** periodically confirms the package is present and auto-installs it if missing.<sup>[[1]](#references)</sup>
+An Android Enterprise Work Profile is implemented as a **managed secondary Android user**. App data and package state such as installed, enabled and suspended are scoped per user. The APK code path and signing identity are still managed by the device-wide Package Manager. This distinction matters because an install operation can change the state of the same package across several users.
 
-Even after the **CVE-2023-21257** patch that blocks ADB sideloads when `DISALLOW_INSTALL_APPS` or `DISALLOW_DEBUGGING_FEATURES` are set, the following chain lets an attacker **replace any Intune-required Work Profile app** with arbitrary code:<sup>[[1]](#references)</sup>
+On Intune-enrolled BYOD devices, apps assigned as **Required** are installed in the Work Profile through managed Google Play. The research behind this page found that this repair flow could be combined with the multi-user installer to place attacker-controlled code in the profile.<sup>[[1]](#references)</sup>
 
-1. Abuse Android Studio's **"Install for all users"** path to stage a malicious APK that looks like an update of the managed package.
-2. Let the MDM notice the required app is missing. Intune triggers the Work-Profile Finsky instance to reinstall it.
-3. Finsky compares the staged APK version with the Play Store version and silently installs the **highest `versionCode`**, bypassing the original restriction.
+> The required-app chain below is an observed behaviour on specific Intune, Android and Play Store builds. It is not a generic Android rule. Reproduce it on the exact OEM build and management mode before reporting impact.
 
-## Recon and prerequisite checks
+## Required-app replacement chain
 
-* Confirm multi-user layout and user IDs:<sup>[[1]](#references)</sup>
+CVE-2023-21257 changed `InstallPackageHelper` so an `INSTALL_ALL_USERS` request does not mark a package as installed for a Work Profile restricted by `DISALLOW_INSTALL_APPS` or `DISALLOW_DEBUGGING_FEATURES`. The later research found a second path on patched devices:<sup>[[1]](#references)</sup>
+
+1. Android Studio submits an install-for-all-users request for an APK whose package name matches an Intune-required Work Profile app.
+2. The request installs the attacker package in the unrestricted personal user. On the tested devices, it also removes the legitimate package from the Work Profile before policy blocks the direct install there.
+3. Intune notices that the required package is absent and asks the Work Profile Play Store, internally called Finsky, to restore it.
+4. The tested Finsky build selects the locally submitted candidate because its `versionCode` is higher than the managed Google Play release. The attacker APK is then installed in the Work Profile.
+
+The original researcher inferred the local-candidate selection from the observed notifications and timing. The temporary storage location and the exact internal Finsky decision path were not demonstrated. Treat those details as a working explanation rather than a proven implementation contract.<sup>[[1]](#references)</sup>
+
+### Preconditions and limits
+
+* The demonstrated target was an **Intune personally owned Work Profile** with an app assigned as **Required**.
+* The attacker needed temporary access to an unlocked device. Developer Options and USB debugging had to be enabled. The host also needed an accepted ADB authorization.
+* The package name of a required app had to be known. A large `versionCode` was used to win the observed Play selection.
+* A normal Android in-place update requires a compatible signing certificate. A matching package name and larger version alone do **not** normally bypass APK signature checks. This chain depends on the unusual per-user removal and managed Play repair behaviour. A signature mismatch at any stage can stop it.
+* Results can change with the OEM framework, Play Store version, Android security update, enrollment backend and MDM policy. The public report reproduced the chain on Android 13 and Android 16 test devices in August 2025.<sup>[[1]](#references)</sup>
+
+## Recon and evidence collection
+
+Enumerate the users, record the build and identify the package in the Work Profile:
 
 ```bash
 adb shell pm list users
-# Expect user 0 = Owner, user 1 = Work profile (or higher if multiple profiles exist)
+adb shell getprop ro.build.version.release
+adb shell getprop ro.build.version.security_patch
+
+WORK_USER=10
+PKG=com.workday.workdroidapp
+adb shell pm list packages --user "$WORK_USER" | grep -F "$PKG"
+adb shell dumpsys package "$PKG" | grep -E 'versionCode=|User [0-9]+:'
 ```
 
-* Direct installs into the work user fail under policy (expected error):
+Do not assume that the Work Profile is user `1`. Profile IDs such as `10` or `11` are common. A direct post-enrollment install should fail when policy is active:
 
 ```bash
-adb install --user 1 legit.apk
-# java.lang.SecurityException: Shell does not have permission to access user 1
+adb install --user "$WORK_USER" payload.apk
+# Expected on a restricted profile: SecurityException or INSTALL_FAILED_USER_RESTRICTED
 ```
 
-* You must have **temporary physical access to an unlocked BYOD** to enable Developer Options + USB debugging.<sup>[[1]](#references)</sup>
-* Identify the **package name** of a Work-Profile app marked as *required* (e.g. `com.workday.workdroidapp`).
+Collect the policy and package evidence before testing. `dumpsys user` exposes effective user restrictions. `dumpsys package` shows per-user package state. The host-side `apksigner` command records the payload certificate:
 
-## Weaponising the Android Studio multi-user installer
+```bash
+adb shell dumpsys user > users-before.txt
+adb shell dumpsys package "$PKG" > package-before.txt
+apksigner verify --print-certs payload.apk
+adb logcat -c
+adb logcat -v time | grep -Ei 'PackageManager|Finsky|DevicePolicy|ManagedProvisioning'
+```
+
+## Weaponising the multi-user installer
 
-Android Studio's Run/Debug configuration can still push builds with the **`INSTALL_ALL_USERS`** flag. Before running, enable *Deploy as instant app* → *Install for all users*.<sup>[[1]](#references)</sup>
+In Android Studio open the app Run/Debug configuration and select **Install for all users**. The exact menu position depends on the Android Studio version. This option is separate from instant-app deployment.
 
-Build the malicious payload with the **same package name** as the managed app and a **much larger `versionCode`** so PackageManager/Finsky treats it as a newer release:<sup>[[1]](#references)</sup>
+Build the test APK with the required app package name and a version code above the managed Google Play build:<sup>[[1]](#references)</sup>
 
 ```gradle
 android {
     namespace = "com.workday.workdroidapp"
     defaultConfig {
         applicationId = "com.workday.workdroidapp"
         versionCode = 900000004
-        versionName = "9000000004.0"
+        versionName = "900000004.0"
     }
 }
 ```
 
-When Android Studio deploys:<sup>[[1]](#references)</sup>
+Run the configuration while the device is attached. On a vulnerable combination, the immediate Work Profile installation is denied but the legitimate required app disappears. Keep `logcat` running and wait for the Work Profile Play Store notification. The reported repair interval was roughly 1–10 minutes.<sup>[[1]](#references)</sup>
 
-1. **Personal user (0)** installs the malicious package normally.
-2. **Work Profile user (1)** receives the APK in a temporary staging area and tries to treat it as an update.
-3. CVE-2023-21257's logic sees the user is restricted → **install is denied**, but the legitimate managed app is marked uninstalled and the staged APK remains cached.
+Verify the result per user instead of relying on the launcher icon:
 
-## Intune/Finsky auto-install bypass
+```bash
+adb shell pm list packages --user 0 | grep -F "$PKG"
+adb shell pm list packages --user "$WORK_USER" | grep -F "$PKG"
+adb shell pm path --user "$WORK_USER" "$PKG"
+adb shell dumpsys package "$PKG" | grep -E 'versionCode=|installerPackageName|User [0-9]+:'
+```
 
-Within ~1–10 minutes (policy refresh interval):<sup>[[1]](#references)</sup>
+A useful negative control is the same APK with a lower `versionCode`. Also repeat with a non-required package. These controls distinguish the managed Play repair path from a general multi-user installation mistake.
 
-1. Intune/Company Portal detects the *required* package is missing from the Work Profile.
-2. The Work-Profile **Finsky** instance is asked to reinstall it.
-3. During version resolution Finsky compares:
-   * Play Store metadata for `com.workday.workdroidapp`.
-   * The locally staged APK from the previous install attempt.
-4. Because the local build has the **highest `versionCode`**, Finsky trusts it as the most recent release and installs it into the restricted Work Profile **without re-applying `DISALLOW_INSTALL_APPS` / `DISALLOW_DEBUGGING_FEATURES` checks**.
+## Provisioning-time ADB race
 
-The malicious binary now resides inside the Work Profile under the genuine package name and is considered compliant by the MDM.<sup>[[1]](#references)</sup>
+A different technique targets **profile creation**, not required-app repair. CVE-2025-22442 describes a race in which a new managed profile exists before the effective debugging restriction protects it. If ADB was authorized before enrollment, a tester controlling the enrollment flow can watch for the new user ID and immediately install an APK into that user.
 
-## Post-exploitation opportunities
+The following lab loop illustrates the timing. Adapt the profile label if the device language or OEM changes it:
 
-* **Work-profile data access** – other enterprise apps keep trusting Intents/content providers bound to the replaced package, enabling internal data theft and covert exfiltration from the Work Profile to attacker infrastructure.<sup>[[1]](#references)</sup>
-* **Per-app VPN hijack** – if the replaced package is mapped to an Intune per-app VPN (MS Tunnels + Defender), the malicious build automatically inherits the VPN profile, giving direct access to internal hosts from an attacker-controlled process.
-* **Persistence** – because the MDM now believes the required app is installed, it will **reinstall the malicious build** whenever the user or defender removes it, providing long-term foothold on BYOD Work Profiles.
+```bash
+APK=payload.apk
+while :; do
+  WORK_USER=$(adb shell pm list users |
+    sed -n 's/.*UserInfo{\([0-9][0-9]*\):Work profile.*/\1/p' | tr -d '\r')
+  [ -n "$WORK_USER" ] &&
+    adb install --user "$WORK_USER" "$APK" && break
+  sleep 0.25
+done
+```
 
-## References
+This race only applies while the profile is being provisioned. After the DPC applies `DISALLOW_DEBUGGING_FEATURES`, the same `adb install --user` request should fail. It also does not require the payload to impersonate an existing package.
+
+The AOSP hardening adds `DISALLOW_DEBUGGING_FEATURES` to the restrictions enabled by default for managed profiles. It deliberately removes that restriction for profiles whose owner is provisioned through ADB so CTS and development flows continue to work. Do not validate the fix using an ADB-created Test DPC profile because that exercises the exception instead of the enterprise path.<sup>[[2]](#references)</sup>
+
+{% hint style="warning" %}
+In February 2026, Android documentation removed CVE-2025-22442 from the April 2025 bulletin's list of addressed vulnerabilities. Therefore, a displayed `2025-04-01` or newer security patch level is not sufficient evidence that the exact OEM build closes the provisioning window. Verify that a real EMM-created profile rejects the loop above from the moment its user ID becomes visible.<sup>[[3]](#references)</sup>
+{% endhint %}
+
+## Impact validation
+
+Being present in the Work Profile does **not** let the payload read every other app's private directory. Android UID isolation still applies. Validate concrete trust relationships instead:
 
-- [1] [Bypassing CVE-2023-21257 via Intune Required-App Auto-Install](https://jgnr.ch/sites/android_enterprise.html)
+* **Intent and provider trust:** look for exported components, implicit Intents, URI grants or workflows that send documents to the replaced package.
+* **Per-app VPN inheritance:** the original research observed that replacing a package selected for Microsoft Tunnel per-app VPN made the attacker process eligible for that route. Confirm the route with a harmless internal test endpoint because VPN assignment and identity checks vary by deployment.<sup>[[1]](#references)</sup>
+* **Package-only compliance:** determine whether the MDM checks only presence and version or also evaluates Play provenance, signing certificate, Play Integrity and app-specific authentication.
+* **Lifecycle:** deleting the payload, syncing policy, rebooting and removing the Work Profile are separate tests. Do not claim guaranteed persistence. A later repair can select the legitimate Play build once the local candidate is gone.
+
+## Detection and mitigation notes
+
+* For the required-app chain, compare reported package versions and signing certificates with the approved release. Alert on unexpected high version codes and packages whose installer or provenance changes.
+* Capture app inventory immediately after enrollment. This is especially useful for finding APKs inserted during the provisioning race.
+* Test the exact supported enrollment method and OEM image. Require a negative ADB installation test as part of acceptance testing rather than trusting only the security patch string.
+* Where operationally possible, assign sensitive apps as **Available** instead of **Required** until the required-app repair behaviour has been verified. This removes the auto-repair trigger used by the demonstrated Intune chain.<sup>[[1]](#references)</sup>
+* Do not map a high-value per-app VPN only by package name. Add application-layer authentication and device or app integrity checks.
+
+
+
+## References
 
+- [1] [Arbitrary App Installation on Intune Managed Android Enterprise BYOD](https://jgnr.ch/sites/android_enterprise.html)
+- [2] [AOSP: Disable Developer options by default for managed profiles](https://android.googlesource.com/platform/frameworks/base/+/2095d130b4d7f2ba1a3284abb58ca894817f5f4a)
+- [3] [AOSP site updates: February 2026 security documentation changes](https://source.android.com/docs/whatsnew/site-updates#february-2026)
 {{#include ../../banners/hacktricks-training.md}}