Identitätskrise: Neue Sicherheitslücken führen zu Kerberos-Downgrade, DoS und vollständiger Übernahme der Domäne

Active Directory (AD) ist nach wie vor das Kronjuwel der Unternehmensinfrastruktur, und für Angreifer ist das oberste Ziel klar: sich Domänenadministratorrechte zu verschaffen. Diese Berechtigungsstufe gewährt praktisch die vollständige Kontrolle über Ihre Umgebung. Der Schutz von Identitäten spielt daher eine wesentliche Rolle für die Unternehmenssicherheit, und Unternehmen unternehmen große Anstrengungen, um zu verhindern, dass Angreifer Zugriff auf die Anmeldedaten von Administratoren erlangen.

Was wäre jedoch, wenn Angreifer Domänencontroller (DCs) einfach verwirren könnten, sodass diese sie fälschlicherweise als jemand anderen identifizieren?

Vor einiger Zeit nahm ich an einem Vortrag von Yossi Sassi über Persistenztechniken in Active Directory teil. Sassi stellte ein Konzept vor, das mir bisher noch nicht bekannt war: die Möglichkeit, „unsichtbare“ Unicode-Zeichen zu Objektattributen hinzuzufügen. Er stellte diese Möglichkeit als Persistenztechnik vor, die die Erstellung von Benutzern ermöglicht, deren Namen scheinbar mit denen anderer bereits vorhandener, legitimer Benutzer übereinstimmen. Diese Technik kann Sicherheits- und IT-Teams verwirren und Untersuchungen erheblich verzögern.

Das Thema weckte meine Neugier. Ich fragte mich:

• Akzeptiert Active Directory noch weitere „unsichtbare“ Zeichen?
• Wie könnte der Missbrauch dieser Zeichen wirksam aufgedeckt werden?
• Gibt es für versteckte Zeichen noch andere Verwendungszwecke als die dauerhafte Speicherung?

Dieser Artikel beschreibt meine Untersuchungen zu diesen Fragen, die zur Entdeckung von zwei neuen Sicherheitslücken in Active Directory im Zusammenhang mit der Ausweitung von Berechtigungen führten: KerberLoss (CVE-2026-25177) und ResetNightmare (CVE-2026-27912). Jede dieser Schwachstellen nutzt einen einzigartigen Ansatz, um auf Domänencontrollern eine Identitätsverwirrung herbeizuführen, was zu unterschiedlichen Auswirkungen führt. Die zweite (und schwerwiegendere) Schwachstelle ermöglicht es einem Benutzer mit geringen Berechtigungen, sofort die Berechtigungen eines Domänenadministrators zu erlangen.

Erste Untersuchungen: Unicode und Active Directory

Meine Fragen führten mich auf eine interessante Entdeckungsreise zum Thema Unicode und serverseitige LDAP-Verarbeitung. Zunächst suchte ich im Internet nach Unicode-Zeichen, die unsichtbar erscheinen können, und stellte eine Liste davon zusammen. Mein besonderes Interesse galt dabei Zeichen, die innerhalb von Objektnamen unsichtbar erscheinen, da mir dies als die interessanteste Möglichkeit erschien, diese Technik zu missbrauchen.

Zu Beginn meiner Tests habe ich ein Beispielbenutzerkonto mit dem Namen UniqueUser. Wie zu erwarten war, war es nicht möglich, ein weiteres Benutzerkonto mit demselben Namen anzulegen (Abbildung 1).

Durch die Verwendung eines „unsichtbaren“ Zeichens gelang es mir jedoch, ein scheinbar identisches Benutzerkonto anzulegen (Abbildung 2).

Abbildung 2 zeigt, dass die PowerShell-Konsole das resultierende Konto so interpretiert, als enthalte es ein ungewöhnliches Leerzeichen (vor „ser“). Betrachtet man die beiden Konten jedoch in den grafischen AD-Verwaltungstools, so sehen sie identisch aus (Abbildung 3).

Mithilfe dieser grundlegenden Methode durchlief ich meine Liste von Unicode-Zeichen und legte mit jedem einzelnen davon Benutzerkonten an. Wie Abbildung 4 zeigt, wurden einige der Zeichen in AD auf seltsame Weise interpretiert – die definitiv nicht unsichtbar war.

Nachdem ich diese gelöscht hatte, blieb mir ein Verzeichnis übrig, das so aussieht wie das in Abbildung 5.

Zudem hat mein Skript zwar einige Zeichen übersprungen, weil der DC diese nicht akzeptierte, aber es hat auch einige übersprungen, weil der DC den Benutzernamen als bereits vorhanden interpretierte. (Im Nachhinein betrachtet war dies ein Vorzeichen.) Um so viele dieser Zeichen wie möglich zu testen, ohne durch Eindeutigkeitsbeschränkungen eingeschränkt zu sein, habe ich außerdem weitere Benutzernamen erstellt (Abbildung 6), von denen jeder ein einzigartiges unsichtbares Zeichen enthält, das zwischen zwei Bindestrichen („–“) versteckt ist.

Zu diesem Zeitpunkt war ich überzeugt, dass meine Liste mit 385 unsichtbaren Zeichen meine erste Forschungsfrage beantwortete. Nun war es an der Zeit, mich der Herausforderung der Erkennung zu stellen.

Ein anderer Ansatz zur Erkennung

In seinem ursprünglichen Vortrag stellte Herr Sassi ein Tool vor, mit dem sich versteckte Unicode-Zeichen in AD-Objekten aufspüren lassen. Ich wollte gerne verstehen, wie dieses Tool funktioniert. Das Skript verfolgt einen einfachen Ansatz:

• Erstellen Sie ein Wörterbuch mit 29 „unsichtbaren“ Zeichen.
• Rufen Sie alle Eigenschaften aller Objekte in der Domäne ab.
• Durchlaufen Sie jedes Attribut.
  • Wandeln Sie das Attribut in ein Zeichenarray um.
  • Ermitteln Sie den Hex-Wert jedes Zeichens und vergleichen Sie diesen Wert mit dem im Wörterbuch.

Dieser Ansatz ist umfassend. Da ich jedoch vor allem an Erkennungsmethoden interessiert bin, die routinemäßig und effizient in Produktionsumgebungen eingesetzt werden können, habe ich mich gefragt, ob die Filterung nicht innerhalb der LDAP-Anfragen selbst (d. h. auf der Serverseite) erfolgen könnte, anstatt jedes einzelne Zeichen auf der Clientseite zu verarbeiten.

