Two Active Directory Bugs Turn Write Access on One Account into Domain Admin

Most privilege escalation research assumes you already have a foothold worth something. These two do not. The entry requirement for both is a permission that gets handed out casually and audited almost never: write access over a single user or computer object. A helpdesk delegation, a stale service account with rights it kept after a project ended, a group that once needed to rename machines. That is the whole starting position.

KerberLoss: the uniqueness check that could not see

Active Directory has enforced service principal name uniqueness since the fix for CVE-2021-42282. Register an SPN that already exists elsewhere and the write is refused, because a duplicate lets you intercept tickets meant for someone else.

Laron found that the check and the lookup disagree about what a string is. Insert a zero-width character, U+200C ZERO WIDTH NON-JOINER for instance, into the SPN you are registering. The uniqueness check treats your value as different from the existing one, so the write succeeds. The LDAP server, resolving the name later, ignores that class of character entirely and hands back your object instead.

From there the KDC does exactly what it is supposed to do with a matching SPN: it issues service tickets encrypted with the key of the account that owns it, which is now the attacker's. The real service receives tickets it cannot decrypt. Authentication to it fails, for everyone, until someone works out why.

The character does not render. Not in Active Directory Users and Computers, not in the attribute editor, not in a PowerShell console. An administrator comparing the malicious SPN against the legitimate one sees two identical strings and a service that will not authenticate.

ResetNightmare: the 2021 fix only covered one door

The 2021 patch for CVE-2021-42282 added a field called PAC_REQUESTOR_SID to Kerberos tickets. Its job is to record who actually asked for the ticket, so that a ticket bearing an administrator's name but issued to somebody else can be caught and rejected during a service ticket request.

ResetNightmare is four steps:

1. With write access over any user object, set that object's userPrincipalName to match a Domain Admin's sAMAccountName.
2. Request a ticket-granting ticket using the NT-ENTERPRISE name type, presenting the admin's name and your own credentials. The domain controller issues a TGT carrying the admin's name, with your SID recorded in PAC_REQUESTOR_SID, exactly as the 2021 fix intended.
3. Use that ticket against the Kerberos Change Password protocol on port 464 to reset the real Domain Admin's password. This is the flaw: the change-password path processes the request without performing the PAC_REQUESTOR_SID validation that a service ticket request would have performed. The name on the ticket is enough.
4. Request a fresh TGT as the genuine Domain Admin, using the password you just set.

The 2021 fix was real. It was applied to the door everyone was watching. RFC 3244 password changes went through a different door, and that one was never checked.

One precondition worth knowing, because it is the only thing standing between an attacker and a five-minute domain takeover: the target account's password must be older than the domain's minimum password age, which defaults to one day.

Both are rated Important. Read that carefully.

Microsoft classified both as Important rather than Critical, and both are elevation of privilege rather than remote code execution. That rating describes the mechanism, not the outcome. The outcome of ResetNightmare is Domain Admin, from a starting position that thousands of organisations have handed out to a helpdesk group and forgotten about. If your patch prioritisation is driven by severity labels alone, these two are the argument against that policy.

Do this week

• Apply the March 10 and April 14 2026 Windows updates to every domain controller. One patch does not cover both.
• Audit who holds write access over user and computer objects, and specifically who holds WriteSPN. This is the entry requirement for both attacks and it is usually broader than anyone expects. Delegations outlive the projects that justified them.
• Enable SACLs on Active Directory objects if you have not. Without them the events below do not exist.
• Hunt for zero-width characters already present in servicePrincipalName and userPrincipalName values across the directory. The patch stops new ones; it does not clean up what a prior intrusion may have left.
• Check your domain's minimum password age. A setting of zero removes the only precondition ResetNightmare has.

How to hunt it

Both attacks are visible in directory-object modification auditing, if it is turned on. The events that matter:

• Event ID 5136, directory service object modified, where the attribute written is servicePrincipalName or userPrincipalName. For KerberLoss, alert when the written value contains a Unicode Default_Ignorable code point: U+200B, U+200C, U+200D, U+2060, U+FEFF, U+00AD. No legitimate SPN contains one. This is a high-fidelity signal, close to zero false positives outside directory migration tooling.
• Event ID 5136 again for ResetNightmare, where a written userPrincipalName collides with an existing sAMAccountName. That comparison needs a lookup, which is why it belongs in a correlation rule rather than a single-event filter.
• Event ID 4724, password reset attempt, where the subject and the target differ and the target is privileged. Helpdesk resets look the same, so tune by target group and by whether the reset came from a known helpdesk workstation.
• Event ID 4768, TGT requested, for the reset principal immediately after a 4724 for the same account. That sequence is the tail of the chain.

The zero-width check is the one to build first. It is cheap, it is specific, and it catches the primitive rather than the exploit, which means it still works when someone finds the next way to use the same trick.

Detection content

We publish Sigma rules for both, free, in the RedEye Intel Feed: STIX 2.1 over TAXII 2.1, subscribable from any TIP. CVE-2026-25177 covers the zero-width SPN write. CVE-2026-27912 covers the UPN write and the privileged-reset tail. Both carry the field lists and the false-positive notes, because a rule without its tuning notes is someone else's alert fatigue.

Both rules are complete and deployable: selectors, field lists, and the tuning notes, because a rule without its false-positive guidance is somebody else's alert fatigue. They target the domain controller Security channel, so point them at a lake that carries 5136, 4724 and 4768 and they run as written. Our own demo lake holds network and host telemetry rather than directory events, which changes nothing about the rules and everything about what we can demo on our own data.

The platform side of this is Caver, and the honest version of the pitch is unglamorous: this hunt needs directory-object auditing retained long enough to look backwards through, because the SPN write that starts KerberLoss may predate the outage it causes by weeks. Retention is the whole game, and retention is a cost problem before it is a detection problem.

Credit

Both vulnerabilities were found and disclosed by Shai Laron at Semperis, reported to MSRC in November and December 2025 and patched in March and April 2026. Their full write-up carries the protocol detail this summary compresses, including the SPN lookup ordering and the exact LDAP filter behaviour, and is worth reading in the original.