emp3r0r v4.7.1

emp3r0r

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

Was ist emp3r0r?

emp3r0r ist ein fortschrittliches Zero-Trust-Post-Exploitation-Framework und 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 reine Speicherausführung, plattformübergreifendes BOF-Laden, Dateiübertragung zwischen Agents und im Speicher skriptbare Agents, um überlegene Tarnung, operative Kontrolle und operative Sicherheit (OPSEC) zu gewährleisten.

Wichtigste Highlights & Einzigartige Funktionen

🐍 Skriptbare Agents (Eingebettete Starlark-Engine & Win32-API-Proxy)

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

• Null Host-Abhängigkeiten: Führt eigenständige Skripte aus, ohne Befehlsinterpreter (/bin/sh, powershell.exe) zu starten oder auf installierte Laufzeitumgebungen angewiesen zu sein.
• Integrierte Agent-Go-APIs: Verfügbare Funktionen für Dateisystemoperationen (read_file, write_file, list_dir, mkdir, remove, exists), HTTP-Netzwerk (http_get, http_post), Befehlsausführung (exec_cmd) und Hashing (crypto_hash).
• Dynamischer Win32-API-Proxy: Auf Windows-Zielen können Starlark-Skripte dynamisch System-DLLs laden und native Win32-APIs (win_call, win_alloc, win_free, win_read_mem) direkt aus dem Skriptcode ausführen, ohne nativen C-Code zu kompilieren.
• Modulare Integration: Starlark-Skripte werden über JSON-Manifeste (config.json) definiert, um eine nahtlose CLI-Parameteranalyse und -Verteilung zu ermöglichen.

Warum das wichtig ist: Herkömmliche C2-Skriptmodule erfordern Host-Interpreter oder Prozess-Spawning, was schwere Datenträger- oder Befehlszeilen-Ausführungsspuren hinterlässt. Die skriptbaren Agents von emp3r0r führen komplexe Logik vollständig im Speicher mit nativer Systeminteraktion aus.

🔐 TOFU-Kryptografische Identitäts-Pinning

emp3r0r erzwingt Trust-On-First-Use (TOFU) mit strengem UUID- und Public-Key-Pinning bei der Agent-Registrierung.

• Unveränderliche Bindung: Nach der Registrierung wird die UUID eines Agents an seinen kryptografischen öffentlichen Schlüssel gebunden. Eine erneute Registrierung mit geänderten Anmeldeinformationen wird als Identitätswechsel-Versuch abgelehnt.
• Kontrolliertes Zurücksetzen: Die Abmeldung erfordert eine ausdrückliche Operator-Autorisierung über forget_agent.

Warum das wichtig ist: Verhindert Session-Hijacking, Agent-Klonen und stilles Identitäts-Driften über operative Umgebungen hinweg.

🔒 Perfekte Vorwärtsgeheimhaltung (PFS)

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

• Ephemere Schlüssel: Jede Sitzung generiert eindeutige Verschlüsselungsschlüssel.
• Entkoppelte Sicherheit: Die Kompromittierung von Langzeitschlüsseln oder eines einzelnen Agents kann vergangene oder parallele Kommunikation nicht kompromittieren.

Warum das wichtig ist: Verhindert die retrospektive Entschlüsselung abgefangener Netzwerkaufzeichnungen.

🕸️ Autonomes P2P-Gossip-Mesh-Netzwerk

Agents in egress-eingeschränkten oder isolierten Netzwerksegmenten entdecken autonom Peers und tunneln Verkehr über ein Gossip-basiertes (Memberlist) Mesh-Netzwerk.

• Steckbare Peer-Transports: Unterstützung für Tarn-mTLS 1.3 (mit ephemeren Zertifikaten) und KCP (zuverlässiges UDP).
• Ende-zu-Ende-Verschlüsselung: Alle Mesh-Hops zwischen Agents sind mit AES-GCM-Verschlüsselung umhüllt.
• Geringer Netzwerk-Fußabdruck: Direkte Agent-zu-Agent-Weiterleitung eliminiert unnötiges Broadcast-Rauschen und zentralisierte C2-Verbindungsengpässe.

Warum das wichtig ist: Das Pivoting über segmentierte Netzwerke erfolgt autonom, ohne ständige Operator-Eingriffe oder statische Proxy-Einrichtungen.

📂 P2P-Dateisystem

Direkter Agent-zu-Agent-Dateiaustausch über P2P-Relay-Transport (mTLS/KCP), um die Dateizustellung über interne Netzwerke zu beschleunigen.