Um dies herauszufinden, führte ich zunächst einen einfachen Test durch, um festzustellen, ob der DC diese Zeichen „unverändert“ verarbeiten konnte. Ich konvertierte ein Zeichen (0x200B) in seine „unsichtbare“ Zeichenfolgenform umgewandelt und anschließend kopiert und in PowerShell eingefügt (Abbildung 7).

So weit, so gut! Das direkte Einfügen des Zeichens in einen LDAP-Filter lieferte ausschließlich das erwartete Objekt. Als ich jedoch begann, mit verschiedenen Zeichen zu experimentieren, stieß ich auf einige seltsamere Szenarien.

Ich habe denselben Test gemacht, aber dieses Mal habe ich das Zeichen 0x200C, was ein weiteres unsichtbares Zeichen ist. Da dieses Zeichen die Prüfungen auf die Eindeutigkeit von Benutzernamen nicht bestanden hat, gab es bei mir keinen Benutzer mit dem Namen Unique{0x200C}User die sich zu diesem Zeitpunkt in meinem Verzeichnis befanden. Meine Abfrage lieferte jedoch weiterhin ein Ergebnis (Abbildung 8).

Aufmerksamen Lesern fällt vielleicht auf, dass das Ergebnis diesmal nicht mehr jene seltsamen Abstände aufweist, die ich beim Ausgeben dieser Zeichen auf der Konsole festgestellt hatte. Nach Überprüfung der zurückgegebenen Benutzer-SID (Security Identifier) konnte ich bestätigen, dass es sich um den Benutzernamen ohne zusätzliche Zeichen handelte. Das Unicode-Zeichen im Filter wurde entweder von PowerShell oder vom Domänencontroller ignoriert .

Sollte meine Theorie zutreffen, würde eine Anpassung der Abfrage, bei der nach einem beliebigen Objekt mit dem 0x200C Das Zeichen sollte alle Objekte im Verzeichnis zurückgeben. Dieses Mal habe ich den Unicode-Wert in der Konsole umgewandelt, um die Lesbarkeit zu verbessern (Abbildung 9).

Zu diesem Zeitpunkt verhielt sich der LDAP-Server nicht einheitlich; einige Zeichen wurden ausgewertet, andere hingegen ignoriert. Um die Möglichkeit auszuschließen, dass die Filterzeichenfolge die Ursache des Problems sein könnte, stieß ich auf RFC 4515, in dem es heißt:

Die Zeichenfolgendarstellung eines LDAP-Suchfilters ist eine Zeichenfolge aus UTF-8-kodierten Unicode-Zeichen

Der RFC enthält zudem einige Beispiele. Dies gab mir Anlass zur Hoffnung, dass es möglich ist, jedes beliebige Unicode-Zeichen zu konvertieren und abzufragen, unabhängig von seiner Druckbarkeit. Auf der Grundlage des RFC habe ich die folgende Funktion erstellt, die einen Unicode-Hexadezimalwert entgegennimmt (z. B. 0x200B) und geben Sie die LDAP-Filter-kompatible Zeichenfolge zurück (Abbildung 10).

Ich habe überprüft, ob meine Funktion die Konvertierung korrekt durchgeführt hat, indem ich den Wert 0x200B verwendet habe, den ich in meinen vorherigen Tests erfolgreich herausgefiltert hatte (Abbildung 11).

Nachdem ich dies überprüft hatte, fuhr ich fort, meine problematischen Zeichen zu testen (Abbildung 12).

Leider hat es selbst bei Befolgung des RFC nicht funktioniert. Bei der Suche nach meinen 385 unsichtbaren Zeichen mit LDAP unter Verwendung dieser Methode habe ich drei unterschiedliche Zeichenkategorien festgestellt:

• Filterbare Zeichen: nur 106 von 385
• Als Leerzeichen behandelte Zeichen: Auch wenn sie in der Benutzeroberfläche nicht sichtbar sind, gibt die Funktion „char“ alle Objektnamen mit Leerzeichen zurück (z. B. „Domain Admins“, „Print Operators“)
• Zeichen, die vom DC vollständig ignoriert werden: Die Funktion „char“ gibt alle Objekte zurück

Nun war ich zu sehr in die Sache vertieft. Ich musste einfach wissen, ob es eine Möglichkeit gab, nach diesen Zeichen zu filtern. Als ich mir überlegte, was man (abgesehen von der Filterzeichenfolge selbst) ändern könnte, fragte ich mich, ob eine der Erweiterte LDAP-Steuerelemente könnte hilfreich sein. Als ich mir die verschiedenen Optionen ansah, ist mir nur eine einzige ins Auge gefallen, nämlich LDAP_SERVER_SORT_OID. Auch wenn in der Beschreibung des Steuerelements lediglich die Sortierreihenfolge erwähnt wird, In den AD-Unterlagen wird mehrfach darauf hingewiesen dass das Vorhandensein der Kontrolloption auch das Verhalten beim Vergleich von Unicode-Zeichenfolgen beeinflusst.

Um dies zu testen, habe ich eine Funktion erstellt, mit der ich auf bequeme Weise das LDAP_SERVER_SORT_OID Steuerung und zur Abfrage von LDAP mit einer beliebigen von mir gewählten „Ordering Rule OID“. Anschließend habe ich ein Szenario nachgestellt, auf das ich bei einem Microsoft-Forum. Ich habe zwei Benutzer angelegt:

• Shai
• Shäi der Zweite

Beachten Sie den Unterschied zwischen „a“ (Unicode 0x0061) und „ä“ (Unicode 0x00E4).

Ich habe den Unterschied zwischen einer LDAP-Abfrage ohne das erweiterte Steuerelement (das standardmäßig auf US-Englisch eingestellt ist) und einer Abfrage mit diesem Steuerelement sowie einer „schwedischen“ Sortierregel überprüft. Der zweite Ansatz führte tatsächlich zu einer Änderung des zurückgegebenen Ergebnisses und nicht nur der Sortierreihenfolge (Abbildung 13).

Dieses Verhalten trat auch bei der Verwendung meines Convert-UnicodeToLdapUtf8 Funktion zur Umwandlung von „ä“ in seinen UTF-8-Escape-Wert (Abbildung 14).

