Kerberos-Härtung: RC4, Roasting und Golden Tickets

Kerberos ist das Rückgrat der AD-Authentifizierung, und seine offline knackbaren Ticketformate machen es zu einem beliebten Ziel: Kerberoasting und AS-REP-Roasting verwandeln jeden Angreifer mit Domänenzugang in einen Kennwortknacker, der gegen die Antworten Ihrer eigenen DCs arbeitet, während Golden und Silver Tickets einem Angreifer, der krbtgt oder ein Dienstkonto bereits kompromittiert hat, das unbegrenzte Fälschen von Authentifizierungen erlauben. Nichts davon erfordert eine Schwachstelle – es funktioniert gegen Kerberos genau wie vorgesehen, wenn Verschlüsselungstypen und Kontoeinstellungen auf Legacy-Standards bleiben.

Dieser Leitfaden behandelt die Verschlüsselungshärtung, Vorauthentifizierung und SPN-Hygiene, das Verfahren zur doppelten krbtgt-Rücksetzung, Kerberos Armoring sowie die Überwachung auf Ticketfälschung.

AES erzwingen, RC4 deaktivieren

Jedes Konto (Benutzer, Computer und Dienst) besitzt ein Attribut msDS-SupportedEncryptionTypes, das festlegt, welche Kerberos-Verschlüsselungstypen es akzeptiert. Legacy-Standards erlauben oft noch RC4-HMAC, das offline weitaus leichter zu knacken ist als AES-256.

Aktuellen Zustand domänenweit prüfen

# Konten, die noch RC4 erlauben oder bei denen der Wert nicht gesetzt ist (dann gilt der KDC-Standard, der RC4 weiterhin enthält)
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 -or -not $_."msDS-SupportedEncryptionTypes" } |
    Select-Object Name, msDS-SupportedEncryptionTypes

Bitwerte der Verschlüsselungstypen: 1 = DES-CBC-CRC, 2 = DES-CBC-MD5, 4 = RC4-HMAC, 8 = AES128, 16 = AES256. Ein Wert von 24 bedeutet nur AES128+AES256 (kein RC4/DES) – das ist der Zielzustand.

Per GPO erzwingen

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos (Netzwerksicherheit: Für Kerberos zulässige Verschlüsselungstypen konfigurieren)

Aktivieren Sie nur AES128_HMAC_SHA1 und AES256_HMAC_SHA1 (sowie Future encryption types, falls angeboten). Lassen Sie DES und RC4_HMAC_MD5 deaktiviert.

Pro Konto per PowerShell setzen

# Nur AES (Wert 24) auf einem bestimmten Dienstkonto setzen
Set-ADUser -Identity "svc-sqlreporting" -Replace @{"msDS-SupportedEncryptionTypes" = 24}

# Alle Benutzerkonten, die noch RC4 erlauben, in einem Durchgang korrigieren
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 } |
    ForEach-Object { Set-ADUser -Identity $_ -Replace @{"msDS-SupportedEncryptionTypes" = 24} }

Überprüfen

# Bestätigen, dass kein Konto mehr RC4 anbietet
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 }
# Sollte nichts zurückgeben

# Tatsächlich verwendete Ticketverschlüsselung über das Sicherheitsprotokoll der DCs prüfen
# Ereignis-ID 4768 (TGT-Anfrage) / 4769 (Dienstticket-Anfrage) – Feld "Ticket Encryption Type"
# 0x12 = AES256, 0x17 = RC4
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 200 |
    ForEach-Object { [xml]$_.ToXml() } |
    ForEach-Object { $_.Event.EventData.Data | Where-Object Name -eq 'TicketEncryptionType' } |
    Group-Object '#text'

Jeder Eintrag mit 0x17 (RC4) nach der Erzwingung weist auf einen Client oder Dienst hin, der noch herunterverhandelt – untersuchen Sie das, bevor Sie annehmen, dass RC4 vollständig beseitigt ist.

Vorauthentifizierung und AS-REP-Roasting

Die Kerberos-Vorauthentifizierung verlangt, dass ein Client einen Zeitstempel mit seinem aus dem Kennwort abgeleiteten Schlüssel verschlüsselt, bevor der KDC ein TGT ausstellt – ein Nachweis der Kennwortkenntnis, bevor irgendwelches Ticketmaterial herausgegeben wird. Das Kontoflag DONT_REQ_PREAUTH deaktiviert das, sodass jeder ohne Anmeldeinformationen eine AS-REP für dieses Konto anfordern und das zurückgegebene Ticket offline gegen das Kennwort des Kontos knacken kann. Den konzeptionellen Angriffspfad beschreibt AS-REP-Roasting.

# Konten mit deaktivierter Vorauthentifizierung finden
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol |
    Select-Object Name, SamAccountName

# Beheben: Flag DONT_REQ_PREAUTH entfernen
Set-ADAccountControl -Identity "jsmith" -DoesNotRequirePreAuth $false

