Ausgangslage: ein alter Account-Schalter macht Passwörter offline angreifbar

AS-REP Roasting ist in vielen AD-Umgebungen kein Zeichen für einen modernen Spezialangriff. Häufig reicht ein historisch falsch gesetztes Kontoattribut: "Do not require Kerberos preauthentication". Wenn diese Option aktiv ist, kann ein Kerberos-Authentication-Service-Response für das Konto angefordert werden, ohne dass vorher ein Preauth-Nachweis geliefert wird. Der kritische Teil ist dann nicht die Online-Anfrage, sondern die anschließende Offline-Prüfung gegen schwache Passwörter.

In Projekten taucht das Muster regelmäßig bei alten Service-Accounts, Migrationskonten, Testbenutzern oder schlecht dokumentierten Applikationskonten auf. Manchmal wurde die Option vor Jahren gesetzt, weil eine Legacy-Anwendung sonst nicht funktionierte. Manchmal ist sie schlicht ein Fehlgriff in der Benutzerverwaltung. Beides ist gefährlich, weil ein einzelnes schwaches Passwort ausreichen kann, um aus einem scheinbar normalen Benutzerkonto einen ernsthaften AD-Pfad zu machen.

Typische Signale:

  • Benutzerkonten mit DONT_REQ_PREAUTH,
  • alte Service-Accounts ohne Owner,
  • Konten mit SPNs, langen Laufzeiten und unklarer Nutzung,
  • Passwörter, die nie rotiert wurden,
  • fehlende Alarmierung auf Kerberos-Preauth-Ausnahmen.

Der saubere Umgang damit ist kein Exploit-Test. Es ist Account-Hygiene, Kerberos-Baseline und kontrollierte Ausnahmeverwaltung.

Zielbild: Preauth ist Standard, Ausnahmen sind selten und begründet

Ein belastbares Zielbild ist konkret:

  1. Kerberos-Pre-Authentication ist für alle normalen Benutzer- und Service-Konten erforderlich.
  2. Alle Konten ohne Preauth sind inventarisiert, mit Owner, Zweck, technischer Abhängigkeit und Ablaufdatum.
  3. Service-Accounts haben starke, rotierte Geheimnisse oder werden auf gMSA umgestellt, wenn das technisch passt.
  4. Legacy-Ausnahmen sind zeitlich begrenzt und haben einen Migrationsplan.
  5. Änderungen am Preauth-Flag werden überwacht, damit neue Ausnahmen nicht unbemerkt entstehen.

Das Ziel ist nicht, alte Applikationen blind zu brechen. Das Ziel ist, den Default wieder sicher zu setzen und Ausnahmen wie echte Risiken zu behandeln.

Umsetzung: erst lesen, dann in kleinen Wellen härten

1) Konten ohne Preauth read-only finden

Starte mit einer reinen Bestandsaufnahme. Die folgende Abfrage verändert nichts und liefert die Konten, bei denen Kerberos-Preauth nicht erforderlich ist:

Import-Module ActiveDirectory

