ResetNightmare CVE-2026-27912, Kerberos Passwortaenderung, Active Directory: Ein selbst gesetzter userPrincipalName genügt, um einen Domain Admin zurückzusetzen

Was ist ResetNightmare CVE-2026-27912 Kerberos Passwortaenderung Active Directory

ResetNightmare CVE-2026-27912 Kerberos Passwortaenderung Active Directory: Diese Bezeichnung steht für eine einzelne Schwachstelle, und sie ist der kürzeste Weg in einer Domäne von Schreibzugriff auf ein Wegwerfkonto zu einem zurückgesetzten Domain-Admin-Passwort. Der Angreifer erfährt niemals das alte Passwort des Opfers, leitet niemals einen Credential weiter und knackt keinen Hash. Er setzt einfach ein neues Passwort auf ein Konto, über das ihm nie Rechte delegiert wurden.

Die Schwachstelle wurde vom Semperis-Forscher Shai Laron gefunden und in der Unternehmensforschung Identity Crisis veröffentlicht, zusammen mit einer zweiten, separaten Schwachstelle, die dieselbe Forschung KerberLoss nennt (CVE-2026-25177). Die Beschreibung der National Vulnerability Database ist knapp: „Improper authorization in Windows Kerberos allows an authorized attacker to elevate privileges over an adjacent network.“

Dieser Satz verbirgt den interessanten Teil. Die „unsachgemäße Autorisierung“ ist keine fehlende ACL-Prüfung an einem Objekt. Es ist eine Identitätsprüfung, die existiert, korrekt funktioniert und schlicht nie erreicht wird, weil das missbrauchte Protokoll genau den Schritt umgeht, an dem diese Prüfung sitzt.

Wie es funktioniert, und warum die fehlende TGS-REQ entscheidend ist

Kerberos kennt nicht nur eine Art, ein Principal zu benennen, und Active Directory nutzt routinemäßig zwei. NT-PRINCIPAL benennt ein Konto über seinen sAMAccountName. NT-ENTERPRISE benennt es über seinen userPrincipalName, den UPN. Ein Client kann eine der beiden Formen in eine AS-REQ einsetzen, und der KDC löst sie zu einem Konto auf und stellt ein Ticket aus.

Angriffe, die diese Mehrdeutigkeit ausnutzen, sind nicht neu. Im November 2021 erlaubte die noPac-Kette, CVE-2021-42278 und CVE-2021-42287, einem Angreifer, ein von ihm kontrolliertes Konto umzubenennen, sodass ein für eine Identität ausgestelltes Ticket als eine andere eingelöst werden konnte. Microsofts Fix für CVE-2021-42287, KB5008380, veröffentlicht am 9. November 2021, fügte „neue Informationen über den ursprünglichen Anforderer zu den PACs von Kerberos Ticket-Granting Tickets (TGT)“ hinzu, den PAC-Requestor-Puffer. Der KDC nutzt ihn, in Microsofts eigenen Worten, beim „Erzeugen eines Kerberos-Service-Tickets“, um zu prüfen, „dass das Konto, das das TGT angefordert hat, dasselbe Konto ist, auf das im Service-Ticket verwiesen wird“.

Lesen Sie das genau, denn ResetNightmare lebt in der Lücke, die dieser Fix offenlässt. Die PAC-Requestor-SID wird geprüft, wenn ein Service-Ticket erzeugt wird, während des TGS-REQ-Austauschs.

Das Kerberos-Passwortänderungsprotokoll kennt keine TGS-REQ.

Definiert in RFC 3244 und über Port 464 bereitgestellt, ist der kpasswd-Ablauf, die Passwortänderung, bewusst kurz gehalten. Ein Client erhält ein TGT und geht dann direkt zu einer AP-REQ gegen den Passwortänderungsdienst. Es gibt keinen dazwischenliegenden Ticket-Granting-Austausch, weil der Client nicht im üblichen Sinne Zugriff auf einen Dienst anfordert. Er weist lediglich den Nachweis seiner eigenen Identität vor, um ein Passwort zu ändern. Semperis beschreibt den Ablauf so, dass er direkt von der TGT-Anfrage zu einer AP-REQ übergeht, „ohne eine TGS-REQ dazwischen“.

Überspringt man die TGS-REQ, überspringt man mit ihr die PAC-Requestor-Prüfung. Nichts sonst auf diesem Pfad leitet die SID des Anforderers erneut aus dem Ticket ab. Ein TGT, das ausgestellt wurde, weil ein NT-ENTERPRISE-Name zufällig auf das eigene Objekt des Angreifers aufgelöst wurde, wird von kpasswd also als Berechtigung über das Konto akzeptiert, auf das dieser Name jetzt aufgelöst wird.

