by jm33-m0
Stealthy, Linux-first multi-operator C2 with a self-healing mesh, in-memory execution, and an AI-driven MCP assistant.
# Add to your Claude Code skills
git clone https://github.com/jm33-m0/emp3r0rGuides for using ai agents skills like emp3r0r.
Last scanned: 11/14/2026
{
"issues": [],
"status": "PASSED",
"scannedAt": "2026-11-14T11:14:20.953Z",
"npmAuditRan": true,
"pipAuditRan": true,
"promptInjectionRan": true
}See how emp3r0r compares with popular alternatives.
emp3r0r is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by jm33-m0. Stealthy, Linux-first multi-operator C2 with a self-healing mesh, in-memory execution, and an AI-driven MCP assistant. It has 1,825 GitHub stars.
Yes. emp3r0r passed SkillsLLM's automated security scan — a dependency vulnerability audit plus prompt-injection heuristics — with no high-severity issues. You can read the full report in the Security Report section on this page.
Clone the repository with "git clone https://github.com/jm33-m0/emp3r0r" and add it to your Claude Code skills directory (see the Installation section above).
emp3r0r is primarily written in Go. It is open-source under jm33-m0 on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh emp3r0r against similar tools.
No comments yet. Be the first to share your thoughts!
From $49 · 30 days · terms & refunds
⚠️ Third-Party Software Notice
This skill is third-party open-source software developed and hosted independently on GitHub. SkillsLLM is an informational directory and does not control or maintain the underlying repository.
Any security checks, ratings, or warnings displayed by SkillsLLM are automated and limited in scope. They do not constitute a security certification or guarantee that the software is safe, error-free, or free from malicious code, vulnerabilities, compromised dependencies, or prompt-injection risks.
Review the source code, permissions, dependencies, and configuration before installing or running any third-party skill. Use is at your own risk. To the maximum extent permitted by applicable law, SkillsLLM is not liable for losses arising from third-party software.
Automated security scan — not a certification.
Linux-first multi-operator C2 built to stay quiet and keep working. Self-healing mesh with assisted discovery, in-memory execution with encrypted storage, scriptable agents, cross-platform BOFs, SOCKS5 pivoting, an AI-driven OPSEC-screened MCP server, and a modular C agent delivered by a sleep-masking stager.
emp3r0r started as a Linux post-exploitation framework with interactive remote shells and autonomous network pivoting. Over time it grew into a multi-operator C2 featuring modular Go and C agents, a self-healing P2P mesh, in-memory execution across Linux and Windows, and an OPSEC-screened MCP server that lets operators turn their own private AI harness into a fully interactive, natural-language C2 interface.
Every agent has an embedded Starlark engine. A module can add post-exploitation logic without rebuilding the agent or uploading an interpreter. Scripts run inside the agent process and use built-in APIs for file I/O, HTTP, process execution, and other common work. They can also call Win32 functions and Linux syscalls through the agent's API proxy. When a script needs an API that is not already present, it can load a DLL or SO from encrypted memfs or the C2 with mem_load_library, call its exports, and unload it when done. Linux eBPF modules use the same path to load libbpf.
Modules are a Starlark file and a small JSON manifest loaded in memory by the agent. Compiled modules use the same in-memory delivery path to run native code.
BOF, ELF, RV32, and PICO modules run in the agent process:
--riscv): the C2 compiles BOF sources for riscv32-linux-musl, links them with musl and any static riscv_libraries into a self-contained guest executable, and runs them inside the on-demand rvvm_linux RV32IMA interpreter on any Linux agent architecture.The repository ships Kerbeus-BOF, Remote-OPs, and a Situational Awareness suite for Windows and Linux. On Windows, modules can run under a borrowed access token.
Linux modules are Starlark scripts with access to the kernel through libbpf. The agent maps libbpf when a module needs it and exposes its API as Go-backed builtins. This uses the same on-demand loader that mem_load_library exposes; libbpf is just another shared object the module asks for. A script can enumerate BPF objects, attach programs, manage maps and links, and start or stop uprobes.
ssh_harvest is the worked example. It finds a pattern in sshd, attaches a long-lived uprobe, streams captured credentials, and keeps the probe running until --disable.
The loader can map any .so a module declares or supplies, including raw bytes provided by the script.
memmod maps shared libraries into the agent's address space and calls their exports in place. On Windows it loads PE DLLs. On Linux it loads ELF .so files and applies relocations, imports, and symbol lookups without LoadLibrary or dlopen.
The PE side follows WireGuard's memmod. The ELF side follows Sliver and sliverarmory/reflektor. memdeps sits on top: a module declares a dependency, the agent verifies its cached copy in encrypted memory storage against the SHA-256 sent by the C2 (refreshing it from the C2 on a mismatch), maps it for one operation, then unmaps it.
Starlark modules can use the same loader directly with mem_load_library. They are not limited to APIs that are already loaded in the agent or target process.
Agent file operations use an in-memory AES-GCM encrypted filesystem. Large files spill to disk only as encrypted blobs with no identifying headers. Agents that take part in the P2P mesh cache files in this filesystem and share them with peers.
The first successful check-in pins the agent's public key and signed UUID. Later check-ins must use the same identity. A different key or signature is rejected instead of quietly replacing the old agent. Removing an agent is an operator decision.
C2 and peer connections use ephemeral ECDH keys for each session. A compromised long-term key cannot decrypt traffic from earlier sessions.
The C2 supports HTTP, TCP, and UDP listeners. Agents can use beacon-style HTTP polling, streaming HTTP/2, or a QUIC UDP channel. HTTP/2 and QUIC are build-time options (with_h2conn, with_quic). QUIC obfuscates datagrams with a per-build key by default. The --quic-standard-key flag disables that and speaks stock QUIC.
HTTP polling uses a malleable request profile from the C2 config. TLS fingerprints can be randomized with uTLS. Behind an ECH-capable CDN, --doh and --ech hide the inner SNI from the ClientHello. Control messages use CBOR rather than JSON.
Agent-to-C2 traffic can run over any reliable byte stream, such as Tor, DNS, SMB, a cloud API, or a custom protocol, without changing authentication, encryption, modules, or file transfers.
A custom transport has two parts: a small dialer compiled into the Go or C agent, and an external bridge process on the C2 host. The bridge can be written in any language and forwards streams to the running server over a local Unix socket (bridge.sock), so adding or switching transports does not require rebuilding or restarting the C2. Multiple bridges can run at the same time for different agents.
A reference Tor hidden-service transport (with_transport_tor for Go agents, TRANSPORT=tor for C agents) and bridge are included. See the custom transport guide.
The Linux stager talks to the kernel through direct syscalls, needs no libc on the target, and keeps transports and packers pluggable: HTTP, TCP, UDP, libcurl, or libssl for delivery, and RC4 or LZSS for packing. It can fetch the C agent at runtime or embed its PIC with --agent-pic, leaving the downloader and listener configuration out of the artifact.
The agent's sleep mask lives in the stager. While it sleeps, the stager flips the agent's executable pages to non-executable and encrypts the agent images, heap, and stack. No anonymous executable mapping is left behind, and executable mappings return only when the agent wakes and runs. Everything the mask covers is encrypted, and the provider is pluggable, so a custom implementation can replace the default XOR scheme.
The C agent is deliberately thin: a C2 beacon with no built-in features. It implements only file I/O, network I/O, and dynload helpers that resolve code already present on the host. Everything else arrives as BOF modules, and both the native BOF loader (coffloader_linux) and the RV32IMA interpreter (rvvm_linux) are dependency modules mapped from memory at run time instead of being linked in.
Operators generate it with generate_c:
generate_c --type glibc --arch amd64 --cc your.domain.com
generate_c --type glibc --arch amd64 --cc your.domain.com --interval 60 --jitter 50 --poll-window 5 --offline-grace 0
Agents can discover each other and relay traffic through a gossip mesh. Peer links use camouflage mTLS 1.3, Windows SMB named pipes, or KCP over UDP, and every hop is encrypted. If a relay dies or the C2 becomes unreachable, traffic can move through another peer.
Files can also move directly between peers. The agent keeps fetched files in encrypted memory storage and serves them to peers on request. If no peer has a file, the agent fetches it from the C2.
The C2 can run a SOCKS5 listener that relays through an agent. The operator can use it from inside the WireGuard tunnel or start tun2socks with a route. For example:
socks_start 1080
tun2socks start --route 10.10.0.0/24
Only the listed subnet goes through the agent. Everything else keeps using the operator's normal connection. Tools that do not support a proxy can still reach the agent-side network.
On Windows, emp3r0r can use an access to