Active Directory AS-REP Roasting Privilegierte Dienstkonten: Die Konten, die Pre-Auth eigentlich schützen sollte

Active Directory AS-REP Roasting privilegierte Dienstkonten ist der Fall mit den höheren Einsätzen, den dieser Beitrag behandelt: Kerberos-Konten mit deaktivierter Pre-Authentication, die zusätzlich in einer privilegierten Gruppe sitzen oder als Dienstkonto laufen – nicht ein beliebiger Standardbenutzer.

Active Directory AS-REP Roasting Privilegierte Dienstkonten

Der EtcSec-Katalog erfasst den Fall privilegierter Konten separat als ADMIN_ASREP_ROASTABLE (Kritisch), denn ein Konto, das bereits in Domain Admins, Enterprise Admins oder einer anderen Tier-0-Gruppe sitzt und dieses Flag gesetzt hat, macht aus AS-REP Roasting ein direktes Offline-Cracking-Rennen zum DA – keine mehrstufige Lateral-Movement-Kette. Für die allgemeine Variante dieses Angriffs auf beliebige Konten siehe AS-REP Roasting: Hashes ohne Anmeldedaten sammeln – dieser Beitrag ist enger gefasst, auf das Cluster aus privilegierten und Dienstkonten, das jener Beitrag nicht erfasst.

Das zugrunde liegende Flag ist DONT_REQ_PREAUTH (0x400000 / dezimal 4194304) im Attribut userAccountControl (Microsoft Learn: UserAccountControl property flags). Ist es gesetzt, kann jeder Client eine Kerberos Authentication Server Reply (AS-REP) für dieses Konto anfordern, und die Antwort kommt mit einem Teil zurück, der mit einem vom Passwort des Kontos abgeleiteten Schlüssel verschlüsselt ist – ohne dass der Client jemals nachweisen muss, dass er dieses Passwort kennt. MITRE ATT&CK T1558.004 erfasst dies als „Steal or Forge Kerberos Tickets: AS-REP Roasting".

Die meisten allgemeinen Beiträge behandeln dies als pauschale Hygienemaßnahme für Benutzerkonten. Diese Einordnung übersieht, warum zwei spezifische Cluster wichtiger sind:

• Privilegierte Konten ohne Pre-Auth (ADMIN_ASREP_ROASTABLE, Kritisch) – Tier-0-Gruppenmitgliedschaft plus ein roastbarer Hash.
• Dienstkonten mit dem angrenzenden Fehlkonfigurations-Cluster – keine Pre-Auth (SERVICE_ACCOUNT_NO_PREAUTH), interaktive Anmeldung erlaubt (SERVICE_ACCOUNT_INTERACTIVE), und ein Passwort, das seit über einem Jahr nicht rotiert wurde (SERVICE_ACCOUNT_OLD_PASSWORD). Jedes für sich ist Hoch – zusammen bedeuten sie, dass der Hash leicht zu beschaffen ist und, einmal geknackt, auf einem Konto, das auch für interaktiven Zugriff missbraucht werden kann, lange gültig bleibt.

Warum das Flag bei echten Konten gesetzt bleibt

DONT_REQ_PREAUTH wird selten böswillig gesetzt – meist ist es ein Überbleibsel eines spezifischen Kompatibilitätsbedarfs, der nie bereinigt wurde. Dokumentierte Ursachen sind domänenübergreifende SIDHistory-Migrationen, bei denen manche VPN- oder Federation-Lösungen von Drittanbietern die Kerberos-Pre-Authentication für migrierte Identitäten nicht abschließen können, sofern das Flag während der Umstellung nicht vorübergehend deaktiviert wird (Quest Support KB 4313059), sowie Kompatibilität mit Legacy-Anwendungen oder -Appliances, bei denen eine ältere Kerberos-Client-Bibliothek Pre-Authentication überhaupt nicht verarbeiten kann (Tenable: How to Stop the Kerberos Pre-Authentication Attack; JumpCloud: What Is Kerberos Pre-Authentication?). Die Migration oder die Legacy-Appliance wird stillgelegt; das Flag bleibt am Konto unbegrenzt gesetzt, weil es nie erneut geprüft wird.

So funktioniert es