Get-ADUser -LDAPFilter '(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))' `
  -Properties Enabled,ServicePrincipalName,PasswordLastSet,LastLogonDate,Description,DistinguishedName |
  Select-Object SamAccountName,Enabled,PasswordLastSet,LastLogonDate,ServicePrincipalName,Description,DistinguishedName

Wichtig: Das Ergebnis ist ein Risiko-Inventar, kein automatischer Änderungsauftrag. Besonders Service-Accounts brauchen vor der Änderung einen Owner, einen Testfall und ein Wartungsfenster.

2) Treffer sauber klassifizieren

Jeder Treffer sollte eine einfache Entscheidung bekommen:

  • entfernen: Konto ist deaktiviert, verwaist oder nicht mehr notwendig,
  • härten: Preauth kann aktiviert werden, Passwort wird rotiert, Nutzung wird getestet,
  • migrieren: Service-Account wird durch gMSA oder ein saubereres Betriebsmodell ersetzt,
  • befristet akzeptieren: Legacy-Abhängigkeit mit Owner, Risiko, Ablaufdatum und Review-Termin.

Die wichtigste Frage ist nicht "Warum steht das Flag da?", sondern: Was würde brechen, wenn es nicht mehr da ist? Wenn niemand diese Frage beantworten kann, ist das bereits ein Finding.

3) Passwort- und Service-Account-Hygiene koppeln

Preauth wieder zu aktivieren reduziert die Angriffsfläche. Es löst aber nicht automatisch das Problem schwacher oder alter Passwörter.

Pragmatische Mindestmaßnahmen:

  • Service-Accounts mit langen Passwortlaufzeiten priorisieren.
  • Konten mit SPNs separat prüfen, weil sie oft auch für Kerberoasting relevant sind.
  • Interaktive Anmeldung für Service-Accounts einschränken.
  • Lokale Anmeldung, RDP und unnötige Gruppenmitgliedschaften entfernen.
  • Wo möglich gMSA verwenden, statt manuelle Passwortrotation auf Papier zu betreiben.

Wenn ein Konto bereits ohne Preauth lief und ein schwaches Passwort hatte, ist nach der Umstellung eine Passwortrotation Pflicht. Sonst bleibt ein historisches Risiko im Raum.

4) Preauth gezielt wieder aktivieren

Für normale Benutzerkonten ist die Änderung meistens unkritisch. Für Service-Accounts sollte sie in kleinen Wellen passieren.

Set-ADAccountControl -Identity "svc-example" -DoesNotRequirePreAuth $false

Vorher gehören Owner, Testfall und Rollback in den Change. Nachher müssen Anwendung, geplante Tasks, Dienste und Kerberos-Fehler für ein definiertes Beobachtungsfenster geprüft werden.

Keine Bulk-Änderung über alle Treffer ohne Fachverantwortliche. Das spart vielleicht eine Stunde Analyse und kostet im Fehlerfall schnell ein Wochenende Betrieb.

5) Neue Ausnahmen verhindern

Nach der Bereinigung ist die technische Arbeit nur halb erledigt. Die Umgebung braucht einen Prozess, der neue Preauth-Ausnahmen sichtbar macht:

  • wiederkehrender Report über Konten mit DONT_REQ_PREAUTH,
  • Alarm bei Änderung des relevanten Kontoattributs,
  • Review von neuen Service-Accounts vor Produktivnahme,
  • klare Regel: Preauth-Ausnahme nur mit Owner, Ticket, Risikoannahme und Ablaufdatum,
  • regelmäßiger Vergleich gegen die dokumentierte Ausnahmeliste.

So bleibt AS-REP-Risiko ein kontrollierter Sonderfall statt ein still wachsender Bestand.

Vorteile

  • Kleine technische Änderung mit hohem Baseline-Nutzen: Der unsichere Default wird für betroffene Konten korrigiert.
  • Reduziert Offline-Risiko bei schwachen Passwörtern: Preauth verhindert, dass betroffene Konten so leicht in diesen Angriffsmodus fallen.
  • Verbessert Service-Account-Disziplin: Owner, SPNs, Passwortrotation und Logon-Rechte werden sichtbar.
  • Gut messbar: Anzahl betroffener Konten, geschlossene Ausnahmen und neue Drift lassen sich sauber reporten.
  • Passt in Kerberos-Hardening: Die Maßnahme ergänzt AES-Only, Kerberos Armoring, gMSA und Tiering.

Nachteile und Grenzen

  • Legacy-Anwendungen können betroffen sein, wenn sie ausnahmsweise wirklich ohne Preauth betrieben wurden.
  • Preauth ersetzt keine starken Passwörter: Schwache Service-Account-Passwörter bleiben ein Risiko, auch wenn dieser konkrete Pfad reduziert wird.
  • gMSA ist nicht überall sofort möglich: Alte Software, Cluster-Setups oder Appliances können Migration erschweren.
  • Das Finding wirkt unscheinbar: Fachbereiche sehen keinen direkten Funktionsgewinn, obwohl das Risiko real ist.
  • Eine einmalige Bereinigung reicht nicht: Ohne Monitoring tauchen neue Ausnahmen durch Betrieb, Migrationen oder Fehlkonfiguration wieder auf.

Typische Stolperfallen

  • Deaktivierte Konten ignorieren: Auch deaktivierte Treffer gehören bewertet und bereinigt, weil sie oft verwaiste Prozesse zeigen.
  • Service-Accounts ohne Owner ändern: Die technische Änderung ist klein, die Betriebsabhängigkeit kann groß sein.
  • Passwortrotation vergessen: Nach Entfernung des Flags sollte das Passwort betroffener aktiver Konten rotiert werden.
  • SPN-Konten isoliert betrachten: Konten ohne Preauth und mit SPNs brauchen eine breitere Kerberos-Risikobetrachtung.
  • Ausnahmen ohne Ablaufdatum zulassen: Sonst wird die Ausnahme wieder zur Baseline.
  • Keine Drift-Erkennung bauen: Neue Konten mit deaktivierter Preauth bleiben sonst bis zum nächsten Assessment unentdeckt.

Projekt-Checkliste

  • [ ] Konten mit deaktivierter Kerberos-Preauth read-only inventarisieren.
  • [ ] Aktiv/deaktiviert, Service-Account, SPNs, Passwortalter und letzte Nutzung erfassen.
  • [ ] Für jeden aktiven Treffer Owner, Anwendung, Testfall und Zielzustand dokumentieren.
  • [ ] Normale Benutzerkonten priorisiert auf Preauth-Pflicht umstellen.
  • [ ] Service-Accounts mit Change-Fenster, Monitoring und Rollback in kleinen Wellen härten.
  • [ ] Passwörter betroffener aktiver Konten rotieren.
  • [ ] gMSA-Eignung für Service-Accounts prüfen.
  • [ ] Interaktive Anmeldung, RDP, lokale Anmeldung und unnötige Gruppenrechte für Service-Accounts einschränken.
  • [ ] Befristete Ausnahmen mit Ablaufdatum, Risikoannahme und Review-Termin dokumentieren.
  • [ ] Wiederkehrenden Report und Alarmierung auf neue Preauth-Ausnahmen etablieren.