Sliver: An Open-Source Red Team C2 Framework

Authorized Adversary Emulation at Any Scale

Sliver is designed for security teams that run authorized red team assessments. The repository README describes it as a tool for organizations of all sizes, covering the full range from small internal red teams to dedicated penetration testing firms. Its primary function is adversary emulation: simulating the command-and-control (C2) behavior of real threat actors so defenders can measure their detection and response capabilities.

The framework has three distinct runtime components: a server that manages implants and operators, a client that operators connect to for issuing commands, and implants that execute on target systems. Each of those components runs on Linux, macOS, and Windows, which means both the infrastructure and the targets can span a wide range of operating environments. The Go compiler also allows implants to target platforms beyond those three when the compiler itself supports the target architecture, though the README notes those configurations are not regularly tested.

Four C2 Transports and How They Differ

Sliver supports four C2 channels: Mutual TLS (mTLS), WireGuard, HTTP(S), and DNS. These transports address different evasion and connectivity requirements.

mTLS provides bidirectional certificate authentication: both the implant and the server verify each other's identity before any traffic flows. This makes passive interception harder but produces TLS traffic that security tools can fingerprint if they inspect certificate details.

WireGuard wraps implant traffic in an encrypted VPN tunnel. It can bypass certain network controls that inspect application-layer protocols, though it requires UDP connectivity on the relevant port.

HTTP(S) is the most flexible option for environments where only web traffic is allowed outbound. Implants can blend into normal web traffic, making this the transport most likely to traverse restrictive perimeter firewalls.

DNS provides a low-bandwidth channel through DNS queries. It is slower than the other transports but can reach through environments where only DNS traffic is permitted. It is typically used as a fallback rather than a primary channel.

The choice of transport is made at implant generation time. An engagement may deploy different implant variants optimized for different network segments within the same target environment.

Per-Binary Keys and the Compilation Model

Every Sliver implant is compiled on demand rather than shipped as a fixed binary. The server compiles a fresh implant for each deployment, embedding a unique asymmetric encryption key pair specific to that binary. The public key is stored on the server; the private key exists only inside the compiled implant.

This design means that if a defender captures and reverses one implant binary, the keys they find cannot be used to decrypt communications from any other Sliver implant generated by the same server. It limits the blast radius of binary analysis by blue teams or malware researchers.

The compilation step requires that the server have a working Go toolchain and that the standard library for cross-compilation targets be available. This is handled automatically by the packaged release, but matters when building from source: the Makefile's default target compiles both the server and client binaries, and the minimum Go version required is 1.27.1.

Installing Sliver and Starting the Server

The fastest path to a running server on Linux is the one-liner provided in the README:

curl https://sliver.sh/install|sudo bash

After the script completes, run `sliver` to start the server and open the operator console. The script downloads a precompiled release binary and sets up the necessary directory structure under `~/.sliver`.

For Docker-based deployments, the Dockerfile includes a production stage:

docker build --target production -t sliver .
docker run -it --rm -v $HOME/.sliver:/home/sliver/.sliver sliver

The `-v` flag mounts the host's `.sliver` directory into the container, preserving server configuration, operator certificates, and implant artifacts across container restarts.

To build from source, the Makefile's default goal compiles both server and client:

make

The resulting binaries are `sliver-server` and `sliver-client`. The Makefile applies link flags that strip debug symbols and enable link-time optimization for smaller binaries. Operators who need to run the client on a separate machine from the server connect via a multiplayer session using certificates issued by the server.

Payload Types and Post-Exploitation Scope

Sliver generates several payload types beyond standard compiled executables. Native payloads are full ELF, PE, or Mach-O binaries. Shellcode payloads are position-independent code suitable for injection into a running process. The framework includes built-in shellcode encoding to help payloads survive environments that filter known shellcode byte sequences.

Userspace reflective loading allows a Sliver implant to be injected as a DLL or shared library that maps itself into memory without touching disk, which avoids some endpoint detection mechanisms that monitor file writes.

BOF (Beacon Object File) and COFF (Common Object File Format) execution are supported on amd64 and arm64 across all three primary platforms. BOF execution is a technique for running small compiled tasks inside a running implant process without spawning a new process, which reduces the footprint visible to process monitoring tools.

Post-exploitation capabilities beyond C2 are documented in the Sliver wiki at sliver.sh rather than in the repository README. The README points to the wiki for tutorials on specific capabilities, which means some built-in post-exploitation commands are not enumerated in the repository README.

Limitations and Cases Where Sliver Is the Wrong Choice

Sliver's compilation model is a genuine operational bottleneck. Generating a new implant requires the server to run the Go compiler, which can take tens of seconds to minutes depending on the server's hardware. In engagements where rapid iterative payload generation is needed, this latency adds friction.

The DNS transport is slow by design. DNS is a low-bandwidth protocol, and using it for C2 means data transfer rates are measured in kilobytes per minute rather than megabytes per second. It is unsuitable as the primary channel for engagements that require moving large files.

Sliver is not the right tool for passive security research, threat intelligence gathering, or reading-only security auditing. Its implant execution model assumes the operator has legitimate access and authorization to run code on target systems. Using it against systems without written authorization is illegal in most jurisdictions.

The Go toolchain and vendor directory in the repository are large. The vendor directory bundles all Go module dependencies, which gives reproducible builds but adds to the repository size and to the build cache. Teams with limited storage or bandwidth should account for this.

Sliver Against Cobalt Strike

Cobalt Strike is the most widely known commercial alternative in the enterprise red team space. It is a closed-source product sold under a commercial license that historically ran around several thousand dollars per year per operator seat, though pricing details are not verified here. Sliver provides an open-source alternative under GPL-3.0, which means it can be used and modified without a license fee, subject to the copyleft requirements of the GPL.

Cobalt Strike's Beacon has a long track record in enterprise engagements and extensive third-party tooling built around its profile and post-exploitation interface. Sliver's implant ecosystem is smaller but growing. The ARMORY_REPO_URL in the Sliver Makefile points to a GitHub armory repository for additional post-exploitation modules, which extends the base capability.

The key architectural difference is that Cobalt Strike uses a malleable C2 profile to shape traffic appearance, while Sliver's traffic shaping is tied to the choice of transport (mTLS, WireGuard, HTTP(S), DNS) and the per-binary compilation model. Teams that need deep traffic profile customization may find Cobalt Strike's malleable C2 system more flexible. Teams that need an open-source, self-hosted option with no per-seat cost will find Sliver more practical.

GPL-3.0 imposes a significant obligation: any organization that distributes a modified version of Sliver must release the modified source under the same license. This matters for commercial penetration testing firms that build proprietary tooling on top of Sliver's codebase.

Editorial conclusion

Sliver is the right tool for security teams conducting authorized adversary emulation who need a self-hosted, open-source C2 with multiple transport channels and cross-platform implant support. It is not the right tool for anyone without explicit written scope to test a target environment. Before deploying, verify that Go 1.27.1 or later is available for source builds, review the GPLv3 obligations that come with distributing modified binaries, and confirm that your use is covered by a signed rules of engagement document.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes