
Ein Shellcode-Loader-Generator mit Unterstützung für mehrere Injektionstechniken, entwickelt für Red-Team-Einsätze.
hollow ist ein Shellcode-Loader-Generator. Sie geben ihm eine rohe Shellcode-Binärdatei und ein Profil, und es gibt einen kompilierten Windows-PE-Loader aus, der Ihren verschlüsselten Shellcode enthält.
Binärdateien sind auf der Releases Seite verfügbar, oder bauen Sie aus dem Quellcode:
go build -o hollow .
Erfordert x86_64-w64-mingw32-gcc für die Kreuzkompilierung.
Auf Arch Linux: pacman -S mingw-w64-gcc
Auf Debian/Ubuntu: apt install gcc-mingw-w64-x86-64
./hollow -shellcode payload.bin -profile profiles/new_process_injection_sc.json
| Flagge | Beschreibung |
|---|---|
-shellcode | Pfad zur rohen Shellcode-Datei (.bin) |
-profile | Pfad zu einer Profil-JSON-Datei |
-templates | Vorlagenverzeichnis (Standard: ./templates) |
hollow folgt einer dreistufigen Pipeline: verschlüsseln, ersetzen, kompilieren.
Ihr Shellcode wird bei jedem Durchlauf mit AES-256-CBC unter Verwendung eines zufällig generierten Schlüssels und IV verschlüsselt. Beide werden in der Ausgabebinärdatei eingebettet. Die gewählte C-Vorlage hat dann ihre Platzhalter durch den verschlüsselten Shellcode, den Schlüssel und das IV ersetzt, und das Ergebnis wird von MinGW zu einem gestrippten, statisch gelinkten PE kompiliert.
Zur Laufzeit entschlüsselt der Loader den Shellcode mit Windows BCrypt und führt ihn mit der Injektionstechnik aus, die die Vorlage implementiert.
Vorlagen sind die C-Quelldateien, die die eigentliche Injektionslogik implementieren. Jede befindet sich in templates/ und enthält Platzhalter-Token (${SHELLCODE}, ${KEY}, ${IV}, ${TARGET_PROCESS}), die hollow vor der Kompilierung ausfüllt. Sie wählen eine Vorlage über Ihr Profil aus.
hollow wird mit sechs Vorlagen geliefert:
| Vorlage | Technik |
|---|---|
new_process_injection | Remote-Thread-Injektion in einen neu gestarteten Prozess |
new_process_injection_sc | Gleiches, über direkte Syscalls (Hell's Gate) |
remote_thread_injection | Klassische Remote-Thread-Injektion in einen vorhandenen Prozess |
remote_thread_injection_sc | Gleiches, über direkte Syscalls (Hell's Gate) |
earlybird_apc | Early-Bird-APC-Injektion |
dll_sideload | DLL-Sideloading, erzeugt eine DLL anstelle einer EXE |
Sie können eigene Vorlagen schreiben und in templates/ ablegen – hollow erkennt sie automatisch, solange Ihr Profil auf sie verweist.
Profile sind JSON-Dateien, die hollow mitteilen, welche Vorlage verwendet werden soll, welcher Prozess anvisiert wird und wie die Ausgabe kompiliert werden soll. Sie befinden sich in profiles/ und sollen für jeden Einsatz angepasst werden.
{
"name": "New Process Injection via Direct Syscalls",
"author": "",
"template": "new_process_injection_sc",
"target_process": "C:\\Windows\\System32\\cmd.exe",
"arch": "x64",
"compile": {
"automatic": true,
"gcc": "x86_64-w64-mingw32-gcc",
"strip": true,
"output_type": "exe"
},
"output_dir": "./output"
}
output_type ist entweder exe oder dll. Setzen Sie automatic: false, um die ersetzte C-Quelle auf die Festplatte zu speichern, anstatt sie zu kompilieren. Nützlich, wenn Sie den Code vor dem Bauen ändern möchten.
Die Ausgabedatei wird in output_dir geschrieben, benannt als {template}_loader.{exe|dll}.
Vorlage: new_process_injection
Technik: Remote-Thread-Injektion in einen neu gestarteten Prozess.
Startet den Zielprozess mit CREATE_BREAKAWAY_FROM_JOB | CREATE_NO_WINDOW, wartet zwei Sekunden auf seine Initialisierung, allokiert dann Speicher in seinem Adressraum, schreibt den entschlüsselten Shellcode, markiert ihn als ausführbar und erstellt einen Remote-Thread, der darauf zeigt. Das BREAKAWAY-Flag ist erforderlich, wenn der Loader von WinRM gestartet wird, das alle Prozesse in ein Job-Objekt einschließt. Das Ziel ist ein vollständiger ausführbarer Pfad.
Win32-Aufrufe: CreateProcessA, VirtualAllocEx, WriteProcessMemory, VirtualProtectEx, CreateRemoteThread.
Vorlage: new_process_injection_sc
Technik: Remote-Thread-Injektion in einen neu gestarteten Prozess, über direkte Syscalls (Hell's Gate).
Gleiches Verhalten wie new_process_injection, aber jeder Allokations- und Threading-Aufruf umgeht die Win32-Ebene vollständig. SSNs werden zur Laufzeit aus ntdll aufgelöst und über die rohe syscall-Anweisung ausgeführt. Siehe den Abschnitt Benchmark.
Vorlage: remote_thread_injection
Technik: Klassische Remote-Thread-Injektion in einen vorhandenen Prozess.
Findet einen laufenden Prozess anhand des Namens mit CreateToolhelp32Snapshot, öffnet ein Handle darauf, allokiert dann Speicher, schreibt den Shellcode und erstellt einen Remote-Thread. Es wird kein neuer Prozess gestartet. Am besten für langlebige Prozesse wie explorer.exe geeignet. Das Ziel ist ein Prozess-Image-Name, kein vollständiger Pfad.
Win32-Aufrufe: OpenProcess, VirtualAllocEx, WriteProcessMemory, VirtualProtectEx, CreateRemoteThread.
Vorlage: remote_thread_injection_sc
Technik: Klassische Remote-Thread-Injektion in einen vorhandenen Prozess, über direkte Syscalls (Hell's Gate).
Gleiches Verhalten wie remote_thread_injection, umgeht die Win32-Ebene. Siehe den Abschnitt Benchmark.
Vorlage: earlybird_apc
Technik: Early-Bird-APC-Injektion (CyberArk, 2018).
Startet den Zielprozess im angehaltenen Zustand (CREATE_SUSPENDED | CREATE_BREAKAWAY_FROM_JOB | CREATE_NO_WINDOW), schreibt den entschlüsselten Shellcode in seinen Adressraum, reiht dann einen Asynchronous Procedure Call (APC) an den Hauptthread ein, der auf den Shellcode zeigt, mittels QueueUserAPC, und setzt mit ResumeThread fort. Da der APC ausgelöst wird, bevor der Prozesseinstiegspunkt läuft, wird der Shellcode ausgeführt, bevor defensive Tools im Prozess initialisiert sind. Vermeidet die Triade VirtualAllocEx + WriteProcessMemory + CreateRemoteThread vollständig.
Vorlage: dll_sideload
Technik: DLL-Sideloading / In-Process-Shellcode-Ausführung.
Erzeugt eine DLL anstelle einer EXE. Bei DLL_PROCESS_ATTACH wird ein Thread gestartet, der den Shellcode prozessintern entschlüsselt und ausführt: VirtualAlloc, memcpy, VirtualProtect, dann ein direkter Funktionsaufruf in den Shellcode. Der Host-Prozess muss am Leben bleiben, während das Payload initialisiert (etwa 10 Sekunden für einen Sliver-Beacon). Bereitstellen, indem Sie die DLL an einem Ort ablegen, an dem eine legitime Binärdatei sie über einen fehlenden DLL-Suchpfadeintrag lädt.
Getestet auf Windows 10 Build 19041, Windows Defender-Echtzeitschutz aktiviert, Definitionen 1.453.354.0, mit einem 17 MB Donut-umhüllten Sliver-Beacon als Payload:
| Vorlage | Defender-Verhaltenswarnung | Sitzung hergestellt |
|---|---|---|
| new_process_injection | Trojan:Win64/AsyncRat.RPY!MTB | ja |
| remote_thread_injection | Trojan:Win64/AsyncRat.RPY!MTB | ja |
| earlybird_apc | keine | ja |
| dll_sideload | keine | ja |
| new_process_injection_sc | keine | ja |
| remote_thread_injection_sc | keine | ja |