Active Directory Pentest: Kerberoasting Schritt fuer Schritt im GOAD Lab

Kerberoasting ist der Angriff, der auf fast jedem internen Engagement Miete zahlt, denn er braucht nichts weiter als ein einziges gultiges Domain-Konto und verwandelt still angeforderte Service-Tickets in offline Passwort-Cracking, ohne Sonderrechte und ohne larmenden Exploit. In dieser Anleitung baust du ein Labor mit GOAD, dem Game of Active Directory von Orange Cyberdefense, und fahrst die volle Kette: verstehen, wie Kerberos Tickets ausstellt, Service Principal Names enumerieren, die Tickets anfordern, sie offline mit hashcat cracken und dann die Schleife mit der Detection und dem Hardening schliessen, die es wirklich stoppen. Alles lauft gegen deine eigenen Domain Controller, in einem isolierten Netz, unter schriftlicher Autorisierung; das Ziel ist Gelaufigkeit im Mechanismus, keine Trophae.

Wie Kerberos-Authentifizierung funktioniert

Kerberos ist ein Ticket-Protokoll mit drei Parteien: dem Client, dem Key Distribution Center auf dem Domain Controller und dem Service. Zuerst beweist der Client mit einem AS-REQ, wer er ist, und erhalt ein Ticket Granting Ticket, verschlusselt mit dem Schlussel des krbtgt-Kontos, sodass nur das KDC es lesen kann. Will der Client einen Service erreichen, prasentiert er das TGT in einem TGS-REQ und bittet um ein Service-Ticket; das KDC antwortet mit einem TGS, verschlusselt mit dem eigenen Schlussel des Service-Kontos, der aus dessen Passwort abgeleitet ist. Der Client reicht das Ticket an den Service, der es entschlusselt, um die Berechtigung zu prufen. Das kritische Detail: das KDC gibt jedem authentifizierten Nutzer ein Service-Ticket fur jeden Service, und dieses Ticket ist mit einem aus einem menschlich gewahlten Passwort abgeleiteten Schlussel verschlusselt.

Warum Kerberoasting funktioniert

Diese eine Design-Tatsache ist die gesamte Schwachstelle. Jeder Domain-Nutzer kann ein TGS fur jedes Konto anfordern, das einen Service Principal Name registriert hat, und das zuruckgegebene Ticket ist mit dem passwort-abgeleiteten Schlussel des Service-Kontos verschlusselt. Nimm das Ticket offline und du kannst das Passwort brute-forcen, ohne die Domain je wieder anzufassen, weil die Verifikation auf deiner eigenen Hardware passiert. Schlimmer wird es, wenn das Ticket als RC4 zuruckkommt (etype 23, der $krb5tgs$23$-Hash), das weit schneller crackt als AES. Service-Konten sind die perfekten Opfer: sie tragen oft schwache, uralte, menschlich gesetzte Passworter, rotieren selten und sind haufig uberprivilegiert, weil jemand ihnen vor Jahren Domain Admin gab, damit ein Installer lief.

Das GOAD-Lab bauen

GOAD liefert eine absichtlich verwundbare Multi-Domain-Active-Directory-Gesamtstruktur, gebaut fur genau diese Ubung. Provisioniere sie mit Ludus oder uber den Vagrant- und Ansible-Pfad auf einem Hypervisor mit genug RAM, denn eine realistische Gesamtstruktur will mehrere Windows-Server-VMs und einen Kali- oder Windows-Angriffshost. Halte die ganze Umgebung in einem isolierten Netz ohne Route zu Produktion oder Internet, weil GOAD absichtlich schwach ist und nie etwas Echtes beruhren darf. Sobald die Domain Controller laufen und du ein niedrig privilegiertes Domain-Konto hast, hast du genau die Ausgangsposition eines Angreifers, der gerade einen einzelnen Helpdesk-Nutzer gephisht hat, der realistische Einstiegspunkt, den Kerberoasting ausnutzen soll.

Enumeration: die Service-Konten finden

Du kannst nicht rosten, was du nicht siehst, also enumeriere zuerst Konten mit SPN. Unter Windows listet setspn -T domain -Q */* registrierte Service Principal Names, wahrend PowerViews Get-DomainUser -SPN direkt auf Benutzerkonten mit gesetztem SPN filtert, die crackbaren Ziele. Unter Linux tut ein authentifizierter ldapsearch nach servicePrincipalName=* dasselbe. Futtere die Domain in BloodHound und es listet nicht nur kerberoastbare Nutzer, sondern zeigt, welche davon in hochwertigen Gruppen sind, sodass du das Service-Konto priorisieren kannst, das zufallig auch in Domain Admins sitzt. Notiere die Verschlusselungstypen jedes Kontos; ein Konto, das noch RC4 erlaubt, ist das weichste Ziel auf dem Brett.

Die Tickets anfordern und extrahieren

Sind die Ziele gewahlt, fordere die Tickets an. Von einem Windows-Standbein fordert Rubeus.exe kerberoast /outfile:hashes.txt ein TGS fur jedes kerberoastbare Konto an und schreibt die Hashes in crackbarem Format; mit /tgtdeleg oder Filter nach User bleibst du leise. Unter Linux mit Impacket tut GetUserSPNs.py DOMAIN/user:password -dc-ip 10.0.0.10 -request dasselbe in einem Befehl und dumpt die $krb5tgs$-Blobs. Wenn du kannst, ziele bewusst auf Konten, die mit RC4-Hashes antworten; gibt das KDC AES etype 18 ($krb5tgs$18$) zuruck, kannst du es trotzdem cracken, nur weit langsamer. Jeder gesammelte Hash ist nun vollstandig vom Netz getrennt, genau darum passiert der nachste Schritt auf deiner eigenen Maschine.

Die Tickets offline cracken

Offline wird Kerberoasting grausam. Gib die Hashes an hashcat mit Modus -m 13100 fur RC4-TGS-Tickets oder -m 19700 fur AES, richte es auf eine starke Wortliste wie rockyou plus gezielte Regeln und lass die GPU arbeiten. Ein schwaches Service-Passwort fallt in Sekunden; ein zwolfstelliges menschliches Passwort mit vorhersehbarer Struktur oft in Stunden. Weil die Verifikation lokal ist, gibt es kein Lockout, kein Rate-Limit und keinen Log-Eintrag in der Domain, der dich verrat. Diese Asymmetrie ist der ganze Punkt: die Passwort-Policy des Verteidigers ist das Einzige zwischen einem einzelnen niedrig privilegierten Konto und einer gecrackten Service-Credential, die weit mehr Zugriff halten kann als das Konto, mit dem du gestartet bist.

Nach dem Crack: ein Passwort in Domain-Macht verwandeln

Ein gecracktes Service-Konto ist selten das Ende; es ist ein Pivot. Melde dich als das Service-Konto an und fahr BloodHound aus dessen Kontext erneut, um zu mappen, was es erreichen kann, denn Service-Konten halten routinemassig lokalen Admin auf vielen Servern oder sitzen in privilegierten Gruppen. Ist das Konto ein SQL- oder Backup-Service, besitzt es vielleicht Pfade zu einem Domain Controller uber Delegation oder DACL-Missbrauch. Deshalb ist Kerberoasting auf echten Engagements so geschatzt: es verwandelt die schwachstmogliche Ausgangsposition, einen gewohnlichen Nutzer, in Credentials, die fur Maschinen provisioniert und daher weit mehr vertraut wurden, als es ein menschliches Konto je sein sollte.

Detection: die Sicht des Verteidigers

Jeder Kerberoast hinterlasst eine Spur, wenn du hinschaust. Windows Event ID 4769 protokolliert jede TGS-Anfrage, und der Verrat ist das Verschlusselungstyp-Feld: ein Schwall 4769-Events mit Verschlusselungstyp 0x17 (RC4) von einem einzelnen Nutzer gegen viele verschiedene Services in kurzem Fenster ist die Signatur eines Roasting-Laufs. Alarmiere auf dieses Muster im SIEM statt auf Einzelevents, denn ein 4769 ist normal, tausend in einer Minute nicht. Die starkste Einzeldetection ist ein Honeypot-SPN: erstelle ein Decoy-Service-Konto mit SPN, nutze es nie und feuere einen High-Severity-Alert in dem Moment, in dem jemand sein Ticket anfordert, denn kein legitimer Prozess wird das je tun.

Mitigation und Hardening

Der Fix zielt auf die Crackbarkeit, nicht auf die Anfrage. Ersetze menschlich verwaltete Service-Konten durch group Managed Service Accounts, deren 240-Zeichen maschinengenerierte Passworter automatisch rotieren und offline praktisch nicht crackbar sind. Wo ein gMSA noch nicht moglich ist, erzwinge ein sehr langes, zufalliges Passwort auf jedem Service-Konto und rotiere es. Deaktiviere RC4 domainweit, sodass Tickets nur als AES zuruckkommen, was die Crack-Kosten um Grossenordnungen hebt, und auditiere jedes Service-Konto auf unnotige Privilegien, sodass selbst eine gecrackte Credential ins Leere fuhrt. Leg den Honeypot-SPN und die 4769-Detection obendrauf, und du hast sowohl die Chance eines erfolgreichen Cracks als auch den Blast-Radius gesenkt, falls einer passiert.

Fallstricke und eine Checkliste

Die haufigen Fehler schneiden in beide Richtungen. Angreifer werden erwischt, weil sie alle Tickets auf einmal anfordern statt zu takten und zu zielen, oder sie verschwenden Tage mit einem AES-Hash, den sie fur einen RC4 hatten uberspringen konnen. Verteidiger wahnen sich sicher, weil sie eine Passwort-Policy fur Nutzer erzwangen, wahrend ihre Service-Konten ein jahrzehntealtes Passwort und RC4 aktiviert tragen. Bevor du die Domain gehardened nennst, bestatige, dass kein Nutzerkonto RC4 erlaubt, dass jedes Service-Konto ein gMSA ist oder ein langes zufalliges Passwort halt, dass ein Honeypot-SPN existiert und alarmiert, dass 4769-Anomalie-Detection lauft und dass kein kerberoastbares Konto in einer privilegierten Gruppe sitzt. Beweise es, indem du deine eigene Domain roastest und den Honeypot feuern siehst.

Ein enger Verwandter: AS-REP Roasting

Sitzt Kerberoasting einmal, kostet sein Geschwister fast nichts extra. AS-REP Roasting zielt auf Konten mit deaktivierter Kerberos-Pre-Authentication, eine Einstellung, die das KDC eine AS-REP zuruckgeben lasst, verschlusselt mit dem passwort-abgeleiteten Schlussel des Nutzers, bevor dieser irgendetwas bewiesen hat. Das heisst, du kannst den Blob fur so ein Konto ganz ohne Credentials anfordern und ihn offline cracken, genau wie ein TGS. Enumeriere die Opfer mit Get-DomainUser -PreauthNotRequired in PowerView oder GetNPUsers.py in Impacket, dann gib den resultierenden $krb5asrep$-Hash an hashcat-Modus -m 18200. Die defensive Geschichte ist im Geiste identisch: deaktiviere Pre-Authentication nie, erzwinge starke Passworter und alarmiere auf die anomale Anfrage. Beide Angriffe in GOAD hintereinander zu fahren lehrt dich, dass die ganze Familie der Roasting-Bugs auf dieselbe Wurzel zuruckgeht, einen aus einem schwachen menschlichen Passwort abgeleiteten Schlussel, den jeder anfordern darf.

FAQ

Brauche ich Admin-Rechte zum Kerberoasten? Nein, und genau das macht es gefahrlich. Jedes einzelne authentifizierte Domain-Konto kann Service-Tickets anfordern und offline nehmen; keine Elevation, kein Exploit und kein Sonderzugriff notig, weshalb es einer der ersten Zuge nach jedem Standbein ist.

Stoppt AES-Aktivierung Kerberoasting vollstandig? Nein, es macht es viel schwerer, nicht unmoglich. AES-Tickets konnen weiter angefordert und gecrackt werden, nur weit langsamer, sodass ein schwaches Service-Passwort auch unter AES verwundbar bleibt. Der dauerhafte Fix sind gMSA-Passworter, die keine Wortliste je erreicht, kombiniert mit Least Privilege, sodass ein Crack nichts bringt.

Praktisches Takeaway: stell GOAD auf, fahr die Kette einmal von einem einzigen niedrig privilegierten Konto zu einem gecrackten Service-Ticket zu einem privilegierten Pivot, dann wechsle zur blauen Seite und bau den Honeypot-SPN und die 4769-Detection, bis dein eigener Roast sie aufleuchten lasst. Kerberoasting ist keine exotische Technik; es ist eine Design-Folge von Kerberos, das auf schwache Service-Passworter trifft. Rotiere zu gMSA, kill RC4, strip Privilegien und wach uber die Anfrage, und du machst aus einem verlasslichen Angreifer-Zahltag eine Sackgasse.