Sliver is an open-source, cross-platform command-and-control framework built for adversary simulation — a modern, Go-based alternative to Cobalt Strike that has become a common choice on real engagements. This page is how Sliver is put together: the concepts behind sessions, beacons, listeners, implants, the armory, and pivots. The step-by-step commands and deployment live in the Sliver toolkit entry; here we cover the model that makes those commands make sense.
Server and client
Sliver ships as two binaries. The sliver-server is the C2 backend — it
runs the listeners, compiles implants, stores operation state, and is meant to run on
Linux/macOS. The sliver-client is the operator console; running the server
binary directly gives you a built-in client. Because the server and client are separate,
Sliver supports multiplayer: several operators connect to one server at
once, each issued a client config with new-operator. That is how a team shares
a single operation.
Implants: sessions vs beacons
A Sliver implant is the payload that runs on the target and calls home. It exists in two modes — the same asynchronous/interactive split every C2 has, but worth pinning down in Sliver's own words because you switch between them constantly.
| Mode | In Sliver |
|---|---|
| Beacon | Asynchronous. Checks in on an interval (sleep + jitter), runs queued tasks, returns output, sleeps again. The default posture for stealth — quiet, bursty callbacks. Generated with the beacon flag |
| Session | Interactive, real-time control. Faster to work in, noisier on the wire. You typically upgrade a beacon to a session only for hands-on-keyboard bursts |
The same compiled implant can back either mode, and Sliver tracks them separately —beaconsandsessionslist them, anduse <id>selects which one your commands target. Everything you type is scoped to the implant you have selected.
Listeners and egress protocols
A listener is the server-side endpoint an implant connects back to. Sliver
speaks several egress protocols so the operator can match the environment; a running
listener is a job, listed with jobs.
| Protocol | Character |
|---|---|
| HTTP(S) | Procedurally generated C2 over web traffic — the everyday default; blends with browsing and survives proxies. Supports custom/Let's Encrypt certificates |
| mTLS | Mutually-authenticated TLS; strong and simple where raw sockets egress is allowed |
| DNS | Slow but almost always permitted; includes a DNS canary feature to detect when blue teams detonate an implant |
| WireGuard | Efficient VPN-style tunnel, typically for internal use |
Generating implants and profiles
Implants are compiled on demand by the server with generate.
Because the code is produced per build, Sliver can apply dynamic code generation
and compile-time / symbol obfuscation so no two implants are byte-identical — which
defeats simple hash and static signatures. The build is parameterised: callback URL,
beacon vs session, output format, and obfuscation.
| Choice at generate-time | What it controls |
|---|---|
Callback (e.g. -b https://host) | Which listener/protocol the implant dials, and beacon vs session |
| Output format | Executable, shared library, service binary, or raw shellcode to inject via a loader |
| Obfuscation / encoders | Symbol obfuscation and shellcode encoding to reduce static detection |
| Staged vs stageless | A one-shot implant, or a small stager that pulls the full implant over C2 |
A profile saves a generate configuration so the same implant recipe can be rebuilt or served on demand — useful for staging and for keeping a consistent build across a team.
The armory: extensions and aliases
Out of the box Sliver has built-in commands (file operations, process listing, injection,
execute-assembly, and so on). Beyond that, the armory is
Sliver's package manager: armory install <name> pulls third-party tooling
and registers it as a first-class command.
| Type | What it is |
|---|---|
| Alias | A wrapper around a .NET assembly (e.g. SharpUp, Rubeus) so it runs like a native command via in-memory execution |
| Extension | A compiled module — often a BOF/COFF (Beacon Object File) — loaded into the implant to add capability without spawning a process |
This is why an operator can run dozens of named commands that are really external tools: the armory turns SharpUp, Rubeus, Seatbelt, service-abuse helpers and BOFs into commands the implant executes in memory. How that in-memory execution actually works — fork-and-run vs inline, PPID spoofing, AMSI/ETW bypass — is covered in in-memory tradecraft.
Pivots: reaching segmented hosts
On a segmented network only the foothold can reach the internet. Sliver handles this with pivots: the foothold implant opens a local TCP or named-pipe pivot listener, and implants on internal machines connect to that instead of the internet. Their C2 traffic is relayed through the foothold's egress channel back to the server.
The result is one egress point and many internal agents — a small, defensible network footprint. A typical lab layout: the foothold beacons out over HTTPS, and every other compromised host talks TCP to a pivot on the foothold, which relays it onward. Named-pipe pivots go a step further, carrying C2 over SMB so it looks like ordinary Windows inter-process traffic.
The C2 message protocol and per-implant crypto
What actually crosses the wire between an implant and the server is not raw commands but serialised task envelopes: a task type and its arguments in one direction, results in the other, wrapped in the framework's own message format and then encrypted. The egress protocol (HTTPS, mTLS, DNS) is only the carrier — the same envelope rides inside any of them, which is why an operator can switch protocols without changing how they task the implant.
The architectural detail that matters for detection is that each implant carries its own key material, established per build, rather than every implant sharing one static key. Sliver leans on modern asymmetric cryptography (elliptic-curve keys, and mutually-authenticated TLS in the mTLS mode) so that traffic is opaque on the wire and one burned implant does not hand a defender the keys to decrypt every other implant's traffic. The practical consequence for a blue team is that network capture alone rarely yields the plaintext tasks — detection has to come from the beaconing pattern, TLS fingerprint, and host-side behaviour rather than from reading the C2 content.
Sliver also ships small integrity features that reflect this defensive-aware design. The DNS canary is the clearest example: an implant can embed a unique DNS name that should never be resolved in normal operation, so if a blue team detonates the sample in a sandbox and it phones that name home, the operator is alerted that the implant is burned. These are the kinds of operational-security affordances that separate a mature framework from a proof-of-concept RAT.
Why Sliver is a common choice
- Open-source and cross-platform — no licence, implants for Windows/Linux/macOS across architectures.
- Per-build obfuscation — dynamic code generation and symbol obfuscation defeat naive signatures.
- In-memory .NET and BOF execution — run the standard C#/BOF offensive toolset without dropping tools to disk.
- Scriptable and multiplayer — automate with JavaScript/TypeScript or Python; share one server across a team.
The takeaway
Sliver is a server that compiles obfuscated implants on demand, listeners that speak HTTPS/mTLS/DNS/WireGuard, implants that run as quiet beacons or interactive sessions, an armory that turns external tools and BOFs into in-memory commands, and pivots that fan C2 out across a segmented network from a single foothold. Hold that model and the command reference reads as a set of knobs on one machine. The full deployment and every command are in the Sliver toolkit entry.