Red Team Basics: Pass-the-Hash & Kerberoasting – So greifen Angreifer an

Red Team Basics: Pass-the-Hash, Kerberoasting und die Realität von Active Directory Angriffen

Wenn Ihr CISO euch in einem Meeting das erste Mal nach „Kerberoasting“ oder „Pass-the-Hash" fragt, wisst ihr genau, was als Nächstes kommt: Panische Telefonate zum Managed Service Provider, der nur mit teuren Scan-Tools kontert. In meiner Zeit als Administrator und heute als Security-Blogger habe ich unzählige Infrastruktur-Umgebungen gesehen, die unter der Haube so unsicher waren, dass sie sich leicht von einem Skriptkiddie übernehmen ließen. Das Problem ist oft nicht mangelnde Technik, sondern eine blinde Stelle im Sicherheitsbewusstsein. Viele Admins glauben fälschlicherweise, ein starkes Passwort erzwingt Sicherheit. Doch wenn Angreifer einmal einen Fuß in die Tür haben, macht es ihnen nichts aus, das Passwort gar nicht erst zu kennen. Stattdessen arbeiten sie mit den kryptographischen Überresten des Logins – den Hashes. Heute nehmen wir zwei dieser Kerberos- und NTLM-Attacken unter die Lupe, nicht um euch Angst zu machen, sondern um euch die Werkzeuge an die Hand zu geben, um euer Netzwerk zu härten.

Der Klassiker unter den Attacken: Pass-the-Hash (PtH)

Wie funktioniert Pass-the-Hash eigentlich?

In einer Windows-dominierten Umgebung ist die Authentifizierung über das Protokoll NTLM weit verbreitet, auch wenn Kerberos heute Standard ist. Wenn ihr euch an einem Domain-Joined System anmeldet, wird euer Passwort nie im Klartext übertragen. Stattdessen wird ein Hashwert erstellt – konkret der NT-Hash. Dieser Wert fungiert als digitales Gleichnis eures Passworts.

Bei einem normalen Login sendet der Client diesen Hash an den Server, der ihn mit seinem gespeicherten Hash vergleicht. Stimmmt die Übereinstimmung, seid ihr drin. Bei einem Pass-the-Hash-Angriff stiehlt der Angreifer nun diesen NT-Hash vom infizierten System, oft aus dem Arbeitsspeicher (LSASS-Prozess). Statt das eigentliche Passwort herauszufinden – was aufwendig sein könnte – nutzt er diesen gestohlenen Hash direkt für die Authentifizierung an anderen Systemen im Netzwerk. Er gibt dem Zielserver quasi vor, er sei der legitime Benutzer.

Praktisches Beispiel: Hash extrahieren und nutzen

Ein häufig genutztes Tool dafür ist Mimikatz. Ein Angreifer mit lokaler Administratorenrechte kann damit den Speicher auslesen:

# Mimikatz Befehl zur Extraktion der Credentials
dump::lsa /inject

Die Ausgabe zeigt unter anderem die NT-HASHES der aktuell angemeldeten Benutzer. Hat der Angreifer diesen Hash, etwa a93b1e5e782d74c901c7e1b3a9143f89, kann er sich per psexec an einem anderen Rechner authentifizieren:

psexec.py domain/username@target-ip -hashes :a93b1e5e782d74c901c7e1b3a9143f89

Dabei passiert kein Password-Guessing; der Server validiert einfach den empfangenen Hash.

Meine Einschätzung:
Pass-the-Hash ist älter als manches Betriebssystem in eurem Rechenzentrum, aber immer noch absolut relevant. Es unterstreicht eindringlich, warum lokale Admin-Rechte streng kontrolliert werden müssen. Jede Maschine, auf der ein User administrative Rechte hat, ist ein potenzieller Startpunkt für eine laterale Bewegung durchs gesamte Netzwerk. Seid ehrlich zu euch selbst: Wie viele Euer PCs haben vielleicht noch alte Service-Accounts mit Domänen-Admin-Rechten? Genau dort fängt der Spass an.

Kerberoasting: Angriffe auf Dienstprinzipalnamen (SPNs)

Warum Kerberoasting so tückisch ist

Während Pass-the-Hash oft lokale Admin-Rechte erfordert, ist Kerberoasting eine Attacke, die bereits mit einem normalen, kompromittierten Domain-Benutzerkonto möglich ist. Sie zielt auf die Art und Weise ab, wie Dienste in Active Directory registriert sind – über sogenannte Service Principal Names (SPNs).

