Active Directory SPN-Duplikat, WriteSPN-Missbrauch, Kerberos-Downgrade: Ein Blick auf CVE-2026-25177 (KerberLoss)

Active Directory SPN-Duplikat, WriteSPN-Missbrauch, Kerberos-Downgrade — drei Probleme, die die meisten AD-Teams auf drei getrennten Tickets verfolgen, kollidierten am 10. März 2026 in einem einzigen, als Microsoft den Fix für CVE-2026-25177 auslieferte. Der Semperis-Forscher Shai Laron, der die Schwachstelle meldete, nannte sie KerberLoss. Kurz gesagt: Ein gering privilegierter Principal mit dem Recht, ein einziges Attribut auf einem einzigen Objekt zu schreiben, konnte Kerberos für jeden HOST-gemappten Dienst in der Gesamtstruktur brechen — und mit einer zweiten Runde desselben Tricks Clients eines beliebigen Dienstes still auf NTLM umleiten.

Was hieraus ein Erkennungsproblem statt eines reinen Patch-Problems macht, ist die Umgehungstechnik. Das SPN-Duplikat, das den Dienst bricht, ist kein Byte-für-Byte-Duplikat. Es kollidiert nur auf der Kerberos-Ebene. Jedes Werkzeug, das Ihr Runbook nutzt — setspn -X, der forstweite Eindeutigkeitsindex, das Directory-Services-Ereignis, das beim Blockieren eines Duplikats feuert — vergleicht Zeichenketten auf Gleichheit, und genau diese Gleichheit umgeht der Angreifer.

Was ist ein SPN-Duplikat in Active Directory

Ein Service Principal Name ist die Zeichenkette, mit der ein Kerberos-Client beim KDC ein Ticket für eine bestimmte Dienstinstanz anfordert — cifs/fileserver.corp.local, http/intranet, MSSQLSvc/db01:1433. Er liegt im mehrwertigen Attribut servicePrincipalName des Benutzer- oder Computerkontos, unter dem der Dienst läuft. Will ein Client mit einem Dienst kommunizieren, baut er den SPN, fordert beim KDC ein Dienstticket an, und der KDC verschlüsselt dieses Ticket mit dem Langzeitschlüssel des Kontos, das den SPN hält — demselben Schlüssel, dessen Kompromittierung die Fälschung eines Silver Tickets ermöglicht.

Dieses Design funktioniert nur, wenn die Zuordnung von SPN zu Konto eine Funktion ist. Microsoft sagt es explizit: „Sofern ein Dienst nicht das Computerkonto und den HOST-SPN verwendet, müssen SPNs innerhalb der AD-DS-Gesamtstruktur eindeutig sein. In einer Umgebung mit mehreren Gesamtstrukturen muss der SPN über alle zugehörigen Gesamtstrukturen hinweg eindeutig sein" und „Ein SPN kann nur mit einem Konto verknüpft sein" (Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error).

Beanspruchen zwei Konten denselben SPN, hat der KDC keine Grundlage, einen Schlüssel auszuwählen. Microsofts Referenz zu Kerberos-Ereignissen dokumentiert dafür einen eigenen Fehlercode, 0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE, beschrieben als „Mehrere Principal-Einträge in der KDC-Datenbank… Dieser Fehler tritt auf, wenn doppelte Principal-Namen existieren. Eindeutige Principal-Namen sind entscheidend, um die gegenseitige Authentifizierung sicherzustellen."

Es gibt hier eine zweite relevante Ebene. Computerkonten erhalten automatisch einen HOST-SPN, und eine dokumentierte Liste von Dienstklassen fällt standardmäßig darauf zurück. Microsofts setspn-Referenz listet sie auf — cifs, http, www, wins, spooler, rpcss, dns, netlogon und rund vierzig weitere — und formuliert die Vorrangregel klar: „Diese SPNs werden für Computerkonten erkannt, wenn der Computer über einen Host-SPN verfügt. Sofern sie nicht explizit auf Objekten platziert sind, kann ein Host-SPN jeden der genannten SPNs ersetzen." Die Äquivalenz selbst wird im Attribut sPNMappings (CN=SPN-Mappings, Attribut-ID 1.2.840.113556.1.4.1347) des NTDS-Service-Objekts ausgedrückt, das Microsoft als „eine Liste von Service Principal Names (SPN), die die Äquivalenz von SPN-Typen zeigt" beschreibt.

