jm33-m0/emp3r0rSelf‑healing Gossip Mesh C2 with Assisted Peer Discovery, Cross-Platform BOF Execution, and Scriptable Agents.
<img align="left" width="150" height="150" alt="emp3r0r" src="https://assets.kitploit.com/production/public/readmes/388/73c4ac7800cb1c221dd61e97f3f9ccad66bc8c5dea12ad532ea7765746d423b6.png" /> ### emp3r0r **A self-healing, memory-only C2 for Linux and Windows — agents that survive broken links, never touch disk, and script their way through the Win32 API.** <br clear="all" /> [](https://discord.gg/vU98aQtk9f) [](https://github.com/sponsors/jm33-m0)  [](https://github.com/jm33-m0/emp3r0r/actions/workflows/test.yml)  [](https://github.com/jm33-m0/emp3r0r/releases) --- <img width="1925" height="1147" alt="emp3r0r-readme" src="https://github.com/user-attachments/assets/945aef28-1c07-4701-a6d9-b8029ad8251e" /> ## What is emp3r0r? emp3r0r is a post-exploitation framework and C2 built for Linux and Windows environments where stealth and resilience aren't optional. Instead of assuming a reliable connection back to one server, agents form a self-healing mesh that keeps working when links break. Instead of asking the target for Python or PowerShell, they execute everything in memory. And instead of limiting you to one platform's tricks, emp3r0r runs Windows BOFs, Linux objects, and Starlark scripts — all fileless, all in-process. --- ## Key Highlights & Unique Features ### 🐍 Scriptable Agents (Embedded Starlark Engine & Win32 API Proxy) Every agent carries its own scripting engine, so you can drop in new post-exploitation logic without compiling or shipping binaries. - Scripts run entirely in memory — no Python, Bash, or PowerShell required on the target, and no command interpreters spawned. - A full set of built-in APIs covers file I/O, HTTP, command execution, and more, straight from script code. - On Windows, scripts can call native Win32 functions directly — the agent proxies straight into system DLLs. - Modules are plain Starlark files with a small JSON manifest, so adding your own is easy and fileless. **Why this matters:** writing and extending agent functionality becomes as simple as editing a script, with none of the footprint of dropping an interpreter or a new binary on the target. --- ### 🔐 TOFU Cryptographic Identity Pinning Agents bind their identity to a cryptographic key the first time they talk to you — and that binding never changes. - Re-enrollment with different credentials is treated as an impostor and rejected. - Removing an agent is an explicit operator decision, not something a stolen key can do quietly. **Why this matters:** session hijacking and agent cloning simply don't happen; every agent you talk to is the one you enrolled. --- ### 🔒 Perfect Forward Secrecy (PFS) Every C2 and peer link uses ephemeral ECDH keys with session-derived encryption keys. **Why this matters:** even if a long-term key is compromised later, it can't be used to decrypt traffic that already passed. --- ### 🕸️ Autonomous P2P Gossip Mesh Network Agents discover each other and relay traffic through a gossip mesh, so the operation doesn't collapse when one link or one server disappears. - Peers connect over camouflage mTLS 1.3, Windows SMB named pipes, or reliable UDP (KCP), with every hop encrypted. - Traffic routes around dead relays automatically — no manual proxy surgery mid-operation. - Segments with no direct C2 access still stay reachable through their neighbors. **Why this matters:** the network does the pivoting for you. Cut a link, lose a box, or block the C2 — agents re-route on their own. --- ### 📂 P2P Filesystem Files move between agents directly, not just through the C2. - Transfers ride encrypted peer-to-peer tunnels, so internal networks don't bottleneck on your server. - Files are cached in agent memory as encrypted blobs and served to peers on demand. - If no peer has a file, the agent fetches it from the C2 automatically. **Why this matters:** delivery is fast and mostly invisible to the C2 channel — ideal for egress-restricted environments. --- ### 📡 Multi-Protocol Listeners & Pluggable Stagers Getting an agent in is treated as seriously as keeping it alive. - HTTP, TCP, and UDP listeners with reliable framing and customizable HTTP profiles. - A roughly 2KB stager built on direct Linux syscalls — no libc, no toolchain on the target. - Pluggable stager transports and self-unpacking packers let you blend initial access into whatever channel your target allows, and defeat static signature matching along the way. - Stage and agent code respect read/write/execute discipline — never RWX. **Why this matters:** small, adaptable, and memory-hygienic initial access means you can land on hosts that would otherwise be out of reach. --- ### 🧩 Native Cross-Platform BOF & PICO Support (COFF, ELF & PICO) Run compiled C modules in-process on either platform: - Windows COFF/BOF binaries with typed argument packing. - Linux ELF relocatable objects loaded straight into agent memory. - Crystal-Kit PICO modules with SilentMoonwalk callstack spoofing. - Kerbeus-BOF, Remote-OPs, and a Situational Awareness suite ship ready to use. **Why this matters:** BOFs are only as good as their loader — emp3r0r runs them in-process with no new process and no trace left behind, on both Linux and Windows. --- ### 🧬 In-Memory Library Loader (memmod) Native libraries are mapped into the agent's own address space and called there — no `LoadLibrary`, no `dlopen`, no file ever hits disk. - `memmod` loads PE DLLs on Windows and ELF `.so` on Linux, handling relocations, imports, and export calls in-process. - It builds on proven upstream work: WireGuard's `memmod` PE loader and the [Sliver C2](https://github.com/BishopFox/sliver) / [sliverarmory/reflektor](https://github.com/sliverarmory/reflektor) ELF loader and call machinery. - `memdeps` sits above it: a declared dependency is resolved from encrypted memfs/C2, mapped only for the operation that needs it, and unmapped on return. **Why this matters:** extending the agent with native code doesn't require a new binary, a loader service, or a file on disk. --- ### 🐧 Linux Modules & eBPF Linux modules are Starlark scripts that can reach all the way into the kernel. The agent maps `libbpf` on demand and exposes its API to scripts as Go-backed builtins, so a module can enumerate, attach to, and tear down eBPF objects with no compiler and no child process. - The builtins mirror libbpf: `ebpf_progs`, `ebpf_maps`, `ebpf_links`, `ebpf_detach`, `ebpf_map_wipe`, `ebpf_code_offset`, and the long-lived `ebpf_uprobe_start`/`ebpf_uprobe_stop`. - [`ssh_harvest`](https://github.com/jm33-m0/emp3r0r/blob/v5/core/modules/ssh_harvest) is the worked example: it locates a pattern in `sshd`, attaches a long-lived uprobe, streams captured credentials live, and holds it until `--disable` — no ptrace, no breakpoints, no disk. - libbpf is not the only option: the same on-demand loader handles any `.so` a module declares or supplies, and scripts can map bytes directly with `mem_load_library`. **Why this matters:** kernel-level tradecraft is a script plus a library the agent maps only while it needs it, then drops. --- ### 🔑 Windows Tokens, Netonly Sessions & Kerberos Tickets (PTT) Once you're on a Windows host, emp3r0r lets you _become_ the users on it — without ever dropping a tool. - Steal an access token from any running process and use it everywhere: Go modules, Starlark, BOFs. - Create disposable netonly sessions with a module's `--user` flag: they keep your agent's own identity and only borrow the target user's for outbound access — any password works, nothing is ever validated. - Import Kerberos tickets with the `--ticket` flag for full pass-the-ticket: your network identity becomes the ticket's (say, the Domain Admin) while your local identity never changes. - Every token-aware module accepts `--token`, `--user`, and `--ticket`, so switching identity is one flag away — including creating a session and loading a ticket in a single command. - Tickets live per logon session, so the DA material stays quarantined in a disposable session you can purge, and the agent process itself stays clean. **Why this matters:** lateral movement to machines running no agent at all — SMB shares, service control, CIFS — becomes a normal part of your workflow, authenticated as the user you've borrowed, not as a tool on disk. --- ### 🧦 SOCKS5 Pivoting & Operator-Side tun2socks Pivot without burning another implant: the C2 runs a SOCKS5 proxy that relays through the agent you select, and the operator side can go one step further with a transparent TUN device. - `socks_start 1080` runs a SOCKS5 endpoint on the C2's WireGuard address that tunnels through the chosen agent; reach it from inside the tunnel, or let `tun2socks` dial it for you. - `tun2socks start --route 10.10.0.0/24` creates a TUN device that routes only the subnets you name through that proxy — everything else keeps using your normal connection. - The result looks like it originates from the agent, with no per-tool proxy configuration. **Why this matters:** reach entire agent-side networks transparently — curl a DC, use any tool — with egress that appears to come from the target network, not your operator box. --- ### 🎭 Pluggable C2 Transport, uTLS JA3 Evasion & CBOR Protocol - Choose beacon-style HTTP polling, streaming HTTP/2, or a QUIC UDP channel — HTTP/2 and QUIC are opt-in build tags (`with_h2conn`, `with_quic`). The QUIC channel obfuscates every datagram with a per-build static key by default; the `--quic-standard-key` generate flag opts out and speaks stock QUIC (interoperable with HTTP/3 endpoints). Every channel supports malleable profiles. - TLS fingerprints are randomized with uTLS, so the channel doesn't stand out in network telemetry. - Behind an ECH-capable CDN edge, `--ech` (with `--doh`) encrypts the inner SNI so the real C2 hostname never appears in the ClientHello. - Control traffic rides a compact CBOR protocol — smaller, faster, and harder to parse than JSON. **Why this matters:** the C2 channel is made to look like ordinary traffic and stay lean on the wire. --- ### 🪶 Modular Agents — Opt In To What You Need Every unused subsystem is another dependency and another string for a defender to find. Optional agent subsystems are opt-in with `with_*` build tags, so a payload carries only what the mission needs. - `--agent-tags 'with_quic with_utls'` compiles in exactly those features; `--list-agent-tags` prints the full reference. The default full build enables every feature; `--agent-slim` builds the minimal agent (plain HTTP polling with `crypto/tls`, no optional subsystems). - C2 server binaries always keep the full feature set, so one C2 serves every agent flavour. - Pick tags by scenario. **Why this matters:** a smaller implant has a shorter string table and fewer third-party dependencies for EDR and AV to key on, while still speaking the full C2 protocol. --- ### 💾 Encrypted Memory-First Storage - Agent file operations run against an in-memory, AES-GCM-encrypted virtual filesystem; large data spills to disk only as encrypted blobs with no identifiable headers. - P2P-capable agents cache what they fetch and share it with peers, shrinking C2 traffic further. **Why this matters:** even disk is treated as hostile — the agent keeps no plaintext artifacts around to find. --- ## Quick Start See [OPERATOR.md](https://github.com/jm33-m0/emp3r0r/blob/v5/OPERATOR.md) for the full deployment and operator guide: C2 server installation, operator setup (native Linux or the recommended Windows container), container capabilities, tmux keybindings and agent payload generation. --- ## Documentation & Resources - 🖥️ **Operator Guide:** [OPERATOR.md](https://github.com/jm33-m0/emp3r0r/blob/v5/OPERATOR.md) - 🛠️ **Module Development Guide:** [core/modules/module_development_guide.md](https://github.com/jm33-m0/emp3r0r/blob/v5/core/modules/module_development_guide.md) - 🧪 **Testing Guide:** [TESTING.md](https://github.com/jm33-m0/emp3r0r/blob/v5/TESTING.md) - 📝 **Security Policy:** [SECURITY.md](https://github.com/jm33-m0/emp3r0r/blob/v5/SECURITY.md) - 📜 **Changelog:** [CHANGELOG.md](https://github.com/jm33-m0/emp3r0r/blob/v5/CHANGELOG.md) --- ## Support Development If emp3r0r has proven valuable in your security research and testing, consider supporting its continued development via [GitHub Sponsors](https://github.com/sponsors/jm33-m0).
