ResetNightmare CVE-2026-27912, Kerberos Changement de Mot de Passe, Active Directory : écrire soi-même son userPrincipalName suffit à réinitialiser un Domain Admin

Qu'est-ce que ResetNightmare CVE-2026-27912 Kerberos Changement de Mot de Passe Active Directory

ResetNightmare CVE-2026-27912 Kerberos Changement de Mot de Passe Active Directory : cette chaîne de mots désigne une seule faille, et c'est le chemin le plus court, dans un domaine, entre un accès en écriture sur un compte sacrifiable et un mot de passe Domain Admin réinitialisé. L'attaquant n'apprend jamais l'ancien mot de passe de la victime, ne relaie jamais d'identifiant, et ne casse jamais de hash. Il se contente de définir un nouveau mot de passe sur un compte sur lequel aucun droit ne lui a jamais été délégué.

La faille a été découverte par le chercheur Shai Laron de Semperis et publiée dans la recherche Identity Crisis de l'entreprise, aux côtés d'une seconde vulnérabilité distincte que la même recherche nomme KerberLoss (CVE-2026-25177). La description du National Vulnerability Database est laconique : « Improper authorization in Windows Kerberos allows an authorized attacker to elevate privileges over an adjacent network. »

Cette phrase cache la partie intéressante. « L'autorisation incorrecte » n'est pas une vérification d'ACL manquante sur un objet. C'est un contrôle d'identité qui existe, qui fonctionne correctement, et qui n'est tout simplement jamais atteint, parce que le protocole détourné prend un raccourci qui contourne exactement l'étape où vit ce contrôle.

Comment ça fonctionne, et pourquoi l'absence de TGS-REQ compte

Kerberos n'a pas une seule façon de nommer un principal, et Active Directory en utilise couramment deux. NT-PRINCIPAL nomme un compte par son sAMAccountName. NT-ENTERPRISE le nomme par son userPrincipalName, l'UPN. Un client peut placer l'une ou l'autre forme dans une AS-REQ, et le KDC la résout vers un compte et émet un ticket.

Les attaques exploitant cette ambiguïté ne sont pas nouvelles. En novembre 2021, la chaîne noPac, CVE-2021-42278 et CVE-2021-42287, permettait à un attaquant de renommer un compte qu'il contrôlait pour qu'un ticket émis pour une identité puisse être racheté comme une autre. Le correctif de Microsoft pour CVE-2021-42287, KB5008380, publié le 9 novembre 2021, a ajouté « de nouvelles informations sur le demandeur d'origine dans les PAC des Ticket-Granting Tickets (TGT) Kerberos », le buffer PAC Requestor. Le KDC l'utilise, selon les mots mêmes de Microsoft, lors de la « génération d'un ticket de service Kerberos », pour vérifier que « le compte qui a demandé le TGT est le même compte que celui référencé dans le ticket de service ».

Lisez cela attentivement, car ResetNightmare vit exactement dans l'interstice que cela laisse. Le SID PAC Requestor est validé au moment de la génération d'un ticket de service, pendant l'échange TGS-REQ.

Le protocole Kerberos de changement de mot de passe, lui, n'a pas de TGS-REQ.

Défini dans la RFC 3244 et servi sur le port 464, kpasswd, le flux de changement de mot de passe est délibérément court. Un client obtient un TGT, puis va directement vers une AP-REQ contre le service de changement de mot de passe. Il n'y a aucun échange de type ticket-granting intermédiaire, parce que le client ne demande pas un accès à un service au sens habituel du terme. Il présente une preuve de sa propre identité afin de changer un mot de passe. Semperis décrit ce flux comme allant directement de la demande de TGT à une AP-REQ, « sans TGS-REQ entre les deux ».

Sautez le TGS-REQ, et vous sautez avec lui la validation du PAC Requestor. Rien d'autre sur ce chemin ne re-dérive le SID du demandeur à partir du ticket. Ainsi, un TGT émis parce qu'un nom NT-ENTERPRISE se résolvait, à ce moment-là, vers l'objet de l'attaquant, est accepté par kpasswd comme une autorité sur le compte vers lequel ce nom se résout maintenant.

