ResetNightmare CVE-2026-27912, Kerberos Change Password, Active Directory: Writing Your Own userPrincipalName Is Enough to Reset a Domain Admin

What Is ResetNightmare CVE-2026-27912 Kerberos Change Password Active Directory

ResetNightmare CVE-2026-27912 Kerberos Change Password Active Directory: that string names a single flaw, and it is the shortest path in a domain from write access on a throwaway account to a reset Domain Admin password. The attacker never learns the victim's old password, never relays a credential, and never cracks a hash. They simply set a new password on an account they were never delegated any rights over.

The flaw was found by Semperis researcher Shai Laron and published in the company's Identity Crisis research, alongside a second, separate vulnerability the same research names KerberLoss (CVE-2026-25177). The National Vulnerability Database description is terse: "Improper authorization in Windows Kerberos allows an authorized attacker to elevate privileges over an adjacent network."

That sentence hides the interesting part. The "improper authorization" is not a missing ACL check on an object. It is an identity check that exists, works correctly, and is simply never reached, because the protocol being abused takes a shortcut past the exact step where the check lives.

How It Works, and Why the Missing TGS-REQ Matters

Kerberos does not have one way of naming a principal, and Active Directory routinely uses two. NT-PRINCIPAL names an account by its sAMAccountName. NT-ENTERPRISE names it by its userPrincipalName, the UPN. A client can put either form in an AS-REQ, and the KDC resolves it to an account and issues a ticket.

Attacks abusing that ambiguity are not new. In November 2021 the noPac chain, CVE-2021-42278 and CVE-2021-42287, let an attacker rename an account they controlled so a ticket issued for one identity could be redeemed as another. Microsoft's fix for CVE-2021-42287, KB5008380, released 9 November 2021, added "new information about the original requestor to the PACs of Kerberos Ticket-Granting Tickets (TGT)", the PAC Requestor buffer. The KDC uses it, in Microsoft's own words, when "generating a Kerberos service ticket", to verify that "the account that requested the TGT is the same account referenced in the service ticket".

Read that carefully, because ResetNightmare lives in the gap it leaves. The PAC Requestor SID is validated when a service ticket is generated, during the TGS-REQ exchange.

The Kerberos change password protocol has no TGS-REQ.

Defined in RFC 3244 and served on port 464, kpasswd, the change password flow is deliberately short. A client obtains a TGT, then goes straight to an AP-REQ against the password change service. There is no intervening ticket-granting exchange, because the client is not requesting access to a service in the usual sense. It is presenting proof of its own identity in order to change a password. Semperis describes the flow as going directly from the TGT request to an AP-REQ, "without a TGS-REQ in between".

Skip the TGS-REQ and you skip the PAC Requestor validation with it. Nothing else on that path re-derives the requester's SID from the ticket. So a TGT minted because an NT-ENTERPRISE name happened to resolve to the attacker's own object is accepted by kpasswd as authority over whichever account that name resolves to now.

The outcome compounds the way broken identity bindings always do. The attacker sets a password they know, on an account they do not own, and every subsequent logon as that account is entirely legitimate. Compare shadow credentials, where the attacker adds a key rather than a password: same outcome, different attribute, and both defeat the "the attacker still has to crack something" assumption that a lot of Active Directory attack path modelling still rests on. The two also compose: Semperis credits Andrea Pierini with the observation that ResetNightmare "can also be combined with the Shadow Credentials technique, enabling a stealthier attack path by abusing writable computer accounts".

The Attack Chain

Semperis publishes the chain step by step. The pivot is the one that made noPac work: the name carried in the ticket is resolved twice, and the attacker changes what it resolves to in between. The order below is not cosmetic: the UPN has to be withdrawn before the password change, not after, or the attacker only resets their own password.

Step 1 — Point a controlled account's UPN at the victim

The attacker writes the victim's sAMAccountName into the userPrincipalName of an account they already control, or one they just created.

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

Step 2 — Request a TGT for kadmin/changepw by enterprise name

The attacker requests a TGT scoped to the kadmin/changepw SPN, using the NT-ENTERPRISE name type, supplying the victim's username and the controlled account's password. That SPN belongs to krbtgt, so as Semperis puts it, "a ticket to kadmin/changepw is just a TGT with the SPN (sname) changed". The KDC resolves the enterprise name through the UPN just written, finds the attacker's object, and returns a ticket carrying the victim's name but the attacker's SID in PAC_REQUESTOR_SID.

Step 3 — Withdraw the UPN, before touching the password

This is the step whose position decides whether the chain escalates at all. The attacker now changes or clears the controlled account's UPN, "leaving no user with the UPN appearing on the ticket". Run the password change while the UPN is still in place, and the enterprise name still resolves to the attacker's own object: Semperis is explicit that doing so "will reset UPNUser's password" and nothing more.

Step 4 — Drive the change password protocol

The already-issued TGT is used to build a password change request over Kerberos, straight to an AP-REQ on port 464. No TGS-REQ is issued, so the PAC Requestor SID is never checked, and the new password lands on the real victim. Semperis records the contrast precisely: reusing that same ticket in a TGS-REQ after the UPN change "will result in a KDC_ERR_TGT_REVOKED error, due to the PAC_REQUESTOR_SID patch, blocking impersonation. However, by using this ticket to construct the password change request, the password change works."

Step 5 — Authenticate as the victim