Semperis destilliert die Konsequenz in einen Satz: „Der SPN-Lookup-Algorithmus sucht immer zuerst nach einem expliziten SPN. Nur wenn kein expliziter SPN gefunden wird, sucht der Algorithmus nach dem gemappten Alias des SPN."

Ein expliziter SPN, egal wo in der Gesamtstruktur, hat Vorrang vor einem HOST-Mapping. Das ist der Hebel.

Active Directory SPN-Duplikat, WriteSPN-Missbrauch, Kerberos-Downgrade: So funktioniert KerberLoss

Seit Windows Server 2012 R2 verweigern Domänencontroller die Erstellung eines Duplikats. Microsofts Referenz SPN and UPN uniqueness dokumentiert den Ablauf: Der DC fragt den forstweiten servicePrincipalName-Index ab — auf einem Global Catalog oder lokal, falls der DC selbst ein GC ist — und „Wenn die Anzahl der zurückgegebenen Einträge != 0 ist -> schlägt der Schreibvorgang fehl." Der Aufrufer erhält den erweiterten Fehler 8647 / 0x21C7 ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (UPNs erhalten 8648 / 0x21C8), und der DC schreibt die Ereignis-ID 2974, Quelle ActiveDirectory_DomainService, in das Directory-Services-Protokoll — ein Ereignis, das den blockierten Wert nennt und bis zu zehn Objekte auflistet, die ihn bereits halten.

Dieselbe Referenz merkt an, dass diese Prüfung auch läuft, wenn ein SPN regeneriert statt direkt geschrieben wird. Das Ändern von dNSHostName, sAMAccountName, msDS-AdditionalDnsHostName, msDS-AdditionalSamAccountName, serverReferenceBL oder userAccountControl veranlasst AD, alte SPNs zu löschen und neue zu konstruieren, und „Ist einer der neuen SPN-Werte ein Duplikat, lassen wir die Änderung fehlschlagen."

Semperis datiert das aktuelle Set von drei Prüfungen — UPN-Eindeutigkeit, SPN-Eindeutigkeit und SPN-Alias-Eindeutigkeit — auf Microsofts Patch von 2021 für CVE-2021-42282. Die Alias-Prüfung ist genau die, die KerberLoss aushebelt.

Es ist eine solide Kontrolle. Sie vergleicht Zeichenketten.

Die Forschung von Semperis griff den Vergleich selbst an. Beim Testen von 385 unsichtbaren Unicode-Zeichen stellte Laron fest, dass nur 106 über Standard-LDAP-Abfragen filterbar waren; der Rest wird entweder als Leerzeichen behandelt oder, in den Worten von Semperis, „vom DC vollständig ignoriert." Wird eines dieser Zeichen in eine SPN-Zeichenkette eingefügt, sieht der Eindeutigkeitsindex keine Übereinstimmung mehr — „durch die Verwendung eines unsichtbaren und nicht filterbaren Zeichens, das in die Zeichenkette eingefügt wird, kann NotAdmin den kollidierenden SPN erfolgreich hinzufügen."

Microsofts eigene FAQ zur Empfehlung für CVE-2026-25177 beschreibt dieselbe Kette und ihr Ergebnis:

Das MSRC bewertete sie mit CVSS 3.1 Base 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, temporal 7.7), Schweregrad Important, klassifiziert als CWE-641 (Improper Restriction of Names for Files and Other Resources), mit dem Titel Active Directory Domain Services Elevation of Privilege Vulnerability. Weder MSRC noch Semperis dokumentieren, was die Codeänderung vom März intern tatsächlich bewirkt — betrachten Sie den Fix als Blackbox und verifizieren Sie ihn anhand der DC-Build-Nummer, nicht anhand des Verhaltens.

Die Berechtigung, auf der das Ganze beruht, ist unspektakulär. Auf Computerobjekten ist es das validierte Schreibrecht, das Microsoft „Validated write to service principal name" nennt (CN=Validated-SPN, Rights-GUID f3a64788-5306-11d1-a9c5-0000f80367c1), delegierbar in ADUC und explizit in der setspn-Dokumentation erwähnt: „Sie können diese Berechtigung auch delegieren, indem Sie dem gewünschten Benutzer oder der Gruppe die Berechtigung Validated write to service principal name zuweisen." Auf jedem beliebigen Objekt erfüllen GenericAll, GenericWrite oder WriteProperty auf servicePrincipalName denselben Zweck. Das ist dieselbe Klasse von Attribut-Schreibrecht, die auch Shadow Credentials über msDS-KeyCredentialLink antreibt — und laut Semperis reichte WriteSPN „auf jedem beliebigen Computer- oder Benutzerkonto in der Gesamtstruktur".

Die Angriffskette

Schritt 1 — Ein beschreibbares Objekt beschaffen

Der Angreifer benötigt Schreibzugriff auf servicePrincipalName bei einem Konto. Das kann ein delegiertes Helpdesk-Recht sein, eine veraltete Service-Desk-Gruppe, eine zu breite OU-Delegation — oder ein Computerobjekt, das der Angreifer selbst erstellt hat, da ms-DS-MachineAccountQuota standardmäßig jedem Domänenbenutzer erlaubt, zehn Computer beizutreten und der Ersteller Schreibrechte auf das erhält, was er erstellt hat.

Schritt 2 — Ein HOST-gemapptes Ziel identifizieren

Das Ziel ist jeder Dienst, der auf den automatischen HOST-SPN statt auf einen expliziten SPN angewiesen ist — Dateifreigaben (cifs), IIS (http/www), Druck (spooler) und der Rest der dokumentierten Liste. Das sind genau die Dienste, die keinen expliziten SPN haben, um ihren Anspruch zu verteidigen.

Die registrierten SPNs eines Ziels auflisten — fehlt cifs/SERVERB, stützt sich der Dienst auf das HOST-Mapping und kann vorweggenommen werden:

setspn -L SERVERB

Schritt 3 — Den kollidierenden SPN platzieren

Der Angreifer schreibt cifs/SERVERB auf sein eigenes kontrolliertes Objekt, mit einem eingebetteten unsichtbaren Codepunkt, sodass der forstweite Index eine andere Zeichenkette sieht. Die Eindeutigkeitsprüfung besteht. Es wird kein Fehler 8647 zurückgegeben. Es wird kein Ereignis 2974 geschrieben, denn aus Sicht des DC wurde nichts blockiert.

Schritt 4 — Der Dienst bricht, laut

Clients fordern nun cifs/SERVERB an, und der KDC findet einen expliziten SPN, der Vorrang vor SERVERBs HOST-Mapping hat. Er stellt ein Ticket aus — versiegelt mit dem Kontoschlüssel des Angreifers. SERVERB kann es nicht entschlüsseln und weist es mit 0x29 KRB_AP_ERR_MODIFIED zurück, von Microsoft dokumentiert als „Die Authentifizierungsdaten wurden mit dem falschen Schlüssel für den vorgesehenen Server verschlüsselt."

Beachten Sie, was nicht passiert ist. Aus Sicht des KDC war die Anfrage erfolgreich: Ein Ticket wurde angefordert, ein Ticket wurde ausgestellt. Es gibt keinen Kerberos-Fehler, von dem aus zurückgefallen werden könnte, und daher keinen NTLM-Fallback — nur einen Dienst, der aufgehört hat zu funktionieren. Semperis berichtet, dass Benutzer Meldungen wie „The specified network name is no longer available.", „The target account name is incorrect." oder „Cannot find path 'path' because it does not exist." sehen, und dass der Zugriff wiederhergestellt wird, sobald der bösartige SPN entfernt wird.

