dis0rder0x00/trustedhivePoC d'élévation de privilèges locaux (LPE) pour Windows 11 exploitant l'objet COM de session Component Based Servicing (CBS) de TrustedInstaller et des jonctions pour une écriture de fichier arbitraire.
Élévation de privilèges locale via une méthode COM CBS non protégée - écriture arbitraire de fichiers de medium-IL vers SYSTEM sur Windows 11
| Date | Événement |
|---|---|
| 22 juillet 2026 | Vulnérabilité signalée au MSRC |
| 8 septembre 2026 | Microsoft corrige la pile de maintenance de Windows Update (Patch Tuesday de septembre) |
| 29 octobre 2026 | Le MSRC répond (voir ci-dessous) |
L'objet COM de session Component Based Servicing (CBS) s'exécute à l'intérieur de TrustedInstaller.exe en tant que SYSTEM et peut être activé par n'importe quel utilisateur interactif. Presque toutes les méthodes de l'interface de session appellent EnsureCallerIsAdministrator avant de poursuivre, à l'exception de CreateExternalTransformerExecutor, qui renvoyait un exécuteur de transformateur de magasin CSI de bas niveau sans aucune vérification d'autorisation.
La méthode Initialize() de cet exécuteur s'exécute en tant que SYSTEM sans emprunt d'identité. Un appelant de niveau d'intégrité moyen peut amener TrustedInstaller à créer un fichier journal de ruche de registre à un emplacement contrôlé par l'attaquant en exploitant des jonctions NTFS et des liens symboliques du gestionnaire d'objets, dont la création ne nécessite aucun privilège particulier.
CreateExternalTransformerExecutorRésultat : écriture arbitraire de fichiers dans n'importe quel répertoire existant en tant que SYSTEM, depuis un compte utilisateur normal. Aucun droit d'administrateur, aucun privilège spécial, aucune interaction utilisateur requise.
Le MSRC a évalué mon rapport comme de faible gravité / Défense en profondeur, déclarant que les « preuves de concept évaluées ne démontraient pas d'écritures de fichiers vers des emplacements non autorisés ». L'affaire a été close comme étant en dessous du seuil de maintenance immédiate, aucune CVE supplémentaire n'a été émise, aucune prime n'a été accordée, et le MSRC ne suivra plus le problème, ce qui est logique s'il s'agit d'un doublon.
Le PoC écrit un contenu contrôlé par l'attaquant dans C:\Windows\System32 depuis un processus de medium-IL non administrateur, et il l'a fait de manière fiable sur chaque build non corrigée sur laquelle il a été testé.
L'explication la plus probable de l'évaluation du MSRC est le timing : le rapport a été soumis en juillet, le correctif de la pile de maintenance a été livré en septembre, et la réponse du MSRC est arrivée en octobre, date à laquelle le PoC échouerait effectivement avec E_ACCESSDENIED sur tout système à jour.
J'ai tout de même été ajouté à la page des mentions spéciales du MSRC, c'est déjà ça :)
Je soupçonne que la vulnérabilité signalée ici est couverte par CVE-2026-81963 (« Windows Update Stack Elevation of Privilege Vulnerability »), qui a été corrigée dans la mise à jour mentionnée et décrit la même classe de vulnérabilité (CWE-59 / CWE-284, suivi de liens + contrôle d'accès inapproprié dans la pile de maintenance CBS). Ce CVE a été crédité à Romain Deperne (Airbus Helicopters) et au Microsoft Threat Intelligence Center (MSTIC), et a été confirmé comme activement exploité dans la nature avant le correctif. MAIS : je n'ai aucune confirmation officielle que mon rapport couvre le même problème.
Les deux PoC doivent être exécutés en tant qu'utilisateur normal, non administrateur (intégrité moyenne) et contiennent le même exploit de base. Si vous les exécutez avec des privilèges élevés, l'exploit réussit trivialement puisque vous êtes déjà administrateur, ce qui manque tout l'intérêt.
PoC_Fun/Le proof-of-concept complet avec une interface graphique. Un harnais graphique vibecodé qui enveloppe la technique d'exploit dans une interface interactive. Idéal pour les démos et pour tous ceux qui n'aiment pas les PoC ennuyeux en terminal uniquement (MAKE POCS FUN AGAIN!)
La police pixel art gothique monospace utilisée dans les titres et la bannière a été créée sur ma commande par nico_n_art.
Compilation :
$ cd PoC_Fun
$ dotnet clean -c Release && dotnet publish -c Release
$ .\bin\Release\net8.0-windows\win-x64\publish\TrustedHive.exe
Utilisation : Double-cliquez simplement sur la release et l'interface devrait vous guider, ou utilisez le « ? » pour ouvrir le menu d'aide.
PoC_Boring/Le fichier C autonome pour l'exploit. Pas d'interface et aucune dépendance au-delà de ole32.lib et advapi32.lib. Compilez avec MSVC (cl /O2 ...), pointez-le vers un fichier d'entrée et un chemin de sortie, et il fait le travail.
Compilation :
$ cd PoC_Boring
$ cl /nologo /W3 /O2 TrustedHive_PoC.c ole32.lib advapi32.lib /link
$ .\TrustedHive_PoC.exe
Utilisation :
$ .\TrustedHive_BoringPoC.exe <input_file> <output_path> [/keep]
<input_file> : file whose bytes are written to the target
<output_path> : destination (its parent directory must exist),
e.g. C:\Windows\System32\poc.dll
/keep : keep the Hidden+System attributes the Configuration Manager
stamps on the created hive-log file (default: clear them)
EvaluateApplicability) sous la même CVE