Außerhalb bestimmter Legacy-Interoperabilitätsfälle gibt es selten einen legitimen Grund für dieses Flag – behandeln Sie jeden Treffer als Befund.

Kerberoasting-Risiko durch SPNs auf Benutzerkonten

Kerberoasting erfordert kein fehlkonfiguriertes Kontoflag: Jeder authentifizierte Benutzer kann für jedes Konto mit Service Principal Name (SPN) ein Dienstticket anfordern und versuchen, es offline zu knacken. Das Risiko konzentriert sich auf Benutzerkonten, die als Dienstkonten dienen, denn diese haben meist von Menschen gewählte (schwächere, wiederverwendete) Kennwörter – anders als Computerkonten, deren lange Zufallskennwörter automatisch rotiert werden. Siehe Kerberoasting.

# Benutzerkonten (keine Computerkonten) mit gesetztem SPN finden
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName, PasswordLastSet |
    Select-Object Name, ServicePrincipalName, PasswordLastSet

Gegenmaßnahmen, nach Wirksamkeit geordnet:

1. Migrieren Sie Dienstkonten auf Group Managed Service Accounts (gMSAs) – zufällige Kennwörter mit 240 Byte (120 Zeichen), automatisch rotiert und praktisch immun gegen Offline-Knacken.
2. Wo gMSAs nicht unterstützt werden, verwenden Sie lange (25+ Zeichen), zufällig generierte Kennwörter, die in einem Kennworttresor liegen und nie auswendig gelernt werden.
3. Stellen Sie sicher, dass msDS-SupportedEncryptionTypes für jedes Konto mit SPN nur AES erlaubt – AES-256-Tickets sind drastisch aufwendiger zu knacken als RC4.
4. Nehmen Sie hochwertige SPN-Konten, wo kompatibel, in Protected Users auf (siehe Tier 0 & privilegierter Zugriff).

Das Verfahren zur doppelten krbtgt-Rücksetzung

Aus dem Kennwort des Kontos krbtgt wird der Schlüssel abgeleitet, mit dem jedes Kerberos-TGT der Domäne signiert wird. Wird es jemals kompromittiert – direkt oder über eine Extraktion im Stil von DCSync –, kann ein Angreifer TGTs (Golden Tickets) für jeden Benutzer fälschen, auch für solche, die in AD gar nicht existieren, und diese bleiben gültig, bis Sie den Schlüssel rotieren. Siehe DCSync.

Warum zwei Rücksetzungen mit Abstand: AD hält sowohl den aktuellen als auch den vorherigen krbtgt-Kennworthash gültig. Eine einzelne Rücksetzung macht mit dem alten Hash gefälschte Tickets also nicht sofort ungültig – der DC akzeptiert sie weiterhin über den Rückgriff auf das „vorherige Kennwort“. Sie müssen zweimal zurücksetzen, mit einem Abstand von mindestens der maximalen Kerberos-Ticketlebensdauer (Standard MaxTicketAge = 10 Stunden; prüfen Sie die tatsächliche MaxTicketAge/MaxRenewAge-Richtlinie Ihrer Domäne, die auf Tage verlängert sein kann), damit das erste neue Kennwort vollständig aus beiden Slots rotiert ist, bevor die zweite Rücksetzung erfolgt.

# Zuerst die aktuelle Ticketlebensdauer-Richtlinie prüfen – sie bestimmt den Abstand der Rücksetzungen
# Die Kerberos-Richtlinie ist kein AD-Attribut; sie liegt in der GPO Default Domain Policy:
# Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy
[xml]$r = Get-GPOReport -Name "Default Domain Policy" -ReportType Xml
$r.GPO.Computer.ExtensionData.Extension.Account | Where-Object Type -eq 'Kerberos' | Select-Object Name, SettingNumber

# Rücksetzung 1
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<generate-random>" -Force)

# --- mindestens MaxTicketAge warten (häufig 10 Stunden; Wert Ihrer Domäne bestätigen) ---

# Rücksetzung 2
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<generate-random-2>" -Force)

Verwenden Sie in Umgebungen mit mehreren DCs das von Microsoft veröffentlichte Skript New-KrbtgtKeys.ps1 (oder gleichwertige geprüfte Werkzeuge) statt Ad-hoc-Rücksetzungen – es prüft zwischen den beiden Rücksetzungen die Replikationskonvergenz, damit Sie nicht rotieren, bevor alle DCs die erste Änderung erhalten haben. Wiederholen Sie das in einer Gesamtstruktur mit mehreren Domänen für das krbtgt-Konto jeder Domäne, nicht nur für die Stammdomäne.

Führen Sie diese Rotation nach festem Zeitplan durch (viele Organisationen tun das vierteljährlich oder nach jedem Verdacht auf kompromittierte Anmeldeinformationen), nicht nur als Incident Response.

Kerberos Armoring / FAST

