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

Benutzerdefiniertes BOF

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

Option	Beschreibung

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

Mimikatz

beacon> help runpe

Hilfe

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

`AllocRWX`	Als RWX allozieren (statt RW→RX-Übergang)
`UnhookNtdll`	ntdll.dll .text durch eine frische Kopie von der Festplatte ersetzen
`Timeout`	Ausführungs-Timeout in Millisekunden (0 = unendlich)
`StompModule`	DLL-Pfad für Module Stomping (z. B. `chakra.dll`)

`GetCommandLineA/W`	Gibt gespoofte Argumente zurück
`__getmainargs` / `__wgetmainargs`	CRT-Argumentinitialisierung
`printf` / `wprintf`	BeaconPrintf-Weiterleitung
`WriteConsoleA/W`	BeaconPrintf-Weiterleitung
`__stdio_common_vfprintf`	UCRT-Druckfunktionen
`ExitProcess` / `exit`	In ExitThread umgewandelt

Indirekte Syscalls	Userland-API-Hooks (EDR/AV)
Draugr Stack Spoofing	Call-Stack-Inspektion
Thread Start Spoofing	Analyse der Thread-Startadresse
Module Stomping	Erkennung von nicht hinterlegtem Speicher
Private Heap Allocation	VirtualAlloc-Überwachung
Ntdll Unhooking	ntdll im Speicher durch ntdll von der Festplatte ersetzen
IAT-Hooking (keine Pipes)	Named-Pipe-Überwachung

BOF_RunPe

Beliebteste