Eden

Eden Loader ist ein PoC-UDRL für Cobalt Strike, das mit Crystal Palace erstellt wurde und Raphael Mudge's Page-Streaming-Technik mit einem modularen Callgate kombiniert (aktuell eine PIC-Version des Sleepmask-VS Draugr Callgate BOF).

Das Ziel von Eden Loader ist es:

Die Leistungsfähigkeit von Crystal Palace zu demonstrieren, 'Fähigkeiten' zu kombinieren (und wiederzuverwenden), um schnell benutzerdefinierte Loader/Tooling zu entwickeln
Als Beispielressource zu dienen, auf der andere aufbauen können
Sicherheitspraktikern zu helfen, zu verstehen, wie UDRLs funktionieren (es ist vollständig debuggbar)
Die Sicherheitsdiskussion zu informieren/anzuregen

Weitere Informationen zu Eden Loader finden Sie im zugehörigen Blog.

Hinweis: Der Zweck von Eden ist es, die Idee zu demonstrieren, Crystal Palace zu verwenden, um verschiedene 'Ausführungseinheiten' (d.h. Fähigkeiten) zu kombinieren, um benutzerdefinierte Loader zu erstellen. Es ist nicht als vollwertiger 'evasiver' Loader gedacht und ihm fehlen daher bewusst einige grundlegende OPSEC-Funktionen. Beispielsweise verwendet es RWX-Speicher und verfolgt/maskiert nicht den Heap-Speicher von Beacon (und ist daher anfällig für YARA-Signaturen wie diese).

Kurzanleitung

Hinweis: Diese Kurzanleitung geht davon aus, dass Sie Crystal Palace heruntergeladen/gebaut und die folgenden Schritte zur Konfiguration Ihrer Entwicklungsumgebung abgeschlossen haben.

Sie müssen zunächst die folgende Malleable C2-Einstellung setzen:

stage {
    set sleep_mask "false";
}

Öffnen Sie ein WSL-Terminal im Repository-Root und bauen Sie Eden Loader: make clean; make.
Kopieren Sie crystalpalace.jar in Ihr Cobalt Strike-Client-Verzeichnis.
Laden Sie eden.cna in den Cobalt Strike-Client.
Wenn Sie das nächste Mal ein Payload exportieren, wird Eden automatisch angewendet. Sie können dies überprüfen, indem Sie die Ausgabe in der Script-Konsole prüfen:

[14:55:55] [*] Generating Payload: HTTP -- Type: HTTP -- Arch: x64 -- Exit Function: Thread -- System Call: None -- HTTP Library: wininet
[14:55:56] [EDEN] Parsing C:\Users\wb\Desktop\eden\eden.spec...
[14:55:56] [EDEN] Applying eden ldr spec...
[14:55:56] [EDEN] Payload Size: 387060 bytes
[14:55:56] [*] Using user modified reflective DLL! DLLName=resources/beacon.x64.rl0k.dll Arch=x64

Hinweis: Eden unterstützt HTTP(S), DNS und Pivot Beacons.

Debug-Anleitung

Eine Einschränkung von Crystal Palace zum Zeitpunkt der Veröffentlichung ist, dass es derzeit nur Objektdateien unterstützt, die mit mingw erstellt wurden. Wenn Sie versuchen, ein mit MSVC oder Clang erstelltes COFF zu verwenden, erhalten Sie normalerweise Relokationsfehler. Dies kann frustrierend sein, da mingw pdb-Dateien nicht direkt unterstützt und es daher schwierig sein kann, beim Schreiben komplexer Windows-Tradecraft zu debuggen. Sie können jedoch die Option -g in Ihrem Makefile hinzufügen, um Debug-Informationen in ausführbare Builds einzubetten. Dies ermöglicht es, Ihren Code in WinDbg schrittweise zu durchlaufen. Weitere Informationen zu diesem Prozess finden Sie im folgenden Blog von Rastamouse.

Dieses Repository verwendet den obigen Ansatz, um standardmäßig einen Debug-Build von Draugr (draugr.x64.exe) und den Page-Streaming-Code (guardexec.x64.exe) zu erstellen. Der Draugr-Debug-Build hat keine Abhängigkeiten und wird daher sofort erstellt, aber wenn Sie den Page-Streaming-/IAT-Hook-Code schrittweise durchlaufen/debuggen möchten, müssen Sie die folgenden Schritte befolgen:

1. Beacon ohne Loader exportieren:

Laden Sie debug/export_beacon_with_no_ldr.cna in Ihren CS-Client und exportieren Sie ein stageless raw x64 (HTTP) Beacon in das Verzeichnis /eden/debug/. Dadurch wird eine Beacon-DLL ohne Reflective Loader exportiert, die wir verwenden können, um den guardexec-Einstiegspunkt zu simulieren.
(In WSL) $ xxd -i ./beacon_x64.bin > debug_beacon.h

2. Draugr-PIC-Stub aus Crystal Palace exportieren:

Dazu müssen Sie Crystal Palace von WSL aus mit $ ./piclink /<path>/eden/debug/draugr.spec x64 /<path>/eden/debug/draugr.bin ausführen. Dadurch wird Crystal Palace verwendet, um nur den Draugr-PIC-Stub auszugeben, den wir zum Simulieren des guardexec-Einstiegspunkts verwenden können.
(In WSL) $ xxd -i ./draugr.bin > debug_druagr.h

3. Debuggen in WinDbg starten:

Bauen Sie Eden nach den obigen Schritten neu: make clean;make
Öffnen Sie WinDbg und wählen Sie Launch executable (/eden/bin/draugr.exe oder /eden/bin/guardexec.exe)
Wählen Sie Open source file und wählen Sie die entsprechende .c-Datei (z.B. guardexec.c, wenn Sie den Page-Streaming-Code debuggen).
Sie können jetzt schrittweise vorgehen/Breakpoints setzen für entweder den eigenständigen Call-Stack-Spoofing-Draugr-Binary oder einen Live-Beacon mit IAT-Hooks. Als Warnung: Die Maskierung funktioniert im Debug-Modus nicht korrekt, da Crystal Palace einen Schlüssel während der Payload-Generierung einspielen muss.

Hinweis: Es gibt keine ausführbare Debug-Datei für den Loader, da es keine offensichtliche Möglichkeit gibt, Crystal Palace zu veranlassen, Debug-Payloads für Dinge wie verschlüsselte DLLs und deren Schlüssel zu exportieren. Daher wird es nicht trivial, simulierte 'verschlüsselte' PIC-Puffer zu übergeben.

Designüberlegungen

Eden Loader ist in erster Linie dazu gedacht, die Leistungsfähigkeit von Crystal Palace zu demonstrieren, indem verschiedene 'Fähigkeiten' kombiniert werden, um einen neuartigen Loader zu erstellen. Diese Idee könnte viel weiter getrieben werden als in diesem Repo (z.B. ein 'statischer' PIC-Loader, der vollständig über COFF-Module anpassbar ist (Guardrails, Callgates, Sleep Obfuscation usw.)).
Eden Loader verwendet explizit eine PIC-Version von Draugr, um jeden Aufruf des Beacon-Lebenszyklus spoofen zu können (d.h. die VirtualAlloc/LoadLibrary-Aufrufe, die während des Reflective-Loading-Prozesses verwendet werden). In manchen Fällen mag dies übertrieben sein (z.B. wenn ein EDR sich nicht für unbacked calls zu LoadLibrary interessiert), in diesem Fall könnte dies modifiziert werden, um ein PICO (=='BOF')-Äquivalent von Draugr zu verwenden, das viel einfacher ist.
Eden Loader versucht bewusst, das 'Callgate' vom Loader entkoppelt zu halten. Dies ist aus Gründen der Modularität so beabsichtigt, da die Idee ist, dass Sie BeaconGate/Callgate-BOFs austauschen könnten. Daher ist der Draugr-Callgate-Code vollständig in seiner eigenen Objektdatei enthalten. Indem Sie diese durch eine andere 'Fähigkeit' ersetzen, könnten Sie Edens TTPs drastisch verändern.
Eden Loader verwendet bewusst keine neueren Funktionen von Crystal Palace. Als Beispiel kann mergelib mit Crystal Palace's Shared Library, LibTCG, verwendet werden. Beachten Sie jedoch, dass dies bedeutet, dass Sie die Fähigkeit verlieren, Ihren Code zu debuggen.

Fehlerbehebung

Die Page-Stream-Technik kann die Beacon-Leistung für bestimmte Befehle beeinträchtigen (standardmäßig dauert die Prozessinjektion mit 4 sichtbaren Seiten etwa ~1 Min(!)). Sie können #define MAXVISIBLE in guardexec.h erhöhen, um die meisten Probleme zu beheben (der Standardwert für Eden ist 6). Allgemein kann Page Streaming Probleme mit Prozessinjektionstechniken verursachen (insbesondere, wenn sie auf Timing angewiesen sind).

Warum diese Veröffentlichung?

https://aff-wg.org/2025/03/13/the-security-conversation/

eden

Beliebteste