AS-REP-Roasting erkennen: Konten ohne Vorauthentifizierung

AS-REP-Roasting ist der kleine, stille Verwandte des Kerberoasting: Beide knacken Kerberos-Material offline, aber AS-REP-Roasting braucht nicht einmal ein gültiges Konto, sondern nur die Kenntnis eines Benutzernamens, bei dem eine bestimmte Kontooption gesetzt ist. Die Option heißt „Keine Kerberos-Vorauthentifizierung erforderlich“, sie ist selten, und genau deshalb ist die Erkennung so dankbar: Wer die betroffenen Konten kennt und die eine Ereignis-Bedingung setzt, sieht jeden Versuch. Dieser Beitrag beschreibt, wie die Technik funktioniert, warum die Vorauthentifizierung der springende Punkt ist, welche Logquellen sie zeigen, das Muster, eine Sigma-Regel, den Test und das Tuning, das hier vor allem Bestandspflege ist.

Was der Angreifer tut

Wenn sich ein Benutzer per Kerberos anmeldet, sendet sein Client normalerweise einen mit dem Passwort verschlüsselten Zeitstempel mit, die Vorauthentifizierung; erst wenn der Domain Controller diesen entschlüsseln kann, gibt er ein Ticket aus. Das verhindert, dass jemand ohne Passwort Ticketmaterial anfordert. Wie dieser Ticket-Fluss insgesamt funktioniert, steht unter Kerberos verstehen. Bei Konten mit der Option „Keine Kerberos-Vorauthentifizierung erforderlich“ entfällt dieser Schritt: Der Domain Controller gibt die Antwort, das AS-REP, an jeden aus, der danach fragt, und diese Antwort enthält einen Teil, der mit dem Passwort-Hash des Kontos verschlüsselt ist. Der Angreifer fragt also für ein solches Konto ein AS-REP an, bekommt es ohne jede Authentifizierung, und knackt den verschlüsselten Teil offline mit Wörterbuch und Regeln, bei RC4-Verschlüsselung schnell. Er braucht dazu nur den Benutzernamen und Netzwerkzugang zum Domain Controller; ein Konto im Netz zu haben hilft bei der Aufzählung der Ziele, ist aber nicht nötig. Werkzeuge sind Rubeus mit der Option asreproast und das GetNPUsers-Skript aus Impacket. In ATT&CK ist die Technik T1558.004 unter Credential Access. Die Konten mit dieser Option sind oft alte Dienstkonten oder solche, die für eine Anwendung ohne Kerberos-Unterstützung angelegt wurden, und weil sie selten überprüft werden, sind ihre Passwörter häufig schwach und alt.

Welche Logquellen die Technik zeigen

Voraussetzung für 4768 ist die Überwachung der Kerberos-Authentifizierung auf den Domain Controllern, dieselbe wie für Kerberoasting; sie gehört zu Microsofts Empfehlungen und steht in der Referenz zu den Event-IDs. Anders als bei Kerberoasting ist die Zahl der betroffenen Konten klein, weshalb die Erkennung nicht von einer Zählung lebt, sondern von der einen Bedingung fehlende Vorauthentifizierung.

Das Muster im Log

Das Muster hat zwei Ebenen, und die erste ist Bestandspflege statt Erkennung. Eine Organisation sollte wissen, welche Konten die Option gesetzt haben, und die Antwort ist meist: keine, oder eine Handvoll alte. Jedes 4768 mit PreAuthType 0 für eines dieser bekannten Konten ist zu erwarten, wenn die Anwendung dahinter läuft, und verdächtig, wenn es von einer fremden Quelle kommt oder wenn RC4 statt AES angefragt wird, wo die Anwendung sonst AES nutzt. Ein 4768 mit PreAuthType 0 für ein Konto, das die Option gar nicht haben sollte, ist entweder eine Fehlkonfiguration oder ein Angreifer, der die Option gerade gesetzt hat, und dann steht kurz davor ein 4738. Die zweite Ebene ist die Aufzählung: Ein Angreifer, der nicht weiß, welche Konten die Option haben, probiert viele Kontonamen durch, und dann entstehen 4768-Ereignisse mit dem Fehlercode für fehlende Vorauthentifizierung für Konten, die die Option nicht haben, in Serie von einer Quelle. Beides zusammen ergibt eine Erkennung, die auf die Option achtet, nicht auf die Menge, und die deshalb schon beim ersten Versuch anschlägt.

Die Sigma-Regel

title: AS-REP Roasting - TGT Request Without Pre-Authentication
id: 2e7a4c9d-1b6f-4e3a-8d5c-9f0b1a2c3d4e
status: test
description: Kerberos-AS-Anfrage ohne Vorauthentifizierung mit RC4. Kennzeichen
  von AS-REP-Roasting gegen Konten mit deaktivierter Vorauthentifizierung.
references:
  - https://attack.mitre.org/techniques/T1558/004/
author: Blue Team
date: 2026-09-13
tags:
  - attack.credential_access
  - attack.t1558.004
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4768
    PreAuthType: '0'
    TicketEncryptionType: '0x17'
  filter_machine:
    TargetUserName|endswith: '$'
  condition: selection and not filter_machine
