krbtgt-Kennwort nach einem Golden-Ticket-Angriff richtig zurücksetzen

Dienstagmorgen, 8 Uhr: Der Incident Responder meldet, dass der Angreifer Domain-Admin-Rechte hatte. Alle Admin-Kennwörter sind seit gestern Abend neu, die verdächtigen Konten deaktiviert. Und trotzdem bleibt der Zugriff. Willkommen beim Golden Ticket – und bei dem einen Konto, das jetzt zweimal zurückgesetzt werden muss: krbtgt.

Warum ein neues Admin-Kennwort nichts bringt

krbtgt ist das Dienstkonto des Key Distribution Center (KDC) auf jedem Domain Controller. Aus seinem Kennwort leitet der KDC den Schlüssel ab, mit dem er jedes Ticket Granting Ticket (TGT) verschlüsselt. Microsoft beschreibt es als den Schlüssel, an dem das gesamte Vertrauen in Kerberos hängt.

Wer Domain-Admin war, kommt an diesen Schlüssel heran und kann sich damit selbst TGTs ausstellen – für jedes Konto, mit jeder Gruppenmitgliedschaft. Das ist ein Golden Ticket. Es hängt nicht am Kennwort eines Benutzers. Deshalb läuft es weiter, egal wie oft man die Admin-Kennwörter ändert.

Warum zweimal?

Das krbtgt-Konto hat eine Kennworthistorie von 2. Es kennt immer das aktuelle Kennwort (n) und das vorherige (n-1), und Tickets mit beiden Schlüsseln gelten. Ein Reset schiebt den Schlüssel des Angreifers nur auf n-1. Erst der zweite Reset wirft ihn raus.

Warum mit Abstand?

Zwischen beiden Resets müssen die legitimen Tickets, die noch mit dem alten Schlüssel ausgestellt wurden, ablaufen. Microsoft schreibt im Leitfaden zur Gesamtstruktur-Wiederherstellung mindestens 10 Stunden vor. Das ist der Standardwert für „Maximale Gültigkeitsdauer des Benutzertickets“ und „des Diensttickets“ (600 Minuten). Wurden diese Werte in der Kerberos-Richtlinie geändert, muss die Wartezeit größer sein als der konfigurierte Wert. Dazu kommt die Zeit, bis der erste Reset auf allen DCs angekommen ist.

Diagnose und Vorbereitung

Ein krbtgt-Reset betrifft die ganze Domäne. Bevor er beginnt, muss die Replikation gesund sein und der Ausgangszustand dokumentiert.

1. Replikation prüfen

repadmin /replsummary zeigt DCs, bei denen die Replikation fehlschlägt. Meldet repadmin Fehler, wird nicht zurückgesetzt. Offline-DCs, die nie sauber entfernt wurden, vorher per Metadatenbereinigung aus dem Verzeichnis werfen.

repadmin /replsummary
repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView

2. Letzte Kennwortänderung auslesen

Bei vielen Domänen steht hier ein Datum aus dem Gründungsjahr. Defender for Identity meldet krbtgt-Konten, deren Kennwort älter als 180 Tage ist.

Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object Name, PasswordLastSet
Get-ADUser -Filter 'Name -like "krbtgt_*"' -Properties PasswordLastSet |
  Select-Object Name, PasswordLastSet

3. Ereignisse

Auf den DCs protokollieren 4768 (TGT angefordert) und 4769 (Dienstticket angefordert) den Kerberos-Verkehr. Microsoft empfiehlt unter anderem, Verschlüsselungstypen ungleich 0x11 und 0x12 (AES) zu überwachen. Einen eindeutigen Golden-Ticket-Nachweis liefern sie allein nicht. Nach jedem Reset muss im System-Protokoll Ereignis 9 der Quelle Key-Distribution-Center erscheinen.

Get-WinEvent -FilterHashtable @{LogName='System'; Id=9} |
  Where-Object ProviderName -like '*Key-Distribution-Center*' |
  Select-Object TimeCreated, MachineName, Message | Format-List

Behebung: zweimal, mit Abstand

Zuerst wird dem Angreifer der Zugang entzogen: kompromittierte Konten deaktivieren, privilegierte Kennwörter ändern, Persistenz wie geplante Aufgaben, Dienste, GPOs und neue Konten entfernen. Erst dann folgt der Reset.

Methode A – Microsoft-Skript New-KrbtgtKeys.ps1