• Verschlüsselte P2P-Tunnel: Tunnelübertragungen über Peers mit mTLS/KCP, um Egress-Beschränkungen zu umgehen und zentrale C2-Bandbreitenengpässe zu reduzieren.
• Intelligentes In-Memory-Datei-Caching: Dateien werden im Agent-Speicher als verschlüsselte Blobs zwischengespeichert; sie können nahtlos für andere Agents zum bedarfsgesteuerten Download bereitgestellt werden. Beim Anfordern einer Datei prüfen Agents zuerst ihr lokales Memfs, dann andere Peers und schließlich das C2.
• Automatischer C2-Relay-Fallback: Wenn ein Ziel-Peer die angeforderte Datei nicht besitzt, holt er sie dynamisch und streamt sie bei Bedarf vom C2-Server.

Warum das wichtig ist: Direkter Agent-zu-Agent-Dateiaustausch maximiert Übertragungsgeschwindigkeiten, umgeht Netzwerkengpässe und reduziert die Sichtbarkeit des direkten C2-Verkehrs.

📡 Multi-Protokoll-Listener & Steckbare 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ässiger Sequenz-Bestätigungs-Framing und anpassbaren HTTP-Profilen. Der eigenständige Listener unterstützt optionales TLS (-tls) und generiert automatisch ein selbstsigniertes Zertifikat, wenn kein Zertifikat/Schlüsselpaar bereitgestellt wird.
• Eigenständiger C-Downloader-Stager: Gebaut mit direkten, libc-unabhängigen Linux-Syscalls für Kompatibilität über Distributionen hinweg ohne Symbolfehler.
• Verschlüsselte Stage-Zustellung: Der Listener verschlüsselt die gestagte Payload mit RC4 unter Verwendung eines Schlüssels, der aus einem vom Operator bereitgestellten Geheimnis abgeleitet wird; der Stager entschlüsselt sie im Speicher vor dem reflektiven Laden.
• Steckbare Stager-Transports: Modulares Transportsystem, das es Operatoren ermöglicht, benutzerdefinierte C-Transportmodule (transport_<name>.c) einzubringen. Integrierte eigenständige Optionen umfassen HTTP, TCP und UDP über rohe Syscalls sowie dynamische Bibliothekstransporte (z. B. libcurl über Laufzeit-Symbolauflösung).
  • Vorteile: Umgeht Egress-Filterung und Netzwerkerkennung, indem Verkehr nahtlos in legitime Systemkanäle (z. B. natives libcurl oder benutzerdefinierte Protokollimplementierungen) eingebettet wird, ohne die Kern-Stager-Logik zu verändern.
• Steckbare Selbst-entpackende Packer: Erweiterbare Stub- und Packer-Modulschnittstelle (pack_<name>.py + unpack_stub_<name>.c). Operatoren können benutzerdefinierte Pack-/Verschleierungsalgorithmen schreiben (integrierte Optionen umfassen RC4-Stream-Verschlüsselung und gierige LZSS-Kompression) mit automatischem Laufzeit-Header-Patching.
  • Vorteile: Bricht statische AV/EDR-YARA-Regeln und Signaturübereinstimmungen, indem die Stage-0-Payload mit einzigartigen Schlüsseln oder Algorithmen verschlüsselt/komprimiert wird, die sich selbst in Lese-/Schreibspeicher entpacken, der dann vor der Ausführung auf Lese-/Ausführen umgestellt wird.
• Winzige Payload-Größe: Während emp3r0r-Agent-Binaries ohne Kompression ~20 MB groß sind, ist dieser Stager 2 KB groß; die sRDI-ähnliche Payload, die er vom emp3r0r-Listener holt, ist ~8 MB (komprimiert aus dem Agent-Binary im ELF-Shared-Object-Format).
• Flexible Formate: Kompiliert zu rohem positionsunabhängigem Shellcode (.bin), selbst-entpackendem gepacktem Shellcode (packed), eigenständigen ELF-Ausführungsdateien oder Shared Objects (.so).
• In-Memory-Härtung: Allokiert Stage-Speicher als Lese/Schreiben, de-obfuskiert Payloads und erzwingt dann Lese/Ausführen vor dem reflektiven Laden. Der Selbst-Entpacker mappt niemals RWX (Lesen/Schreiben → Entpacken → Lesen/Ausführen), und der veränderliche Stager-Zustand befindet sich auf einer dedizierten Lese-/Schreibseite und nicht in beschreibbarem Code.

🧩 Natives plattformübergreifendes BOF- & PICO-Support (COFF, ELF & PICO)

Führt In-Memory-Binärmodule auf Windows- und Linux-Zielen aus:

• Windows-COFF-Loader: Führen Windows-BOF-Binaries dateilos mit typisierter Parameterverpackung (int, short, cstr, wstr, binary) aus.
• Linux-ELF-Objekt-Loader: Laden ELF-relozierbare Objektdateien (.o) direkt in den Agent-Speicher auf Linux.
• Crystal-Kit-PICO-Module & Stack-Spoofing: Integrierte PICO-Loader (Position-Independent Code Object) und Packer mit SilentMoonwalk-Callstack-Desync-Spoofer für erweiterte Umgehung.
• Gebündelte BOF-Suiten: Integrierter Support für Kerbeus-BOF-, Remote-OPs- und Situational-Awareness-Modulsammlungen (SA).

Warum das wichtig ist: Eliminiert Prozesserstellungs-Overhead und umgeht Befehlszeilen- und Callstack-Überwachung, indem kompilierte C-Module im Prozess mit Callstack-Spoofing ausgeführt werden.

🔑 On-Demand-Windows-Token-Manipulation

Agents auf Windows können Zugriffstokens von laufenden Prozessen stehlen, zwischenspeichern und impersonieren — vollständig im Prozess unter Verwendung indirekter NT-Syscalls.

• Stehlen & Zwischenspeichern: steal_token --pid <PID> dupliziert ein Prozess-Token über NtOpenProcess + NtDuplicateToken und speichert es im Speicher 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 DOMAIN\User (SID)-Namen an.
• Universelle Impersonation: Referenzieren Sie ein zwischengespeichertes Token per SID (--token <sid>) in jedem Modul — Go, Starlark, COFF/BOF. Thread-Ebene-Impersonation (NtSetInformationThread) wird um sensible Operationen herum 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 exec_cmd kann untergeordnete Prozesse unter der gestohlenen Identität über CreateProcessWithTokenW starten.

Warum das wichtig ist: Keine externen Tools, keine Datenträger-Artefakte, kein Prozesserstellungs-Rauschen. Token-Diebstahl und -Wiederverwendung erfolgen vollständig im Prozess unter Verwendung indirekter Syscalls, wobei gestohlene Tokens sofort von jedem eingebauten Modul konsumierbar sind.

🎭 Steckbarer C2-Transport, uTLS-JA3-Umgehung & CBOR-Protokoll

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

💾 Verschlüsselter Speicher-First-Speicher

• In-Memory-Verschlüsseltes Virtuelles Dateisystem: Alle Agent-Dateioperationen verwenden ein In-Memory-AES-GCM-Virtuelles-Dateisystem. Große Daten werden automatisch auf verschlüsselten Datenträgerspeicher ausgelagert, ohne identifizierbare Header oder Erweiterungen.
• P2P-gestütztes Smart-Caching: Jeder P2P-fähige Agent cached die Dateien, die er vom C2 holt, im Memfs; dann stellt er sie anderen Peers zur Verfügung, wodurch der C2-Verkehrs-Fußabdruck minimiert wird, während schnelle Inter-Agent-Verbindungen genutzt werden.

Schnellstart

1. C2-Server-Installation

Das Erstellen von emp3r0r erfordert Docker oder Podman auf dem Host. Keine lokale Go-Toolchain erforderlich.

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

# In einem Container bauen und lokal installieren
./install.py

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

Optionen:

./install.py [--debug] [--disable-garble] [--prefix /usr/local] [--skip-build] \
  [--lightweight] [--targets linux/amd64,windows/amd64]

Verwenden Sie --lightweight, um nur linux/amd64- und windows/amd64-exe/dll-Ziele zu bauen (am schnellsten, für reine x86-64-Bereitstellungen), oder --targets OS/ARCH,..., um einen bestimmten Satz von Payload-Typen zu kompilieren.

Starten Sie den C2-Server:

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

Hinweis: Wenn mit root-Benutzer statt mit Standard-sudo installiert, kann Ihr aktueller Benutzer emp3r0r möglicherweise nicht starten, da Berechtigungen vom Installer nicht ordnungsgemäß gesetzt werden können. Das gilt auch für Ihre Operator-Maschinen.

2. Operator-Maschinen-Einrichtung

Übertragen Sie das generierte 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.py

Verbinden Sie den Operator-Client mit dem C2-Server unter Verwendung der WireGuard-Tunnel-Anmeldeinformationen, die vom Server ausgegeben werden:

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. Agent-Payloads generieren

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

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-Zwischen-Peer:

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

Dokumentation & Ressourcen

• 📝 Sicherheitsrichtlinie: SECURITY.md
• 📜 Änderungsprotokoll: CHANGELOG.md
• 🛠️ Modulentwicklungsleitfaden: core/modules/module_development_guide.md

Entwicklung unterstützen

Wenn emp3r0r sich in Ihrer Sicherheitsforschung und -prüfung als wertvoll erwiesen hat, erwägen Sie, seine fortlaufende Entwicklung über GitHub Sponsors zu unterstützen.