Ich hatte gehofft, dass vielleicht eine dieser OIDs für Sortierregeln das „Unfilterbare“ aus meiner Liste unsichtbarer Zeichen herausfiltern könnte.

Ich habe ein Skript geschrieben, das jede Sortierregel durchläuft und jedes nicht filterbare Zeichen damit abfragt. Ich bin zu dem Schluss gekommen, dass keine der Sortierregeln dazu führt, dass der DC eines der problematischen Zeichen „erkennt“.

Damit endete meine Untersuchung unsichtbarer LDAP-Zeichen aus Sicht der Erkennung, wobei mir ein ungelöstes Problem blieb: Es gibt Unicode-Zeichen, die der LDAP-Server von Active Directory vollständig ignoriert.

Dieses Erkennungsproblem bot jedoch eine interessante Möglichkeit für Angriffe.

Verschiedene Rollen

Zur kurzen Zusammenfassung:

• Einige Unicode-Zeichen werden von Active Directory nicht korrekt verarbeitet und erscheinen daher unsichtbar.
• Einige dieser Zeichen können von LDAP nicht gefiltert werden, was bedeutet, dass bei der Filterung nach einem „normalen“ Wert möglicherweise auch Werte mit diesen Zeichen zurückgegeben werden.

Im Wesentlichen gibt es einen Potenzial um Eindeutigkeitsbeschränkungen für jedes Unicode-basierte Attribut. Bei meinen ersten Tests mit SamAccountNames und cnIch habe festgestellt, dass Active Directory die Erstellung doppelter Objekte mit nicht filterbaren Zeichen (zu Recht) verhindert. Dies galt jedoch nicht für alle Attribute.

Im Jahr 2021 veröffentlichte Microsoft einen Patch für eine Sicherheitslücke mit der Kennung CVE-2021-42282. Mit diesem Patch wurden drei neue Prüfungen zur Überprüfung der Eindeutigkeit eingeführt:

• Eindeutigkeit des Benutzer-Prinzipalnamens (UPN)
• Eindeutigkeit des Service Principal Name (SPN)
• Eindeutigkeit von SPN-Aliasen

Jeder dieser Werte muss einzigartig im gesamten Wald, und alle drei Prüfungen werden standardmäßig durch die forstweite dSHeuristics Attribut. Jeder Benutzer, dessen Berechtigungen unter denen eines Domänenadministrators liegen, erhält eine „Eindeutigkeitsfehlermeldung“, wenn er versucht, einen Wert festzulegen, der gegen diese Eindeutigkeitsprüfungen verstößt.

Wie Sie jedoch in den folgenden Abschnitten sehen werden, können nicht filterbare Zeichen es Benutzern mit geringen Berechtigungen ermöglichen, diese Überprüfungen zu umgehen. Dies ist die erste Sicherheitslücke, die ich entdeckt habe. Aufgrund ihrer vielfältigen Auswirkungen habe ich sie „KerberLoss“ genannt; Microsoft hat ihr die Kennung CVE-2026-25177 zugewiesen.

KerberLoss: Einleitung zu SPNs

Um die Auswirkungen dieser Sicherheitslücke zu verstehen, müssen Sie zunächst die Service Principal Names (SPNs) genau kennen.

Was sind Service Principal Names?

SPNs sind ein häufig missverstandenes Konzept von Active Directory. Ein SPN ist die Methode, mit der Kerberos Dienstinstanzen identifiziert. Im Zusammenhang mit Active Directory ist ein Dienst jede Ressource, auf die zugegriffen wird und die in der Regel eine Authentifizierung erfordert. Beispiele hierfür sind SMB-Dateifreigaben (cifs), Remotedesktopverbindungen (TERMSRV), LDAP und HTTP … allesamt Beispiele für sogenannte Dienstklassen .

Dienste derselben Klasse können auf verschiedenen Hosts ausgeführt werden, und ein Host kann Dienste mehrerer Klassen bereitstellen. Daher muss ein SPN diese beiden Komponenten enthalten und folgende Grundstruktur aufweisen:

<service class>/<host>

Hinweis: SPNs können zudem zwei weitere, optionale Komponenten enthalten, die jedoch den Rahmen dieses Artikels sprengen.

Die oben aufgeführten Grundlagen sind recht allgemein bekannt. Ich möchte jedoch einige wichtige Punkte hervorheben:

• In der Welt von Active Directory und Kerberos wird ein Dienst von einer Identität bereitgestellt. Dabei kann es sich um ein Computerkonto, ein Benutzerkonto oder ein verwaltetes Dienstkonto handeln, doch hinter dem Dienst muss eine Identität stehen. Dies ist auf die kryptografischen Prinzipien zurückzuführen, auf denen Kerberos basiert. Diensttickets werden mit dem geheimen Schlüssel verschlüsselt, der zu „dem Zieldienst“ (d. h. dessen Identität) gehört.
• Das Objekt, das jede Identität in Active Directory repräsentiert, verfügt über ein Attribut mit dem Namen servicePrincipalName, das zur Verwaltung einer Liste der SPNs der Identität dient.
• Bei der Anforderung eines Kerberos-Diensttickets verwendet das Key Distribution Center (KDC) den SPN aus der Anfrage, um den Zieldienst zu identifizieren. In diesem Zusammenhang ist der Zieldienst die Identität, die den entsprechenden SPN besitzt.
• Schließlich enthalten Kerberos-Tickets einen Klartextteil und einen verschlüsselten Teil. Der SPN befindet sich im Klartextteil des Tickets. Da der SPN unverschlüsselt ist, können wir den SPN in Tickets bearbeiten und diese zwischen verschiedenen Diensten derselben Identität übertragen. Entscheidend ist, welcher Schlüssel zur Verschlüsselung des Tickets verwendet wurde.

Was sind SPN-Aliase?

Wenn Sie schon einmal eine Active Directory-Domäne verwaltet haben, ist Ihnen wahrscheinlich aufgefallen, dass jeder Computer über einige Standard-SPNs verfügt, darunter auch SPNs mit dem HOST Service-Klasse (HOST/computer). Für diejenigen, die damit nicht vertraut sind, können diese SPNs durchaus verwirrend sein.