Le résultat s'aggrave de la façon dont les liaisons d'identité cassées s'aggravent toujours. L'attaquant définit un mot de passe qu'il connaît, sur un compte qu'il ne possède pas, et chaque connexion ultérieure en tant que ce compte est parfaitement légitime. À comparer avec les shadow credentials, où l'attaquant ajoute une clé plutôt qu'un mot de passe : même résultat, attribut différent, et les deux mettent en défaut l'hypothèse selon laquelle « l'attaquant doit tout de même casser quelque chose », sur laquelle repose encore une bonne partie de la modélisation des chemins d'attaque Active Directory. Les deux se combinent d'ailleurs : Semperis crédite Andrea Pierini de l'observation selon laquelle ResetNightmare « peut aussi être combiné à la technique Shadow Credentials, permettant un chemin d'attaque plus discret en abusant de comptes ordinateur inscriptibles ».

La chaîne d'attaque

Semperis publie la chaîne étape par étape. Le pivot est celui qui faisait fonctionner noPac : le nom porté par le ticket est résolu deux fois, et l'attaquant modifie sa résolution entre les deux. L'ordre ci-dessous n'est pas cosmétique : l'UPN doit être retiré avant le changement de mot de passe, pas après, sinon l'attaquant ne réinitialise que son propre mot de passe.

Étape 1 — Pointer l'UPN d'un compte contrôlé vers la victime

L'attaquant écrit le sAMAccountName de la victime dans le userPrincipalName d'un compte qu'il contrôle déjà, ou qu'il vient de créer.

Set-ADUser -Identity 'controlledUser' -UserPrincipalName 'da-admin'

Étape 2 — Demander un TGT pour kadmin/changepw par le nom enterprise

L'attaquant demande un TGT ciblant le SPN kadmin/changepw, en utilisant le type de nom NT-ENTERPRISE, en fournissant le nom d'utilisateur de la victime et le mot de passe du compte contrôlé. Ce SPN appartient à krbtgt, donc comme le formule Semperis, « un ticket pour kadmin/changepw n'est jamais qu'un TGT dont le SPN (sname) a été changé ». Le KDC résout le nom enterprise via l'UPN qui vient d'être écrit, trouve l'objet de l'attaquant, et renvoie un ticket portant le nom de la victime mais le SID de l'attaquant dans PAC_REQUESTOR_SID.

Étape 3 — Retirer l'UPN, avant de toucher au mot de passe

C'est l'étape dont la position décide si la chaîne escalade réellement. L'attaquant modifie ou efface maintenant l'UPN du compte contrôlé, « ne laissant aucun utilisateur avec l'UPN apparaissant sur le ticket ». Exécuter le changement de mot de passe pendant que l'UPN est encore en place, et le nom enterprise se résout toujours vers l'objet de l'attaquant lui-même : Semperis est explicite sur le fait que cela « réinitialisera le mot de passe de UPNUser » et rien de plus.

Étape 4 — Piloter le protocole de changement de mot de passe

Le TGT déjà émis est utilisé pour construire une demande de changement de mot de passe via Kerberos, directement vers une AP-REQ sur le port 464. Aucune TGS-REQ n'est émise, donc le SID PAC Requestor n'est jamais vérifié, et le nouveau mot de passe atterrit sur la véritable victime. Semperis note ce contraste avec précision : réutiliser ce même ticket dans une TGS-REQ après le changement d'UPN « entraînera une erreur KDC_ERR_TGT_REVOKED, en raison du correctif PAC_REQUESTOR_SID, bloquant l'usurpation. En revanche, en utilisant ce ticket pour construire la demande de changement de mot de passe, le changement de mot de passe fonctionne. »

Étape 5 — S'authentifier en tant que la victime

Un nouveau TGT est demandé pour le véritable compte victime, en utilisant le mot de passe que l'attaquant vient de définir et sans le type de nom NT-ENTERPRISE. Il revient avec le type de nom NT-PRINCIPAL, ce qui constitue la preuve que le ticket appartient bien au véritable détenteur du sAMAccountName. À partir de là, l'attaquant détient une identité normale, entièrement valide.

Le proof of concept public regroupe tout cela dans une seule fonction PowerShell. Il nécessite le module ActiveDirectory et une copie de Rubeus, et son usage publié tient en un seul appel :

Invoke-ResetNightmare -TargetAccount "victim" -TargetNewPassword "NewP@ssw0rd!" -UPNUser "controlledUser" -UPNUserPassword "ControlledP@ss!"

Qui peut vraiment exécuter cette attaque, et qui ne le peut pas

C'est ici qu'une bonne partie de la couverture médiatique secondaire exagère la faille, il vaut donc la peine de citer la recherche directement. Semperis affirme que la vulnérabilité « permet une prise de contrôle complète du domaine par un attaquant disposant de permissions Generic Write sur n'importe quel objet utilisateur ou ordinateur du domaine, ou pouvant créer des objets utilisateur ou ordinateur dans le domaine (hors MachineAccountQuota) ».