Kerberos-Pre-Authentication existiert genau, um diese Angriffsklasse zu verhindern: Der Client muss einen Zeitstempel mit einem vom Passwort abgeleiteten Schlüssel verschlüsseln und ihn im AS-REQ senden, bevor die KDC überhaupt etwas ausstellt. Fällt diese Anforderung weg, reduziert sich der Ablauf auf vier Schritte: Der Angreifer sendet ein AS-REQ für den Zielbenutzernamen ohne Passwort und ohne vorherige Domänenauthentifizierung, solange das Konto enumerierbar ist (LDAP, RPC oder eine geleakte Benutzernamensliste); die KDC antwortet sofort mit einem AS-REP, weil keine Pre-Authentication erforderlich ist; ein Teil dieses AS-REP ist mit einem vom Passwort des Kontos abgeleiteten Schlüssel verschlüsselt; und der Angreifer knackt diesen Teil offline, ohne dass die Domäne fehlgeschlagene Passwortversuche protokolliert, da jeder Versuch auf der Hardware des Angreifers läuft, nicht gegen den DC.

Die Cracking-Geschwindigkeit hängt vom ausgehandelten Kerberos-Verschlüsselungstyp ab. Erlaubt das Konto noch RC4 (etype 23), fordert der Angreifer RC4 an, und Hashcat-Modus 18200 ($krb5asrep$23$...) knackt es um Größenordnungen schneller als eine AES-256-Antwort (etype 18) es zuließe. Der RC4-Fallback lohnt sich, gleichzeitig zu schließen – siehe Kerberos RC4 Fallback in Active Directory für den zugehörigen Erkennungs- und Entfernungspfad.

Die Angriffskette

AS-REP Roasting steht bei einer realen Kompromittierung selten allein. Ein veröffentlichter Walkthrough des ShadowGate-Labs von Hack Smarter Labs – „ShadowGate Active Directory Lab Walkthrough" von incoggeek – beschreibt eine Kette, die mit anonymer SMB-Enumeration beginnt, als ersten authentifizierten Schritt in AS-REP Roasting übergeht und dann in BloodHound-kartierten ACL-Missbrauch (ein über Shadow Credentials missbrauchtes GenericWrite-Recht) und AD-CS-Enrollment-Angriffe (ESC8, über PetitPotam-erzwungene Authentifizierung am Web-Enrollment-Endpunkt der CA) auf dem Weg zu einem Domain-Controller-Zertifikat mündet. AS-REP Roasting ist das, was aus einem vollständig unauthentifizierten Fuß in der Tür das erste knackbare Geheimnis dieser Kette macht – aus demselben Grund, aus dem Active Directory Attack Paths to Domain Admin einen frühen Kerberos-Roasting-Schritt als zentrale Kante behandelt, und genau deshalb wird ein ADMIN_ASREP_ROASTABLE-Fund an einem Tier-0-Konto als Kritisch bewertet statt als Routine-Hygiene.

Schritt 1 — Enumerieren und anfordern

# Impacket -- enumeriert jedes Konto in usersfile.txt mit deaktivierter Pre-Auth
# und dumpt knackbare AS-REP-Hashes ohne gültige Domänen-Anmeldedaten
impacket-GetNPUsers CORP.LOCAL/ -no-pass -usersfile usersfile.txt -format hashcat -outputfile asrep_hashes.txt

Schritt 2 — Offline knacken

# Die resultierenden $krb5asrep$23$...-Hashes offline knacken (Modus 18200 = Kerberos 5, AS-REP, etype 23)
hashcat -m 18200 asrep_hashes.txt rockyou.txt

Erkennung

Das aussagekräftigste Signal ist Windows Security Event ID 4768 (Kerberos Authentication Ticket Request) mit Pre-Authentication Type 0, was legitim nur auftritt, wenn beim Zielkonto Pre-Auth deaktiviert ist (MITRE ATT&CK Detection Strategy DET0113; HackTheBox: AS-REP roasting detection). Kombinieren Sie es mit dem ausgehandelten Verschlüsselungstyp: 0x17 (RC4) zusammen mit Pre-Auth Type 0 ist der stärkste kombinierte Indikator, da ein Angreifer bewusst auf RC4 herabstuft, um das Offline-Cracking zu beschleunigen. Für die breitere Audit-Policy- und Event-ID-Baseline, auf der diese Erkennung aufbaut, siehe Active Directory Monitoring: Sicherheitsereignis-IDs, die zählen.

Zwei PowerShell-Abfragen decken die Katalog-Lücken-Detektoren direkt ab:

