Android Enterprise Work Profile Required-App Replacement

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

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.

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:

  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.

Recon and prerequisite checks

  • Confirm multi-user layout and user IDs:
adb shell pm list users
# Expect user 0 = Owner, user 1 = Work profile (or higher if multiple profiles exist)
  • Direct installs into the work user fail under policy (expected error):
adb install --user 1 legit.apk
# java.lang.SecurityException: Shell does not have permission to access user 1
  • You must have temporary physical access to an unlocked BYOD to enable Developer Options + USB debugging.
  • Identify the package name of a Work-Profile app marked as required (e.g. com.workday.workdroidapp).

Weaponising the Android Studio 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.

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:

android {
    namespace = "com.workday.workdroidapp"
    defaultConfig {
        applicationId = "com.workday.workdroidapp"
        versionCode = 900000004
        versionName = "9000000004.0"
    }
}

When Android Studio deploys:

  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.

Intune/Finsky auto-install bypass

Within ~1–10 minutes (policy refresh interval):

  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.

The malicious binary now resides inside the Work Profile under the genuine package name and is considered compliant by the MDM.

Post-exploitation opportunities

  • 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.
  • 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.

References

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks