Abwehr von Kerberoasting und AS-REP-Roasting

Kerberoasting braucht nichts als ein Domänenkonto. Der Angreifer listet Konten mit einem Service Principal Name auf, fordert für jedes ein Dienstticket an und knackt die Tickets offline mit Werkzeugen wie Hashcat. Der DC protokolliert ein routinemäßiges 4769-Ereignis, und sonst passiert nichts, bis das Kennwort eines Dienstkontos fällt. AS-REP-Roasting ist dieselbe Idee gegen Konten, die keine Kerberos-Vorauthentifizierung verlangen, und benötigt nicht einmal ein Domänenkonto. Beide Angriffe zielen auf von Menschen gewählte Kennwörter von Konten, die oft weit mehr Rechte besitzen, als ihren Verantwortlichen bewusst ist.

Der Leitfaden Kerberos-Härtung hat beide Angriffe vorgestellt. Dieser hier ist der operative Plan: Ihre roastbare Angriffsfläche messen, entfernen, was Sie nicht brauchen, den Rest unknackbar machen und die Versuche erkennen, die Sie nicht verhindern können.

Messen: Ihre roastbare Angriffsfläche

Auch Computerkonten haben SPNs, aber ihre Kennwörter sind zufällig und werden alle 30 Tage rotiert, sodass sie keine praktikablen Ziele sind. Das Risiko liegt bei Benutzerkonten mit SPNs. Schließen Sie krbtgt aus, das den SPN kadmin/changepw trägt, aber über eine normale Dienstticket-Anfrage nicht geroastet werden kann.

Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate, AdminCount,
                msDS-SupportedEncryptionTypes, MemberOf, Enabled |
    Where-Object { $_.SamAccountName -ne 'krbtgt' } |
    Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, AdminCount,
        @{n='EncTypes';e={$_.'msDS-SupportedEncryptionTypes'}},
        @{n='SPNs';e={$_.ServicePrincipalName -join '; '}} |
    Sort-Object PasswordLastSet

Priorisieren Sie die Ausgabe anhand von drei Fragen:

1. Ist es privilegiert? AdminCount = 1 oder die Mitgliedschaft in einer Tier-0-Gruppe bedeutet: Ein geknacktes Kennwort ist eine Domänenkompromittierung. Diese Konten kommen zuerst. Behandeln Sie sie als Tier 0, bis das Gegenteil bewiesen ist.
2. Wie alt ist das Kennwort? Ein PasswordLastSet von vor Jahren bedeutet fast immer ein kurzes, von Menschen gewähltes Kennwort und möglicherweise keine AES-Schlüssel.
3. Erlaubt es RC4? Ein leeres oder RC4 enthaltendes msDS-SupportedEncryptionTypes bedeutet, dass der KDC dafür RC4-Tickets ausstellen kann.

Beim AS-REP-Roasting ist die Exposition das Flag DONT_REQ_PREAUTH (userAccountControl-Bit 0x400000):

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, Enabled, PasswordLastSet

Vergessen Sie nicht, wer neue Exposition schaffen kann. Jeder Prinzipal mit Schreibzugriff auf servicePrincipalName eines Benutzers kann einen SPN hinzufügen und ihn roasten (sogenanntes Targeted Kerberoasting), und jeder, der userAccountControl ändern kann, kann die Vorauthentifizierung deaktivieren. Das ist ein ACL-Problem; prüfen Sie es mit ACL- und Objektsicherheit.

Warum der Verschlüsselungstyp zählt

Ein RC4-Dienstticket ist mit einem Schlüssel verschlüsselt, der schlicht der NT-Hash des Kontos ist; jeder Kennwortversuch kostet also eine MD4-Berechnung. Ein AES-Ticket verwendet einen mit PBKDF2 (4.096 Iterationen HMAC-SHA1) abgeleiteten Schlüssel, gesalzen mit Realm und Kontoname, was jeden Versuch auf derselben Hardware tausendfach teurer macht. Diese Lücke verwandelt ein Kennwort mit acht Zeichen von „in der Mittagspause geknackt“ in „den Strom nicht wert“, rettet aber kein Kennwort, das in einer Wortliste steht. Betrachten Sie AES als Multiplikator der Kennwortstärke, nicht als Ersatz dafür, und bedenken Sie, dass viele Roasting-Werkzeuge RC4 anfordern, solange das Konto es noch erlaubt.

Prüfen: pro Konto entscheiden

Wählen Sie für jedes Benutzerkonto mit SPN ein Ergebnis:

Prüfen Sie LastLogonDate und 4769-Ereignisse, um vor dem Entfernen zu bestätigen, ob ein SPN tatsächlich angefordert wird:

