emp3r0r

emp3r0r

Selbstheilendes Gossip-Mesh-C2 mit unterstützter Peer-Erkennung, plattformübergreifender BOF-Ausführung und skriptbaren Agenten.

Was ist emp3r0r?

emp3r0r ist ein fortschrittliches Post-Exploitation-Framework mit Zero-Trust-Architektur und ein Command-&-Control-System (C2), das für Linux- und Windows-Zielumgebungen entwickelt wurde. Von Grund auf für den Betrieb in Hochsicherheitsumgebungen konzipiert, vereint emp3r0r autonome Gossip-Mesh-Vernetzung, dateilose, rein speicherbasierte Ausführung, plattformübergreifendes BOF-Laden, Dateiübertragung zwischen Agenten und skriptbare In-Memory-Agenten, um überlegene Tarnung, operative Kontrolle und Operationssicherheit (OPSEC) zu bieten.

Wichtigste Highlights & besondere Funktionen

🐍 Skriptbare Agenten (eingebettete Starlark-Engine & Win32-API-Proxy)

emp3r0r-Agenten verfügen über eine eingebettete Starlark-Scripting-Engine (ein vollständig in Go implementierter Python-Dialekt). Skripte werden dateilos im Speicher ausgeführt, ohne dass Python, Bash oder PowerShell auf dem Zielsystem installiert sein müssen.

• Keinerlei Abhängigkeiten auf dem Zielsystem: Führt eigenständige Skripte aus, ohne Befehlsinterpreter (/bin/sh, powershell.exe) zu starten oder sich auf installierte Laufzeitumgebungen zu verlassen.
• Integrierte Go-APIs des Agenten: Stellt Funktionen für Dateisystemoperationen (read_file, write_file, list_dir, mkdir, remove, exists), HTTP-Netzwerkkommunikation (http_get, http_post), Befehlsausführung (exec_cmd) und Hashing (crypto_hash) bereit.
• Dynamischer Win32-API-Proxy: Auf Windows-Zielsystemen können Starlark-Skripte System-DLLs dynamisch laden und native Win32-APIs (win_call, , , ) direkt aus dem Skriptcode ausführen, ohne nativen C-Code zu kompilieren.

Warum das wichtig ist: Herkömmliche C2-Skriptmodule erfordern Host-Interpreter oder das Starten von Prozessen, was deutliche Spuren auf der Festplatte oder in der Befehlszeile hinterlässt. Die skriptbaren Agenten von emp3r0r führen komplexe Logik vollständig im Speicher mit nativer Systeminteraktion aus.

🔐 Kryptografisches Identitäts-Pinning per TOFU

emp3r0r erzwingt Trust-On-First-Use (TOFU) mit strenger UUID- und Public-Key-Bindung bei der Registrierung von Agenten.

• Unveränderliche Bindung: Nach der Registrierung ist die UUID eines Agenten fest an seinen kryptografischen öffentlichen Schlüssel gebunden. Eine erneute Registrierung mit veränderten Anmeldedaten wird als Impersonationsversuch abgelehnt.
• Kontrolliertes Zurücksetzen: Die Abmeldung erfordert eine ausdrückliche Autorisierung durch den Operator über forget_agent.

Warum das wichtig ist: Verhindert Session-Hijacking, das Klonen von Agenten und eine unbemerkte Identitätsdrift über operative Umgebungen hinweg.

🔒 Perfect Forward Secrecy (PFS)

Die gesamte C2- und Peer-Kommunikation erzwingt ECDH-Schlüsselaustausch mit per HKDF abgeleiteten Sitzungsschlüsseln.

• Ephemere Schlüssel: Jede Sitzung erzeugt einzigartige Verschlüsselungsschlüssel.
• Entkoppelte Sicherheit: Die Kompromittierung langfristiger Schlüssel oder eines einzelnen Agenten kann vergangene oder parallele Kommunikation nicht gefährden.

Warum das wichtig ist: Verhindert die nachträgliche Entschlüsselung abgefangener Netzwerk-Mitschnitte.

🕸️ Autonomes P2P-Gossip-Mesh-Netzwerk

Agenten in Netzwerksegmenten mit eingeschränktem ausgehendem Datenverkehr oder in isolierten Segmenten entdecken autonom Peers und tunneln Datenverkehr über ein gossip-basiertes (Memberlist) Mesh-Netzwerk.

• Austauschbare Peer-Transports: Unterstützung für getarntes mTLS 1.3 (mit ephemeren Zertifikaten) und KCP (zuverlässiges UDP).
• Ende-zu-Ende-Verschlüsselung: Alle Mesh-Hops zwischen Agenten sind mit AES-GCM-Verschlüsselung geschützt.
• Geringer Netzwerk-Fußabdruck: Die direkte Weiterleitung von Agent zu Agent eliminiert unnötiges Broadcast-Rauschen und zentralisierte C2-Verbindungsengpässe.

Warum das wichtig ist: Das Pivotieren über segmentierte Netzwerke erfolgt autonom, ohne dass ein ständiges Eingreifen des Operators oder statische Proxy-Konfigurationen erforderlich sind.

📂 P2P-Dateisystem

Direkter Dateiaustausch von Agent zu Agent über den P2P-Relay-Transport (mTLS/KCP), um die Dateizustellung in internen Netzwerken zu beschleunigen.

• Verschlüsselte P2P-Tunnel: Tunnelt Übertragungen über Peers mittels mTLS/KCP, um Einschränkungen des ausgehenden Datenverkehrs zu umgehen und zentrale C2-Bandbreitenengpässe zu reduzieren.
• Intelligentes In-Memory-Datei-Caching: Dateien werden im Speicher des Agenten als verschlüsselte Blobs zwischengespeichert; sie können nahtlos für andere Agenten zum bedarfsweisen Herunterladen bereitgestellt werden. Wenn ein Agent eine Datei anfordert, durchsucht er zuerst sein lokales memfs, dann andere Peers und schließlich den C2-Server.
• Automatisches C2-Relay-Fallback: Wenn ein Ziel-Peer die angeforderte Datei nicht besitzt, holt er sie dynamisch bei Bedarf vom C2-Server und streamt sie.

Warum das wichtig ist: Der direkte Dateiaustausch von Agent zu Agent maximiert die Übertragungsgeschwindigkeit, umgeht Netzwerkengpässe und reduziert die Sichtbarkeit des direkten C2-Datenverkehrs.

📡 Multi-Protokoll-Listener & Stager

Flexible Stage-0-Downloader-Stager und Protokoll-Listener für den Erstzugriff und die Payload-Zustellung.

• Multi-Protokoll-Listener: Eingebettete und eigenständige HTTP-, TCP- und UDP-Listener mit zuverlässigem Sequenz-Bestätigungs-Framing und benutzerdefinierten HTTP-Profilen.
• Eigenständiger C-Downloader-Stager: Entwickelt mit direkten, libc-unabhängigen Linux-Syscalls für Kompatibilität über Distributionen hinweg ohne Symbolfehler.
• Winzige Payload-Größe: Während die Binaries der emp3r0r-Agenten unkomprimiert etwa 20 MB groß sind, liegt dieser Stager unter 1,5 KB; die sRDI-ähnliche Payload, die er vom emp3r0r-Listener abruft, ist etwa 8 MB groß (komprimiert aus der Agenten-Binary im ELF-Shared-Object-Format).
• Flexible Formate: Kompiliert zu rohem positionsunabhängigem Shellcode (.bin), eigenständigen ELF-Executables oder Shared Objects (.so).
• In-Memory-Härtung: Weist Stager-Speicher mit Lese-Schreib-Berechtigungen zu, entschleiert Payloads und erzwingt Read-Execute, bevor Stage 1 reflektiv ausgeführt wird.

🧩 Nativer plattformübergreifender BOF-Support (COFF & ELF)

Führt In-Memory-Binärmodule sowohl auf Windows- als auch auf Linux-Zielsystemen aus:

• Windows-COFF-Loader: Führt Windows-BOF-Binaries dateilos mit typisierter Parameterverpackung (int, short, cstr, wstr, binary) aus.
• Linux-ELF-Object-Loader: Lädt ELF-Relocatable-Object-Dateien (.o) unter Linux direkt in den Speicher des Agenten.
• Gebündelte BOF-Suiten: Integrierte Unterstützung für die Modulsammlungen Kerbeus-BOF, Remote-OPs und Situational Awareness (SA).

Warum das wichtig ist: Eliminiert den Overhead der Prozesserstellung und umgeht die Überwachung der Befehlszeile, indem kompilierte C-Module prozessintern ausgeführt werden.

🔑 Bedarfsweise Windows-Token-Manipulation

Agenten unter Windows können Zugriffstokens aus laufenden Prozessen stehlen, zwischenspeichern und impersonieren – vollständig prozessintern unter Verwendung indirekter NT-Syscalls.

• Stehlen & Zwischenspeichern: steal_token --pid <PID> dupliziert ein Prozess-Token über NtOpenProcess + NtDuplicateToken und speichert es im Speicher, abgelegt nach SID. Optional kann die Impersonation mit --token <sid> verkettet werden, um von einer gestohlenen Identität zu einer anderen zu eskalieren.
• Auflisten: list_tokens zeigt alle zwischengespeicherten Tokens mit Namen im Format DOMAIN\User (SID) an.
• Universelle Impersonation: Ein zwischengespeichertes Token kann per SID (--token <sid>) in jedem Modul referenziert werden – Go, Starlark, COFF/BOF. Thread-Level-Impersonation (NtSetInformationThread) wird bei sensiblen Operationen angewendet.
• Token-bewusstes Starlark: Eingebaute Funktionen (read_file, write_file, exec_cmd, Win32-API-Proxy usw.) impersonieren automatisch pro Syscall, wenn ein Token gesetzt ist, und kann über Kindprozesse unter der gestohlenen Identität starten.

