AD Security News | Radioactive Directory

ResetNightmare: Reset Any Password in the Domain, Including Domain Admins

CVE-2026-27912 is a validation gap in the Kerberos Change Password protocol (kpasswd, port 464). The 2021 noPac fix added PAC_REQUESTOR_SID checking to TGS exchanges but never extended it to password changes — so a ticket obtained by UPN spoofing is still trusted by kpasswd. Any principal that can write a userPrincipalName (including on an account it just created via MachineAccountQuota) can reset the password of any account in the domain without knowing the current one. Microsoft patched it on 14 April 2026; Semperis published a working PowerShell PoC in August 2026. If your DCs are behind on patches, this is a one-command path from any-user to Domain Admin.

Read the research → Jump to full coverage ↓

2026

August 2026 Vulnerability PoC Released Research

CVE-2026-27912 — "ResetNightmare": Reset Any AD Account's Password via the Kerberos Change Password Protocol (CVSS 8.0)

Semperis researcher Shai Laron disclosed a validation flaw in the Kerberos Change Password protocol (RFC 3244, port 464) that lets a low-privileged attacker reset the password of any user or computer account in the domain — Domain Admins included — without knowing the current password. Microsoft patched it on 14 April 2026. Semperis released a PowerShell PoC in August 2026 that automates the entire chain.

Root cause — an incomplete 2021 fix. The patch for CVE-2021-42287 (the KDC half of noPac) added PAC_REQUESTOR_SID validation so the KDC verifies that the SID in a ticket's PAC actually matches the account named in it. That check was applied to TGS exchanges. It was never applied to the Kerberos Change Password protocol. Five years later, the same class of name-confusion bug is exploitable again through a door nobody closed.

The attack chain:
1. Attacker controls an account whose UPN they can write — either a real account with GenericWrite over itself, or one they just created (creating an object grants you rights over it, and MachineAccountQuota defaults to 10).
2. Set that account's userPrincipalName to the target's sAMAccountName (e.g. DemoAdmin1). AD's uniqueness check passes because a bare SAM name doesn't collide with any existing UPN.
3. Request a TGT using the NT-ENTERPRISE name type with the target's name and the attacker's password. The DC returns a ticket carrying the attacker's SID in the PAC but the target's name in the ticket body.
4. Present that ticket to kpasswd. Because kpasswd never cross-checks the PAC SID against the name, the password change is applied to the target account.
5. Clear the spoofed UPN, request a TGT as the target with the new password. Domain takeover.

Prerequisites are low: an unpatched DC, write access to a UPN on any account you control (or the ability to create objects anywhere in the directory), and a target whose password is older than the minimum password age — which defaults to 1 day, so virtually every account qualifies.

For defenders: patch every domain controller with the April 2026 update — that is the fix, and there is no clean workaround. Then enable Audit Directory Service Changes and hunt Event ID 5136 for UPN modifications whose new value matches an existing account's sAMAccountName. That pattern has essentially no legitimate use and is a definitive indicator. Pair it with 4724/4738 password-reset events on privileged accounts that no help desk initiated. Exploitation in the wild has not been confirmed, and it is not currently in the CISA KEV catalog — but the PoC is public, the prerequisites are trivially common, and the payoff is the whole domain.

Semperis Research → PoC Tool (GitHub) → MSRC →

March 2026 Vulnerability Research Patch Tuesday

CVE-2026-25177 — "KerberLoss": Unicode SPN Collisions Enable DoS, SPN-Jacking, and Silent Kerberos→NTLM Downgrade (CVSS 8.8)

Microsoft's March 2026 Patch Tuesday (10 March) fixed a high-severity AD DS vulnerability disclosed by Semperis researcher Shai Laron and named KerberLoss. AD's LDAP server fails to normalise 386 "unfilterable" Unicode characters when enforcing SPN and UPN uniqueness. The characters are ignored on lookup but accepted on write, so an attacker with WriteSPN on any account they control can register an SPN that collides with a legitimate service while passing the duplicate-name check.

