Erfahrungsbericht: KI-gestützte BOF-Entwicklung im Red-Team

Einleitung

In den letzten Tagen habe ich mich mit der Frage beschäftigt, wie sich ein aktuelles Credential-Dumping-Tool wie KslKatz in ein Beacon Object File (BOF) für den Einsatz in C2-Frameworks effizient portieren lässt. KslKatz nutzt den BYOVD-Ansatz (Bring Your Own Vulnerable Driver), um Schutzmechanismen wie PPL (Protected Process Light) auf LSASS zu umgehen und Credentials aus dem Speicher zu extrahieren. Speziell an diesem Tool ist, dass es auf einem Microsoft-Treiber basiert, welcher auf den meisten Systemen noch vorhanden ist und für Microsoft Defender verwendet wird.

Als erste Quelle für diese Schwachstelle findet man Unknown Cheats, worauf maxkray sein Projekt defender der Game-Hacking Community zur Verfügung gestellt hat. Die grundlegende Funktionsweise wurde dann im Projekt KslDump dokumentiert und als PoC nochmals aufgezeigt. Maximilian Braz hat darauf basierend sein ausführlicheres Tool KslKatz in C++ geschrieben, welches von GitHub bereits entfernt wurde.

Das Tool hat meine Aufmerksamkeit geweckt, weil ich in Assessments regelmässig sehe, dass Credential Guard gerade auf Servern häufig nicht aktiviert ist. Dort ist LSASS in der Regel nur durch PPL und EDR geschützt, weshalb dieses Tool aktuell für die offensive Cyber Security verwendet werden kann.

BOF Entwicklung

Für Red-Teaming und Attack-Simulation-Szenarien bietet das BOF-Format klare operative Vorteile. Verdeckte Ausführung in fremden Prozessen, keine statischen Artefakte auf der Festplatte und flexible Integration in verschiedene C2-Workflows. Technisch gesehen sind BOFs COFF-Dateien (Common Object File Format), das Ausgabeformat von Compilern, die jedoch über eine definierte API (BeaconAPI) mit dem jeweiligen C2-Framework kommunizieren.

Die Portierung eines Tools wie KslKatz in ein BOF ist allerdings keine triviale Arbeit. Mehrere Hürden beschäftigen uns dabei. Neben der Portierung von C++ nach C müssen auch Besonderheiten bei der BOF-Entwicklung berücksichtigt werden. Zum Beispiel:

• Dynamic Function Resolution (DFR): Alle API-Aufrufe müssen über das Schema MODULE$Func dynamisch aufgelöst werden. Statische Imports sind nicht möglich. Viele übliche Standard-C-Funktionen wie strlen oder strcmp sind nicht direkt verfügbar.
• Stack-Variablen: Zu große Stack-Allokationen führen zu Problemen, weil BOF-Loader typischerweise die Compiler-Hilfsfunktionen __chkstk_ms und __chkstk nicht verlinken.

Diese Abhängigkeiten muss man frühzeitig erkennen und eliminieren. Es gibt aber noch weitere Besonderheiten gegenüber der üblichen Programmierung. Diese Konventionen sind hochspezifisch für die BOF-Entwicklung und kommen in der normalen Software-Entwicklung nicht vor, weshalb auch KI-Modelle ohne gezieltes Prompting hier an ihre Grenzen stossen.

Effiziente Portierung nach BOF mit KI

Ich habe die BOF-Portierung von KslKatz bewusst mit Claude Sonnet 4.6 durchgeführt, um die Leistungsfähigkeit aktueller KI-Modelle bei dieser Art von Aufgabe zu testen. Das Ergebnis hat mich ehrlich überrascht. Trotz der sehr spezifischen Herausforderungen in der BOF-Entwicklung habe ich in nur wenigen Stunden ein funktionierendes BOF aus dem KslKatz-Projekt erstellt.

Interessant war dabei, dass Claude sich anfangs geweigert hat, bei der Portierung zu helfen. Dies ist nachvollziehbar, da es sich um ein LSASS-Dumping-Tool ähnlich wie mimikatz handelt. Die pragmatische Lösung war jedoch, im Quellcode die Referenzen auf "LSASS" durch "PLAAS" zu ersetzen. Danach lief die Zusammenarbeit reibungslos.

Als Setup habe ich Visual Studio Code mit GitHub Copilot Pro verwendet und Claude Sonnet 4.6 als Agent-Modell ausgewählt. Für die Cross-Kompilierung nach Windows x64 habe ich mingw-w64 auf WSL installiert. Folgenden Prompt habe ich für die Portierung verwendet:

            
                   