# Einen veralteten SPN von einem Konto entfernen
Set-ADUser -Identity 'svc-oldreport' -ServicePrincipalNames @{ Remove = 'HTTP/oldreport.corp.example.com' }

# Doppelte SPNs in der Domäne finden (Duplikate brechen auch Kerberos)
setspn -X

Durchsetzen: verbleibende Tickets unknackbar machen

Auf gMSA umstellen

Ein gMSA hat ein zufälliges Kennwort mit 120 Zeichen, das von der Domäne verwaltet und automatisch rotiert wird. Seine Tickets lassen sich weiterhin anfordern, aber ihr Knacken ist unrealistisch. SQL Server, IIS-Anwendungspools, geplante Aufgaben und die meisten Windows-Dienste unterstützen gMSAs. Die Details je Anwendung finden Sie in Dienstkonten auf gMSA migrieren.

# Nach der Migration: Das alte Konto sollte keine SPNs mehr besitzen
Get-ADUser 'svc-sql01' -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName
Get-ADServiceAccount 'gmsa-sql01' -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName

Lange Kennwörter und nur AES für den Rest

Für Konten, die Benutzerkonten bleiben müssen:

• Erzeugen Sie mit Ihrem PAM-Werkzeug oder Kennwortmanager ein zufälliges Kennwort mit mindestens 25 Zeichen und rotieren Sie es in einem Rhythmus, den die Anwendung verträgt.
• Erzwingen Sie die Länge mit einer differenzierten Kennwortrichtlinie (FGPP) für eine Gruppe ServiceAccounts, damit manuelle Rücksetzungen sie nicht unterschreiten können.
• Setzen Sie msDS-SupportedEncryptionTypes auf 24 (AES128 + AES256) und setzen Sie das Kennwort danach zurück, falls es älter als die AES-Unterstützung ist, damit AES-Schlüssel existieren.

New-ADFineGrainedPasswordPolicy -Name 'PSO-ServiceAccounts' -Precedence 10 `
    -MinPasswordLength 25 -ComplexityEnabled $true -PasswordHistoryCount 24 `
    -MaxPasswordAge '365.00:00:00' -LockoutThreshold 0
Add-ADFineGrainedPasswordPolicySubject -Identity 'PSO-ServiceAccounts' -Subjects 'ServiceAccounts'

Set-ADUser 'svc-app01' -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }

AES allein rettet kein schwaches Kennwort; es verteuert nur jeden Versuch. Länge und Zufälligkeit leisten die eigentliche Arbeit. Das domänenweite Entfernen von RC4 behandelt RC4 in Kerberos deaktivieren.

Zuerst privilegierte Dienstkonten angehen

Der schlimmste Befund in fast jedem Assessment ist ein Dienstkonto mit SPN, das zugleich Domain Admin ist – oft, weil ein Installationsprogramm das vor zehn Jahren verlangt hat. Das Knacken dieses einen Kennworts beendet den Auftrag. Entfernen Sie diese Konten vor jeder anderen Maßnahme aus privilegierten Gruppen und gewähren Sie nur die Rechte, die die Anwendung tatsächlich nutzt – meist lokale Administratorrechte auf einer Handvoll Server oder eine delegierte Berechtigung auf einer OU.

Das erfordert Verhandlungen mit Anwendungsverantwortlichen, sammeln Sie also zuerst Belege: an welchen Servern sich das Konto anmeldet (4624-Ereignisse auf diesen Servern oder LastLogonDate plus die Hostnamen der SPNs), welche geplanten Aufgaben und Dienste es nutzen und welche AD-Berechtigungen es ausübt. Wo die Anwendung ohne Rechte auf Domänenebene nicht läuft, sind das Konto und jeder Server, auf dem es läuft, Tier 0 und müssen entsprechend verwaltet werden. Beide Ergebnisse sind besser als ein roastbarer Domain Admin.

AS-REP-roastbare Konten beheben

Entfernen Sie das Flag und setzen Sie dann das Kennwort jedes Kontos zurück, das es hatte, denn seine AS-REP könnte bereits gesammelt worden sein:

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' |
    ForEach-Object { Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false }

Benötigt eine Legacy-Anwendung das Flag tatsächlich, dokumentieren Sie die Ausnahme, geben Sie dem Konto ein zufälliges Kennwort mit 25 oder mehr Zeichen und überwachen Sie es.

Erkennen, was bleibt

Überwachungsrichtlinie

Auf DCs: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon > Audit Kerberos Service Ticket Operations und Audit Kerberos Authentication Service, Erfolg und Fehler. Leiten Sie 4768 und 4769 an Ihr SIEM oder einen zentralen Collector weiter.