Die Active Directory-Konfigurationspartition enthält ein Attribut mit dem Namen sPNMappings. Dieses Attribut ermöglicht die Zuordnung von SPNs zu sogenannten SPN-Aliase. Standardmäßig enthält dieses Attribut einen einzelnen Wert, der die HOST Alias für die folgenden Dienste:

alerter, appmgmt, cisvc, clipsrv, browser, dhcp, dnscache, replicator, eventlog, eventsystem, policyagent, oakley, dmserver, dns, mcsvc, fax, msiserver, ias, messenger, netlogon, netman, netdde, netddedsm, nmagent, plugplay, protectedstorage, rasman, rpclocator, rpc, rpcss, remoteaccess, rsvp, samss, scardsvr, scesrv, seclogon, scm, dcom, cifs, spooler, snmp, schedule, tapisrv, trksvr, trkwks, ups, time, wins, www, http, w3svc, iisadmin, msdtc

Bei der Aufnahme in die Domäne erhält jedes Active-Directory-Computerkonto ein HOST Klasse SPN. Wenn Benutzer versuchen, auf einen Dienst zuzugreifen, der HOST (z. B. cifs, http), verschlüsselt das KDC das Service-Ticket mit dem Schlüssel, der zu dem Konto mit der entsprechenden HOST SPN.

Ein interessanter Sonderfall

Die zuvor beschriebene Überprüfung der Eindeutigkeit von SPN-Aliasen verhindert die Erstellung von SPNs mit zugeordneten Namen, die zu Konflikten führen. Wenn die Gesamtstruktur beispielsweise einen Computer mit dem Namen Server, das über die HOST/Server SPN, Zuweisung der cifs/Server SPN-Verbindungen zu einem anderen Server werden blockiert, obwohl die cifs/Server SPN existiert nicht ausdrücklich.

Ich habe bereits erwähnt, dass die entdeckte Sicherheitslücke diese Eindeutigkeitsprüfung umgehen kann. Das Interessante daran ist jedoch, dass der SPN-Lookup-Algorithmus stets zuerst nach einem expliziten SPN sucht. Der Algorithmus sucht erst dann nach dem zugeordneten Alias des SPN, wenn kein expliziter SPN gefunden wird.

Mit dieser (ziemlich ausführlichen) Einführung in SPNs verfügen Sie nun über das nötige Wissen, um zu verstehen, wie die Sicherheitslücke ausgenutzt werden kann.

Nachweis der Wirkung

Ich werde Ihnen verschiedene Szenarien veranschaulichen. Zu diesem Zweck werde ich eine einfache Umgebung verwenden, die drei Server umfasst, die Mitglieder einer Domäne sind:

• ServerA
• ServerB
• ServerC

Der Angreifer ist als nicht privilegierter Benutzer mit dem Namen „NotAdmin“ angemeldet.

Szenario Nr. 1: Denial-of-Service-Angriff auf HOST-zugeordnete Dienste

Nehmen wir für unser erstes Szenario an, dass ServerB beherbergt eine wichtige SMB-Dateifreigabe. Benutzer, die auf die Freigabe zugreifen, fordern Diensttickets für cifs/SERVERB. Weil ServerB verfügt über die HOST/SERVERB Standardmäßig identifiziert der Domänencontroller das SPN als das Konto, das den entsprechenden Verschlüsselungsschlüssel für den Zieldienst besitzt. Wenn „NotAdmin“ über die Berechtigung „WriteSPN“ für ServerC, können sie das cifs/SERVERB Fügen Sie den SPN hinzu, da die Überprüfung der Eindeutigkeit des SPN-Alias diese Aktion blockiert (Abbildung 15).

Durch die Verwendung eines unsichtbaren und nicht filterbaren Zeichens und dessen Einfügung in die Zeichenkette gelingt es NotAdmin jedoch, den konfliktauslösenden SPN hinzuzufügen (Abbildung 16).

Wie bereits zu erwarten war, ist das Zeichen in der PowerShell-Konsole nicht vollständig unsichtbar. In dsa.msc ist es jedoch nicht sichtbar (Abbildung 17).

Und, was noch wichtiger ist: Wenn jemand eine LDAP-Abfrage für die cifs/SERVERB SPN, ServerC ist das Objekt, das zurückgegeben wird (Abbildung 18).

In diesem Szenario gilt aufgrund der zuvor erläuterten expliziten SPN-Priorität: Wenn ein beliebiger Benutzer innerhalb der Domäne versucht, auf ServerB über SMB, Das KDC verschlüsselt das Ticket mit ServerC’s Schlüssel. Wenn der Benutzer versucht, dieses Ticket zu verwenden, ServerB kann es nicht entschlüsseln, was zu einem KRB_AP_ERR_MODIFIED Fehler. Für den durchschnittlichen Benutzer könnte sich dies in Form mehrerer unterschiedlicher, mehrdeutiger Meldungen äußern:

• Der angegebene Netzwerkname ist nicht mehr verfügbar.
• Der Name des Zielkontos ist falsch.
• Der Pfad „path“ kann nicht gefunden werden, da er nicht existiert.

Durch das Entfernen des gefälschten SPN wird der normale Zugriff umgehend wiederhergestellt (Abbildung 19).

Sie verfügen über die Berechtigung „WriteSPN“ für jede Ein Computer- oder Benutzerkonto in der Gesamtstruktur ermöglichte die Durchführung eines Denial-of-Service-Angriffs (DoS) auf jede HOST- einen zugeordneten Dienst in der Forest-Struktur, indem nicht filterbare Zeichen verwendet werden. Abbildung 20 veranschaulicht dieses Szenario.

Szenario Nr. 2: SPN-Jacking

Eine weitere interessante Möglichkeit betrifft Angriffe mittels eingeschränkter Kerberos-Delegierung, da die klassische eingeschränkte Delegierung über SPNs konfiguriert wird. Um dies zu veranschaulichen, habe ich ein Szenario aus Elad Shamirs Blog zum Thema „SPN-Jacking“ angepasst.

Hinweis: Dieses Szenario setzt Kenntnisse über Kerberos-Delegationsangriffe (d. h. den „vollständigen S4U-Angriff“) voraus. Eine Erläuterung der Kerberos-Delegation würde den Rahmen dieses Artikels sprengen.