Schritt 5 — Derselbe Schreibvorgang, ein leiseres Ergebnis: NTLM

Der Downgrade ist eine andere Verwendung derselben Berechtigung. Statt ein HOST-Mapping vorwegzunehmen, dupliziert der Angreifer einen SPN, der bereits explizit existiert. Nun findet der KDC zwei Konten, die ihn halten, kann keinen Schlüssel auswählen und gibt — in den Tests von Semperis — KDC_ERR_S_PRINCIPAL_UNKNOWN zurück. Das ist ein echter Kerberos-Fehlschlag, genau das, was ein Windows-Client für einen Fallback benötigt.

Das ist die Variante, um die man sich sorgen sollte. Laut Semperis funktioniert sie gegen jeden Dienst in der Gesamtstruktur, HOST-gemappt oder nicht, und „aus Sicht des Benutzers scheint der normale Zugriff erhalten zu bleiben." Niemand eröffnet ein Ticket. Unterdessen ruht alles, was auf der Annahme beruht, dass Kerberos der Authentifizierungsweg ist — jede Relay-Abwehr, die übersprungen wurde, weil „wir sind Kerberos-only" — nun auf den NTLM-Relay-Kontrollen statt darauf. Wo NTLM deaktiviert wurde, erzeugt dasselbe Duplikat einen Ausfall statt eines Downgrades.

Schritt 6 — Oder: Die Delegation eines anderen steuern

Semperis demonstriert eine dritte Verwendung, SPN-Jacking, adaptiert von Elad Shamirs ursprünglichem Beitrag. Ein Angreifer, der ein für eingeschränkte Delegation konfiguriertes Konto kompromittiert hat und WriteSPN auf einem selbst kontrollierten Konto besitzt, platziert den SPN des Zwischendienstes auf diesem Konto und führt den vollständigen S4U-Ablauf aus — und erhält so ein mit dem eigenen Schlüssel versiegeltes Ticket. Shamirs Version benötigte zusätzlich WriteSPN auf dem Konto, das den Ziel-SPN hielt, um diesen zuerst zu entfernen; KerberLoss beseitigt diese Voraussetzung. Falls Ihre Umgebung noch die in Kerberos-Delegationsangriffen behandelten Delegationsmuster nutzt, ist das der Pfad, den Sie zuerst überprüfen sollten.

Erkennung

Beginnen wir mit einer unbequemen Tatsache: Die Ereignisse, die normalerweise ein SPN-Duplikat melden, sind genau die, die diese Technik zu vermeiden versucht.

Ereignis 5136 ist die Stelle, an der dies erfasst wird. Microsoft dokumentiert, dass es „jedes Mal, wenn ein Active-Directory-Objekt geändert wird" generiert wird, und es führt genau die Felder mit, die Sie benötigen: ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType (%%14674 Wert hinzugefügt, %%14675 Wert gelöscht) sowie SubjectUserSid/SubjectUserName des Schreibers.

Zwei Voraussetzungen, beide leicht zu übersehen. Die Unterkategorie Audit Directory Service Changes muss aktiviert sein, und das Objekt braucht eine passende SACL: „Um dieses Ereignis zu generieren, muss das geänderte Objekt einen entsprechenden Eintrag in der SACL haben: die 'Write'-Aktionsauditierung für bestimmte Attribute." Ohne die SACL erzeugt die Unterkategorie allein nichts.

Jeder SPN-Schreibvorgang, mit der Identität des ausführenden Principals:

$xpath = "*[System[EventID=5136]] and *[EventData[Data[@Name='AttributeLDAPDisplayName']='servicePrincipalName']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 500 |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    [pscustomobject]@{
      Time      = $_.TimeCreated
      Actor     = ($x.Event.EventData.Data | Where-Object Name -eq 'SubjectUserName').'#text'
      Target    = ($x.Event.EventData.Data | Where-Object Name -eq 'ObjectDN').'#text'
      Operation = ($x.Event.EventData.Data | Where-Object Name -eq 'OperationType').'#text'
      Value     = ($x.Event.EventData.Data | Where-Object Name -eq 'AttributeValue').'#text'
    }
  }

