emp3r0r v4.15.0

emp3r0r

Ein selbstheilendes, rein speicherbasiertes C2 für Linux und Windows — Agents, die abgebrochene Verbindungen überleben, niemals die Festplatte berühren und sich per Skript durch die Win32-API arbeiten.

Was ist emp3r0r?

emp3r0r ist ein Post-Exploitation-Framework und C2, das für Linux- und Windows-Umgebungen entwickelt wurde, in denen Stealth und Resilienz nicht optional sind. Statt eine zuverlässige Verbindung zu einem Server anzunehmen, bilden Agents ein selbstheilendes Mesh, das weiter funktioniert, wenn Verbindungen abbrechen. Statt vom Ziel Python oder PowerShell zu verlangen, führen sie alles im Speicher aus. Und statt dich auf die Tricks einer Plattform zu beschränken, führt emp3r0r Windows-BOFs, Linux-Objekte und Starlark-Skripte aus — alles fileless, alles im Prozess.

Wichtige Highlights & Einzigartige Funktionen

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

Jeder Agent trägt seine eigene Skript-Engine mit sich, sodass du neue Post-Exploitation-Logik einbringen kannst, ohne Binaries zu kompilieren oder auszuliefern.

• Skripte laufen vollständig im Speicher — kein Python, Bash oder PowerShell auf dem Ziel erforderlich, und keine Kommando-Interpreter werden gestartet.
• Ein vollständiger Satz integrierter APIs deckt Datei-I/O, HTTP, Befehlsausführung und mehr ab, direkt aus dem Skriptcode heraus.
• Unter Windows können Skripte native Win32-Funktionen direkt aufrufen — der Agent leitet direkt in System-DLLs weiter.
• Module sind einfache Starlark-Dateien mit einem kleinen JSON-Manifest, sodass das Hinzufügen eigener Module einfach und fileless ist.

Warum das wichtig ist: Das Schreiben und Erweitern von Agent-Funktionalität wird so einfach wie das Bearbeiten eines Skripts, ohne den Footprint, einen Interpreter oder ein neues Binary auf dem Ziel abzulegen.

🔐 TOFU-Kryptografische Identitätsbindung

Agents binden ihre Identität beim ersten Kontakt an einen kryptografischen Schlüssel — und diese Bindung ändert sich nie.

• Eine erneute Registrierung mit anderen Anmeldedaten wird als Eindringling behandelt und abgelehnt.
• Das Entfernen eines Agents ist eine explizite Entscheidung des Operators, nicht etwas, das ein gestohlener Schlüssel still und leise tun kann.

Warum das wichtig ist: Session-Hijacking und Agent-Cloning finden schlicht nicht statt; jeder Agent, mit dem du sprichst, ist der, den du registriert hast.

🔒 Perfect Forward Secrecy (PFS)

Jede C2- und Peer-Verbindung verwendet ephemere ECDH-Schlüssel mit sitzungsabgeleiteten Verschlüsselungsschlüsseln.

Warum das wichtig ist: Selbst wenn ein langfristiger Schlüssel später kompromittiert wird, kann er nicht verwendet werden, um bereits übertragenen Datenverkehr zu entschlüsseln.

🕸️ Autonomes P2P-Gossip-Mesh-Netzwerk

Agents entdecken sich gegenseitig und leiten Datenverkehr durch ein Gossip-Mesh weiter, sodass die Operation nicht zusammenbricht, wenn eine Verbindung oder ein Server verschwindet.

• Peers verbinden sich über getarntes mTLS 1.3 oder zuverlässiges UDP (KCP), wobei jeder Hop verschlüsselt ist.
• Der Datenverkehr umgeht tote Relays automatisch — keine manuelle Proxy-Chirurgie mitten in der Operation.
• Segmente ohne direkten C2-Zugang bleiben über ihre Nachbarn erreichbar.

Warum das wichtig ist: Das Netzwerk übernimmt das Pivoting für dich. Kappe eine Verbindung, verliere eine Box oder blockiere das C2 — Agents leiten sich selbst neu.

📂 P2P-Dateisystem

Dateien bewegen sich direkt zwischen Agents, nicht nur über das C2.

• Übertragungen laufen über verschlüsselte Peer-to-Peer-Tunnel, sodass interne Netzwerke nicht deinen Server zum Flaschenhals machen.
• Dateien werden im Agent-Speicher als verschlüsselte Blobs zwischengespeichert und Peers bei Bedarf bereitgestellt.
• Wenn kein Peer eine Datei hat, holt der Agent sie automatisch vom C2.