Deux clauses de cette phrase méritent d'être soulignées, car ensemble elles fixent la vraie barre :

• Generic Write sur n'importe quel objet utilisateur ou ordinateur. Pas sur la victime. L'attaquant a besoin d'un accès en écriture sur un objet qu'il peut pointer vers la victime, ce qui, dans la plupart des domaines, est une délégation bien plus courante qu'un accès en écriture sur un compte Tier 0.
• Hors MachineAccountQuota. C'est la limite qui sépare ResetNightmare de noPac. La capacité par défaut d'un utilisateur authentifié à joindre dix machines au domaine n'est pas suffisante ici, donc « n'importe quel utilisateur du domaine par défaut » est un résumé erroné de ce CVE.

Le FAQ de Microsoft précise l'autre moitié de la barre, le vecteur d'attaque adjacent (AV:A) : l'exploitation « nécessite que l'attaquant se trouve dans le même domaine Active Directory restreint que le système cible ». Au moment de la publication, le MSRC avait également classé la faille comme non divulguée publiquement, non exploitée, et « Exploitation Less Likely » — une évaluation faite en avril 2026, avant la publication de la recherche et l'existence du proof of concept.

Il existe une contrainte supplémentaire. Semperis note que « la seule autre exigence est que le mot de passe de l'utilisateur cible doit être suffisamment ancien », et observe que l'âge minimal de mot de passe par défaut dans la Default Domain Policy est de 1 jour, de sorte qu'un véritable compte admin satisfera presque toujours cette condition.

Détection

L'indicateur principal cité par la recherche est l'Event ID 5136, « un objet du service d'annuaire a été modifié », filtré sur les ajouts d'un userPrincipalName qui correspond au sAMAccountName d'un compte existant. C'est une signature précise, à faible bruit : dans un domaine sain, un préfixe d'UPN ne devrait pratiquement jamais entrer en collision avec le nom de connexion d'un objet différent.

Côté mot de passe, attendez-vous à 4723 plutôt qu'à 4724. Semperis distingue directement les deux opérations de protocole, notant que Microsoft utilise les termes « change password » et « set password » « pour différencier un utilisateur changeant son propre mot de passe d'un administrateur définissant le mot de passe d'un utilisateur ». ResetNightmare pilote l'opération de changement — ce qui explique aussi pourquoi l'âge minimal du mot de passe de la cible est une précondition — donc le contrôleur de domaine enregistre le 4723, « une tentative de changement du mot de passe d'un compte a été effectuée ». L'événement 4724 couvre le chemin de réinitialisation qu'emprunte un administrateur ou un compte helpdesk délégué. Il vaut la peine d'être surveillé pour lui-même, mais ce n'est pas l'artefact que laisse ce CVE.

La même collision peut être recherchée rétrospectivement dans l'état de l'annuaire, ce qui vaut la peine d'être fait une fois même si votre audit était désactivé :

# Chaque préfixe d'UPN entrant en collision avec le sAMAccountName d'un objet différent
$sam = @{}
Get-ADObject -LDAPFilter '(|(objectClass=user)(objectClass=computer))' -Properties sAMAccountName |
    ForEach-Object { if ($_.sAMAccountName) { $sam[$_.sAMAccountName] = $_.DistinguishedName } }

Get-ADUser -Filter 'userPrincipalName -like "*"' -Properties userPrincipalName |
    Where-Object {
        $prefix = ($_.UserPrincipalName -split '@')[0]
        $sam.ContainsKey($prefix) -and $sam[$prefix] -ne $_.DistinguishedName
    } | Select-Object SamAccountName, UserPrincipalName, DistinguishedName

Remédiation

1. Prouvez le correctif, ne le supposez pas. Semperis est explicite : « la meilleure prévention pour ces vulnérabilités est de corriger tous les DC ». Un seul DC non corrigé, ou hors ligne depuis longtemps, garde le domaine exploitable, donc recensez les numéros de build plutôt que de faire confiance à un tableau de bord de conformité.

Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem,
    @{n='Build';e={ (Get-CimInstance Win32_OperatingSystem -ComputerName $_.HostName).Version }}

2. Retirez la délégation de réinitialisation de mot de passe en dehors du Tier 0. La deuxième recommandation de la recherche est que « les organisations devraient s'en tenir au principe du moindre privilège et surveiller les ajouts anormaux de permissions non par défaut ». Le droit à auditer est le droit étendu User-Force-Change-Password, documenté par Microsoft sous le nom d'affichage « Reset Password » et le Rights-GUID 00299570-246d-11d0-a768-00aa006e0529.