-- Microsoft Sentinel: SPN-Schreibvorgänge durch Nicht-Tier-0-Principals.
-- Die Attributfelder von 5136 sind NICHT auf SecurityEvent-Spalten gemappt
-- (siehe Tabellenreferenz) — aus dem rohen EventData-XML extrahieren.
SecurityEvent
| where EventID == 5136
| extend Attribute = extract(@'Name="AttributeLDAPDisplayName">([^<]*)<', 1, EventData),
         SpnValue  = extract(@'Name="AttributeValue">([^<]*)<', 1, EventData),
         ObjectDN  = extract(@'Name="ObjectDN">([^<]*)<', 1, EventData),
         Operation = extract(@'Name="OperationType">%%(\d+)<', 1, EventData)
| where Attribute =~ "servicePrincipalName"
| where Operation == "14674"               // Wert hinzugefügt
| where SubjectUserName !in ("svc_scom$", "svc_sccm$")
| project TimeGenerated, Computer, SubjectUserName, ObjectDN, SpnValue
| order by TimeGenerated desc

Direkt nach dem unsichtbaren Zeichen suchen

Dies ist die Prüfung, die nicht davon abhängt, den Schreibvorgang abzufangen. Jeder SPN, der einen Codepunkt außerhalb des druckbaren ASCII-Bereichs enthält, ist anomal — legitime SPNs bestehen aus Hostnamen, Dienstklassen, Ports und Instanznamen.

Get-ADObject -LDAPFilter '(servicePrincipalName=*)' -Properties servicePrincipalName -ResultPageSize 500 |
  ForEach-Object {
    $dn = $_.DistinguishedName
    foreach ($spn in $_.servicePrincipalName) {
      if ($spn -notmatch '^[\x20-\x7E]+$') {
        [pscustomobject]@{
          DistinguishedName = $dn
          SPN               = $spn
          CodePoints        = ($spn.ToCharArray() | ForEach-Object { '{0:X4}' -f [int]$_ }) -join ' '
        }
      }
    }
  }

Führen Sie die byte-genaue Duplikatsuche trotzdem aus — sie erfasst die gewöhnliche Fehlkonfiguration und den unversierten Angreifer:

setspn -X -F -P
setspn -T * -T contoso -X

Die TGS-Telemetrie aktivieren, die Sie vermutlich nicht haben

Microsofts Referenz zu Ereignis 4769 besagt, dass manche Fehlschläge „nur gemeldet werden, wenn Sie den Registrierungsschlüsselwert KdcExtraLogLevel setzen", mit 0x01: Audit SPN unknown errors. Die KDC-Registrierungsreferenz dokumentiert den Standardwert 2 — was bedeutet, dass Bit 0x1 deaktiviert ist und KDC_ERR_S_PRINCIPAL_UNKNOWN-Fehlschläge auf einem Standard-DC nicht in das Security-Protokoll geschrieben werden. Der genaue Fehlschlag, den ein SPN-Duplikat erzeugt, ist standardmäßig unsichtbar.

Behalten Sie auf jedem DC das standardmäßige PKINIT-Logging (0x2) bei und fügen Sie das SPN-unknown-Auditing (0x1) hinzu — das ergibt 3:

$k = 'HKLM:\SYSTEM\CurrentControlSet\Services\Kdc'
New-Item -Path $k -Force | Out-Null
Set-ItemProperty -Path $k -Name 'KdcExtraLogLevel' -Value 3 -Type DWord
Get-ItemProperty -Path $k -Name 'KdcExtraLogLevel'

Rechnen Sie mit Volumen und erstellen Sie eine Woche lang eine Baseline, bevor Sie alarmieren. Microsoft warnt, dass 0x20-Fehlschläge (abgelaufene Tickets) übliches Hintergrundrauschen sind; SPN-unknown-Fehlschläge sind seltener, aber in einer gesunden Gesamtstruktur nicht null.