Das Ergebnis potenziert sich so, wie es bei gebrochenen Identitätsbindungen immer der Fall ist. Der Angreifer setzt ein ihm bekanntes Passwort auf ein Konto, das ihm nicht gehört, und jede nachfolgende Anmeldung als dieses Konto ist vollkommen legitim. Vergleichbar mit Shadow Credentials, bei denen der Angreifer einen Schlüssel statt eines Passworts hinzufügt: gleiches Ergebnis, anderes Attribut, und beide widerlegen die Annahme „der Angreifer muss trotzdem etwas knacken“, auf der ein Großteil der Modellierung von Active-Directory-Angriffspfaden noch beruht. Beide lassen sich zudem kombinieren: Semperis schreibt Andrea Pierini die Beobachtung zu, dass ResetNightmare „auch mit der Shadow-Credentials-Technik kombiniert werden kann, was einen unauffälligeren Angriffspfad durch den Missbrauch beschreibbarer Computerkonten ermöglicht“.

Die Angriffskette

Semperis veröffentlicht die Kette Schritt für Schritt. Der Dreh- und Angelpunkt ist derselbe, der noPac funktionieren ließ: Der im Ticket geführte Name wird zweimal aufgelöst, und der Angreifer ändert dazwischen, worauf er verweist. Die folgende Reihenfolge ist nicht kosmetisch: Der UPN muss vor der Passwortänderung entfernt werden, nicht danach — sonst setzt der Angreifer nur sein eigenes Passwort zurück.

Schritt 1 — Den UPN eines kontrollierten Kontos auf das Opfer richten

Der Angreifer schreibt den sAMAccountName des Opfers in den userPrincipalName eines Kontos, das er bereits kontrolliert oder das er gerade erstellt hat.

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

Schritt 2 — Ein TGT für kadmin/changepw per Enterprise-Name anfordern

Der Angreifer fordert ein TGT an, das auf das SPN kadmin/changepw beschränkt ist, unter Verwendung des Namenstyps NT-ENTERPRISE, mit dem Benutzernamen des Opfers und dem Passwort des kontrollierten Kontos. Dieses SPN gehört zu krbtgt, weshalb Semperis es so formuliert: „Ein Ticket für kadmin/changepw ist einfach ein TGT mit geändertem SPN (sname)“. Der KDC löst den Enterprise-Namen über den soeben gesetzten UPN auf, findet das Objekt des Angreifers und liefert ein Ticket zurück, das den Namen des Opfers, aber die SID des Angreifers in PAC_REQUESTOR_SID trägt.

Schritt 3 — Den UPN entfernen, bevor das Passwort angefasst wird

Dies ist der Schritt, dessen Position darüber entscheidet, ob die Kette überhaupt eskaliert. Der Angreifer ändert oder löscht jetzt den UPN des kontrollierten Kontos, „sodass kein Benutzer mehr den auf dem Ticket erscheinenden UPN trägt“. Führt man die Passwortänderung durch, während der UPN noch gesetzt ist, löst der Enterprise-Name weiterhin auf das eigene Objekt des Angreifers auf: Semperis stellt ausdrücklich klar, dass dies „das Passwort von UPNUser zurücksetzen wird“ und nichts weiter.

Schritt 4 — Das Passwortänderungsprotokoll ausführen

Das bereits ausgestellte TGT wird verwendet, um eine Passwortänderungsanfrage über Kerberos zu erstellen, direkt zu einer AP-REQ auf Port 464. Es wird keine TGS-REQ ausgestellt, sodass die PAC-Requestor-SID nie geprüft wird, und das neue Passwort landet beim echten Opfer. Semperis hält den Kontrast präzise fest: Die Wiederverwendung desselben Tickets in einer TGS-REQ nach der UPN-Änderung „führt zu einem KDC_ERR_TGT_REVOKED-Fehler, aufgrund des PAC_REQUESTOR_SID-Patches, der die Impersonation blockiert. Wird dieses Ticket jedoch zur Konstruktion der Passwortänderungsanfrage verwendet, funktioniert die Passwortänderung.“

Schritt 5 — Sich als das Opfer authentifizieren

Ein neues TGT wird für das echte Opferkonto angefordert, mit dem Passwort, das der Angreifer soeben gesetzt hat, und ohne den Namenstyp NT-ENTERPRISE. Es kommt mit dem Namenstyp NT-PRINCIPAL zurück, was der Beweis dafür ist, dass das Ticket dem tatsächlichen Inhaber des sAMAccountName gehört. Von hier aus verfügt der Angreifer über eine normale, vollständig gültige Identität.

