BOF_RunPE
BOF RunPE ist eine Beacon-Objektdatei für Cobalt Strike, die PE-Dateien vollständig im Speicher innerhalb des Beacon-Prozesses ausführt. Anders als beim traditionellen fork&run wird kein untergeordneter Prozess erzeugt, keine Konsole erstellt und keine Pipe verwendet – die gesamte Ausgabe wird über IAT-Hooking erfasst und an die Beacon-Konsole umgeleitet.
Architektur: nur x64
Übersicht
┌──────────────────────────────────────────────────────────────┐
│ Cobalt Strike Beacon │
│ (Current Process) │
└────────────────────────┬─────────────────────────────────────┘
│
│ beacon_inline_execute()
│
▼
┌──────────────────────────────────────────────────────────────┐
│ BOF RunPE │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ VxTable + Draugr Initialization │ │
│ │ (Syscall Resolution + Stack Spoofing) │ │
│ └──────────────────────┬─────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────▼─────────────────────────────────┐ │
│ │ PE Mapping │ │
│ │ - Section Copy - IAT Patching (with hooks) │ │
│ │ - Relocations - Memory Protection │ │
│ └──────────────────────┬─────────────────────────────────┘ │
│ │ │
│ ┌──────────────────────▼─────────────────────────────────┐ │
│ │ Thread Execution │ │
│ │ - Spoofed Start Address │ │
│ │ - RIP Hijacking to Entry Point │ │
│ │ - Output Redirection via Hooks │ │
│ └────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
Hauptfunktionen
- Keine Prozesserstellung: Die PE läuft innerhalb des Beacon-Prozesses
- Keine Konsole/Pipe: Ausgabe wird über
printf/WriteConsole-Hooks erfasst
- Mehrere Allokationsmethoden: Heap, VirtualAlloc, Module Stomping
- Proxy-Laden: Timer Queue, RegisterWait oder direkte Aufrufe
- Ntdll-Unhooking: Optional frische Kopie von der Festplatte
- RWX : Optional Speicher als RWX allozieren
- Thread-Start-Spoofing: Legitime Startadresse mit RIP-Hijacking
Konfigurationsoptionen
Das Verhalten des BOF kann bearbeitet werden in Additionals postex -> RunPe Config

Proxy-Methoden
| Methode | Beschreibung |
|---|
None | Direkte API-Aufrufe |
Draugr | Stack-gespoofte API-Aufrufe |
Regwait |
Allokationsmethoden
| Methode | Beschreibung |
|---|
Heap | Privater Heap über RtlCreateHeap mit Draugr |
VirtualAlloc | NtAllocateVirtualMemory mit Draugr |
Module stomping | Überschreibt den .text-Abschnitt einer legitimen DLL |
Allgemeine Optionen
Thread-Spoofing
| Option | Beschreibung |
|---|
ModuleName | Legitimes Modul für die Startadresse (z. B. Kernel32.dll) |
ProcedureName | Funktionsname innerhalb des Moduls (z. B. ) |
Ausgabeerfassung
Die gesamte PE-Ausgabe wird über IAT-Hooks an die Beacon-Konsole umgeleitet. Es wird kein Konsolenfenster und keine Named Pipe erstellt.
Evasion-Techniken
Erkennungsvektoren
Kernel-Telemetrie (ETW-TI)
NtGetContextThread / NtSetContextThread:
- Manipulation des Thread-Kontexts bei angehaltenen Threads und anschließendes Fortsetzen
Speicheroperationen:
- NtAllocateMemory-Allokation, kann RWX sein (abhängig von der Konfiguration)
- NtProtectVirtualMemory-Übergänge (RW → RX)
- Ausführbarer Speicher in Heap-Bereichen ist verdächtig (abhängig von der Konfiguration)
- Module Stomping erkennbar über Abschnitt-Hash-Abweichung (abhängig von der Konfiguration)
Verhaltensindikatoren
- Angehaltener Thread erstellt, Kontext auslesen und dann den Wert von RIP ändern
- Heap-Speicher als ausführbar markiert (wenn der Speicherallokator Heap ist)
- DLL mit
DONT_RESOLVE_DLL_REFERENCES geladen (wenn der Speicherallokator Module Stomping ist)
- ntdll .text-Abschnitt modifiziert (wenn Unhooking aktiviert ist)
Verwendung
Laden des Skripts
Cobalt Strike → Script Manager → Load → BOF_RunPe.cna
Aggressor-Befehle
beacon> runpe /path/to/binary.exe --arg1 value1


Kompilierung
Erfordert GCC 13 (mingw-w64). Verwenden Sie das bereitgestellte Dockerfile:
sudo docker build -t ubuntu-gcc-13 .
sudo docker run --rm -it -v "$PWD":/work -w /work ubuntu-gcc-13:latest make
Ausgabe: Bin/runpe.o
Einschränkungen
| Einschränkung | Beschreibung |
|---|
| CET | Control-flow Enforcement Technology kann synthetische Stack-Frames blockieren |
Credits / Ressourcen für die Entwicklung
Repos/Blogposts
Bücher
Windows Native API Programming von Pavel Yosifovich
Windows Internals, Part 1 von Pavel Yosifovich
Windows Internals, Part 2 von Andrea Allievi