AS-REP Roasting — Erkennung & Behebung

Was ist AS-REP Roasting?

AS-REP Roasting ist ein Active-Directory-Angriff auf Konten, bei denen die Kerberos-Vorauthentifizierung deaktiviert ist.

Wenn das Flag DONT_REQ_PREAUTH für ein Benutzer- oder Dienstkonto gesetzt ist, kann das KDC eine AS-REP zurückgeben, ohne vorher den Nachweis zu verlangen, dass der Anfragende das Passwort kennt. Ein Angreifer, der einen gültigen Kontonamen kennt oder errät, kann diese Antwort anfordern, den verschlüsselten Teil extrahieren und anschließend offline knacken.

Genau das macht die Einstellung gefährlich: Ein Domain-Konto wird dadurch schon vor erfolgreicher Authentifizierung zum Offline-Passwortziel.

Der operative Unterschied zu Kerberoasting ist wichtig:

Kerberoasting benötigt eine gültige Domain-Identität, um Service Tickets anzufordern.
AS-REP Roasting benötigt keine gültigen Anmeldedaten, um für einen bekannten Kontonamen eine AS-REP anzufordern.

Das bedeutet aber nicht, dass anonyme LDAP-Aufzählung standardmäßig offen ist. Microsoft deaktiviert anonyme LDAP-Operationen auf Active-Directory-Domain-Controllern seit Windows Server 2003 standardmäßig, abgesehen von begrenzten Vorgängen wie rootDSE und Bind. Die Entdeckung von Benutzernamen ist also ein eigenes Problem und nicht mit der AS-REP-Sammlung identisch.

Wie sich der Kerberos-Ablauf verändert

In einem normalen Kerberos-AS-Austausch sendet der Client eine AS-REQ mit Vorauthentifizierungsdaten, typischerweise einem verschlüsselten Zeitstempel. Damit weist er gegenüber dem KDC nach, dass er das Passwort des Kontos kennt.

Ist DONT_REQ_PREAUTH gesetzt, überspringt das KDC diese Prüfung und liefert sofort eine AS-REP zurück. Der verschlüsselte Teil dieser Antwort ist mit dem langfristigen Kerberos-Schlüssel des Kontos geschützt, der aus dem Passwort abgeleitet wird.

Für technische Leser sind zwei Punkte entscheidend:

der Angriff funktioniert, weil die verschlüsselte Antwort vor erfolgreicher Authentifizierung ausgeliefert wird
diese Antwort eignet sich für Offline-Cracking, sodass Passwortlänge und Passwortqualität den Schaden direkt beeinflussen

Man sollte nicht annehmen, dass jedes roastbare Konto denselben Verschlüsselungstyp zurückgibt. In modernen Windows-Umgebungen sind oft AES-Typen zu erwarten, in älteren Umgebungen findet man weiterhin RC4. Das saubere Modell ist daher nicht „RC4 standardmäßig“, sondern „das zurückgegebene Material hängt von Kerberos-Konfiguration und unterstützten Verschlüsselungstypen in dieser Umgebung ab“.

Was ein Angreifer wirklich braucht

Für einen erfolgreichen AS-REP-Roasting-Versuch reichen drei Dinge:

Netzwerkzugriff auf einen Domain Controller, der Kerberos-AS-Anfragen beantwortet.
Kandidaten für Benutzernamen.
Mindestens ein Konto mit aktiviertem DONT_REQ_PREAUTH.

Genau deshalb ist die Technik attraktiv. Der Angreifer muss nicht erst eine Windows-Sitzung kompromittieren oder ein erstes Konto stehlen, bevor die Sammlung beginnt.

In der Praxis stammen Benutzernamen meist aus:

E-Mail-Namenskonventionen oder öffentlichen Verzeichnissen
einem bereits bestehenden Low-Privilege-Fußabdruck in der Domain
alten Exporten, Skripten oder Inventardateien
authentifizierter AD-Aufzählung durch ein gewöhnliches Domain-Konto

Anonymes LDAP ist damit ein zusätzlicher Fehler, aber keine Voraussetzung des Angriffs.

Welche Konten zuerst priorisiert werden sollten

In der Praxis sind nicht alle roastbaren Konten gleich riskant. Zuerst sollten Konten untersucht werden, die mindestens eines der folgenden Merkmale erfüllen:

Dienstkonten mit breiter Nutzung auf mehreren Servern
Konten mit alten oder nie rotierten Passwörtern
Konten mit privilegierten Gruppenmitgliedschaften oder weitreichenden lokalen Rechten
Identitäten, die in Skripten, geplanten Aufgaben oder Anwendungen weiterverwendet werden

Diese Priorisierung ist wichtig, weil AS-REP Roasting selten wegen des Flags allein kritisch wird. Kritisch wird es, wenn das exponierte Konto gleichzeitig operative Reichweite und ein schwaches Passwortprofil besitzt.

Die Angriffskette