Wenn ein Benutzer auf einen Dienst zugreifen will, der über ein SPN registriert ist (z.B. eine SQL-Datenbank oder eine Webanwendung), fordert sein Kerberos-Client beim Key Distribution Center (KDC) ein Ticket Request (TGS-REQ) an. Das Besondere: Dieses Ticket wird mit dem Passwort des Dienstkontos verschlüsselt. Und hier liegt die Schwachstelle: Der normale Benutzer kann dieses Ticket zwar nicht entschlüsseln, aber er kann es anfordern und mitnehmen. Danach führt der Angreifer Offline-Kraftstoffattacken durch, um das Passwort des Dienstkonto aus dem Ticket zu knacken. Da keine Interaktion mit dem KDC stattfindet, kann der Angriff unbemerkt erfolgen – keine Sperren, keine direkten Warnhinweise im Echtzeit-Log.

Schritt-für-Schritt: Kerberoasting in Aktion

Als Angreifer listet man zunächst alle Dienstkonten mit konfigurierten SPNs auf. Ein gängiges PowerShell-Beispiel dazu:

Get-DomainUser -SPN | select samaccountname, serviceprincipalname

Hat man ein interessantes Ziel gefunden, z.B. SQLSvc, kann man mit dem Tool Rubeus ein Ticket anfordern:

# Ticket anfordern und speichern
Rubeus.exe asktgs /ticket:base64ticket /service:SQLSvc

Anschließend extrahiert man den verschlüsselten Teil und übergibt ihn an einen Cracker wie Hashcat:

hashcat -m 13100 ticket.kirbi password-list.txt

Da Dienstkonten oft komplexe, lange Passwörter haben, dauert dies vielleicht länger, aber da der Angriff offline erfolgt, kann der Angreifer ungestört hunderte Millionen Versuche pro Sekunde durchlaufen lassen.

Meine Einschätzung:
Kerberoasting ist für mich das perfekte Beispiel dafür, wie gut gedachte Mechanismen (wie SPNs für einfache Diensteanbindung) zu einer massiven Sicherheitslücke werden können, wenn man die Implikationen vernachlässigt. Oft sind es interne Tools, die von Entwicklern eingerichtet wurden, ohne dass die IT-Security überhaupt davon wusste. Ein kurzes Audit der SPNs hätte viel Ärger verhindert. Vergesst nicht: Jeder Dienst, der unter einem domänenweiten Konto läuft, ist ein potenzielles Ziel.

Häufige Fehler in der Verteidigung

Viele Unternehmen investieren riesige Summen in Firewalls und Endpoint Protection, scheitern dann aber an einfachen internen Hygienefehlern. Hier sind die drei größten Fallstricke, die ich in Audits sehe:

1. Schwache Dienstpasswörter: Viele Admins erstellen für Services einfache Passwörter, weil sie sie nicht merken müssen, oder noch schlimmer: sie ändern sie nie. Ein 15-stelliges, zufälliges Passwort wäre gegen Offline-Cracking fast immun, doch statt dessen steht oft Summer2023! in der Config.
2. Überprivilegierte Service-Accounts: Ein klassischer Mistake ist es, einem Dienstkonto Domänenadministrationsrechte zu verleihen, nur um Gruppenrichtlinien leichter anpassen zu können. Damit erhöht man den Wert des Kontos enorm – wenn es ge-Kerberoastet wird, fällt nicht nur der Dienst, sondern die ganze Domäne.
3. Desenabled NTLM oder falsche Protokoll-Einstellungen: Um PtH einzudämmen, sollte NTLM wherever possible eingeschränkt oder durch LDAP Signing und Channel Binding ersetzt werden. Viele vergessen jedoch, Ausnahmen für Legacy-Systeme zu dokumentieren und regelmäßig zu prüfen.

Fazit und dein konkreter nächster Schritt

Pass-the-Hash und Kerberoasting zeigen deutlich: Die Sicherheit eurer Active Directory Umgebung hängt nicht nur von firewalls oder Virenscannern ab. Sie hängt von der korrekten Konfiguration interner Dienste, der strikten Trennung von Benutzer- und Servicekonten und einem gesunden Misstrauen gegenüber jeder Berechtigung ab.

Was kannst du morgen früh machen? Starte mit einem einfachen, aber wirkungsvollen Audit. Öffne eine PowerShell als Domain-User (nicht als Admin!) und führe den Befehl Get-DomainUser -SPN aus (via PowerView). Schau dir die Liste an. Für jeden Eintrag prüfe zwei Dinge: Läuft der Dienst wirklich noch? Ist das dazugehörige Passwort lang und komplex genug? Und vor allem: Kann man das Konto durch ein managed Service Account (gMSA) ersetzen, das automatisch Passwörter verwaltet und somit Kerberoasting unmöglich macht? Beginne heute mit diesem Check – denn wer seine internen Schatten kennt, kann sie ausschalten, bevor der Gegner sie findet.