# Privilegierte Konten mit deaktivierter Pre-Auth (ADMIN_ASREP_ROASTABLE-Kandidaten)
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (adminCount -eq 1)} `
    -Properties userAccountControl, adminCount, ServicePrincipalName, MemberOf |
    Select-Object Name, DistinguishedName, ServicePrincipalName

# Dienstkonten (mit SPN) mit deaktivierter Pre-Auth, plus Passwortalter
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (ServicePrincipalName -like '*')} `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate |
    Select-Object Name, ServicePrincipalName, PasswordLastSet,
        @{N='PasswordAgeDays';E={(New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days}}

SERVICE_ACCOUNT_INTERACTIVE ist kein userAccountControl-Flag – es ist ein Verhaltensbefund. Bestätigen Sie ihn, indem Sie den sAMAccountName des Dienstkontos mit 4624-Events mit Logon Type 2 (Interactive) oder 10 (RemoteInteractive/RDP) korrelieren. Ein echtes Dienstkonto sollte ausschließlich Logon Type 3 (Network) oder 5 (Service) zeigen.

Remediation

Für privilegierte Konten

Flag entfernen: Deaktivieren Sie „Kerberos-Voranmeldung nicht erforderlich" auf der Registerkarte „Konto" des Kontos, oder führen Sie Set-ADAccountControl -Identity <account> -DoesNotRequirePreAuth $false aus. Führen Sie die obige Erkennungsabfrage erneut aus und bestätigen Sie, dass sie null Zeilen zurückgibt. Wurde das Konto wegen einer früheren SIDHistory-Migration oder Federation-Umstellung markiert, bestätigen Sie, dass diese Migration – einschließlich SIDHistory-Bereinigung – vollständig abgeschlossen ist, bevor Sie das Flag zurücksetzen, damit Pre-Auth keine noch aktive Abhängigkeit bricht.

Für Dienstkonten

1. Roastbare Dienstkonten zu gMSA migrieren. Group Managed Service Accounts rotieren automatisch ein 120-stelliges Passwort und können konstruktionsbedingt nicht für interaktive Anmeldung verwendet werden – das schließt SERVICE_ACCOUNT_OLD_PASSWORD und SERVICE_ACCOUNT_INTERACTIVE im selben Schritt. Siehe gMSA-Passwortoffenlegung in Active Directory für die Vorbehalte, wer das Passwort eines gMSA nach der Bereitstellung noch lesen kann.
2. Interaktive Anmeldung explizit einschränken. Wo ein Konto noch nicht zu gMSA wechseln kann, wenden Sie „Lokal anmelden verweigern" und „Anmelden über Remotedesktopdienste verweigern" per GPO an, die auf die OU des Dienstkontos beschränkt ist, und beschränken Sie „Anmelden als Dienst" auf die Hosts, die es tatsächlich benötigen.
3. Passwort rotieren und Kerberos-AES erzwingen. Setzen Sie jetzt ein starkes, eindeutiges Passwort, und stellen Sie das Konto unter eine Passwortrichtlinie oder Fine-Grained Password Policy, die eine Rotation tatsächlich erzwingt, statt es ein Jahr oder länger statisch zu belassen. Erzwingen Sie separat AES statt RC4 über „Netzwerksicherheit: Konfigurieren der zulässigen Verschlüsselungstypen für Kerberos" – das behebt keine fehlende Pre-Auth-Anforderung, erhöht aber die Cracking-Kosten jedes Tickets, das das Konto legitim aushandelt.
4. Protected Users nicht als Lösung heranziehen. Die Protected-Users-Sicherheitsgruppe ist die richtige Kontrolle für menschliche privilegierte Konten, aber Microsoft rät ausdrücklich davon ab, Dienst- oder Computerkonten dort aufzunehmen: Die Mitgliedschaft blockiert das Credential-Caching, sodass ein Dienstkonto, das den DC auch nur kurz nicht erreichen kann, vollständig fehlschlägt. Die Mitgliedschaft löscht auch nicht das Flag DONT_REQ_PREAUTH – ein Dienstkonto, das in der Gruppe verbleibt, während dieses Flag weiterhin gesetzt ist, ist genauso roastbar wie zuvor. Siehe Active Directory privilegierte Konten: Protected Users, Delegation und Lücken bei Dienstkonten dafür, wo diese Gruppe greift und wo nicht.

Wie EtcSec das erkennt

Das Active-Directory-Audit von EtcSec prüft dieses Cluster direkt: ADMIN_ASREP_ROASTABLE markiert Mitglieder privilegierter Gruppen mit deaktivierter Kerberos-Pre-Authentication, SERVICE_ACCOUNT_NO_PREAUTH erfasst dasselbe Flag bei jedem Dienstkonto mit SPN, SERVICE_ACCOUNT_INTERACTIVE markiert Dienstkonten, die für interaktive Anmeldung beobachtet oder konfiguriert wurden, und SERVICE_ACCOUNT_OLD_PASSWORD markiert Dienstkonten, deren Passwort nicht innerhalb der Richtlinie rotiert wurde. Keiner dieser Checks erfordert eine Live-Angriffssimulation – es sind LDAP-Attribut- und Logon-Verhaltensprüfungen, die bei jedem Audit-Durchlauf ausgeführt werden.