A new TGT is requested for the real victim account, using the password the attacker just set and without the NT-ENTERPRISE name type. It comes back with name type NT-PRINCIPAL, which is the proof that the ticket belongs to the real sAMAccountName holder. From here the attacker holds a normal, fully valid identity.

The public proof of concept wraps all of this in a single PowerShell function. It requires the ActiveDirectory module and a copy of Rubeus, and its published usage is a single call:

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

Who Can Actually Run This, and Who Cannot

This is where a lot of secondary coverage overstates the flaw, so it is worth quoting the research directly. Semperis states the vulnerability "allows a complete domain takeover by an attacker that has generic Write permissions over any user or computer object in the domain or who can create user or computer objects in the domain (excluding MachineAccountQuota)".

Two clauses in that sentence deserve emphasis, because together they set the real bar:

• Generic Write over any user or computer object. Not over the victim. The attacker needs write access to an object they can point at the victim, which in most domains is a far more common grant than write access to a Tier 0 account.
• Excluding MachineAccountQuota. This is the limit that separates ResetNightmare from noPac. The default ability of an authenticated user to join ten machines to the domain is not sufficient here, so "any domain user by default" is the wrong summary of this CVE.

Microsoft's own FAQ pins down the other half of the bar, the adjacent attack vector (AV:A): exploitation "requires that an attacker needs to be in the same restricted Active Directory domain as the target system". At publication MSRC also recorded the flaw as not publicly disclosed, not exploited, and "Exploitation Less Likely" — an assessment made in April 2026, before the write-up and the proof of concept existed.

There is one further precondition. Semperis notes that "the only other requirement is that the target user's password must be sufficiently aged", and observes that the default Minimum password age in the Default Domain Policy is 1 day, so a real admin account will almost always satisfy it.

Detection

The primary indicator named by the research is Event ID 5136, "a directory service object was modified", filtered for additions of a userPrincipalName that matches an existing account's sAMAccountName. That is a precise, low-noise signature: in a healthy domain, a UPN prefix should essentially never collide with a different object's logon name.

On the password side, expect 4723 rather than 4724. Semperis separates the two protocol operations directly, noting that Microsoft uses "change password" and "set password" terminology "to differentiate between a user changing their own password and an administrator setting the password for a user". ResetNightmare drives the change operation — which is also why the target's minimum password age is a precondition at all — so the domain controller records 4723, "an attempt was made to change an account's password". Event 4724 covers the reset path an administrator or a delegated helpdesk account takes. It is worth watching for its own sake, but it is not the artefact this CVE leaves.

The same collision can be hunted retrospectively in directory state, which is worth doing once even if your auditing was off:

# Every UPN prefix that collides with a different object's sAMAccountName
$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

Remediation

1. Prove the patch, do not assume it. Semperis is explicit that "the best prevention for these vulnerabilities is patching all DCs". A single unpatched or long-offline DC keeps the domain exploitable, so enumerate build numbers rather than trusting a compliance dashboard.

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

2. Strip password-reset delegation outside Tier 0. The research's second recommendation is that "organizations should stick to the principle of least privilege and monitor for abnormal additions of non-default permissions". The right hand to audit is the User-Force-Change-Password extended right, documented by Microsoft with the display name "Reset Password" and the 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. Constrain who can create accounts. Because the attack works for an attacker who can create user or computer objects outside MachineAccountQuota, review delegated Create Child rights on OUs. Delegation granted years ago for a helpdesk or a deployment tool is the usual finding here, and it is the same class of stale grant covered in the dangerous ACE and orphaned SID audit.

4. Turn on the auditing that makes step 1 of the chain visible. Enable Audit Directory Service Changes and set SACLs so that userPrincipalName writes on user and computer objects generate 5136.

5. Assume nothing about the exposure window. The patch is from April 2026 and the PoC is public now. If a DC lagged, treat privileged password changes in that interval as suspect: review 4723 events against Tier 0 targets, with 4724 alongside them for the delegated-reset path, and confirm each one maps to a real helpdesk ticket. The wider hygiene checklist in auditing Active Directory security and the Tier 0 review in privileged accounts, Protected Users and delegation both apply directly.

Semperis names no mitigation beyond patching and least privilege, and that ceiling is worth stating plainly. Protected Users membership in particular should not be expected to stop this attack: the protections Microsoft documents for the group block NTLM, bar DES and RC4 in Kerberos preauthentication, forbid constrained and unconstrained delegation and cap TGT lifetime, and none of those is what fails here. The flaw is in how the KDC binds an identity during the change password exchange, which is also why hardening measures aimed at ticket theft, such as Kerberos delegation cleanup or rotating krbtgt, are useful for other reasons but irrelevant to CVE-2026-27912.

How EtcSec Detects This

ResetNightmare is a patch-once problem, but its prerequisite is a permissions problem that outlives any single CVE. EtcSec audits exactly that surface.

ACL_USER_FORCE_CHANGE_PASSWORD and ACL_FORCECHANGEPASSWORD enumerate every principal holding the Reset Password extended right, and ACL_GENERICALL surfaces the generic write grants that let an attacker rewrite another object's userPrincipalName in the first place.

For teams working to a compliance baseline, ANSSI_R12_1_FORCE_PWD_RESET_PRIVS flags User-Force-Change-Password granted outside system accounts, and ANSSI_R12_2_USER_RESTRICTIONS_PRIVS does the same for User-Account-Restrictions. Both map to the "who can act on this account" question that CVE-2026-27912 turns into domain compromise. Older domain controllers raise the stakes further, which is why Windows Server 2016 end of support matters here.

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