FAST (Flexible Authentication Secure Tunneling), aktiviert über Kerberos Armoring, kapselt den initialen AS-REQ-Austausch in einem verschlüsselten, authentifizierten Kanal, der die Anmeldeinformationen des anfragenden Computers nutzt. Das schützt die Vorauthentifizierungsdaten und verringert die Angriffsfläche für Offline-Angriffe gegen schwache Benutzerkennwörter.

Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring (unter Windows Server 2012 als Support Dynamic Access Control and Kerberos armoring bezeichnet) – setzen Sie dies auf den DCs zuerst auf Supported und erst dann auf Fail unarmored authentication requests, wenn alle DCs und Clients es unterstützen. Auf Clients: Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring.

Voraussetzung sind die Domänenfunktionsebene 2012 oder höher sowie aktualisierte DCs, bevor Sie erzwingen.

Golden und Silver Tickets: wie die Maßnahmen zusammenwirken

Ein Golden Ticket fälscht ein TGT mit einem gestohlenen krbtgt-Hash; ein Silver Ticket fälscht ein Dienstticket mit einem gestohlenen Dienstkontohash, ohne den KDC überhaupt zu berühren. Keines davon ist eine Schwachstelle, die man „patchen“ kann – es ist Missbrauch des legitimen Kerberos-Vertrauens, sobald ein Schlüssel gestohlen wurde. Die Abwehr ist mehrschichtig:

• Nur AES + Protected Users für Tier-0- und Dienstkonten macht die Hashes selbst schwerer zu erlangen und nach einer Exfiltration schwerer zu knacken.
• krbtgt-Rotation (siehe oben) macht zuvor gefälschte Golden Tickets ungültig und begrenzt den künftigen Wert eines gestohlenen Hashs.
• Überwachung auf Anomalien: TGTs mit ungewöhnlich langer Lebensdauer, Tickets für nicht existierende Konten oder Muster der Ereignisse 4624/4768, die nicht zu den üblichen Anmeldequellen passen.

# Ein gefälschtes Golden Ticket erzeugt nie ein 4768, daher sind 4769-Ereignisse eines Kontos ohne
# passendes 4768 auf irgendeinem DC die gesuchte Anomalie. Auf allen DCs ausführen (oder im SIEM abfragen),
# über ein Zeitfenster länger als die TGT-Lebensdauer (standardmäßig 10 h): ein einzelner DC liefert Fehlalarme.
$since  = (Get-Date).AddHours(-12)
$events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769; StartTime=$since} |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        [pscustomobject]@{
            Id      = $_.Id
            # 4769 protokolliert user@REALM, 4768 nur den Namen: vor dem Vergleich normalisieren
            Account = (($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text' -split '@')[0]
        }
    }
$withTgt = $events | Where-Object Id -eq 4768 | Select-Object -ExpandProperty Account -Unique
$events | Where-Object { $_.Id -eq 4769 -and $_.Account -notin $withTgt } |
    Group-Object Account | Sort-Object Count -Descending | Select-Object Name, Count

Was dabei bricht

• Legacy-Anwendungen und Netzwerkgeräte (ältere NAS-Geräte, manche Backupsoftware, ältere Linux-/Java-Kerberos-Clients, bestimmte SCADA-/Industriesysteme), die nur RC4 unterstützen, scheitern bei der Authentifizierung, sobald RC4 domänenweit deaktiviert ist. Werten Sie vor der Erzwingung 90 Tage lang TicketEncryptionType in Ereignis 4769 aus, um diese zu finden.
• Dateifreigaben von Drittanbietern oder auf Basis älterer Samba-Versionen unterstützen AES256 möglicherweise nicht ohne Weiteres – prüfen Sie das vor der Umstellung.
• Die doppelte krbtgt-Rücksetzung hat bei korrektem Abstand kaum sichtbare Auswirkungen, weil der DC mit dem vorherigen Schlüssel signierte TGTs weiterhin akzeptiert. Zwei Rücksetzungen kurz hintereinander (der Incident-Response-Fall) oder eine zweite Rücksetzung, bevor die erste repliziert ist, machen jedes ausstehende TGT dieser Domäne ungültig und zwingen Benutzer und Dienste zur erneuten Authentifizierung – planen Sie ein Zeitfenster mit geringer Auswirkung ein und rechnen Sie mit einer Welle erneuter Anmeldungen.
• Die Erzwingung von Kerberos Armoring setzt voraus, dass jedes DC- und Client-Betriebssystem FAST unterstützt; gemischte Umgebungen mit Legacy-DCs brechen bei der Authentifizierung, wenn vorzeitig „Fail unarmored authentication requests“ gesetzt wird.

Weiterführende Lektüre: Tier 0 & privilegierter Zugriff für Schutzmaßnahmen auf Kontoebene, Delegierung dazu, wie gefälschte Tickets mit Delegierungsmissbrauch zusammenwirken, und NTLM & Legacy-Protokolle für die Authentifizierungsschicht, die Kerberos ersetzen soll.