falsepositives:
  - Dokumentierte Konten mit deaktivierter Vorauthentifizierung fuer Altanwendungen; nach Kontoname und Quelladresse ausnehmen
level: high

Die Regel filtert auf AS-Anfragen ohne Vorauthentifizierung mit RC4 und nimmt Computerkonten aus. Sie ist in einer sauberen Umgebung fast still, weil kaum ein Konto die Option hat; ihre Stärke ist, dass sie den ersten Versuch sieht, nicht erst den hundertsten. Die dokumentierten Ausnahmekonten kommen namentlich in einen Filter, zusammen mit ihrer erwarteten Quelladresse, sodass dasselbe Konto von einer fremden Adresse ein Alarm bleibt. Eine zweite Regel auf 4738 mit gesetztem DONT_REQ_PREAUTH fängt den Moment, in dem die Option überhaupt aktiviert wird, und die gehört auf Stufe hoch, weil das außerhalb einer geplanten Änderung fast immer ein Fehler oder ein Angriff ist. Eine dritte, die die Aufzählung findet, zählt 4768 mit dem Fehlercode 0x19 (Vorauthentifizierung erforderlich) pro Quelle; sie ist in der Community-Sammlung vorhanden. Die Übersetzung in das eigene SIEM steht im Beitrag zu Sigma-Regeln.

Der Test

Im Homelab braucht der Test ein Konto mit gesetzter Option „Keine Kerberos-Vorauthentifizierung erforderlich“, das im Bauplan des Labs neben dem Kerberoasting-Dienstkonto gut aufgehoben ist. Von der Kali-VM aus ein Aufruf von GetNPUsers.py gegen die Domäne ohne Anmeldeinformationen, oder auf einem Client mit Rubeus die Option asreproast. Erwartet wird auf dem Domain Controller ein 4768 mit PreAuthType 0 und Ticketverschlüsselungstyp 0x17 für das Testkonto, und die Regel muss treffen. Wer zusätzlich die Option per PowerShell an einem zweiten Konto setzt, sieht 4738 und prüft die zweite Regel; wer viele Kontonamen durchprobiert, sieht die Serie mit dem Fehlercode 0x19 und prüft die dritte. Im Zeek-Sensor erscheint die AS-Anfrage im kerberos.log. Atomic Red Team hat für T1558.004 einen Test mit Rubeus. Ergebnis und Datum in den Navigator.

Fehlalarme und Tuning

• Dokumentierte Altkonten. Die wenigen Konten, die die Option legitim brauchen, erzeugen erwartete 4768 mit PreAuthType 0. Sie kommen namentlich mit ihrer Quelladresse in den Filter; jede Anfrage von einer anderen Adresse bleibt ein Alarm. Zugleich ist jedes dieser Konten ein Kandidat für die Frage, ob es die Option wirklich noch braucht.
• RC4 statt AES bei legitimen Konten. Wenn ein dokumentiertes Konto sowohl RC4 als auch AES kann, wird die Regel auf RC4 es treffen. Die Antwort ist, dem Konto per Kontooption nur AES zu erlauben; danach ist jedes RC4 für dieses Konto ein Angreifer, der die schwächere Verschlüsselung erzwingen will.
• Das Volumen ist kein Problem. Anders als bei den meisten Kerberos-Regeln ist AS-REP-Roasting selten, weil die Option selten ist. Wer viele Treffer sieht, hat entweder viele Konten mit der Option, und das ist der eigentliche Befund, oder einen laufenden Angriff.
• Die Gegenmaßnahme, die die Regel überflüssig macht. Die Option „Keine Vorauthentifizierung“ überall entfernen, wo sie nicht zwingend gebraucht wird, und das ist fast überall. Danach gibt es keine Konten mehr, gegen die AS-REP-Roasting funktioniert, und die Regel schlägt nur noch an, wenn jemand die Option neu setzt, was die zweite Regel ohnehin fängt. Wo die Option bleiben muss, bekommt das Konto ein langes, zufälliges Passwort und nur AES, sodass der abgezogene Hash nicht zu knacken ist. Die Bestandsprüfung gehört in denselben regelmäßigen Durchlauf wie die Prüfung der Replikationsrechte aus dem Beitrag zu DCSync.

Fazit

AS-REP-Roasting ist die Technik mit dem kleinsten Angriffsfenster und der einfachsten Erkennung, sofern die Vorarbeit stimmt: Wer weiß, welche Konten die Vorauthentifizierung abgeschaltet haben, sieht jeden Versuch über ein einziges Feld in einem einzigen Ereignis. Und weil die beste Erkennung hier eine Konfiguration ist, ist die Regel zugleich ein Aufruf zum Aufräumen: Jedes Konto, das die Option nicht braucht, verliert sie, und die Technik verschwindet. Zusammen mit Kerberoasting deckt dieser Beitrag die zwei Kerberos-Techniken ab, mit denen Angreifer aus einem Fuß in der Tür offline gewonnene Passwörter machen, und für ein Blue Team ist das die Sorte Erkennung, die man einmal baut und die danach fast nur noch bestätigt, dass aufgeräumt wurde.