ResetNightmare (CVE-2026-27912) : comprendre et vérifier son exposition

Dans Active Directory, le nom affiché d’un compte et son identifiant de sécurité ne sont pas la même chose. ResetNightmare exploite une confusion d’identité dans un parcours Kerberos de changement de mot de passe. Pour un responsable informatique, l’enjeu est concret : vérifier les contrôleurs de domaine, examiner les délégations sensibles et disposer de traces interprétables.

1. Comprendre le mécanisme sans reproduire l’attaque

Kerberos utilise des tickets pour authentifier les utilisateurs et les services. L’UPN est un nom de connexion ; le SID identifie le compte dans le système de sécurité. La recherche de Semperis décrit une confusion entre des noms de comptes et l’identité effectivement autorisée dans le service de changement de mot de passe. Avec les permissions nécessaires sur un UPN, le scénario peut conduire à la prise de contrôle d’un compte privilégié. La publication indique que Microsoft a corrigé ResetNightmare le 14 avril 2026.

Cette description provient de la recherche originale de Semperis. Elle distingue ResetNightmare de KerberLoss, une autre vulnérabilité étudiée dans le même travail. Ce guide ne décrit pas une désynchronisation de clés LSASS, ne fournit pas de chaîne d’exploitation et ne présente pas la désactivation de RC4 comme le correctif de cette CVE.

2. Préparer un inventaire fiable

Périmètre : Active Directory Domain Services et les contrôleurs de domaine Windows concernés par l’avis éditeur. Relevez la version, l’édition, le numéro de build, les mises à jour installées et l’état de redémarrage de chaque serveur. Incluez les sites distants et les équipements momentanément indisponibles. Un serveur absent de la collecte reste à vérifier, il ne devient pas sain par défaut.

Avant toute modification, vérifiez la santé de la réplication, la disponibilité de sauvegardes utilisables et votre procédure de récupération de l’annuaire. Utilisez un poste d’administration et un compte autorisés. Les contrôles documentaires ci-dessous peuvent être préparés sans toucher aux comptes ; les changements de configuration exigent un périmètre pilote et une fenêtre adaptée.

3. Vérifier le correctif, sans inventer un numéro de KB

Ouvrez la fiche Microsoft CVE-2026-27912 et sélectionnez le produit exact. Relevez la mise à jour applicable, ses prérequis et ses éventuels remplacements cumulatifs. Le contenu dynamique de cette fiche ne permettait pas, lors de cette rédaction, de confirmer ici une table complète des versions et KB. Aucun numéro de mise à jour universel n’est donc proposé.

Comparez ensuite avec votre inventaire et les preuves de déploiement. Après une mise à jour pilote, vérifiez les connexions, les changements de mot de passe légitimes, les services dépendants et la réplication. La présence d’un package sans redémarrage requis terminé ne suffit pas à clore le dossier.

Si un produit n’est plus maintenu, traitez explicitement cette situation avec l’éditeur et le responsable du risque. Une mesure de réduction d’exposition ne doit pas être étiquetée « corrigé » sans démonstration.

4. Examiner les droits et les traces

Revoyez qui peut modifier userPrincipalName, directement ou par des droits plus larges, et sur quels objets. Les groupes imbriqués et l’héritage peuvent donner un droit indirect. Demandez au propriétaire de chaque délégation son besoin réel avant une suppression qui pourrait interrompre un processus de gestion des comptes.

L’événement Windows 5136 peut décrire une modification d’objet AD lorsque la politique d’audit et la SACL de l’objet sont adaptées. Examinez l’attribut, les valeurs, l’objet et l’auteur. Corrélez avec les opérations de comptes et la chronologie d’authentification disponible. Des renommages légitimes peuvent produire des événements voisins.

Ne transformez pas une requête générique sur les tickets Kerberos en « détecteur ResetNightmare ». Il faut vérifier les champs réellement présents dans votre collecteur, les événements attendus pour le scénario et le bruit normal. Une absence d’alerte peut venir d’une collecte incomplète.

5. Recette de validation et retour arrière

• Consigner les versions et correctifs de deux contrôleurs de laboratoire, sans comptes ni secrets de production.
• Vérifier un changement d’UPN autorisé sur un compte de test et sa présence dans la collecte.
• Vérifier qu’un rôle non habilité ne peut pas effectuer la même modification.
• Tester les parcours de connexion et de changement de mot de passe après le correctif applicable.
• Comparer les délégations avant et après réduction des droits, puis rétablir uniquement la délégation de test si nécessaire.
• Documenter les limites de détection et faire relire les conclusions après chaque rejeu.

La stratégie de retour arrière d’une mise à jour de contrôleur de domaine doit suivre les procédures de récupération supportées. Évitez de restaurer arbitrairement une ancienne image pour résoudre une difficulté d’authentification. En cas d’indice de compromission, préservez les éléments et faites traiter le périmètre identité : appliquer le correctif ne révoque pas automatiquement des accès déjà acquis.

Sources et références

Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.

• Semperis - Recherche ResetNightmare et KerberLoss
• Microsoft MSRC - CVE-2026-27912, produits et mises à jour
• Microsoft - Événement 5136 et prérequis d’audit