Red Team Basics 2026: Pass-the-Hash und Kerberoasting praxisnah erklärt

Stell dir vor, du sitzt im Zug, das Wi‑Fi ist schwach, aber du hörst plötzlich ein Gespräch über das „Tür‑Klopfen“ – nicht an der Tür deines Zugabteils, sondern an den virtuellen Türen einer Windows‑Domain. Während du das Gespräch verfolgst, merkst du: Das ist kein Mythos, das ist das tägliche Handwerk von Red‑Teamern. In diesem Artikel zerlegen wir die beiden Klassiker Pass‑the‑Hash (PtH) und Kerberoasting, zeigen dir drei handfeste Beispiele mit echten Befehlen und geben nach jedem Abschnitt ein persönliches Fazit, warum das in deinem Unternehmen gerade heute relevant ist.

Pass-the-Hash: Was steckt dahinter?

Erklärung\nDer Begriff stammt aus den frühen 2000er‑Jahren, als Angreifer entdeckt haben, dass ein NTLM‑Hash eines Benutzerkontos genauso gut funktioniert wie das eigentliche Klartext‑Passwort – vorausgesetzt, das System authentifiziert sich ausschließlich über das NTLM‑Protokoll. Der Angreifer erlangt den Hash, zum Beispiel über ein vorheriges Lateral‑Movement, und „klopft“ damit die Tür zu einem anderen System, ohne das Passwort zu kennen. Der entscheidende Punkt ist, dass das Zielsystem den Hash akzeptiert, wenn er korrekt in das Authentifizierungs‑Token eingebettet wird.

Beispiel 1 – Impacket pth.py\nImpacket ist ein Python‑Toolkit, das viele low‑level Netzwerk‑Operationen für Windows‑Protokolle kapselt. Mit pth.py lässt sich ein NTLM‑Hash übernehmen und für eine Remote‑Shell nutzen.

# Impacket installieren (Python 3.11 empfohlen)
python3 -m pip install impacket

# Annahme: Wir haben den NTLM‑Hash von "svcAccount" bereits (z. B. von einem vorherigen Mimikatz‑Dump)
# Das Format lautet LM:NTLM; der LM‑Teil ist meistens leer (""), deshalb nur ein Doppelpunkt
pth.py -hashes :aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 10.0.0.42 cmd.exe

Oben wird das Ziel‑IP‑Adresse 10.0.0.42 angegriffen, das einen offenen SMB‑Port hat. Der Befehl startet cmd.exe als Prozess unter dem Kontext des kompromittierten Kontos, ohne das Passwort zu kennen. Sobald du die Shell hast, kannst du beliebige Befehle ausführen – von Datenexfiltration bis zu weiterem Lateral‑Movement.

Einschätzung\nAus meiner Sicht ist PtH immer noch ein Kernstück des Red‑Teamings, weil viele Unternehmen noch immer Legacy‑Anwendungen laufen lassen, die ausschließlich NTLM nutzen. Selbst wenn du bereits auf Kerberos umgestellt hast, gibt es Rückfallmechanismen (z. B. SMB‑Signing deaktiviert), die PtH wieder aktivieren. Der häufigste „Blindspot“ ist, dass Administratoren NTLM‑Hashes in Log‑Dateien (z. B. Security‑EventID 4624) finden, aber nicht verstehen, dass diese Hashes direkt als Passwörter verwendet werden können.

Kerberoasting: Das vergessene Schlupfloch

Erklärung\nKerberoasting nutzt das Kerberos‑Ticket‑Granting‑Service (TGS) aus. In einer Active‑Directory‑Umgebung erhalten Service‑Principals (SPNs) – typischerweise für Dienste wie http/webserver – ein Service‑Ticket, das mit dem Passwort‑Hash des Dienstkontos verschlüsselt ist. Der Angreifer kann ein Ticket anfordern, dieses abspeichern und offline mit Tools wie Hashcat knacken. Der Clou: Der Angriff erfordert keinerlei privilegierten Zugriff, nur das Recht, ein Service‑Ticket zu beantragen – das ist standardmäßig für jeden authentifizierten Benutzer erlaubt.

Beispiel 2 – Rubeus Kerberoast\nRubeus ist ein C#‑Tool, das sämtliche Kerberos‑Funktionen ausnutzen kann. Der folgende Workflow illustriert den kompletten Vorgang von Ticket‑Request bis zum Offline‑Cracking.

# Rubeus herunterladen (GitHub Releases) und entpacken
wget https://github.com/GhostPack/Rubeus/releases/download/v1.7.0/Rubeus.exe -O Rubeus.exe

# Kerberoasting: Service‑Ticket für alle SPNs anfordern und in hashes.txt speichern
Rubeus.exe kerberoast /service:ldap /outfile:hashes.txt

# Offline‑Cracking mit Hashcat (Modus 13100 = Kerberos 5 TGS / TGT)
hashcat -m 13100 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt --quiet

Nach dem erfolgreichen Crack besitzt der Angreifer das Klartext‑Passwort des Dienstkontos. Mit diesem Passwort kann er sich auf dem jeweiligen Host anmelden, häufig mit local admin‑Rechten, weil Dienstkonten in produktiven Umgebungen meist umfangreiche Berechtigungen besitzen.

Einschätzung\nKerberoasting ist ein Paradebeispiel dafür, dass ein scheinbar harmloses Feature – das Abrufen von Service‑Tickets – zu einem mächtigen Angriffsvektor wird. In den meisten Unternehmen werden Dienstkonten mit sehr starken Passwörtern eingerichtet, aber nie mit Managed Service Accounts oder gMSA ersetzt. Mein persönlicher Rat: Prüfe regelmäßig die Stärke aller Dienstkonten‑Passwörter und migriere, wo möglich, zu gMSA, weil diese keine NT‑Hashes mehr besitzen und somit nicht geknackt werden können.