Microsoft hat für den Reset ein PowerShell-Skript veröffentlicht. Es liegt heute im archivierten GitHub-Repository microsoftarchive/New-KrbtgtKeys.ps1 – seit März 2024 schreibgeschützt, die Entwicklung ist eingestellt. Ältere Fassungen scheitern an Offline-DCs, die noch im Verzeichnis stehen. Laut CISA laufen beschreibbare DCs und RODCs in getrennten Durchläufen. Wer das Skript nutzt, liest es vorher vollständig und testet es im Labor.

Methode B – manuell

Das ist der Weg, den Microsoft im Leitfaden selbst beschreibt: in „Active Directory-Benutzer und -Computer“ mit eingeschalteten erweiterten Features auf krbtgt „Kennwort zurücksetzen“. Das eingegebene Kennwort ist laut Microsoft nicht maßgeblich, das System erzeugt selbst ein starkes. Per PowerShell geht es so:

1. Ersten Reset auf einem festen DC ausführen, z. B. dem PDC-Emulator.
2. Prüfen, ob der neue Zeitstempel auf allen beschreibbaren DCs angekommen ist und Ereignis 9 vorliegt.
3. Mindestens 10 Stunden warten, bei geänderter Kerberos-Richtlinie länger.
4. Zweiten Reset ausführen und genauso prüfen.

# 1. und 4. Reset
$dc = (Get-ADDomain).PDCEmulator
$pw = -join ((33..126) | Get-Random -Count 32 | ForEach-Object { [char]$_ })
Set-ADAccountPassword -Identity krbtgt -Server $dc -Reset `
  -NewPassword (ConvertTo-SecureString $pw -AsPlainText -Force)
Remove-Variable pw

# 2. Replikation prüfen
Get-ADDomainController -Filter {IsReadOnly -eq $false} | ForEach-Object {
  $u = Get-ADUser krbtgt -Server $_.HostName -Properties PasswordLastSet
  [pscustomobject]@{ DC = $_.HostName; PasswordLastSet = $u.PasswordLastSet }
} | Format-Table -AutoSize
repadmin /replsummary

Nach dem zweiten Reset

Alle bereits ausgestellten TGTs werden abgelehnt. Bestehende Sitzungen zu Ressourcen halten, bis das Dienstticket erneuert werden muss, NTLM-Verbindungen sind nicht betroffen. Microsoft sagt klar: Man muss davon ausgehen, dass alle Computer und Benutzer betroffen sein können, und ein Neustart ist der einzige zuverlässige Weg, die Funktion wiederherzustellen. Server mit langlaufenden Diensten unter Domänenkonten also einplanen.

Fallstricke

Vorbeugen und Compliance

• krbtgt wie jedes privilegierte Dienstkonto in festem Rhythmus zurücksetzen – das empfiehlt Microsoft ausdrücklich
• Den zweifachen Reset mit Wartezeit in ruhigen Zeiten üben, damit er im Notfall Routine ist
• Replikation automatisiert überwachen und Offline-DCs sauber entfernen
• Domain-Admin-Konten nur auf DCs und Admin-Arbeitsplätzen einsetzen (Tier-Modell)
• Ereignisse 4768 und 4769 zentral sammeln und Verschlüsselungstypen ungleich AES auswerten
• Den Notfallablauf schriftlich festhalten

Wurde krbtgt noch nie zurückgesetzt, kann das Konto laut CISA noch alte Verfahren wie DES oder RC4 verwenden. Eine Rotation in ruhigen Zeiten deckt das auf, bevor es im Ernstfall Probleme macht.

Das zahlt auf die Anforderungen ein: BSI IT-Grundschutz APP.2.2 (Active Directory Domain Services), ORP.4 (Identitäts- und Berechtigungsmanagement), DER.2.1 (Behandlung von Sicherheitsvorfällen) sowie NIS2 Art. 21 Abs. 2 lit. b (Bewältigung von Sicherheitsvorfällen).

Fazit

Nach einem Golden-Ticket-Angriff ist krbtgt der eine Schlüssel, der zählt. Zweimal, mit Abstand, nach geprüfter Replikation und erst, wenn der Angreifer draußen ist. Die reine Arbeit dauert zwei bis vier Stunden – die Wartezeit dazwischen ist kein Leerlauf, sondern der Teil, der den Betrieb am Laufen hält.

Quellen: Microsoft Learn – „Active Directory Forest Recovery – Reset the krbtgt password“; Microsoft Learn – „Active Directory accounts“ (KRBTGT account); Microsoft Learn – „Maximum lifetime for user ticket“; Microsoft Learn – „Set-ADAccountPassword“; Microsoft Learn – „4768(S, F)“ und „4769(S, F)“; Microsoft Learn – „Change password for krbtgt account“ (Defender for Identity); GitHub – microsoftarchive/New-KrbtgtKeys.ps1; CISA – „Reset KRBTGT Password Twice“ (CM0050).