Schritt 1 - Roastbare Konten identifizieren

Mit authentifiziertem Zugriff lässt sich das direkt in AD abfragen:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Ohne Anmeldedaten kann ein Angreifer dennoch bekannte Kontonamen testen, indem er AS-Anfragen sendet und prüft, welche Konten verwertbares Material zurückgeben.

Schritt 2 - AS-REP-Antworten anfordern

# AS-REP-Material für bekannte Benutzernamen anfordern
impacket-GetNPUsers corp.local/ -usersfile users.txt -no-pass -dc-ip 10.10.0.1

Mit einem gültigen Domain-Konto ist die Aufzählung noch direkter:

impacket-GetNPUsers corp.local/user:password -request -dc-ip 10.10.0.1

Auf einem Windows-System liefert Rubeus dasselbe Ergebnis:

.\Rubeus.exe asreproast /format:hashcat /outfile:asrep_hashes.txt

Schritt 3 - Offline knacken

Ab diesem Punkt spielt der Domain Controller keine Rolle mehr. Die Passwortversuche laufen offline in der Geschwindigkeit des Angreifers.

Darum sind alte Dienstkontopasswörter, menschlich gebildete Kennwörter und nie ablaufende Passwörter in diesem Szenario besonders gefährlich.

Schritt 4 - Das wiedergewonnene Konto nutzen

Wird das Passwort wiederhergestellt, kann das Konto wie jede andere kompromittierte Identität verwendet werden:

interaktive Anmeldung, sofern erlaubt
LDAP- und PowerShell-Aufklärung
laterale Bewegung auf Systeme mit lokalen oder delegierten Rechten
Eskalation, wenn das Konto mit privilegierten Gruppen, Diensten, Aufgaben oder Anwendungen verknüpft ist

Eine einzige Ausnahme für eine Legacy-Anwendung kann damit der erste Schritt in einem deutlich größeren Identitätspfad werden.

Erkennung

Der wichtigste Erkennungspunkt bleibt der Domain Controller.

Event 4768 ist das zentrale Signal

Die Microsoft-Dokumentation zu Event ID 4768 macht zwei Felder besonders nützlich:

Pre-Authentication Type = 0 bedeutet, dass die TGT-Anfrage ohne Kerberos-Vorauthentifizierung stattfand.
Ticket Encryption Type zeigt, welcher Kerberos-Verschlüsselungstyp tatsächlich verwendet wurde.

Für AS-REP Roasting ist deshalb das wichtigste Signal ein 4768 mit Pre-Authentication Type 0.

Praktische Hunting-Muster

Starten Sie mit diesen Fällen:

wiederholte 4768-Ereignisse mit Pre-Authentication Type = 0
Bursts von Anfragen aus derselben Quelle gegen mehrere Konten
Anfragen für Dienst- oder Admin-Konten, die nie interaktiv genutzt werden sollten
Spitzen bei 4768 Result Code 0x6, die auf Benutzernamensraten vor erfolgreichen Anfragen hinweisen können
Kontoänderungen, die DONT_REQ_PREAUTH aktivieren, besonders bei Dienst- oder privilegierten Konten

Beispiel für eine SIEM-Abfrage

event.code: "4768" AND
winlog.event_data.PreAuthType: "0" AND
winlog.event_data.Status: "0x0"

Wenn Verzeichnisänderungen auditiert werden, sollten zusätzlich die Änderungen geprüft werden, die das relevante userAccountControl-Bit setzen. Genau dort lässt sich die gefährliche Ausnahme oft vor der Ausnutzung entdecken.

Behebung

1. Unnötige Pre-Auth-Ausnahmen entfernen

Set-ADAccountControl -Identity vulnerable_user -DoesNotRequirePreAuth $false

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

Das ist die primäre Korrektur. Wenn ein Konto die Ausnahme nicht technisch begründen kann, sollte sie nicht gesetzt bleiben.

2. Passwörter nach der Korrektur rotieren

Es reicht nicht, die Vorauthentifizierung wieder einzuschalten. Wenn das Konto roastbar war, muss man davon ausgehen, dass das Material bereits gesammelt wurde.

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
    Set-ADUser -ChangePasswordAtLogon $true

Bei Dienstkonten ist eine echte Geheimnisrotation nötig, nicht nur eine Flag-Änderung.

3. Legacy-Abhängigkeiten technisch überprüfen

Wenn ein Team behauptet, dass Pre-Auth deaktiviert bleiben muss, ist eine technische Review erforderlich:

welches System wirklich davon abhängt
ob dieses System modernisiert oder isoliert werden kann
ob das Konto auf Minimalrechte reduziert werden kann
ob interaktive Anmeldung, Delegation oder breite Gruppenmitgliedschaften entfernt werden können

Eine Pre-Auth-Ausnahme auf einem privilegierten oder breit verwendeten Konto ist kein kleiner Kompatibilitätskompromiss, sondern eine Offline-Passwort-Exposition.

