Une faille du SSO Azure de Windows Admin Center pourrait permettre à des attaquants de progresser depuis une machine compromise vers un accès à l’ensemble du tenant, à travers les machines virtuelles Azure et les systèmes connectés à Arc.
La vulnérabilité « … permet à un attaquant disposant d’un accès administrateur local sur une seule machine d’élever ses privilèges, d’exécuter du code à distance et de se déplacer latéralement entre les machines virtuelles Azure et les systèmes connectés à Arc au sein du même tenant, sans identifiants Azure valides », ont indiqué les chercheurs de Cymulate.
La faille de jeton de Windows Admin Center
Référencée sous le nom de CVE-2026-20965, cette faille concerne les organisations qui utilisent Windows Admin Center pour gérer des machines virtuelles Azure et des systèmes connectés à Arc, en particulier lorsque les administrateurs se connectent fréquemment via le portail Azure.
Le principal risque est qu’un attaquant ayant pris pied sur un système géré par WAC puisse potentiellement utiliser cet accès pour se déplacer latéralement et atteindre d’autres machines au sein du tenant.
Le flux de SSO Azure de Windows Admin Center repose sur deux jetons distincts qui fonctionnent conjointement.
Le premier, WAC.CheckAccess, sert à confirmer que l’utilisateur dispose des autorisations requises selon son rôle.
Le second est un jeton de preuve de possession (PoP), conçu pour empêcher la réutilisation d’un jeton en associant l’authentification à des clés cryptographiques générées dans le navigateur.
Dans des conditions normales, cette association permet de garantir que, même si un jeton est dérobé, il ne peut pas être réutilisé depuis un autre contexte.
Les chercheurs de Cymulate ont découvert que WAC ne validait pas ces jetons avec toute la rigueur nécessaire.
En pratique, des attaquants pouvaient associer un jeton WAC.CheckAccess volé à un jeton PoP falsifié, ce qui leur permettait d’usurper l’identité d’utilisateurs privilégiés et d’exécuter à distance des commandes d’administration sur d’autres systèmes compatibles avec WAC.
Le problème découle de plusieurs lacunes de validation, notamment l’absence de vérification de l’UPN entre les jetons, l’acceptation de jetons PoP inter-tenant, la réutilisation des valeurs nonce et la prise en charge du PoP pour des URL qui ne sont pas celles de la passerelle, comme l’accès direct par adresse IP via le port 6516.
Plus important encore, le jeton WAC.CheckAccess n’était pas suffisamment limité en portée, ce qui signifie que l’autorisation pouvait dépasser le cadre d’une seule machine et permettre de fait des accès plus larges à l’échelle du tenant.
Ce qu’il faut pour déclencher l’attaque
L’exploitation n’est pas entièrement « opportuniste ».
L’attaquant doit déjà disposer d’un accès administrateur local sur une machine virtuelle Azure compatible avec WAC ou sur une machine connectée à Arc, et un utilisateur privilégié doit ouvrir une session WAC via le portail Azure pendant la fenêtre d’opportunité de l’attaquant.
Mais une fois ces conditions réunies, le rayon d’action peut être considérable : déplacement latéral, élévation de privilèges et compromission étendue de systèmes que l’on pensait isolés.
Microsoft a publié un correctif pour résoudre le problème, et les organisations doivent l’appliquer immédiatement tout en examinant les journaux à la recherche de signes d’utilisation abusive de jetons ou d’une activité inhabituelle liée aux identités inter-tenant.
Comment réduire l’exposition à l’échelle du tenant
Les organisations qui exécutent Windows Admin Center dans Azure doivent considérer CVE-2026-20965 comme un risque hautement prioritaire, car cette vulnérabilité peut transformer un seul hôte compromis en une exposition plus large à l’échelle du tenant.
Les équipes de sécurité doivent également partir du principe qu’une utilisation abusive des jetons peut être difficile à détecter sans une surveillance ciblée.
- Mettez à niveau vers Windows Admin Center Azure Extension v0.70.00 ou une version ultérieure et supprimez WAC lorsqu’il n’est pas nécessaire afin de réduire la surface d’attaque.
- Limitez l’accès à WAC en appliquant le principe du moindre privilège, PIM et les contrôles d’accès conditionnel (par exemple, MFA, les appareils conformes et les règles de localisation et de risque).
- Verrouillez l’exposition réseau en limitant le port 6516 aux chemins approuvés passant exclusivement par la passerelle et en renforçant les règles NSG/JIT afin d’empêcher tout accès entrant généralisé.
- Isolez les systèmes compatibles avec WAC dans des sous-réseaux de gestion dédiés et limitez le trafic sortant afin de réduire les possibilités de déplacement latéral et d’utilisation abusive des jetons.
- Surveillez les anomalies liées à l’identité et aux jetons, notamment les ouvertures de session UPN sur des tenants différents, les comptes WAC_user inattendus et les signes de réutilisation de PoP ou de jetons.
- Déclenchez des alertes en cas d’activité WAC suspecte, comme des pics d’appels à InvokeCommand, de nouvelles identités sur les cibles ou la présence de services ou processus WAC malveillants révélant une interception.
Ces mesures présentent des actions concrètes pour contribuer à combler la faille, limiter les déplacements latéraux et détecter rapidement toute activité WAC suspecte.
Risque à l’échelle du tenant : un seul maillon faible
Cette vulnérabilité rappelle que les failles de validation des identités et des jetons peuvent transformer des flux d’administration ordinaires en un risque à l’échelle du tenant, en particulier dans les environnements cloud conçus pour la rapidité et le passage à l’échelle.
Les organisations doivent donner la priorité à la mise à jour de Windows Admin Center, puis renforcer les contrôles d’accès, les restrictions réseau et la surveillance afin de réduire le rayon d’action en cas de compromission d’un seul système.
C’est pourquoi les organisations adoptent un modèle de sécurité zero trust fondé sur le principe de considérer la compromission comme acquise et d’en limiter l’impact.