Der öffentliche Proof of Concept fasst all dies in einer einzigen PowerShell-Funktion zusammen. Er benötigt das ActiveDirectory-Modul und eine Kopie von Rubeus, und die veröffentlichte Nutzung ist ein einziger Aufruf:

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

Wer das tatsächlich ausführen kann — und wer nicht

Hier übertreibt ein Großteil der Sekundärberichterstattung die Schwachstelle, weshalb es sich lohnt, die Forschung direkt zu zitieren. Semperis stellt fest, dass die Schwachstelle „eine vollständige Domänenübernahme durch einen Angreifer ermöglicht, der über generische Schreibrechte auf ein beliebiges Benutzer- oder Computerobjekt in der Domäne verfügt oder der Benutzer- oder Computerobjekte in der Domäne erstellen kann (ausgenommen MachineAccountQuota)“.

Zwei Teile dieses Satzes verdienen besondere Betonung, denn zusammen setzen sie die eigentliche Hürde:

• Generische Schreibrechte auf ein beliebiges Benutzer- oder Computerobjekt. Nicht auf das Opfer. Der Angreifer benötigt Schreibzugriff auf ein Objekt, das er auf das Opfer richten kann — in den meisten Domänen eine weitaus häufigere Berechtigung als Schreibzugriff auf ein Tier-0-Konto.
• Ausgenommen MachineAccountQuota. Dies ist die Grenze, die ResetNightmare von noPac unterscheidet. Die Standardfähigkeit eines authentifizierten Benutzers, zehn Rechner in die Domäne aufzunehmen, reicht hier nicht aus, weshalb „jeder Domänenbenutzer standardmäßig“ die falsche Zusammenfassung dieser CVE wäre.

Microsofts eigenes FAQ legt die andere Hälfte der Hürde fest, den benachbarten Angriffsvektor (AV:A): Die Ausnutzung „erfordert, dass sich ein Angreifer in derselben eingeschränkten Active-Directory-Domäne wie das Zielsystem befindet“. Zum Zeitpunkt der Veröffentlichung führte MSRC die Schwachstelle zudem als nicht öffentlich bekannt, nicht ausgenutzt und mit der Einschätzung „Exploitation Less Likely“ — eine im April 2026 getroffene Bewertung, vor dem Write-up und dem Proof of Concept.

Es gibt eine weitere Voraussetzung. Semperis merkt an, dass „die einzige weitere Voraussetzung ist, dass das Passwort des Zielbenutzers ausreichend alt sein muss“, und weist darauf hin, dass das Standard-Minimum password age in der Default Domain Policy 1 Tag beträgt, sodass ein echtes Admin-Konto dies fast immer erfüllt.

Erkennung

Der von der Forschung genannte primäre Indikator ist Event ID 5136, „ein Verzeichnisdienstobjekt wurde geändert“, gefiltert auf das Hinzufügen eines userPrincipalName, der mit dem sAMAccountName eines bestehenden Kontos übereinstimmt. Das ist eine präzise, wenig verrauschte Signatur: In einer gesunden Domäne sollte ein UPN-Präfix im Grunde nie mit dem Anmeldenamen eines anderen Objekts kollidieren.

Auf der Passwortseite ist mit 4723 statt 4724 zu rechnen. Semperis trennt die beiden Protokolloperationen klar und weist darauf hin, dass Microsoft die Begriffe „change password“ und „set password“ verwendet, „um zu unterscheiden, ob ein Benutzer sein eigenes Passwort ändert oder ein Administrator das Passwort für einen Benutzer festlegt“. ResetNightmare löst die change-Operation aus — was auch erklärt, warum das Mindestalter des Zielpassworts überhaupt eine Voraussetzung ist —, sodass der Domain Controller 4723 protokolliert, „es wurde versucht, das Passwort eines Kontos zu ändern“. Event 4724 deckt den Reset-Pfad ab, den ein Administrator oder ein delegiertes Helpdesk-Konto nutzt. Es lohnt sich, dieses Event ebenfalls im Auge zu behalten, aber es ist nicht das Artefakt, das diese CVE hinterlässt.

Dieselbe Kollision lässt sich auch rückwirkend im Verzeichniszustand aufspüren — lohnenswert, selbst wenn das Auditing bislang deaktiviert war:

# Jedes UPN-Präfix, das mit dem sAMAccountName eines anderen Objekts kollidiert
$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. Den Patch nachweisen, nicht annehmen. Semperis stellt ausdrücklich klar, dass „die beste Prävention für diese Schwachstellen das Patchen aller DCs ist“. Ein einzelner ungepatchter oder lange offline befindlicher DC hält die Domäne angreifbar, daher sollten Build-Nummern erfasst werden, statt einem Compliance-Dashboard zu vertrauen.

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

2. Passwort-Reset-Delegation außerhalb von Tier 0 entfernen. Die zweite Empfehlung der Forschung lautet, dass „Organisationen sich an das Prinzip der geringsten Rechte halten und auf ungewöhnliche Hinzufügungen nicht standardmäßiger Berechtigungen achten sollten“. Zu prüfen ist das erweiterte Recht User-Force-Change-Password, von Microsoft dokumentiert mit dem Anzeigenamen „Reset Password“ und der 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. Einschränken, wer Konten erstellen kann. Da der Angriff für einen Angreifer funktioniert, der Benutzer- oder Computerobjekte außerhalb der MachineAccountQuota erstellen kann, sollten delegierte Create-Child-Rechte auf OUs überprüft werden. Vor Jahren für einen Helpdesk oder ein Deployment-Tool vergebene Delegationen sind hier der übliche Befund, und sie fallen in dieselbe Kategorie veralteter Berechtigungen wie im Audit gefährlicher ACEs und verwaister SIDs beschrieben.

4. Das Auditing aktivieren, das Schritt 1 der Kette sichtbar macht. Audit Directory Service Changes aktivieren und SACLs setzen, sodass userPrincipalName-Schreibvorgänge an Benutzer- und Computerobjekten Event 5136 erzeugen.

5. Nichts über das Expositionsfenster annehmen. Der Patch stammt vom April 2026, und der PoC ist jetzt öffentlich. War ein DC im Rückstand, sollten privilegierte Passwortänderungen in diesem Zeitraum als verdächtig behandelt werden: 4723-Events gegen Tier-0-Ziele prüfen, 4724 für den delegierten Reset-Pfad daneben legen, und jedes davon einem echten Helpdesk-Ticket zuordnen. Die umfassendere Checkliste in Active Directory-Sicherheit auditieren und die Tier-0-Überprüfung in privilegierte Konten, Protected Users und Delegation gelten hier direkt.

Semperis nennt keine Abhilfe über Patchen und geringste Rechte hinaus, und diese Grenze sollte klar ausgesprochen werden. Insbesondere die Mitgliedschaft in Protected Users sollte nicht als Schutz vor diesem Angriff erwartet werden: Die von Microsoft für die Gruppe dokumentierten Schutzmechanismen blockieren NTLM, verbieten DES und RC4 in der Kerberos-Vorauthentifizierung, untersagen constrained und unconstrained Delegation und begrenzen die TGT-Lebensdauer — und keiner davon greift hier. Der Fehler liegt darin, wie der KDC eine Identität während des Passwortänderungsaustauschs bindet, weshalb auch Härtungsmaßnahmen gegen Ticket-Diebstahl, wie die Bereinigung von Kerberos-Delegation oder die Rotation von krbtgt, aus anderen Gründen nützlich, für CVE-2026-27912 jedoch irrelevant sind.

Wie EtcSec das erkennt

ResetNightmare ist ein Problem, das man einmalig patcht, aber seine Voraussetzung ist ein Berechtigungsproblem, das jede einzelne CVE überdauert. EtcSec auditiert genau diese Angriffsfläche.

ACL_USER_FORCE_CHANGE_PASSWORD und ACL_FORCECHANGEPASSWORD listen jeden Principal auf, der über das erweiterte Recht Reset Password verfügt, und ACL_GENERICALL deckt die generischen Schreibrechte auf, mit denen ein Angreifer überhaupt erst den userPrincipalName eines anderen Objekts umschreiben kann.

Für Teams, die sich an einer Compliance-Baseline orientieren, markiert ANSSI_R12_1_FORCE_PWD_RESET_PRIVS User-Force-Change-Password-Rechte außerhalb von Systemkonten, und ANSSI_R12_2_USER_RESTRICTIONS_PRIVS tut dasselbe für User-Account-Restrictions. Beide beziehen sich auf die Frage „Wer kann auf dieses Konto einwirken“, die CVE-2026-27912 in eine Domänenübernahme verwandelt. Ältere Domain Controller erhöhen die Risiken zusätzlich, weshalb auch das Support-Ende von Windows Server 2016 hier relevant ist.

Quellen

• 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