Erkennungslogik

• RC4-Diensttickets für Benutzerkonten: 4769 mit TicketEncryptionType 0x17, wobei der Dienst ein Benutzerkonto ist, in einer Umgebung, in der AES sonst die Norm ist. Viele Roasting-Werkzeuge fordern RC4 explizit an.
• Volumen: ein Konto, das in kurzer Zeit Diensttickets für viele verschiedene SPNs anfordert (zum Beispiel mehr als 10 innerhalb von 5 Minuten).
• AS-REP-Roasting: 4768 mit PreAuthType 0.

# Clients, die in der letzten Stunde RC4-Tickets für mehr als 10 verschiedene Dienste angefordert haben
$since = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4769; StartTime=$since } |
    ForEach-Object {
        $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        if ($d.TicketEncryptionType -eq '0x17' -and $d.ServiceName -notlike '*$') {
            [pscustomobject]@{ Client = $d.TargetUserName; Service = $d.ServiceName }
        }
    } | Group-Object Client | Where-Object { ($_.Group.Service | Sort-Object -Unique).Count -gt 10 }

Feinabstimmung

Rechnen Sie am ersten Tag mit etwas Rauschen. Schwachstellenscanner, Identity-Governance-Werkzeuge und manche Monitoringprodukte zählen SPNs auf und fordern massenhaft Tickets an, und ältere Clients handeln legitimerweise RC4 gegen Konten aus, die es noch erlauben. Erstellen Sie eine Allowlist bekannter Scanner-Quelladressen und Dienstidentitäten und überprüfen Sie sie vierteljährlich. Das RC4-Signal wird deutlich schärfer, sobald Dienstkonten nur noch AES zulassen: Danach ist jedes RC4-Ticket für ein benutzerbasiertes Dienstkonto entweder ein nicht behobener Legacy-Client oder ein Roasting-Werkzeug, das absichtlich den schwächeren Verschlüsselungstyp anfordert.

Honey-SPN

Erstellen Sie ein Honeytoken: ein Benutzerkonto mit realistischem Namen und SPN, einem langen Zufallskennwort, ohne Anmeldeaktivität und ohne echten Dienst dahinter. Jedes 4769 dafür ist ein Alarm. Designdetails finden Sie in Honeytokens und Täuschung.

New-ADUser -Name 'svc-sqlbackup-legacy' -SamAccountName 'svc-sqlbackup-legacy' `
    -Path 'OU=ServiceAccounts,DC=corp,DC=example,DC=com' -Enabled $true `
    -AccountPassword (Read-Host -AsSecureString 'Random 30+ char password') `
    -ServicePrincipalNames 'MSSQLSvc/sqlbackup01.corp.example.com:1433'

Überprüfen

• Die SPN-Inventurabfrage liefert nur gMSAs, Computerkonten und eine kurze, dokumentierte Liste von Benutzerkonten, jedes mit einem Kennwort, das jünger ist als Ihr Rotationsintervall, und msDS-SupportedEncryptionTypes auf 24.
• Die Abfrage auf DoesNotRequirePreAuth liefert nichts oder nur dokumentierte Ausnahmen.
• Kein Benutzerkonto mit SPN ist Mitglied einer privilegierten Gruppe.
• Eine Testticket-Anfrage für den Honey-SPN (klist get MSSQLSvc/sqlbackup01.corp.example.com:1433 von einem Admin-Arbeitsplatz, dem SOC vorher angekündigt) löst einen Alarm aus.

Was dabei bricht

• Das Entfernen noch genutzter SPNs bricht Kerberos zu diesem Dienst; Clients fallen, wo erlaubt, auf NTLM zurück oder scheitern. Prüfen Sie vor dem Entfernen den 4769-Verlauf.
• Kennwortrücksetzungen bei Legacy-Dienstkonten brechen jede Stelle, an der das alte Kennwort fest hinterlegt ist: Dienste, geplante Aufgaben, Anwendungskonfigurationsdateien, Skripte auf anderen Servern.
• Nur AES auf Dienstkonten bricht Clients und Keytabs, die nur RC4 unterstützen, insbesondere alte Java- und Linux-Integrationen.
• Die gMSA-Migration funktioniert nicht für Anwendungen, die das Kennwort im Klartext benötigen, oder für Dienste auf Hosts außerhalb der Domäne.
• Das Entfernen von DONT_REQ_PREAUTH kann die seltene Legacy-Unix- oder Appliance-Integration brechen, die darauf angewiesen war.

Weiterführende Lektüre: der Bereich Kerberos & Authentifizierung und Dienstkonten mit gMSA und LAPS härten für das umfassendere Dienstkontenprogramm.