DbgNexum - Shellcode-Injektion

DbgNexum ist ein Proof-of-Concept zum Injizieren von Shellcode mithilfe der Windows-Debugging-API und gemeinsam genutztem Speicher (Dateizuordnung). Es vermeidet das direkte Schreiben und Lesen von Remote-Speicher und nutzt stattdessen Kontextmanipulation, um den Zielprozess zu zwingen, die Payload selbst zu laden und auszuführen.

Übersicht

Der Injizierer hängt an einen Zielprozess an und erstellt einen angehaltenen Thread. Über eine Debug-Schleife setzt er einen Hardware-Breakpoint, um die Ausführung an einer bestimmten Rücksprungadresse abzufangen. Bei jedem Trap verändert der Injizierer die CPU-Register, um Funktionsaufrufe nachzuahmen und so eine Abfolge von Windows-API-Funktionsaufrufen im Zielprozess zu orchestrieren.

Zum Zeitpunkt der Erstellung dieser README habe ich die Technik gegen MDE und Elastic getestet; keiner der beiden hat sie erkannt.

Hauptfunktionen

• Kein WriteProcessMemory / VirtualAllocEx: Die Payload wird über CreateFileMapping und MapViewOfFile übertragen.
• Kein ReadProcessMemory: Der Ansatz bezieht alle wichtigen Informationen aus dem Thread-Kontext.

Verwendung

Der PoC verwendet einen XOR-verschlüsselten msfvenom-Shellcode, der "calc.exe" startet. Bitte verwende aber deinen eigenen Shellcode!

1. Füge deinen Shellcode (und XOR-Schlüssel) in shellcode.h ein.
2. Ermittle die Prozess-ID des Ziels.
3. Führe den Injizierer aus:

DbgNexum.exe <PID>

Beispielausgabe:

[i] Section 'MZ' created and shellcode copied
[+] Bait thread created. Setting HWBP on FileTimeToSystemTime
[i] Execution Redirected:
|-> [0] Preparation & anchoring stack
|-> [1] Setting HWBP & buffer alloc
|-> [2] Copying File-Mapping name
|-> [3] Zeroing stack slot
|-> [4] Opening handle to named file mapping
|-> [5] Mapping payload into mem. with exec. perm.
|-> [6] Cleanup & shellcode execution
[+] Successfully detached from process 19256
[i] Orchestration complete.

So funktioniert es

Der Ausführungsfluss ist ein ständiges Hin und Her zwischen der Debug-Schleife des Injizierers und dem Zielprozess.

Injektionsphasen

Die Funktion DebugLoop enthält die Hauptinjektionslogik und orchestriert die "Zustandsmaschine":

0. Vorbereitung:

• Der Injizierer speichert den aktuellen Stack-Pointer, um ihn für jede Phase wiederzuverwenden.
• Um die Rücksprungadresse des verankerten Stacks zu erhalten, setzen wir ein Trap-Flag und setzen die Ausführung auf einen sofortigen ret-Aufruf.

1. Speicherzuweisung:

• Setze einen HWBP auf die Rücksprungadresse des verankerten Stacks, um benachrichtigt zu werden, wenn eine aufgerufene Funktion zurückkehrt.
• Bereite den Thread vor und erzwinge einen Aufruf von LocalAlloc, um (natürlich) einen kleinen Puffer zu reservieren.

2. Datenvorbereitung:

• Bereite den Thread vor und erzwinge einen Aufruf von memcpy, um die Zeichenkette MZ in den zuvor reservierten Puffer zu kopieren.

3. Stack-Vorbereitung:

• Erzwinge einen Aufruf von memset, um einen Stack-Slot zu nullen. Dies dient der Vorbereitung von Phase 5, die MapViewOfFile aufrufen wird. Da die Funktion mehr als 4 Argumente verwendet, wird das 5. Argument über den Stack übergeben (das wir hier setzen).

4. Mapping öffnen:

• Erzwinge einen Aufruf von OpenFileMappingA durch den Thread, wobei der Name MZ verwendet wird, der in den Phasen 2 und 3 "erstellt" wurde.

5. Payload mappen:

• Zwingt den Zielprozess, MapViewOfFile aufzurufen. Dadurch wird der gemeinsame Speicherabschnitt (der den Shellcode enthält) mit EXECUTE-Berechtigungen in den Adressraum des Ziels gemappt.

6. Ausführung:

• Leitet RIP auf die von MapViewOfFile zurückgegebene Adresse um.
• Löscht die Debug-Register und trennt die Verbindung zum Zielprozess.