emp3r0r v4.15.0 — Self‑healing Gossip Mesh C2 with Assisted Peer Discovery, Cross-Platform BOF Execution, and Scriptable Agents.

emp3r0r

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

GitHub go.mod Go version GitHub License

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 keine Option sind. Statt eine zuverlässige Verbindung zu einem einzigen Server anzunehmen, bilden Agents ein selbstheilendes Mesh, das weiter funktioniert, wenn Verbindungen abbrechen. Statt das Ziel nach Python oder PowerShell zu fragen, führen sie alles im Speicher aus. Und statt dich auf die Tricks einer einzigen Plattform zu beschränken, führt emp3r0r Windows-BOFs, Linux-Objekte und Starlark-Skripte aus — alles fileless, alles im Prozess.

Wichtige Highlights & Einzigartige Funktionen

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

Jeder Agent trägt seine eigene Scripting-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 Command-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 proxyt direkt in System-DLLs.
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 eines Interpreters oder eines neuen Binaries auf dem Ziel.

🔐 TOFU-Kryptografische Identitäts-Pinning

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 Impostor behandelt und abgelehnt.
Das Entfernen eines Agents ist eine explizite Entscheidung des Operators, nichts, was ein gestohlener Schlüssel stillschweigend tun kann.

Warum das wichtig ist: Session-Hijacking und Agent-Cloning finden einfach 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 Traffic zu entschlüsseln.

🕸️ Autonomes P2P-Gossip-Mesh-Netzwerk

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

Peers verbinden sich über camouflage mTLS 1.3 oder zuverlässiges UDP (KCP), wobei jeder Hop verschlüsselt ist.
Traffic routet automatisch um tote Relays herum — 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 routen sich selbst neu.

📂 P2P-Dateisystem

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

Transfers laufen über verschlüsselte Peer-to-Peer-Tunnel, sodass interne Netzwerke nicht an deinem Server zum Flaschenhals werden.
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 & Pluggable Stagers

Der Einstieg eines Agents wird genauso ernst genommen wie sein Überleben.

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.
Pluggable Stager-Transporte und selbstentpackende Packer lassen dich den initialen Zugang in jeden Kanal einbetten, den dein Ziel zulässt, und unterlaufen dabei statisches Signature-Matching.
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 Cross-Platform BOF- & PICO-Unterstützung (COFF, ELF & PICO)

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

Windows COFF/BOF-Binaries mit typisierter Argument-Packung.
Linux ELF relocatable Objects, die direkt in den Agent-Speicher geladen werden.
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.

🧬 In-Memory-Bibliotheksloader (memmod)

Native Bibliotheken werden in den eigenen Adressraum des Agents gemappt und dort aufgerufen — kein LoadLibrary, kein dlopen, keine Datei berührt jemals die Festplatte.

memmod lädt PE-DLLs unter Windows und ELF .so unter Linux und übernimmt Relocations, Imports und Export-Aufrufe im Prozess.
Es baut auf bewährter Upstream-Arbeit auf: WireGuards memmod PE-Loader und den ELF-Loader und die Call-Machinery von Sliver C2 / sliverarmory/reflektor.
memdeps sitzt darüber: Eine deklarierte Abhängigkeit wird aus dem verschlüsselten memfs/C2 aufgelöst, nur für die Operation gemappt, die sie benötigt, und bei der Rückkehr wieder entmappt.

Warum das wichtig ist: Das Erweitern des Agents mit nativem Code erfordert kein neues Binary, keinen Loader-Dienst und keine Datei auf der Festplatte.

🐧 Linux-Module & eBPF

Linux-Module sind Starlark-Skripte, die bis in den Kernel reichen können. Der Agent mappt libbpf bei Bedarf und stellt seine API Skripten als Go-gestützte Builtins zur Verfügung, sodass ein Modul eBPF-Objekte aufzählen, an sie anhängen und sie abbauen kann — ohne Compiler und ohne Kindprozess.