In seinem Beitrag stellte Shamir das folgende Szenario vor, in dem ein Angreifer mit Administratorrechten auf ServerA möchte Administratorrechte für ServerC. ServerA ist für die eingeschränkte Delegierung an cifs/ServerB, und der Angreifer verfügt über WriteSPN-Rechte für ServerB und ServerC (Abbildung 21).

Shamir schlug vor, die Überprüfung der Eindeutigkeit von SPN-Aliasen durch den Einsatz von „WriteSPN“ auf beiden Seiten durchzuführen. ServerB und ServerC, wobei das HOST/SERVERB SPN von ServerB, und erst dann fügen Sie cifs/SERVERB zu ServerC. Nun kann der Angreifer den vollständigen S4U-Angriff mithilfe von ServerAdas Konto von …, um ein Service-Ticket für einen privilegierten Benutzer zu erhalten, damit dieser ServerC, bevor Sie die Änderungen rückgängig machen.

Durch die Verwendung von KerberLoss in Kombination mit einer expliziten SPN-Priorität kann ein Angreifer den „WriteSPN“-Vorgang für den Zwischendienst umgehen. Um dies zu veranschaulichen, habe ich mein Labor wie in Abbildung 22 dargestellt eingerichtet.

Wie im vorherigen DoS-Beispiel kann der Angreifer nicht filterbare Zeichen verwenden, um ServerC die cifs/SERVERB SPN, wodurch die Eindeutigkeitsprüfung umgangen wird und eine Situation entsteht, in der Tickets an cifs/SERVERB wird mit ServerC’s Schlüssel (Abbildung 23).

Nun kann der Angreifer den gesamten S4U-Angriffsablauf ausführen, um ein privilegiertes Ticket für cifs/SERVERB (Abbildung 24).

Ich habe erfolgreich ein Service-Ticket für einen Administrator-Benutzer erhalten. Nun werde ich prüfen, ob das Ticket erfolgreich verschlüsselt wurde mit ServerCist der Schlüssel. Da sich der SPN im unverschlüsselten Teil des Tickets befindet, kann ich ihn in cifs/ServerC und auf den Server zugreifen. Der Zugriff funktioniert nur, wenn das Ticket mit ServerC…s Schlüssel, nicht ServerB’s (Abbildung 25).

Szenario Nr. 3: Herabstufung der Authentifizierung

Wir kennen nun die Auswirkungen der Erstellung widersprüchlicher zugeordneter SPNs. Doch wie verhält es sich mit doppelten expliziten SPNs? Erinnern wir uns an unsere DoS-Möglichkeit über HOST-Zuordnungen.

Bei widersprüchlichen SPN-Aliasen wird bei der Anforderung eines Diensttickets ein SPN gefunden und ein Dienstticket erstellt. Aus Sicht des Domänencontrollers hat Kerberos ordnungsgemäß funktioniert; der DoS-Effekt tritt auf, weil die Ressource selbst Das Ticket kann nicht entschlüsselt werden, was zu einem KRB_AP_ERR_MODIFIED Fehler. Wenn wir jedoch ein exaktes Duplikat eines SPN erstellen, fällt das Ergebnis anders aus.

Bei expliziten SPN-Duplikaten findet der Domänencontroller bei der Anforderung eines Diensttickets zwei Konten, die das SPN führen. In diesem Fall kann der Domänencontroller keine „Auswahl“ treffen Welcher Schlüssel sollte für das Ticket verwendet werden? und gibt somit ein KDC_ERR_S_PRINCIPAL_UNKNOWN Fehler. In diesem Fall gibt der DC den Fehler zurück, der darauf hinweist, dass die Kerberos-Authentifizierung fehlgeschlagen ist, woraufhin der Client auf NTLM ausweicht.

Das bedeutet, dass Sie durch den Besitz der Berechtigung „WriteSPN“ auf einem beliebigen Computer oder Benutzerkonto in der Gesamtstruktur nicht nur einen vollständigen DoS-Angriff auf jeden HOST-zugeordneten Dienst in der Gesamtstruktur auslösen, sondern auch jeden Dienst in der Gesamtstruktur – unabhängig davon, ob er HOST-zugeordnet ist oder nicht – dazu zwingen könnten , ausschließlich NTLM zu verwenden (sofern dies nicht deaktiviert ist, was wiederum zu einem DoS-Angriff führen würde).

Aus Sicht des Benutzers scheint der normale Zugriff weiterhin gewährleistet zu sein (Abbildung 26, Abbildung 27).

Abbildung 28 veranschaulicht dieses Szenario.

ResetNightmare: Wie sieht es mit UPNs aus?

Auf der Suche nach einer Methode zur direkten Rechteausweitung wandte ich mich den User Principal Names (UPNs) zu. Da die Überprüfung der Eindeutigkeit von UPNs durch denselben Mechanismus gesteuert wird wie die Überprüfung der Eindeutigkeit von SPNs, ging ich zu Recht davon aus, dass sie auf dieselbe Weise umgangen werden könnte (Abbildung 29).

Die Überprüfung der Eindeutigkeit wurde zusammen mit einer Reihe weiterer von Andrew Bartlett entdeckter Sicherheitslücken behoben, darunter insbesondere der „Dollar Ticket/noPac“-Angriff (CVE-2021-42287 + CVE-2021-42278), der es jedem Benutzer ermöglichte, sofort Domänenadministratorrechte zu erlangen. Da der Angriff eine Verwechslung bei der DC-Namensgebung beinhaltete, hoffte ich, dass KerberLoss die Möglichkeit bieten würde, diese Sicherheitslücke wieder aufzugreifen oder eine ähnliche zu entdecken. Für diese und alle meine anderen Ideen musste ich verstehen, ob und, falls ja, wie Kerberos UPNs verwendet.

Kerberos-Namensarten

In Kerberos besteht eine Prinzipal-Kennung aus einem Realm und ein PrincipalName. A PrincipalName ist wie folgt aufgebaut:

PrincipalName   ::= SEQUENCE {
	   name-type       [0] Int32,
	   name-string     [1] SEQUENCE OF KerberosString
}

Die name-string Das Feld gibt den Namen als Kerberos-Zeichenkette an. Allerdings ist das name-string Dies allein reicht nicht aus, um einen Auftraggeber zu identifizieren. Die name-type Das Feld gibt den Typ des Namens an, was im Klartext bedeutet, welcher Attribut Zunächst wird dieses Feld überprüft, um den Principal zu ermitteln. Das Kerberos-Protokoll ([RFC4120], Abschnitt 6.2) definiert verschiedene mögliche Werte für dieses Feld.