Warum das wichtig ist: Die Auslieferung ist schnell und für den C2-Kanal weitgehend unsichtbar — ideal für Umgebungen mit eingeschränktem Egress.

📡 Multi-Protokoll-Listener & Austauschbare Stager

Einen Agent hineinzubekommen wird genauso ernst genommen wie ihn am Leben zu halten.

• HTTP-, TCP- und UDP-Listener mit zuverlässigem Framing und anpassbaren HTTP-Profilen.
• Ein etwa 2KB großer Stager, der auf direkten Linux-Syscalls aufbaut — kein libc, keine Toolchain auf dem Ziel.
• Austauschbare Stager-Transporte und selbstentpackende Packer lassen dich den initialen Zugang in jeden Kanal einbetten, den dein Ziel zulässt, und unterwegs statische Signaturerkennung umgehen.
• Stage- und Agent-Code respektieren die Read/Write/Execute-Disziplin — niemals RWX.

Warum das wichtig ist: Kleiner, anpassungsfähiger und speicherhygienischer initialer Zugang bedeutet, dass du auf Hosts landen kannst, die sonst außer Reichweite wären.

🧩 Native plattformübergreifende BOF- & PICO-Unterstützung (COFF, ELF & PICO)

Führe kompilierte C-Module im Prozess auf beiden Plattformen aus:

• Windows COFF/BOF-Binaries mit typisierter Argumentverpackung.
• Linux ELF relocatable objects, direkt in den Agent-Speicher geladen.
• Crystal-Kit PICO-Module mit SilentMoonwalk-Callstack-Spoofing.
• Kerbeus-BOF, Remote-OPs und eine Situational-Awareness-Suite sind einsatzbereit.

Warum das wichtig ist: BOFs sind nur so gut wie ihr Loader — emp3r0r führt sie im Prozess aus, ohne neuen Prozess und ohne Spuren zu hinterlassen, auf Linux und Windows gleichermaßen.

🔑 Windows-Token, Netonly-Sessions & Kerberos-Tickets (PTT)

Sobald du auf einem Windows-Host bist, lässt emp3r0r dich die Benutzer darauf werden — ohne jemals ein Tool abzulegen.

• Stiehl ein Access Token aus einem beliebigen laufenden Prozess und nutze es überall: Go-Module, Starlark, BOFs.
• Erstelle wegwerfbare Netonly-Sessions mit dem --user-Flag eines Moduls: Sie behalten die eigene Identität deines Agents und leihen sich nur die des Zielbenutzers für ausgehenden Zugriff — jedes Passwort funktioniert, nichts wird jemals validiert.
• Importiere Kerberos-Tickets mit dem --ticket-Flag für vollständiges Pass-the-Ticket: Deine Netzwerkidentität wird die des Tickets (sagen wir, des Domain Admins), während deine lokale Identität sich nie ändert.
• Jedes token-fähige Modul akzeptiert --token, --user und --ticket, sodass der Identitätswechsel nur ein Flag entfernt ist — einschließlich des Erstellens einer Session und Ladens eines Tickets in einem einzigen Befehl.
• Tickets leben pro Anmeldesession, sodass das DA-Material in einer wegwerfbaren Session isoliert bleibt, die du bereinigen kannst, und der Agent-Prozess selbst sauber bleibt.

Warum das wichtig ist: Laterale Bewegung zu Maschinen, auf denen überhaupt kein Agent läuft — SMB-Freigaben, Service Control, CIFS — wird ein normaler Teil deines Workflows, authentifiziert als der geliehene Benutzer, nicht als ein Tool auf der Festplatte.

🧦 SOCKS5-Pivoting & Operator-seitiges tun2socks

Pivote, ohne ein weiteres Implant zu verbrennen: Das C2 betreibt einen SOCKS5-Proxy, der durch den von dir gewählten Agent weiterleitet, und die Operator-Seite kann mit einem transparenten TUN-Gerät noch einen Schritt weiter gehen.

• socks_start 1080 gibt dir einen SOCKS5-Endpunkt auf dem C2, der durch den gewählten Agent tunnelt — richte proxychains oder ein beliebiges Tool darauf und du bist im Zielnetzwerk.
• tun2socks start --route 10.10.0.0/24 erstellt ein TUN-Gerät, das nur die von dir benannten Subnetze durch diesen Proxy routet — alles andere nutzt weiterhin deine normale Verbindung.
• Das Ergebnis sieht aus, als käme es vom Agent, ohne Proxy-Konfiguration pro Tool.

Warum das wichtig ist: Erreiche ganze Agent-seitige Netzwerke transparent — curl auf einen DC, nutze jedes Tool — mit Egress, der aus dem Zielnetzwerk zu kommen scheint, nicht von deiner Operator-Box.

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

• Wähle Beacon-artiges HTTP-Polling oder Streaming-HTTP/2 — beide mit formbaren Profilen.
• TLS-Fingerabdrücke werden mit uTLS randomisiert, sodass der Kanal in der Netzwerk-Telemetrie nicht auffällt.
• Kontrollverkehr läuft über ein kompaktes CBOR-Protokoll — kleiner, schneller und schwerer zu parsen als JSON.

Warum das wichtig ist: Der C2-Kanal ist darauf ausgelegt, wie gewöhnlicher Datenverkehr auszusehen und schlank auf der Leitung zu bleiben.

💾 Verschlüsselter Memory-First-Speicher

• Agent-Dateioperationen laufen gegen ein speicherbasiertes, AES-GCM-verschlüsseltes virtuelles Dateisystem; große Datenmengen werden nur als verschlüsselte Blobs ohne identifizierbare Header auf die Festplatte ausgelagert.
• P2P-fähige Agents cachen, was sie abrufen, und teilen es mit Peers, wodurch der C2-Datenverkehr weiter schrumpft.

Warum das wichtig ist: Selbst die Festplatte wird als feindlich behandelt — der Agent behält keine Klartext-Artefakte zum Auffinden zurück.

Schnellstart

1. C2-Server-Installation

Das Bauen von emp3r0r erfordert Docker oder Podman auf dem Host — keine lokale Go-Toolchain.

git clone --depth=1 https://github.com/jm33-m0/emp3r0r.git && cd emp3r0r
./install.py

Der Installer baut alles in einem Wegwerf-Container und bereitet das Operator-Kit vor. Nützliche Flags: --lightweight (nur Linux/Windows amd64, am schnellsten), --targets OS/ARCH,..., --debug, --skip-build.

Starte den Server:

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

2. Einrichtung des Operator-Rechners

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

Verbinde dich mit den WireGuard-Anmeldedaten, die der Server ausgegeben hat:

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

In der Operator-Konsole:

# Direct C2 agent
generate --type linux_executable --arch amd64 --cc your.domain.com

# Mesh gateway agent (also reachable from the C2 directly)
generate --type linux_executable --arch amd64 --cc your.domain.com \
  --p2p --direct-c2 --p2p-transport mtls

# Mesh intermediate peer (relays for other agents)
generate --type linux_executable --arch amd64 --cc your.domain.com \
  --p2p --p2p-transport mtls --peers 1.2.3.4

# Windows mesh peer over SMB named pipes (local \\.\pipe, cross-host \\host\pipe),
# AES-GCM framed like the other transports
# (requires the Windows SMB stack / logon session to reach the peer)
generate --type windows_executable --arch amd64 --cc your.domain.com \
  --p2p --p2p-transport smb

Mesh-Knoten können unterschiedliche Transporte verwenden. Jeder Agent gibt den Transport und Port bekannt, auf dem sein Relay lauscht, und Dialer verwenden immer den vom Peer angekündigten Transport, sodass ein gemischtes Mesh (zum Beispiel Windows-SMB-Knoten neben Linux-mTLS- Knoten) durch einen Peer routet, der einen nutzbaren Transport teilt, statt anzunehmen, dass alle den lokalen Standard verwenden. smb wird nur für Windows-Payloads akzeptiert; kcp/mtls funktionieren überall.

Dokumentation & Ressourcen

• 📝 Security Policy: SECURITY.md
• 📜 Changelog: CHANGELOG.md
• 🛠️ Module Development Guide: core/modules/module_development_guide.md

Unterstütze die Entwicklung

Wenn sich emp3r0r in deiner Sicherheitsforschung und im Testing als wertvoll erwiesen hat, ziehe in Betracht, die weitere Entwicklung über GitHub Sponsors zu unterstützen.