AS-REP Roasting mit Rubeus: Hashes ganz ohne Login

Während eines internen Assessments fanden wir uns in einer restriktiven Testumgebung ohne gültige Logins wieder. Doch auch ohne authentifizierten Zugriff konnten wir wertvolle Hashes für das Offline-Cracking sammeln – dank einer Kerberos-Fehlkonfiguration, die AS-REP Roasting ermöglichte. Einzige Voraussetzung: Ein Benutzerkonto mit deaktivierter Preauthentication.

Warum gibt es diese Option überhaupt?

Die Einstellung Do not require Kerberos preauthentication stammt aus Kompatibilitätsgründen: In sehr alten Umgebungen oder bei bestimmten Diensten, die Kerberos nicht vollständig unterstützen, war es notwendig, diesen Mechanismus zu deaktivieren. Microsoft hält diese Option weiterhin verfügbar – obwohl sie ein hohes Risiko darstellt.

In der Praxis kann es vorkommen, dass Admins bei Problemen mit einem Dienstkonto einfach Preauthentication deaktivieren, um Fehler zu umgehen. Ein typisches Beispiel:

Ein Backup-System meldet Authentifizierungsprobleme – statt den Kerberos-Fehler im Detail zu analysieren, deaktiviert der Admin Pre-Auth für den zugehörigen Service-Account. Funktioniert wieder – aber auf Kosten der Sicherheit.

Was steckt hinter AS-REP Roasting?

Wenn ein Benutzerobjekt diese Option gesetzt hat, beantwortet der Domain Controller ein Ticket-Request (AS-REQ) direkt mit einem AS-REP – ganz ohne vorherige Authentifizierung. Der zurückgelieferte Block ist mit dem Passwort-Hash des Benutzers verschlüsselt und kann offline gebruteforced werden.

🔍 Ein Blick auf die Verschlüsselung: Warum etype 23 so gefährlich ist

Die verschlüsselten AS-REP-Tickets verwenden einen bestimmten Verschlüsselungsalgorithmus – in älteren Active-Directory-Umgebungen ist das meist etype 23 (RC4-HMAC). Dieser basiert auf dem NTLM-Hash des Benutzerpassworts und ist besonders anfällig, da er keine Salt-Werte nutzt und extrem schnell geprüft werden kann.

Moderne Kerberos-Setups unterstützen auch AES-128 (etype 17) und AES-256 (etype 18). Diese sind deutlich rechenintensiver zu knacken und nutzen Salt, wodurch gängige Rainbow Tables und Brute-Force-Versuche deutlich langsamer sind – aber nicht unmöglich.

Die größte Schwachstelle bleibt jedoch das Passwort selbst. Auch AES schützt nicht vor schwachen Passwörtern wie Sommer2023!.

Rubeus in Aktion

Auf einem kompromittierten Host führten wir Rubeus aus. Dabei gibt es zwei typische Szenarien:

🔓 Variante 1: Kein Domänenbenutzer

Wenn wir keine gültige Kerberos-TGT besitzen (z. B. bei lokaler Ausführung als System oder lokaler Admin), können wir gezielt Benutzernamen durchprobieren:

    Rubeus.exe asreproast /user:svc_backup /domain:corp.local /dc:10.0.0.5
    

🔹 Tipp: Die Benutzerliste kann per ldapsearch, kerbrute oder bei SMB-Enumeration vorab gewonnen werden.

🔐 Variante 2: Mit Domänenbenutzer (z. B. über Shell)

    Rubeus.exe asreproast
    

Hier listet Rubeus automatisch alle Benutzer, bei denen keine Preauthentication erforderlich ist, und gibt Hashes im AS-REP-Format aus.

Offline-Knacken mit Hashcat

    hashcat -m 18200 asrep.hashes rockyou.txt --force
    

Innerhalb weniger Minuten erhielten wir Klartext-Zugangsdaten eines Servicekontos – und fanden kurze Zeit später ein .ps1-Backupscript mit Zugang zur SQL-DB des HR-Systems.

Starke Passwörter entschärfen die Gefahr

AS-REP Roasting funktioniert nur, wenn das Passwort schwach genug ist, um mit einer Passwortliste erraten zu werden. Je länger und komplexer das Passwort, desto unwahrscheinlicher ein erfolgreicher Angriff.

Ein zufällig generiertes Passwort mit 24 Zeichen (z. B. bW4@F9zpL7xQ2!duCv6&mRsT) erzeugt mehr als 10⁴⁷ mögliche Kombinationen. Selbst mit einem Supercomputer, der 100 Billionen Passwörter pro Sekunde prüft, würde ein Brute-Force-Angriff mehr Zeit als das Alter des Universums benötigen. Solche Passwörter sind in der Praxis nicht knackbar.

🔒 Empfehlung: Verwenden Sie für Service-Accounts Passwörter mit mindestens 20 Zeichen und setzen Sie ein regelmäßiges Rotationskonzept ein.

Lessons Learned

• AS-REP Roasting benötigt keine Anmeldung – ein beliebter Einstiegspunkt in interne Netze.
• Deaktivierte Preauthentication ist fast nie notwendig – und sollte auditiert werden.
• Service-Accounts mit schwachen Passwörtern und Sonderkonfigurationen sind ein hohes Risiko.
• Starke Passwörter und moderne Algorithmen machen diesen Angriff nahezu wirkungslos.

Ein simples Häkchen im AD, kombiniert mit einem schwachen Passwort – das reicht aus, um einem Angreifer die Tür zur Domäne zu öffnen. Und leider sehen wir diese Konstellation häufiger, als man denken würde.

👉 Zurück zur Blog-Übersicht