4. Konten härten, die vorübergehend in Ausnahme bleiben müssen

Wenn eine Ausnahme temporär bestehen bleibt:

ein langes zufälliges Passwort erzwingen
privilegierte Gruppenmitgliedschaften soweit möglich entfernen
Logon-Rechte einschränken
Event 4768 für dieses Konto gezielt überwachen
Verantwortlichen und Review-Datum festlegen

5. Nicht auf Geheimhaltung von Benutzernamen vertrauen

Selbst wenn anonymes LDAP deaktiviert ist, sollte man davon ausgehen, dass Angreifer dennoch Benutzernamenlisten aufbauen können. Der nachhaltige Schutz besteht darin, roastbare Konten zu entfernen und den Wert unvermeidbarer Ausnahmen zu senken.

Validierung nach dem Fix

Eine saubere Abschlussprüfung für AS-REP Roasting besteht aus vier Punkten:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} liefert nur noch dokumentierte Ausnahmen.
Die Passwörter der zuvor exponierten Konten wurden rotiert.
4768 mit Pre-Authentication Type = 0 taucht für normale Benutzer- und Dienstkonten nicht mehr auf.
Jede verbleibende Ausnahme hat einen Verantwortlichen, eine geschäftliche Begründung, kompensierende Kontrollen und ein Review-Datum.

Wenn diese vier Punkte nicht belegt werden können, ist das Thema nicht wirklich geschlossen.

Welche Zusatzprüfung sich besonders lohnt

Für verbleibende Ausnahmen sollte zusätzlich geprüft werden, ob das Konto noch an einen realen Dienst gebunden ist: vorhandene SPNs, Alter des Passworts, Gruppenmitgliedschaften und verantwortlicher Applikations-Owner. Diese kleine Zusatzprüfung verhindert, dass verwaiste Legacy-Konten nur aus organisatorischer Trägheit roastbar bleiben.

Welche Netzsicht nach dem Fix noch zählt

Zusätzlich lohnt es sich, die tatsächliche Erreichbarkeit dieser Konten zu dokumentieren: welche Netze Domain Controller für AS-Anfragen erreichen können, welche Jump Hosts oder Administrationssysteme relevant sind und ob ein erster Low-Privilege-Fußabdruck den Angriff noch praktisch machen würde. Diese Sicht hilft, zwischen theoretischer und real ausnutzbarer Exposition zu unterscheiden.

Was bei der nächsten Review sofort wieder geprüft werden sollte

Bei der nächsten turnusmäßigen Prüfung sollten dieselben Konten erneut gegen Passwortalter, Gruppenmitgliedschaften und verbleibende Anwendungspfade geprüft werden. Genau dort entstehen die meisten Rückfälle: Das Flag bleibt entfernt, aber Passwortqualität, Kontorechte oder Legacy-Abhängigkeiten verschlechtern sich erneut, bis derselbe Risikotyp zurückkehrt.

Welche Service-Klassen besonders verdächtig sind

Besondere Aufmerksamkeit verdienen weiterhin Helpdesk-, Integrations- und alte Middleware-Konten, weil genau dort Ausnahmen oft ohne saubere Dokumentation überleben. Wenn diese Klassen sauber überprüft sind, fällt es deutlich schwerer, dieselbe Schwäche später unbemerkt wieder einzuführen.

Häufige Verteidigerfehler

Die wiederkehrenden Fehler sind fast immer dieselben:

annehmen, dass anonymes LDAP Voraussetzung des Angriffs ist
Vorauthentifizierung wieder einschalten, aber das Passwort nicht rotieren
Ausnahmen auf alten Dienstkonten mit breiten Rechten stehen lassen
die Einstellung als harmlos behandeln, weil das Konto „nicht interaktiv“ sei
ein sichtbares Konto korrigieren, aber nicht den Provisionierungsprozess, der die Ausnahme erzeugt hat

Für technische Leser ist der entscheidende Punkt nicht die Komplexität des Exploits, sondern die Menge an Berechtigung, die das exponierte Konto über die Zeit angesammelt hat.

Primärquellen

So erkennt EtcSec das Problem

EtcSec markiert Konten mit deaktivierter Kerberos-Vorauthentifizierung in jedem AD-Audit.

Der zentrale Befund ist ASREP_ROASTING_RISK: Jedes Konto mit gesetztem DONT_REQ_PREAUTH ist ein Kandidat für Passwort-Exposition.

Verwandte Befunde ändern oft die tatsächliche Schwere:

PASSWORD_NEVER_EXPIRES
PASSWORD_POLICY_WEAK
WEAK_KERBEROS_POLICY

Die Kombination ist wichtiger als das Flag allein. Ein roastbares Konto mit schwachem, altem oder nie ablaufendem Passwort ist deutlich gefährlicher als eine eng kontrollierte temporäre Ausnahme.

AS-REP Roasting: Hashes Ohne Anmeldedaten Sammeln