Remediation

1. Die Domänencontroller patchen. Der Fix ist im Sicherheitsupdate vom März 2026 enthalten — das monatliche Rollup für Server 2012 und 2012 R2. Das MSRC listet dies pro Server-SKU:

Wo das MSRC zwei Pakete für ein SKU listet — Server 2022 und Server 2025 — ist das zweite das Hotpatch-Paket (KB5078737 und KB5078736), das nur für Hotpatch-fähige Installationen gilt. Bestätigen Sie vor dem Deployment, welches auf Ihren genauen Build zutrifft. Die Schwachstelle wird auf dem DC behoben, nicht auf Mitgliedsservern — eine vollständig gepatchte Flotte mit einem einzigen ungepatchten DC verarbeitet Schreibvorgänge weiterhin über den ungepatchten Pfad.

2. Herausfinden, wer SPNs schreiben kann. Das ist die Berechtigung, die der gesamte Angriff benötigt, und in den meisten Gesamtstrukturen hat sie noch nie jemand erfasst. Die folgende Abfrage meldet nicht-administrative Principals, die Validated-SPN, direktes Schreibrecht auf das Attribut servicePrincipalName oder generisches Schreibrecht auf ein beliebiges Computerobjekt besitzen.

$validatedSpn = [guid]'f3a64788-5306-11d1-a9c5-0000f80367c1'
$schemaNC     = (Get-ADRootDSE).schemaNamingContext
$spnAttrGuid  = [guid](Get-ADObject -SearchBase $schemaNC `
                  -LDAPFilter '(lDAPDisplayName=servicePrincipalName)' `
                  -Properties schemaIDGUID).schemaIDGUID

