Depuis l’installation du correctif cumulatif KB5051989 de février 2025, les kiosques Windows 11 23H2 configurés avec AppLocker peuvent être contournés en renommant un exécutable : une régression critique qui ouvre la porte à l’évasion de kiosque et à l’élévation de privilèges.
Contexte et portée
Les environnements kiosque sous Windows 11 23H2 (build 22631.4890) reposent souvent sur Assigned Access multi‑applications pour exposer un nombre restreint d’outils métiers. La sécurité est assurée par AppLocker : des règles construites sur le chemin, le hash ou la signature bloquent toute exécution non autorisée. Or, depuis l’application de KB5051989, une anomalie dans le moteur d’évaluation fait que le système ne reconnaît plus correctement un binaire lorsque son nom change. Résultat : il suffit de copier cmd.exe dans un dossier accessible en écriture, le renommer en msedge.exe (ou tout autre binaire autorisé) et l’exécuter pour sortir du kiosque.
Fonctionnement normal d’AppLocker en mode kiosque
En mode kiosque multi‑applications, AppLocker est généralement configuré avec :
- des règles de chemin permettant seulement le lancement d’
%ProgramFiles%\Microsoft\Edge\msedge.exe; - des règles de signature éditeur autorisant certains composants Microsoft signés ;
- un mode obligatoire (enforce) pour bloquer tout ce qui n’est pas explicitement listé.
Avant la mise à jour, si un utilisateur plaçait cmd.exe dans son profil et le renommait, le moteur détectait le chemin : %USERPROFILE%\Desktop\msedge.exe ne correspondait pas à la règle et l’exécution était logiquement bloquée (événement 8004). KB5051989 casse cette chaîne de décision : le contrôle par chemin considère désormais uniquement le nom de fichier final ; le moteur suppose « MS Edge » et autorise le lancement.
Analyse de la régression introduite par KB5051989
La note de version officielle n’annonce qu’une « amélioration de la performance des filtres WMI ». Pourtant, le patch diff révèle une modification du composant AppID.dll : le calcul de l’empreinte repose à présent sur un cache optimisé qui, dans certains cas, ne rafraîchit pas le fully qualified path après l’opération rename. Le bogue touche spécifiquement les modes :
- Kiosque multi‑applications (
AssignedAccessConfiguration) ; - Règles AppLocker de type chemin (
FilePathRule) en étatDeny/Allow.
Autrement dit, les serveurs, stations ou kiosques configurés avec des règles AppLocker basées sur hash ou signature éditeur ne sont pas affectés, tandis que ceux appuyant leur sécurité sur le chemin le sont pleinement.
Démonstration pas à pas
- Ouvrir une session restreinte sur le kiosque.
- Copier
C:\Windows\System32\cmd.exevers%USERPROFILE%\Downloads\. - Renommer le fichier en
msedge.exe. - Double‑cliquer : l’invite de commandes s’ouvre alors qu’elle devrait être bloquée.
- Le journal des événements (
Microsoft‑Windows‑AppLocker/EXE and DLL) ne montre aucun ID 8004, preuve que la règle n’a même pas été évaluée.
Impacts en production
La gravité dépend de la surface d’écriture :
- Postes publics (bornes interactives) : un utilisateur malveillant peut lancer
cmd.exe, puispowershell.exe, télécharger des outils et obtenir des privilèges SYSTEM viarunasou des failles locales. - Ateliers industriels : exécution de programmes tiers susceptibles de perturber le processus.
- Environnements scolaires : accès à des contenus interdits ou propagation de malwares sur le réseau.
Recommandations opérationnelles immédiates
| Axe | Mesure recommandée |
|---|---|
| Isolation | Désinstaller ou mettre en pause KB5051989 sur les postes critiques via Intune, WSUS ou stratégie de groupe (Select when Preview Builds and Quality Updates are received). |
| Renforcement des règles | Convertir les règles AppLocker basées sur chemin en règles hash ou publisher, ou migrer vers WDAC (Windows Defender Application Control) avec un policy signing strict. |
| Réduction de surface | Restreindre les autorisations d’écriture : bloquer la copie dans %PUBLIC%, filtrer les supports USB, placer le profil utilisateur sur un volume NTFS read‑only. |
| Surveillance | Activer l’audit AppLocker (ID 8004) en parallèle du mode enforce ; exporter les journaux vers Microsoft Sentinel pour une corrélation. |
| Escalade produit | Ouvrir un ticket Premier/Unified, suivre la rubrique « Known Issues » des prochains correctifs et voter dans le Centre de commentaires Windows pour prioriser la résolution. |
Script PowerShell d’audit rapide
# Vérifier la présence de KB5051989 et détecter les binaires renommés
$kb = Get‑HotFix ‑Id KB5051989 ‑ErrorAction SilentlyContinue
if ($kb) {
Write‑Host "KB5051989 installé le $($kb.InstalledOn)"
Get‑ChildItem -Path $env:USERPROFILE -Filter *.exe -Recurse |
Where‑Object { $.Name -eq 'msedge.exe' -and $.DirectoryName -notlike 'Program Files' } |
ForEach‑Object {
Write‑Host "⚠ Binaire suspect trouvé : $($_.FullName)"
}
} else {
Write‑Host 'Correctif non installé – système potentiellement sûr.'
}Stratégie de remédiation à long terme
Passage à WDAC
WDAC remplace progressivement AppLocker sur les terminaux modernes. Basé sur le noyau, il applique les règles avant même le chargement de l’EXE : un renommage de fichier ne trompe donc pas la politique. Il est possible de générer une stratégie WDAC à partir des règles AppLocker existantes (Convert‑From‑AppLockerPolicy) puis de la signer et de la déployer via Intune.
Mise en place de rings de validation
Pour éviter les régressions futures :
- Créer un ring « Pilote » (5 % du parc) recevant les mises à jour cumulatives dès J+0.
- Attendre 14 jours et vérifier les journaux AppLocker, WDAC et Defender.
- Élargir au ring « Largeur » (20 %) puis « Production » si aucun incident n’est détecté.
Automatisation des tests
Intégrez un test de non‑régression AppLocker dans votre pipeline :
- Déployer la build candidat.
- Exécuter un script qui renomme
cmd.exeenmsedge.exe. - Mesurer le code de retour ; l’attendu est un échec (exit code 5).
- Remonter une alerte Teams/Slack en cas de succès inattendu.
Questions fréquentes (FAQ)
Q : Puis‑je simplement désactiver AppLocker le temps qu’un correctif arrive ?
R : Non. Vous perdriez toute barrière de confinement. Préférez le mode Audit pour observer l’impact tout en conservant un minimum de contrôle.
Q : Les règles de registre (.reg) ou de script (.ps1) sont‑elles touchées ?
R : La régression concerne uniquement la validation des exécutables .exe et .dll. Les règles script sont toujours appliquées normalement.
Q : Un correctif hors bande est‑il prévu ?
R : Microsoft ne communique pas encore de date. La priorité dépend du volume de tickets Premier et des votes dans le Centre de commentaires.
Conclusion
KB5051989 réintroduit une faiblesse corrigée en 2020 : l’identification des exécutables par AppLocker chemin peut être contournée par simple renommage. Sur les kiosques Windows 11 23H2, le risque est majeur : un utilisateur non privilégié franchit les limites imposées et peut élever ses droits. Jusqu’à la disponibilité d’un correctif officiel, la meilleure défense combine la mise en pause du correctif incriminé, le renforcement des règles par hash/signature ou, idéalement, la migration vers WDAC. En parallèle, restreindre l’écriture des utilisateurs et surveiller les journaux AppLocker restent des réflexes essentiels. Investir dans des rings de validation et des tests automatisés évitera que ce type de régression ne refasse surface à l’avenir.