Active Directory verwendet in der Regel die NT-PRINCIPAL Namestyp zur Identifizierung von Kerberos-Clients, der dem Konto zugeordnet ist SamAccountName. Bei der Übermittlung von Anfragen für ein Kerberos-Ticket Granting Ticket (TGT) ist es zudem möglich, das NT-ENTERPRISE Typname, der Konten anhand ihres UserPrincipalName (UPN). Der tatsächliche Kundenname im daraus resultierenden Ticket kann lauten: SamAccountName (NT-PRINCIPAL) oder das UPN (NT-ENTERPRISE), und dies wird in der Regel durch die Name-canonicalize Flagge.

Glücklicherweise bieten gängige Kerberos-Tools wie Rubeus und Impacket bereits die Möglichkeit, anzugeben, welcher Namens-Typ in der TGT-Anfrage verwendet werden soll, sodass ich Tickets mit dem NT-ENTERPRISE Name-Typ.

Als ich jedoch versuchte, mit meinem duplizierten UPN Tickets anzufordern, versuchte der DC weiterhin, mich als privilegiertes Ziel zu authentifizieren, was zu dem Fehler „Vorabauthentifizierung fehlgeschlagen“ führte (Abbildung 30).

Dies funktionierte zwar beim Entfernen des UPN von „DemoAdmin1“ , doch für diese Methode wären Schreibrechte für das Ziel erforderlich, was im Hinblick auf eine Rechteausweitung unrealistisch ist (Abbildung 31).

Kurz darauf fand ich eine Lösung für dieses Problem: Anstatt die Überprüfung der Eindeutigkeit des UPN mithilfe von nicht filterbaren Zeichen zu umgehen, kann ich meinen UPN einfach auf den SamAccountName meines Ziels. Dies ist zulässig, da die Zeichenfolgen nicht identisch sind (Abbildung 32).

Wenn Sie nun mit dem Passwort von „UPNUser“ ein Ticket für „DemoAdmin1“ anfordern, schlägt dies erwartungsgemäß fehl. Wenn Sie jedoch den Namestyp in NT-ENTERPRISE, kann ich ein Ticket erhalten, auf dem der Name „DemoAdmin1“ vermerkt ist (Abbildung 33).

Diese Methode ermöglichte es mir im Wesentlichen, ein Ticket mit dem Namen eines beliebigen Benutzers zu erhalten. Auf diese Weise versuchte ich, eine weitere Confusion-Schwachstelle zu finden, und zwar mithilfe verschiedener Methoden, darunter:

• Normale AS-REQ zu TGS-REQ
• Ablauf des „Modified Dollar Ticket“-Angriffs
• S4U2: Selbstmissbrauch
• Missbrauch von U2U-Kerberos
• DoS-Angriff bei der Benutzeranmeldung, wie von Andrew Bartlett erwähnt
• Entra Hard/Soft-Match SyncJacking
• Priorität von domänenübergreifenden UPNs

Alle meine Versuche, UPNs zur Ausweitung von Berechtigungen zu missbrauchen, schlugen jedoch fehl. Je nach der jeweiligen Methode und dem verwendeten Tool erhielt ich entweder Fehlermeldungen oder ein Ticket, das an den korrekten, nicht privilegierten Benutzer gerichtet war. Ich habe dieses Verhalten genauer untersucht, um den Grund dafür herauszufinden.

Der Patch für CVE-2021-42287

Wie bereits erwähnt, führte die „Dollar-Ticket“-Sicherheitslücke zu einer Verwechslung bei der Namensgebung, ähnlich dem, was ich hier erreichen wollte. Microsoft hat die Sicherheitslücke behoben, indem es Kerberos um zwei wichtige Funktionen erweitert hat:

• Zurückgesendete TGTs enthalten stets ein Privileged Attribute Certificate (PAC), selbst wenn der Client ein Ticket ohne PAC angefordert hat.
• Der PAC in TGTs enthält nun ein Feld mit dem Namen PAC_REQUESTOR_SID, das die SID des Clients enthält, der das Ticket angefordert hat.

Dies PAC_REQUESTOR_SID Wert müssen und anschließend während der TGS-Börse, wodurch der bisherige Angriffsvektor unwirksam wird, bei dem der Angreifer das Konto löschte, das das TGT angefordert hatte, sodass der Domänencontroller glaubte, das TGT gehöre stattdessen dem gleichnamigen Domänencontroller.

Dieser (hervorragende) Patch hatte den etwas ärgerlichen Nebeneffekt, dass alle meine Versuche zur Rechteausweitung mittels UPN-Verwirrung unwirksam wurden. Der PAC enthielt nun stets meine ursprüngliche SID, und der DC ignorierte den Clientnamen in meinem Ticket vollständig und stützte sich ausschließlich auf die SID als maßgebliche Quelle des Tickets.

Gerade als ich im Begriff war, die Ausweitung von Berechtigungen mithilfe von UPNs aufzugeben, beschloss ich, meinen Rückstand an Ideen für Missbrauchsversuche ein letztes Mal durchzugehen und zu prüfen, ob jede davon funktionieren könnte. Dabei stieß ich auf etwas Interessantes.

Durchbruch: (Miss-)Brauch des Kerberos-Protokolls zum Ändern des Passworts

Standardmäßig kann jeder Active Directory-Benutzer sein eigenes Passwort ändern. Eine Möglichkeit hierfür ist die Verwendung des „Kerberos Change Password and Set Password Protocol“ von Microsoft, das festlegt, wie Passwortänderungen über Kerberos durchgeführt werden. Das Protokoll ist äußerst einfach (der RFC umfasst lediglich 7 Seiten) und enthält lediglich eine einzige Anforderungsnachricht und eine einzige Antwortnachricht.

Microsoft verwendet die Begriffe „Passwort ändern“ und „Passwort festlegen“, um zwischen dem Fall, dass ein Benutzer sein eigenes Passwort ändert, und dem Fall, dass ein Administrator das Passwort für einen Benutzer festlegt, zu unterscheiden.