$resetPwd = [guid]'00299570-246d-11d0-a768-00aa006e0529'
Get-ADUser -Filter * -SearchBase (Get-ADDomain).DistinguishedName | ForEach-Object {
    $dn = $_.DistinguishedName
    (Get-Acl "AD:$dn").Access |
        Where-Object { $_.ObjectType -eq $resetPwd -and $_.AccessControlType -eq 'Allow' } |
        Select-Object @{n='Target';e={$dn}}, IdentityReference, ActiveDirectoryRights
}

3. Contraignez qui peut créer des comptes. Puisque l'attaque fonctionne pour un attaquant capable de créer des objets utilisateur ou ordinateur en dehors du MachineAccountQuota, passez en revue les droits Create Child délégués sur les OU. Une délégation accordée des années plus tôt pour un helpdesk ou un outil de déploiement est le constat habituel ici, et c'est la même classe de délégation obsolète que couvre l'audit des ACE dangereuses et des SID orphelins.

4. Activez l'audit qui rend visible l'étape 1 de la chaîne. Activez Audit Directory Service Changes et configurez des SACL pour que les écritures sur userPrincipalName des objets utilisateur et ordinateur génèrent du 5136.

5. Ne présumez de rien sur la fenêtre d'exposition. Le correctif date d'avril 2026 et le PoC est public maintenant. Si un DC a pris du retard, traitez les changements de mot de passe privilégiés survenus durant cette fenêtre comme suspects : passez en revue les événements 4723 sur les cibles Tier 0, avec les 4724 en parallèle pour le chemin de réinitialisation déléguée, et confirmez que chacun correspond à un ticket helpdesk réel. La checklist d'hygiène plus large de l'audit de la sécurité Active Directory et la revue Tier 0 des comptes privilégiés, Protected Users et délégation s'appliquent toutes deux directement.

Semperis ne nomme aucune mitigation au-delà du correctif et du moindre privilège, et ce plafond mérite d'être énoncé clairement. L'appartenance à Protected Users en particulier ne devrait pas être attendue comme bloquant cette attaque : les protections que Microsoft documente pour ce groupe bloquent NTLM, interdisent DES et RC4 dans la pré-authentification Kerberos, interdisent la délégation contrainte et non contrainte et plafonnent la durée de vie du TGT, et aucune de ces protections n'est ce qui échoue ici. La faille réside dans la façon dont le KDC lie une identité pendant l'échange de changement de mot de passe, ce qui explique aussi pourquoi les mesures de durcissement visant le vol de tickets, comme le nettoyage de la délégation Kerberos ou la rotation du mot de passe krbtgt, sont utiles pour d'autres raisons mais sans rapport avec le CVE-2026-27912.

Comment EtcSec détecte cela

ResetNightmare est un problème que l'on corrige une fois pour toutes, mais son prérequis est un problème de permissions qui survit à n'importe quel CVE isolé. EtcSec audite exactement cette surface.

ACL_USER_FORCE_CHANGE_PASSWORD et ACL_FORCECHANGEPASSWORD recensent chaque principal détenant le droit étendu Reset Password, et ACL_GENERICALL fait remonter les délégations d'écriture générique qui permettent à un attaquant de réécrire le userPrincipalName d'un autre objet en premier lieu.

Pour les équipes qui travaillent sur un référentiel de conformité, ANSSI_R12_1_FORCE_PWD_RESET_PRIVS signale le droit User-Force-Change-Password accordé en dehors des comptes système, et ANSSI_R12_2_USER_RESTRICTIONS_PRIVS fait de même pour User-Account-Restrictions. Les deux répondent à la question « qui peut agir sur ce compte » que le CVE-2026-27912 transforme en compromission du domaine. Des contrôleurs de domaine plus anciens accroissent encore l'enjeu, ce qui explique pourquoi la fin de support de Windows Server 2016 compte ici.

Sources

• MSRC — CVE-2026-27912, Windows Kerberos Elevation of Privilege Vulnerability
• NVD — CVE-2026-27912
• Semperis — Identity Crisis: novel vulnerabilities leading to Kerberos downgrade, DoS and full domain takeover
• Semperis-Community/ResetNightmare (proof of concept)
• Microsoft — KB5008380 authentication updates (CVE-2021-42287)
• Microsoft — User-Force-Change-Password extended right
• Microsoft — Event 4723, an attempt was made to change an account's password
• Microsoft — Event 4724, an attempt was made to reset an account's password
• Microsoft — Protected Users security group
• Microsoft — Minimum password age