Get-ADComputer -Filter * -ResultPageSize 500 | ForEach-Object {
  $dn = $_.DistinguishedName
  (Get-Acl "AD:$dn").Access |
    Where-Object {
      $_.AccessControlType -eq 'Allow' -and
      ($_.ObjectType -eq $validatedSpn -or $_.ObjectType -eq $spnAttrGuid -or
       $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite')
    } |
    Where-Object { $_.IdentityReference -notmatch 'SYSTEM|Domain Admins|Enterprise Admins|Administrators' } |
    ForEach-Object {
      [pscustomobject]@{ Object = $dn; Principal = $_.IdentityReference; Rights = $_.ActiveDirectoryRights }
    }
}

Entfernen Sie, was nicht gerechtfertigt ist. Achten Sie besonders auf Delegationen an breite Gruppen (Authenticated Users, Domain Users, alte Helpdesk-Gruppen) und auf Principals mit Rechten auf Tier-0-Computerobjekten.

3. Den Pool angreiferkontrollierter Objekte reduzieren. Setzen Sie ms-DS-MachineAccountQuota auf 0 und gewähren Sie stattdessen Computer-Beitritte über eine delegierte Gruppe. Das behebt CVE-2026-25177 nicht, entzieht einem gewöhnlichen Benutzer aber den einfachsten Weg, an ein vollständig von ihm kontrolliertes Objekt zu gelangen.

4. Dafür sorgen, dass der Downgrade ins Leere läuft. Ein Kerberos-Fehlschlag ist ein Resilienzproblem; ein Kerberos-Fehlschlag hinein in NTLM ist ein Sicherheitsproblem. Verlangen Sie SMB-Signierung, erzwingen Sie LDAP-Signierung und Channel-Binding, und beginnen Sie, NTLM einzuschränken, wo Sie können — der Auditpfad ist in NTLM-Relay-Angriffen behandelt, und das Verschlüsselungs-Downgrade-Gegenstück dieses Problems in Kerberos-RC4-Fallback.

5. Instrumentieren, dann verifizieren. Aktivieren Sie Audit Directory Service Changes, fügen Sie eine SACL hinzu, die Schreibvorgänge auf servicePrincipalName in Ihren Computer- und Dienstkonten-OUs auditiert, setzen Sie KdcExtraLogLevel auf 3, und planen Sie den oben genannten Sweep nach nicht-ASCII-SPNs als wiederkehrenden Job. Bestätigen Sie dann, dass die Pipeline von Ende zu Ende funktioniert, indem Sie einen harmlosen SPN auf ein Testobjekt schreiben und prüfen, ob die 5136 in Ihrem SIEM ankommt — eine Auditrichtlinie, die keine Ereignisse erzeugt, ist von einer Gesamtstruktur ohne Angriffe nicht zu unterscheiden.

6. Die benachbarte Schwachstelle prüfen. Dieselbe Semperis-Forschung deckte CVE-2026-27912 (ResetNightmare) auf, ein Problem mit userPrincipalName und der Kerberos-Passwortänderung, gepatcht am 14. April 2026. Wenn Sie erst jetzt März anwenden, wenden Sie auch erst jetzt April an. Beide sind in Semperis' Beitrag dokumentiert.

Wie EtcSec dies erkennt

Der Active-Directory-Audit von EtcSec bildet direkt die Voraussetzungen ab, die dieser Angriff benötigt, sodass Sie die Frage „Sind wir exponiert" beantworten können, ohne die obigen Abfragen selbst zu schreiben.

WRITESPN_ABUSE erfasst die Principals mit Schreibzugriff auf servicePrincipalName — die eine Berechtigung, die CVE-2026-25177 in einen forstweiten Denial of Service verwandelt. DUPLICATE_SPN und COMPUTER_DUPLICATE_SPN fördern SPN-Werte zutage, die von mehr als einem Objekt beansprucht werden — die byte-identischen Duplikate, die Kerberos brechen, egal ob ein Angreifer sie platziert hat oder eine Migration. COMPUTER_WITH_SPNS inventarisiert, welche Computerobjekte explizite SPNs tragen, wodurch sich ein Dienst, der seinen eigenen Namen verteidigt, von einem unterscheiden lässt, der vom HOST-Mapping abhängt und daher vorweggenommen werden kann. DELEGATION_UNKNOWN_TARGET markiert Konfigurationen eingeschränkter Delegation, die auf SPNs verweisen, die sich nicht sauber auflösen lassen — die Bedingung, die SPN-Jacking benötigt.

Zusammen rekonstruieren diese vier Prüfungen die Angriffsfläche: wer schreiben kann, was bereits kollidiert, welche Dienste HOST-abhängig sind, und wohin Delegation zeigt, wo sie es nicht sollte. Für die breitere Überprüfung, in die sich dies einfügt, siehe wie man die Sicherheit von Active Directory auditiert, und für das klassische SPN-Expositionsproblem Kerberoasting-Erkennung und -Prävention.

Quellen

• Microsoft Security Response Center — CVE-2026-25177, Active Directory Domain Services Elevation of Privilege Vulnerability (CVSS 3.1 8.8, CWE-641, veröffentlicht am 10. März 2026)
• Semperis — Identity Crisis: Novel Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain Takeover, Shai Laron, 5. August 2026
• Microsoft Learn — SPN and UPN uniqueness (Ereignis 2974, Fehler 8647/8648)
• Microsoft Learn — Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error
• Microsoft Learn — setspn (HOST-gemappte Dienstklassen, -X, -F, Validated-SPN-Delegation)
• Microsoft Learn — Validated-SPN validated write (Rights-GUID f3a64788-5306-11d1-a9c5-0000f80367c1)
• Microsoft Learn — SPN-Mappings attribute
• Microsoft Learn — 5136(S) A directory service object was modified
• Microsoft Learn — 4769(S, F) A Kerberos service ticket was requested (Fehlercode-Tabelle)
• Microsoft Learn — Registry entries about Kerberos protocol and KDC (KdcExtraLogLevel, Standardwert 2)
• Microsoft Learn — Azure Monitor Logs reference: SecurityEvent (Spaltenliste hinter der Sentinel-Abfrage)
• Semperis — SPN-jacking: An Edge Case in WriteSPN Abuse, Elad Shamir