Kombination beider Techniken im Angriff

Erklärung\nEin geschickter Angreifer kombiniert PtH und Kerberoasting, um sich schrittweise durch das Netzwerk zu bewegen. Typischer Ablauf: \n1. PtH auf einem ersten kompromittierten Host, um sich als lokaler Administrator auszugeben. \n2. Mit diesen Rechten das Active Directory‑Sammlungs‑Tool SharpHound (Teil von BloodHound) ausführen, um das gesamte Beziehungs‑Graphen‑Diagramm zu extrahieren. \n3. Aus dem Graphen die Service‑Accounts identifizieren, die Kerberoastable sind. \n4. Kerberoasting durchführen, Passwort knacken und auf den entsprechenden Servern erneut PtH ausführen – ein klassischer „privilege‑escalation‑Loop“.

Beispiel 3 – BloodHound und SharpHound\nBloodHound visualisiert AD‑Beziehungen. Mit dem PowerShell‑Wrapper SharpHound lässt sich das komplette Netzwerk auslesen.

# Auf dem kompromittierten Host, mit PtH‑Shell, PowerShell starten
Import-Module .\SharpHound.ps1

# Alle Daten sammeln (inkl. Session‑ und ACL‑Informationen)
Invoke-BloodHound -CollectionMethod All -Domain "corp.example.com" -ZipFileName bhdata.zip

# Daten in BloodHound UI importieren (Web‑Interface unter https://bh.corp.example.com)
# Im UI nach Knoten "Kerberoastable" filtern und zu privilegierten Konten verlinken

Nachdem du die Graph‑Ansicht hast, erkennst du sofort, welche Service‑Accounts über privilegierte Rechte verfügen und welche Computer sie hosten. Dort setzt du die Kerberoasting‑Methode ein, knacken das Passwort, loggst dich per PtH erneut ein und erhältst Administrator‑Zugriff auf weitere Systeme.

Einschätzung\nDie Kombination ist gefährlich, weil sie das Prinzip „einmal kompromittiert – nie zurück“ verkörpert. Ein einzelner PtH‑Fehler kann das gesamte Netzwerk offenlegen. Deshalb sollte jedes Unternehmen nicht nur auf einzelnen Ebenen, sondern auf das Zusammenspiel dieser Techniken achten. Im Pen‑Test‑Reporting empfehle ich daher immer, den “Attack-Path” von PtH → SharpHound → Kerberoasting → PtH zu visualisieren und entsprechende Gegenmaßnahmen zu definieren.

Häufige Fehler im Red Teaming

1. Nur ein Tool verwenden – Viele Red‑Team‑Ressourcen setzen ausschließlich auf Mimikatz für Credential‑Dumping. Dadurch übersehen sie, dass Kerberoasting ohne Dump überhaupt funktioniert.
2. Logs ignorieren – Event‑ID 4771 (Kerberos‑Pre‑Authentication‑Failure) und 4624 (Logon Type 2) geben Hinweise auf laufende PtH‑Versuche. Nicht‑Logging führt zu einer falschen Erfolgs‑Wahrnehmung.
3. Passwörter nicht rotieren – Wenn Dienstkonten nie geändert werden, bleibt das geknackte Passwort dauerhaft gültig. Das ist ein Konfigurations‑Fehler, den viele Unternehmen nicht bemerken.
4. Kein Netzwerk‑Segement‑Testing – PtH funktioniert nicht nur innerhalb einer Sub‑Netz, sondern auch über VPN‑Bridges. Ohne Segment‑Testing bleibt das Risiko verborgen.
5. Fehlende Nachbereitung – Nach erfolgreichem PtH oder Kerberoasting wird oft sofort abgebrochen, anstatt die gewonnenen Rechte zu nutzen, um weitere Persistenz‑Mechanismen zu etablieren (z. B. Golden‑Ticket). Das reduziert das Gesamtergebnis des Red‑Team‑Engagements.

Fazit & nächster Schritt

Du hast jetzt ein vollständiges Bild: PtH ist das klassische „Schlüssel‑Klauen“, Kerberoasting das moderne „Passwort‑Knacken“, und die Kombination beider Techniken eröffnet ein fast endloses Lateral‑Movement‑Spiel. Der kritische Punkt ist, dass beide Angriffe keine Super‑User‑Rechte voraussetzen – ein normaler Nutzer kann bereits weitreichende Schäden verursachen, wenn das Umfeld nicht härtet.

Konkreter nächster Schritt für dein Unternehmen:\n1. Audit – Führe ein automatisiertes Skript aus, das alle Benutzer‑ und Dienst‑SPNs auf Kerberoasting‑Potential prüft (z. B. Get‑ADUser -Filter * -Properties ServicePrincipalName).\n2. NTLM‑Deaktivierung – Schalte, wo möglich, NTLM‑Authentifizierung aus (Domain Policy → Network security: LAN Manager authentication level).\n3. gMSA‑Einführung – Migriere kritische Dienstkonten zu Managed Service Accounts, um die NT‑Hash‑Auflage zu eliminieren.\n4. Monitoring – Setze eine SIEM‑Rule ein, die gleichzeitig Event‑ID 4624 (Logon Type 3) und Event‑ID 4771 (Kerberos‑Pre‑Auth‑Failure) korreliert, um Live‑PtH‑Versuche zu entdecken.

Wenn du diese vier Maßnahmen binnen der nächsten 30 Tage umsetzt, reduzierst du das Risiko von erfolgreichen PtH‑ und Kerberoasting‑Attacken deutlich. Und denk dran: Der beste Schutz ist keine Angriffsfläche, sondern ein bewusstes, kontinuierliches Hardening‑Programm.