> For the complete documentation index, see [llms.txt](https://alham-rizvi.gitbook.io/alhamrizvi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alham-rizvi.gitbook.io/alhamrizvi/c2-framworks/07-sliver-commands-reference.md). # 07 — Sliver Commands Reference ### 7.1 Server / Console Basics #### `help` Lists every command available in your current context. Sliver's console is context-sensitive — the commands available at the top-level `sliver >` prompt are different from the commands available once you're `use`-d into a session (e.g., `sliver (SESSION) >`). Run `help` again after `use` to see the new command set. #### `version` Shows the server and client version numbers. Matters because Sliver ships frequent releases, and a client/server version mismatch can cause odd behavior or missing commands — always the first thing to check if something feels broken. #### `multiplayer` Turns on multi-operator mode on the team server, so more than one tester can connect to the same engagement at once. Without this, Sliver runs single-player by default (just you, locally). #### `new-operator --name --lhost ` Generates a new operator identity: an mTLS client certificate bundled into a `.cfg` file. You give this file to a teammate, they `import` it into their own `sliver-client`, and now they can connect and see/share sessions with you. Each operator gets their own cert — so actions are attributable to the person who ran them, which matters for engagement logging. #### `jobs` Lists everything currently "running" on the server side — mainly your active listeners (mTLS, HTTP, DNS, WG). Think of it as `ps` but for your C2 infrastructure instead of the target's processes. #### `jobs -k ` Kills a specific job (usually a listener) by its ID from the `jobs` list. Use this during cleanup, or when rotating a listener to a new port/config without restarting the whole server. *** ### 7.2 Listeners Listeners are what actually accept implant check-ins. You must start one *before* generating an implant that points at it, since the implant needs a live listener to call back to. #### `mtls` Starts a mutual-TLS listener — both server and implant present certificates to authenticate each other. This is Sliver's strongest and most "native" transport: hard to intercept or spoof, and the default choice when stealth against active MITM isn't your main concern (e.g., internal lab work, or when the target network doesn't inspect TLS deeply). #### `http` / `https` Starts a listener that speaks plain HTTP or HTTPS. This is the go-to choice when you need traffic that blends in with normal web browsing on the way out of a target network — most corporate egress filters allow port 443 outbound, so this is often the highest-reliability option in real engagements. #### `dns` Starts a DNS-based listener. Implants communicate by encoding data into DNS queries/responses. Extremely useful when a network only allows DNS resolution out (very locked-down egress) — but bandwidth is low, so it's slow for large data transfers. Best for check-ins and small command/response traffic, not file exfiltration. #### `wg` Starts a WireGuard listener — Sliver's VPN-based transport. Once established, it behaves like a fast, encrypted tunnel rather than a request/response protocol, which is useful when you want a persistent, low-latency channel (e.g., for interactive work) rather than a beacon-style check-in. *** ### 7.3 Generating Implants "Generate" is where you compile the actual binary that will run on the victim host. Every implant is tied to a specific listener/transport, OS, and architecture — you're building a custom payload per target, not reusing one generic file. #### `generate --mtls --os windows --arch amd64 --save ` Builds a **stageless session implant** — the full agent in one binary — configured to call back over mTLS to `` (your listener's address). `--os` and `--arch` must match the victim machine. `--save` writes the compiled binary to disk so you can transfer it to the target. This is your "default," straightforward implant for interactive work. #### `generate beacon --http --os windows --seconds 60 --jitter 30 --save ` Same idea, but builds a **beacon** instead of a session: instead of staying connected, it wakes up every `--seconds` (60s here) with `--jitter` (±30%) randomness added, checks for queued tasks, runs them, and goes quiet again. Use this when stealth over time matters more than speed of interaction — the classic long-term persistence implant. #### `generate --os linux --arch amd64` Same generate command, just targeting a Linux victim instead of Windows. Sliver's cross-platform compilation means the workflow is identical — only the `--os`/`--arch` flags change. #### `implants` Lists implant *profiles* you've already generated/saved — so you don't have to remember every flag combination you used previously if you need to regenerate or reference one. *** ### 7.4 Sessions & Beacons Once a generated implant runs on a victim and successfully calls back to your listener, it shows up here as either a session or a beacon (matching how you built it in 7.3). #### `sessions` Lists all currently active interactive sessions — implants that are connected and can be commanded in near real-time. If a victim host's implant is a "session" type and currently online, it appears here with an ID. #### `beacons` Same idea, but for beacon-type implants. Because beacons check in only periodically, an entry here might currently be "asleep" — your queued commands will run at its *next* check-in, not instantly. #### `use ` Switches your console context into that specific implant, so all following commands (whoami, ls, screenshot, etc.) run on that host. This is the equivalent of "connecting" to one compromised machine among many. #### `background` Steps back out of the current session/beacon context to the top-level `sliver >` prompt, without killing the implant — it stays connected in the background so you can go interact with a different one, or check `jobs`/`sessions` again. #### `kill` Terminates the implant process on the target host itself (not just your console's view of it). This is a real, disruptive action on the victim machine — use it deliberately, typically during cleanup/teardown at the end of an engagement or lab. *** ### 7.5 Post-Exploitation (once inside a session/beacon) These run *on the compromised host*, through the implant, once you've `use`-d into it. This is the actual "hands on keyboard" phase of the engagement. #### `whoami` Shows the user context the implant is running as — critical for figuring out whether you need to escalate privileges before doing anything more sensitive. #### `info` Dumps general host/implant metadata: hostname, OS version, implant ID, PID, etc. Good first command to run in any new session to orient yourself. #### `ps` Lists running processes on the victim. Useful for spotting AV/EDR products, other users' active sessions, or interesting running services worth targeting. #### `netstat` Shows active network connections on the host — helps you understand what else this machine talks to, which is exactly the kind of information you need before planning lateral movement. #### `ifconfig` Shows network interfaces and their IP addresses/subnets. Tells you what other network segments this host can reach — key input for deciding where to pivot next. #### `ls` / `cd` Basic filesystem navigation through the implant, without needing a full interactive shell. Use this for quick recon of file structure before deciding whether to pull a full shell or grab specific files. #### `screenshot` Captures whatever is currently displayed on the victim's screen. Useful evidence for a report, and sometimes reveals credentials, open documents, or context that command-line recon misses. #### `shell` / `execute` `shell` drops you into a more traditional interactive shell on the host through the implant; `execute` runs a single specified command/binary and returns the output. Use `execute` for one-off actions, `shell` when you need a back-and-forth session. *** ### 7.6 Pivoting Pivoting lets you reach hosts that aren't directly reachable from your team server/listener — usually because they're on an internal-only network segment. #### `pivots` Lists any pivot listeners currently active from within a session/beacon — shows you what pivot paths already exist before you set up a new one. #### `tcp-pivot start --lhost ` Starts a TCP-based pivot listener *on the already-compromised host*. A second implant, deployed on a deeper internal host that can't reach your team server directly, can instead connect to this pivot listener — which relays its traffic back through the first host to you. This is how you reach machines your redirector/listener has no direct line to. #### `named-pipe-pivot start` Same pivoting concept, but over SMB named pipes — a very "native" Windows internal-network channel, often blending in better than raw TCP on a segment full of Windows hosts talking to each other over SMB anyway. *** ### 7.7 Armory (Extensions) #### `armory` Lists community-built extensions and aliases available to install — think of it as Sliver's package manager/app store for extra post-exploitation tooling that isn't built into the core framework. #### `armory install ` Installs a specific extension by name. Always review what an extension actually does (source code, not just the description) before running it against any host — especially outside your own lab, since you're trusting third-party code to run in your engagement. #### `armory update` Updates already-installed extensions to their latest versions — worth running periodically so you're not stuck on stale/buggy tooling. *** ### 7.8 What's Next `08-sliver-practical-labs.md` chains all of the above into a full, step-by-step lab exercise — same commands, now in the order you'd actually run them end-to-end. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://alham-rizvi.gitbook.io/alhamrizvi/c2-framworks/07-sliver-commands-reference.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.