Das Protokoll empfängt Nachrichten auf Port 464 (kpasswd), wobei die Anforderungsstruktur in Abbildung 34 dargestellt ist.

Die beiden Hauptbestandteile dieser Nachricht sind die KRB-PRIV-Nachricht und die AP-REQ-Struktur.

Die KRB-PRIV-Nachricht dient im Wesentlichen lediglich dazu, verschlüsselte Daten zu übermitteln. Sie ermöglicht zudem die Einbindung benutzerdefinierter Daten. Das Protokoll nutzt dies, indem es den Wert des neuen Passworts in diese Struktur einfügt (Abbildung 35).

Besonders interessant ist die AP-REQ-Struktur. Diese Struktur enthält ein Ticket und einen Authentifikator, der den rechtmäßigen Besitz des Tickets nachweist, da er mit dessen Sitzungsschlüssel verschlüsselt ist (Abbildung 36).

In den meisten Fällen führt bei Kerberos eine TGS_REQ/TGS_REP-Anfrage zu einem Service-Ticket (und dem dazugehörigen Sitzungsschlüssel). Diese Antwort wird anschließend zur Erstellung der AP_REQ-Nachricht verwendet, die an den Dienst gesendet wird, um den Besitz des Tickets nachzuweisen.

Im Falle des Kerberos-Passwortänderungsprotokolls muss das Ticket in der AP-REQ-Struktur auf den kadmin/changepw SPN. Es handelt sich hierbei jedoch um ein SPN, das dem krbtgt-Konto gehört, und wir wissen, dass allein der Verschlüsselungsschlüssel von Bedeutung ist, daher eine Fahrkarte nach kadmin/changepw ist lediglich ein TGT, bei dem der SPN (sname) geändert wurde.

Das bedeutet, dass wir lediglich das TGT eines Benutzers benötigen, um dessen Passwort zu ändern. Es bedeutet ferner, dass der Ablauf der Passwortänderung durch einen Benutzer unter Verwendung von Kerberos wie in Abbildung 37 dargestellt verläuft.

Das Interessante daran ist, dass dieser Ablauf direkt von einem TGT-REQ zu einem AP-REQ übergeht, ohne dass dazwischen ein TGS-REQ steht. Erinnern Sie sich an den Patch, den wir zuvor betrachtet haben: Im TGS-REQ ist der Ort, an dem die PAC_REQUESTOR_SID Die Validierung findet statt.

In Anbetracht der Tatsache, dass ich bereits ein TGT mit einem beliebigen Benutzernamen anfordern konnte (unter Verwendung des NT-ENTERPRISE Name Typ), falls die PAC_REQUESTOR_SID Sollte die Korrektur hier nicht implementiert worden sein, könnte das Protokoll möglicherweise anfällig sein.

Ich fasste all das Wissen zusammen, das ich aus meinen bisherigen Tests gewonnen hatte, und machte mich daran, es auszuprobieren. Da mir bewusst war, dass standardmäßig jeder Benutzer in Active Directory die Berechtigung besitzt, sein eigenes Passwort zu ändern, sah mein Missbrauchsversuch wie folgt aus:

1. Ein Angreifer hat Zugriff auf einen Benutzer namens „UPNUser“ erlangt, der über keine besonderen Berechtigungen verfügt, abgesehen von der Möglichkeit, seinen eigenen UPN-Wert zu ändern.
2. Der Angreifer legt den UPN des Benutzers auf den SamAccountName des betreffenden Kontos; zum Beispiel, DemoAdmin1.
   Für diesen Vorgang ist es nicht erforderlich, die Überprüfungen zur Eindeutigkeit der UPN zu umgehen. DemoAdmin1Die tatsächliche UPN sollte „DemoAdmin1@demo.lab“ lauten, daher sollte die Einstellung UPNUserUPN auf lediglich DemoAdmin1 ist zulässig (Abbildung 38).

3. Der Angreifer fordert ein TGT für kadmin/changepw durch Angabe von DemoAdmin1 als Benutzernamen, NT-ENTERPRISE als Typ des Namens und Das Passwort des UPN-Benutzers.
4. Der DC gibt ein TGT_REP mit einem TGT für UPNUser zurück (wie durch PAC_REQUESTOR_SID im PAC), jedoch mit dem Benutzernamen „DemoAdmin1“ (NT_ENTERPRISE), als Abbildung 39 zeigt.

5. Wenn Sie dieses Ticket verwenden, um eine Passwortänderungsanforderung zu stellen, wird das Passwort von „UPNUser“ zurückgesetzt. Um sich erweiterte Berechtigungen zu verschaffen, ändert oder löscht der Angreifer den UPN-Wert von „UPNUser“, sodass kein Benutzer mehr mit dem im Ticket angegebenen UPN existiert.
6. Der Versuch, dieses Ticket nach der UPN-Änderung für eine TGS_REQ zu verwenden, führt zu einem KDC_ERR_TGT_REVOKED Fehler, bedingt durch die PAC_REQUESTOR_SID Patch, der die Identitätsfälschung verhindert. Wenn Sie dieses Ticket jedoch zur Erstellung der Anfrage zur Passwortänderung verwenden, funktioniert die Passwortänderung.
7. Nun kann der Angreifer ein neues TGT für DemoAdmin1, ohne zur Festlegung der NT-ENTERPRISE Name Typ. Die Anfrage funktioniert nun und der Namens-Typ des Tickets lautet NT-PRINCIPAL, was darauf hindeutet, dass das Ticket dem echten (SamAccountName) DemoAdmin1 Benutzer (Abbildung 40).

Erfolg! Allein durch die Möglichkeit, eine UPN zu erstellen, haben wir die Domäne kompromittiert.

Ich habe diese Sicherheitslücke „ResetNightmare“ genannt; ihr wurde die Kennung CVE-2026-27912 zugewiesen. Die Sicherheitslücke ermöglicht einem Angreifer, der über allgemeine Schreibrechte für beliebige Benutzer- oder Computerobjekte in der Domäne verfügt oder der Benutzer- oder Computerobjekte in der Domäne erstellen kann (mit Ausnahme von „MachineAccountQuota“), die vollständige Übernahme der Domäne.

Abbildung 41 veranschaulicht den Ablauf des Missbrauchs von „ResetNightmare“.