Warum das wichtig ist: Keine externen Tools, keine Festplatten-Artefakte, kein Prozesserstellungs-Rauschen. Tokendiebstahl und -wiederverwendung erfolgen vollständig prozessintern mit indirekten Syscalls, wobei gestohlene Tokens sofort von jedem eingebauten Modul verwendet werden können.

🎭 Austauschbarer C2-Transport, uTLS-JA3-Evasion & CBOR-Protokoll

• Austauschbare C2-Modi: Flexibles Beaconing (http_poll) mit anpassbaren HTTP-Profilen und Streaming (h2conn) über HTTP/2.
• JA3-Signatur-Randomisierung: Verwendet uTLS, um TLS-Client-Hello-Fingerprints zu randomisieren und damit statische Netzwerksignaturen zu überwinden.
• Binäres Wire-Protokoll: Verwendet CBOR (Concise Binary Object Representation) für alle Steuerdaten und die Wire-Serialisierung, wodurch die Netzwerk-Payload-Größen im Vergleich zu JSON um 30-40% reduziert werden.

💾 Verschlüsselte Memory-First-Speicherung

• Verschlüsseltes virtuelles In-Memory-Dateisystem: Alle Dateioperationen des Agenten verwenden ein virtuelles AES-GCM-Dateisystem im Arbeitsspeicher. Große Datenmengen werden automatisch auf verschlüsselten Festplattenspeicher ausgelagert, ohne erkennbare Header oder Dateiendungen.
• Intelligentes Caching mit P2P-Unterstützung: Jeder P2P-fähige Agent speichert die Dateien, die er vom C2 abruft, in memfs zwischen; anschließend stellt er sie anderen Peers zur Verfügung, wodurch der C2-Datenverkehr minimiert wird und gleichzeitig schnelle Verbindungen zwischen Agenten genutzt werden.

Schnellstart

1. Installation des C2-Servers

Zum Erstellen von emp3r0r werden Docker oder Podman auf dem Host benötigt. Eine lokale Go-Toolchain ist nicht erforderlich.

# Clone repository
git clone --depth=1 https://github.com/jm33-m0/emp3r0r.git && cd emp3r0r

# Build inside a container and install locally
./install.sh

Der Installer kompiliert die Kern-Binaries in einem Wegwerf-Container, erzeugt das vorkompilierte emp3r0r-operator-kit.tar.zst, konfiguriert die erforderlichen Linux-Capabilities (setcap) und richtet die System-Laufzeitverzeichnisse ein.

Optionen:

./install.sh [--debug] [--disable-garble] [--prefix /usr/local] [--skip-build]

C2-Server starten:

emp3r0r server --c2-hosts 1.2.3.4 --http-port 12345 --operator-port 13377

Hinweis: Wenn die Installation mit dem Benutzer root statt mit dem üblichen sudo erfolgt, kann Ihr aktueller Benutzer emp3r0r möglicherweise nicht starten, da der Installer die Berechtigungen nicht ordnungsgemäß setzen kann. Das gilt auch für Ihre Operator-Maschinen.

2. Einrichtung der Operator-Maschine

Übertragen Sie das erzeugte emp3r0r-operator-kit.tar.zst auf Ihre Operator-Maschine und führen Sie den Installer aus:

tar --zstd -xpf emp3r0r-operator-kit.tar.zst
cd ./emp3r0r-operator-kit && ./install.sh

Verbinden Sie den Operator-Client mithilfe der vom Server ausgegebenen WireGuard-Tunnel-Zugangsdaten mit dem C2-Server:

emp3r0r client --c2-port 13377 \
  --server-wg-key '<SERVER_WG_KEY>' \
  --server-wg-ip '<SERVER_WG_IP>' \
  --operator-wg-ip '<OPERATOR_WG_IP>' \
  --operator-wg-key '<OPERATOR_WG_KEY>' \
  --c2-host 1.2.3.4

3. Agenten-Payloads erzeugen

Verwenden Sie den Befehl generate in der emp3r0r-Operator-Oberfläche, um Payloads zu generieren.

Direkter C2-Agent:

generate --type linux_executable --arch amd64 --cc your.domain.com

Mesh-Gateway-Agent:

generate --type linux_executable --arch amd64 --cc your.domain.com \
  --p2p --direct-c2 --p2p-transport mtls

Mesh-Zwischenpeer:

generate --type linux_executable --arch amd64 --cc your.domain.com \
  --p2p --p2p-transport mtls --peers 1.2.3.4

Dokumentation & Ressourcen

• 📝 Sicherheitsrichtlinie: SECURITY.md
• 📜 Changelog: CHANGELOG.md
• 🛠️ Leitfaden zur Modulentwicklung: core/modules/module_development_guide.md

Entwicklung unterstützen

Wenn sich emp3r0r in Ihrer Sicherheitsforschung und Ihren Tests als wertvoll erwiesen hat, erwägen Sie, seine weitere Entwicklung über GitHub Sponsors zu unterstützen.