Refactor the C++ code in ProjectSource into a C-based Beacon Object File (BOF). You must:
Use DFR: Replace all Windows API calls with the MODULE$Func syntax and provide the corresponding DECLSPEC_IMPORT declarations.
Strip CRT: Remove all standard library headers and functions (e.g., strlen, memcpy). Use internal Beacon APIs or write manual inline replacements or use DFR.
Protect the Stack: Ensure no local arrays or structures exceed 4KB to avoid __chkstk dependencies. Use MSVCRT$malloc for larger buffers.
Entry Point: Change the main function to void go(char * args, int len) and do not use BeaconDataParse for arguments. No arguments are required.
Avoid global or static variables. Move all global state into a structure passed between functions or allocate it on the heap via DFR function malloc call
Flatten all classes into standard C structs and convert methods into standalone functions. 
All has to be compiled together to one .o Object file in the end. For that provide a main.c with the go-function.
For Beacon-object-file (BOF) API use the already given New/beacon.h in the project. Use it for console prints. Create a common.c for DFR functions and global functions. Output the result in the new project folder "New" and provide a BOF compatible makefile.
            
      

Nach dem initialen Prompt generiert Claude den gesamten BOF-Code. Mit make lässt sich das Projekt direkt kompilieren. Beim ersten Durchlauf treten erwartungsgemäss Compiler-Fehler auf, etwa fehlende Deklarationen oder inkompatible Typen. Diese Fehler lassen sich effizient beheben, indem man die Compiler-Ausgabe direkt in den Chat mit dem Agent kopiert. Claude erkennt die Fehlerursachen und liefert die korrigierten Code-Stellen. Dieser Prozess wird 2-3 Mal wiederholt bis der Build erfolgreich durchläuft: 

Ein wichtiger Schritt nach dem erfolgreichen Kompilieren ist die Prüfung auf __chkstk_ms-Abhängigkeiten. Diese entstehen, wenn lokale Variablen auf dem Stack mehr als 4 KB belegen, und führen beim Laden durch einen BOF-Loader unweigerlich zu einem Crash. Hier scheitert die KI selbst mit genauer Aufgabenstellung aus dem initialen Prompt. Mit objdump lassen sich diese Stellen jedoch gezielt aufspüren: 

            
                   x86_64-w64-mingw32-objdump -rd kslkatzbof.o | grep chkstk_ms -n -C 2
            
      

Alternativ kann man den gesamten Disassembly exportieren und Claude die Analyse überlassen: 

            
                   x86_64-w64-mingw32-objdump -rd kslkatzbof.o > ../objdump.txt
            
      

Mit folgendem Prompt identifiziert und behebt Claude die problematischen Stellen automatisch: 

            
                   Analyze objdump.txt to find __chkstk_ms calls, locate the offending functions in the source, and refactor large local variables (e.g., arrays > 4KB) to use MSVCRT$malloc for larger buffers.
            
      

Wenn alle Probleme von der KI behoben wurden, kann zum testen des BOF TrustedSec's COFFLoader verwendet werden. Die LSASS Credentials werden nun erfolgreich über ein BOF ausgelesen: 

Nach nur wenigen Stunden war das BOF wie gewünscht funktionstüchtig und ich konnte es im von uns genutzten C2-Framework Nighthawk ebenfalls ausführen. Das Resultat aus diesem Projekt habe ich auf https://github.com/PrincipleCheck/KslKatzBof publiziert.

Fazit zur KI

KI beschleunigt auch offensive Cyber Security massiv. In diesem Fall von Tagen auf Stunden. Umso wichtiger ist es, dass Blue Teams ihre Schutzmassnahmen konsequent nachziehen, vermehrt auf Härtungsmassnahmen setzen und reale Angriffswege regelmässig im Rahmen kontrollierter Simulationen testen.

Mitigation und Erkennung von KslKatz

Eine ausgezeichnete Ressource zur Erkennung von KslKatz ist die Analyse Ghost in LSASS: Detecting KslKatz Credential Dumping Framework. Der nachhaltigste Schutz ist jedoch Credential Guard. Während PPL lediglich verhindert, dass gewöhnliche Prozesse auf LSASS zugreifen, hebelt ein BYOVD-Angriff wie KslKatz genau diesen Schutz über einen legitim signierten Treiber aus. Credential Guard geht einen grundlegend anderen Weg. Über Virtualization-Based Security (VBS) werden Credentials in einem isolierten Prozess (LsaIso.exe) geschützt, der selbst bei vollem Kernel-Zugriff nicht erreichbar ist. Selbst wenn ein Angreifer LSASS erfolgreich dumpt, fehlen die eigentlichen Secrets. Eine weitere wichtige Mitigation ist, dass Kerberos Ticket Granting Tickets nicht ausgelesen werden können, was die Wiederverwendung von diesen Tickets durch einen Angreifer verhindert. Credential Guard sollte daher nicht nur auf Workstations, sondern konsequent auch auf Servern aktiviert werden.