Die einzige weitere Voraussetzung ist, dass das Passwort des Zielbenutzers bereits ausreichend lange gültig ist. Da die Standard-Mindestgültigkeitsdauer für Passwörter in Active Directory jedoch 1 Tag beträgt, ist es sehr wahrscheinlich, dass das Passwort des Zielbenutzers diese Anforderung erfüllt.

Als zusätzlicher Vorteil (dank Andrea Pierini) lässt sich diese Sicherheitslücke zudem mit der „Shadow Credentials“-Technik kombinieren, wodurch durch den Missbrauch von schreibberechtigten Benutzerkonten ein noch heimlicherer Angriffsweg ermöglicht wird.

Außerdem habe ich ein Open-Source-Community-Tool namens „ResetNightmare“ entwickelt, das den gesamten Ablauf des ResetNightmare-Angriffs implementiert, einschließlich verschiedener Parameter zur Anpassung der Ausführung. Das Tool ist in PowerShell geschrieben und nutzt „Rubeus.exe“ sowie das PowerShell-ActiveDirectory-Modul (Abbildung 42). Sie finden das Tool auf GitHub.

Erkennung und Abwehr von KerberLoss und ResetNightmare

Kunden von Semperis Directory Services Protector (DSP) können die folgenden neuen Sicherheitsindikatoren nutzen, um verschiedene in diesem Artikel erwähnte Fehlkonfigurationen zu erkennen:

• Die Überprüfung der Eindeutigkeit von UPN oder SPN ist deaktiviert
• Objekte, die versteckte Unicode-Zeichen enthalten
• Verdächtige doppelte Objekte, die versteckte Unicode-Zeichen enthalten
• Ein nicht privilegierter Prinzipal kann einen Dienstprinzipalnamen festlegen
• Ein nicht privilegierter Prinzipal kann einen Benutzerprinzipalnamen festlegen

Darüber hinaus können Kunden von „ DSP “ ungewöhnliche Änderungen an SPN- und UPN-Namen anhand von zwei Indikatoren für Kompromittierung (IoCs) erkennen:

• Ein widersprüchlicher Service Principal Name wurde hinzugefügt (CVE-2026-25177)
• Es wurde ein Benutzer-Prinzipalname hinzugefügt, der mit dem SAM-Kontonamen eines anderen Kontos übereinstimmt (CVE-2026-27912)

Ohne „ DSP “ besteht die beste Möglichkeit, den Missbrauch beider Techniken zu erkennen, darin, SACLs so zu konfigurieren, dass Änderungen an Active-Directory-Objekten protokolliert werden. Ist die SACL entsprechend konfiguriert, kann das Sicherheitsprotokollereignis mit der ID 5136 („Ein Verzeichnisdienstobjekt wurde geändert“) auf Domänencontrollern genutzt werden, um Änderungen zu erkennen, die zu den Auswirkungen der Sicherheitslücke führen.

Bei „KerberLoss“ zeigt der Eintrag mit der Ereignis-ID 5136 an, dass ein „ServicePrincipalName“ hinzugefügt wurde, der mit einem bereits vorhandenen in Konflikt steht (Abbildung 43).

Bei „ResetNightmare“ zeigt der Eintrag mit der Ereignis-ID 5136 die Hinzufügung eines „UserPrincipalName“ an, der einem bereits vorhandenen entspricht SamAccountName (Abbildung 44).

Die beste Vorbeugungsmaßnahme gegen diese Sicherheitslücken ist die Installation von Patches auf allen Domänencontrollern. Microsoft hat im März 2026 einen Patch für „KerberLoss“ (CVE-2026-25177) und im April 2026 einen Patch für „ResetNightmare“ (CVE-2026-27912) veröffentlicht.

Abgesehen von Patches sollten Unternehmen sich an das Prinzip der geringsten Berechtigungen halten und auf ungewöhnliche Hinzufügungen von nicht standardmäßigen Berechtigungen achten. Strengere Berechtigungen können den Missbrauch dieser Schwachstellen erschweren.

Zeitplan für die Offenlegung

• 26. November 2025: KerberLoss wird entdeckt und dem MSRC gemeldet.
• 17. Dezember 2025: „ResetNightmare“ wird entdeckt und dem MSRC gemeldet.
• 9. Januar 2026: Das MSRC bestätigt, dass „ResetNightmare“ wie berichtet funktioniert.
• 17. Januar 2026: Das MSRC bestätigt, dass KerberLoss wie berichtet funktioniert.
• 10. März 2026: Microsoft behebt am „Patch Tuesday“ die Sicherheitslücke „KerberLoss“ (CVE-2026-25177) als „wichtige“ Sicherheitslücke, die eine Ausweitung von Berechtigungen ermöglicht.
• 14. April 2026: Microsoft behebt die Sicherheitslücke „ResetNightmare“ (CVE-2026-27912) als wichtige Sicherheitslücke, die eine Ausweitung von Berechtigungen ermöglicht.

Danksagung

Ein besonderer Dank gilt den folgenden Forschern, die verschiedene Teile dieser Forschungsarbeit maßgeblich inspiriert haben:

• Yossi Sassi (@Yossi_Sassi)
• Andrew Bartlett
• Elad Shamir (@elad_shamir)
• Charlie Clark (@exploitph)
• Will Schroeder (@harmj0y)
• Andrea Pierini (@decoder_it)
• Benjamin Delpy (@gentilkiwi)

Weitere Ressourcen

• Semperis-Forschungsbibliothek zur Identitätssicherheit
• Semperis-Katalog für Identitätsbedrohungen

Haftungsausschluss

Dieser Inhalt wird ausschließlich zu Bildungs- und Informationszwecken bereitgestellt. Er soll das Bewusstsein und die verantwortungsvolle Behebung von Sicherheitslücken fördern, die auf Systemen bestehen können, die Sie besitzen oder zu deren Prüfung Sie berechtigt sind. Die unbefugte Nutzung dieser Informationen zu böswilligen Zwecken, zur Ausbeutung oder zum unrechtmäßigen Zugriff ist strengstens untersagt. Semperis befürwortet oder duldet keine illegalen Aktivitäten und lehnt jede Haftung ab, die aus dem Missbrauch des Materials entsteht. Darüber hinaus übernimmt Semperis keine Garantie für die Richtigkeit oder Vollständigkeit der Inhalte und haftet nicht für Schäden, die sich aus der Verwendung der Inhalte ergeben.