Three distinct outcomes fall out of that primitive:
1. Denial of service. Register a colliding SPN for a HOST-mapped service (e.g. cifs/SERVERB with an embedded invisible character) on an account you own. The KDC starts encrypting service tickets with your account's key, and the real server can no longer decrypt them — clients get KRB_AP_ERR_MODIFIED and the service is effectively offline.
2. SPN-jacking. The same collision bypasses SPN alias uniqueness without needing WriteSPN on the intermediate service, opening S4U2Self abuse against constrained-delegation hosts and compromise of delegation-enabled systems.
3. Kerberos→NTLM downgrade. Create an exact duplicate explicit SPN and the DC returns KDC_ERR_S_PRINCIPAL_UNKNOWN, forcing clients forest-wide to fall back to NTLM. Access keeps working, so nobody notices — but the authentication posture has been silently degraded to a relayable protocol.

Network-reachable, low complexity, no user interaction. Microsoft rates exploitation as "less likely" and it is not in the CISA KEV catalog, but the blast radius is wide. Patch DCs, restrict WriteSPN via least privilege, and hunt Event ID 5136 for conflicting SPN additions. Note that KerberLoss and ResetNightmare came out of the same Semperis research and were patched a month apart — one patch does not cover both.

Semperis Research → Microsoft Security Response Center →

February 2026 Hardening Deprecation

Microsoft Announces 3-Phase Plan to Kill NTLM — Kerberos Migration Roadmap is Official

Microsoft has formally laid out a three-phase roadmap to deprecate NTLM across Windows. Phase 1 (available now) introduces enhanced NTLM auditing to identify where NTLM is still in use. Phase 2 (expected H2 2026) tackles common migration blockers with IAKerb and a local Key Distribution Center (KDC). Phase 3 will disable NTLM by default in the next Windows Server and client releases, requiring explicit re-enablement via policy. Worth noting: Windows Server 2025 and Windows 11 24H2 already kill NTLMv1, which is a real win. NTLMv2 is a different story entirely — it's deeply embedded in enterprise environments with far more dependencies, and actually removing it will be significantly harder. Phase 3 hinges on the "next major release," which for most orgs means a 5-10 year adoption horizon at best. The auditing in Phase 1 is genuinely useful, but don't hold your breath on NTLM disappearing anytime soon.

Microsoft Windows IT Pro Blog →

January 2026 Hardening Tool

January Patch Tuesday Breaks Shadow Credentials — Tooling Already Updated

Microsoft's January 2026 cumulative update (KB5073723 for Server 2019, KB5073379 for Server 2025) introduced changes that broke Shadow Credentials attacks. The security community quickly diffed the patch and identified the changes. RedTeamPentesting has already updated their keycred tool (v1.2.1) to work with the new requirements.

@RedTeamPT on X →

January 2026 Vulnerability Research

CVE-2026-20929 — Kerberos Relay via DNS CNAME Abuse: "Relay-Proof" Kerberos Falls (CVSS 7.5)

Cymulate researcher Ben Zamir broke the long-held assumption that Kerberos authentication is inherently immune to cross-service relay attacks. By poisoning DNS with CNAME records, an attacker can cause the Windows Kerberos client to request a TGS ticket for an attacker-chosen SPN instead of the intended service — the client blindly follows the CNAME alias when constructing the service ticket request. Combined with DNS MITM (ARP poisoning, DHCPv6/mitm6, rogue DNS), this enables full cross-service Kerberos relay to SMB, LDAP, and AD CS endpoints. The most devastating path: relay to AD CS web enrollment to obtain a certificate as the victim, granting persistent access that survives password changes.

Microsoft's January 2026 patch added Channel Binding Token (CBT) support to HTTP.sys, but this only mitigates HTTP-based relay. The underlying CNAME coercion primitive is unchanged — the Kerberos client still follows CNAME records and constructs TGS requests using the alias hostname. SMB and LDAP relay vectors remain exploitable without explicit signing and channel binding enforcement. This isn't a fix — it's a band-aid on one protocol while the root cause persists.

For defenders: this is a wake-up call. If your relay protection strategy assumed Kerberos was safe, it isn't. Enforce SMB signing, LDAP signing, and channel binding across your environment — these protections are now critical for both NTLM and Kerberos relay defense. And for the "just disable NTLM and you're safe from relay" crowd: disabling NTLM eliminates NTLM relay, but it does not make you relay-proof — this attack targets Kerberos directly.

Cymulate Research → PoC Tool (GitHub) →