Android Enterprise Work Profile Required-App Replacement
Tip
Apprenez et pratiquez le hacking AWS :
HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP :HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez le hacking Azure :
HackTricks Training Azure Red Team Expert (AzRTE)
Soutenir HackTricks
- Vérifiez les plans d’abonnement !
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.
Surface d’attaque
Android Enterprise Work Profiles are implemented as secondary Android users (BYOD example: user 0 = personal, user 1 = work). Chaque utilisateur possède des arbres /data/user/<id> indépendants, des applications système, des instances Play Services et des objets de politique maintenus par le MDM. Quand un MDM comme Microsoft Intune marque une app comme requis pour le Work Profile, le Work-Profile Play Store (Finsky) vérifie périodiquement que le package est présent et le réinstalle automatiquement si absent.
Même après le patch CVE-2023-21257 qui bloque les sideloads ADB lorsque DISALLOW_INSTALL_APPS ou DISALLOW_DEBUGGING_FEATURES sont définis, la chaîne suivante permet à un attaquant de remplacer n’importe quelle app Work Profile requise par Intune par du code arbitraire :
- Abuser du chemin d’Android Studio “Install for all users” pour déposer un APK malveillant qui ressemble à une mise à jour du package géré.
- Laisser le MDM constater que l’app requise est manquante. Intune déclenche l’instance Finsky du Work-Profile pour la réinstaller.
- Finsky compare la version de l’APK mis en scène avec celle du Play Store et installe silencieusement le
versionCodele plus élevé, contournant la restriction originale.
Recon et vérifications préalables
- Confirmer la disposition multi-utilisateurs et les IDs utilisateur:
adb shell pm list users
# Expect user 0 = Owner, user 1 = Work profile (or higher if multiple profiles exist)
- Les installations directes dans le work user échouent à cause de la politique (erreur attendue) :
adb install --user 1 legit.apk
# java.lang.SecurityException: Shell does not have permission to access user 1
- Vous devez avoir un accès physique temporaire à un BYOD déverrouillé pour activer Developer Options + USB debugging.
- Identifiez le package name d’une application Work-Profile marquée comme required (p.ex.
com.workday.workdroidapp).
Exploitation de l’installateur multi-utilisateur d’Android Studio
La configuration Run/Debug d’Android Studio peut toujours pousser des builds avec le flag INSTALL_ALL_USERS. Avant d’exécuter, activez Deploy as instant app → Install for all users.
Générez la charge utile malveillante avec le même package name que l’application gérée et un versionCode beaucoup plus élevé afin que PackageManager/Finsky la traite comme une version plus récente :
android {
namespace = "com.workday.workdroidapp"
defaultConfig {
applicationId = "com.workday.workdroidapp"
versionCode = 900000004
versionName = "9000000004.0"
}
}
When Android Studio deploys:
- Personal user (0) installe normalement le package malveillant.
- Work Profile user (1) reçoit l’APK dans une zone de staging temporaire et tente de le traiter comme une mise à jour.
- La logique de CVE-2023-21257 constate que l’utilisateur est restreint → l’installation est refusée, mais l’application gérée légitime est marquée comme désinstallée et l’APK en staging reste mis en cache.
Intune/Finsky auto-install bypass
Dans un délai d’environ 1–10 minutes (intervalle de rafraîchissement des politiques) :
- Intune/Company Portal détecte que le package requis est manquant du Work Profile.
- L’instance Finsky du Work Profile est sollicitée pour le réinstaller.
- Lors de la résolution de version, Finsky compare :
- les métadonnées Play Store pour
com.workday.workdroidapp. - l’APK local mis en staging lors de la tentative d’installation précédente.
- Parce que la build locale a le plus haut
versionCode, Finsky la considère comme la release la plus récente et l’installe dans le Work Profile restreint sans ré-appliquer les vérificationsDISALLOW_INSTALL_APPS/DISALLOW_DEBUGGING_FEATURES.
Le binaire malveillant réside maintenant dans le Work Profile sous le nom de package légitime et est considéré comme conforme par le MDM.
Post-exploitation opportunities
- Accès aux données du Work Profile – d’autres applications d’entreprise continuent de faire confiance aux Intents/content providers liés au package remplacé, permettant le vol de données internes et l’exfiltration covert depuis le Work Profile vers l’infrastructure de l’attaquant.
- Détournement de per-app VPN – si le package remplacé est mappé à un per-app VPN Intune (MS Tunnels + Defender), la build malveillante hérite automatiquement du profil VPN, donnant un accès direct aux hôtes internes depuis un processus contrôlé par l’attaquant.
- Persistance – parce que le MDM croit désormais que l’application requise est installée, il réinstallera la build malveillante chaque fois que l’utilisateur ou le défenseur la supprimera, assurant une présence longue durée sur les BYOD Work Profiles.
References
Tip
Apprenez et pratiquez le hacking AWS :
HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP :HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez le hacking Azure :
HackTricks Training Azure Red Team Expert (AzRTE)
Soutenir HackTricks
- Vérifiez les plans d’abonnement !
- Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
- Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.
HackTricks

