Update docs for wg+grpc/mtls multiplayer

2026-11-09 09:59:43 -10:00 · 2026-03-26 17:30:33 -07:00
8 changed files with 109 additions and 33 deletions
@@ -5,8 +5,8 @@ This document describes the technical design of Sliver.
 There are four major components to the Sliver ecosystem:

 - **Server Console -** The server console is the main interface, which is started when you run the `sliver-server` executable. The server console is a superset of the client console. All code is shared between the client/server consoles except server-specific commands related to client (i.e., operator) management. The server console talks over an in-memory gRPC interface to the server.
- **Sliver Server -** The Sliver server is also part of the `sliver-server` executable and manages the internal database, starts/stops network listeners (such as C2 listeners, though there are other types). The main interface used to interact with the server is the gRPC interface, thru which all functionality is implemented. By default the server will only start an in-memory gRPC listener that can only be communicated with from the server console. However, the gRPC interface can also be exposed to the network (i.e., multiplayer mode) over mutual TLS (mTLS).
- **Sliver Client -** The client console is the primary user interface that is used to interact with the Sliver server. Note that most of the code in the server console is actually the client console. The client console can also be compiled into a separate client binary file `sliver-client`, which is generally used to connect to the "mutliplayer" gRPC network listener.
+- **Sliver Server -** The Sliver server is also part of the `sliver-server` executable and manages the internal database, starts/stops network listeners (such as C2 listeners, though there are other types). The main interface used to interact with the server is the gRPC interface, thru which all functionality is implemented. By default the server will only start an in-memory gRPC listener that can only be communicated with from the server console. However, the gRPC interface can also be exposed to the network in multiplayer mode, either directly over mutual TLS (mTLS) or, by default, through a WireGuard-protected wrapper that carries the same gRPC/mTLS service.
+- **Sliver Client -** The client console is the primary user interface that is used to interact with the Sliver server. Note that most of the code in the server console is actually the client console. The client console can also be compiled into a separate client binary file `sliver-client`, which is generally used to connect to the multiplayer gRPC network listener.
 - **Implant -** The implant is the actual malicious code run on the target system you want remote access to.

 ```
@@ -17,7 +17,8 @@ There are four major components to the Sliver ecosystem:
 └─────────┘             └───────────────┘
                               ▲
                               │
-                               │gRPC/mTLS
+                               │WireGuard (default)
+                               │or direct gRPC/mTLS
                               │
                          ┌────┴────┐
                          │ Sliver  │
@@ -25,4 +26,4 @@ There are four major components to the Sliver ecosystem:
                          └─────────┘
 ```

-By implementing all functionality over this gRPC interface, and only differing the in-memory/mTLS connection types the client code doesn't "know" if it's running in the server console or the client console. Due to this, a single command implementation will work in both the server console and over the network in multiplayer mode.
+By implementing all functionality over this gRPC interface, and only differing the in-memory or remote transport types, the client code doesn't "know" if it's running in the server console or the client console. Due to this, a single command implementation will work in both the server console and over the network in multiplayer mode.
@@ -12,6 +12,7 @@ daemon:
    host: ""
    port: 31337
    tailscale: false
+    disable_wg: false
 logs:
    level: 4
    grpc_unary_payloads: false
@@ -51,8 +52,9 @@ cxx: {}
 - `daemon_mode` - Enable [daemon mode](/docs?name=Daemon+Mode).
 - `daemon` - Options for daemon mode.
  - `host` - Interface to bind the daemon listener to. Empty string means all interfaces.
-  - `port` - TCP port for the daemon listener.
-  - `tailscale` - Enable Tailscale for daemon listener setup.
+  - `port` - Listen port for the multiplayer listener.
+  - `tailscale` - Enable Tailscale for daemon listener setup. When enabled, Sliver does not wrap multiplayer in its own WireGuard layer.
+  - `disable_wg` - Expose multiplayer directly over mTLS instead of the default WireGuard-protected mode.
 - `logs` - Server logging options.
  - `level` - `logrus` level (`0`-`6`, clamped by Sliver). `4` is `INFO`, `5` is `DEBUG`, `6` is `TRACE`.
  - `grpc_unary_payloads` - Log gRPC unary payloads.
@@ -140,8 +142,21 @@ For details on generating them, see [multiplayer mode](/docs?name=Multi-player+M
  "lport": 31337,
  "ca_certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n",
  "private_key": "-----BEGIN EC PRIVATE KEY-----\n...\n-----END EC PRIVATE KEY-----\n",
-  "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n"
+  "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n",
+  "wg": {
+    "server_pub_key": "<multiplayer-wg-server-pubkey>",
+    "client_private_key": "<operator-wg-private-key>",
+    "client_pub_key": "<operator-wg-public-key>",
+    "client_ip": "100.65.0.10",
+    "server_ip": "100.65.0.1"
+  }
 }
 ```

 **Note:** The `operator` field is mostly a local label in the client. Server-side identity is derived from the client certificate (`CommonName`) and token material generated by the server. If you need to rename an operator, generate a new client configuration.
+
+The `wg` block is optional:
+
+- When present, `sliver-client` automatically brings up the multiplayer WireGuard wrapper and then dials the in-tunnel gRPC/mTLS service.
+- When absent, the client connects directly to the multiplayer mTLS listener.
+- Generate a direct-only profile with `new-operator --disable-wg` or `sliver-server operator --disable-wg` when you need compatibility with external gRPC clients that do not implement the multiplayer WireGuard wrapper.
@@ -1,9 +1,20 @@
 Although the `sliver-client` is the default way to interact with a `sliver-server` and with implant sessions, there might be a time where you would want to automate some tasks upon reception of certain events.

-To do so, one case use [sliver-script](https://github.com/moloch--/sliver-script), [sliver-py](https://github.com/moloch--/sliver-py) or write a custom client in another language. As all the communications between the client and the server are based on gRPC, any language with gRPC support should in theory be used to create a custom client.
+To do so, you can use [sliver-script](https://github.com/moloch--/sliver-script), [sliver-py](https://github.com/moloch--/sliver-py), or write a custom client in another language.
+
+Current Sliver releases generate multiplayer operator configs with a `wg` block by default. The official `sliver-client`, and Go clients that reuse Sliver's `client/assets` plus `client/transport` packages, will automatically bring up that WireGuard wrapper before dialing the in-tunnel gRPC/mTLS service.
+
+If you are writing a custom client in another language, you have two options:
+
+- Implement the multiplayer WireGuard wrapper described in [multiplayer mode](/docs?name=Multi-player+Mode), then connect to the in-tunnel gRPC/mTLS service.
+- Keep multiplayer in direct mode by starting the listener with `multiplayer --disable-wg` or `sliver-server daemon --disable-wg`, then generate operator profiles with `new-operator --disable-wg` or `sliver-server operator --disable-wg`.
+
+Once connected, the client/server API is still gRPC, so any language with gRPC support can in theory be used to create a custom client.

 ## Writing a Go client

+This example uses Sliver's Go client libraries, so it works with either a direct multiplayer profile or a WireGuard-enabled profile.
+
 In this example, we will focus on writing a custom Go client that executes a new system command on every new implant that connects to the sliver server.

 Create a new Go project somewhere on your file system:
@@ -1,4 +1,6 @@
-Sliver supports running in daemon mode, which automatically starts the multiplayer client listener (but not an interactive console). To connect to a daemonized server, use [multiplayer mode](/docs?name=Multi-player+Mode) operator configs.
+Sliver supports running in daemon mode, which automatically starts the multiplayer listener but does not provide an interactive console. To connect to a daemonized server, use [multiplayer mode](/docs?name=Multi-player+Mode) operator configs.
+
+By default, daemon mode starts the same WireGuard-protected multiplayer listener used by the interactive `multiplayer` command. That means the outer listener is UDP on `31337` by default, while the authenticated gRPC/mTLS service stays inside the WireGuard tunnel.

 There are two ways to run in daemon mode:

@@ -13,9 +15,11 @@ If `server.yaml` does not exist, Sliver generates it. If a legacy `server.json`
  - `-l, --lhost` multiplayer listener host
  - `-p, --lport` multiplayer listener port
  - `-t, --tailscale` enable Tailscale listener
+  - `--disable-wg` expose multiplayer directly over mTLS instead of using the default WireGuard wrapper
  - `-f, --force` force unpack static assets
 - For `sliver-server daemon`, `--lhost` and `--lport` override config values. If omitted, Sliver uses `daemon.host` and `daemon.port` from `server.yaml`.
- For normal startup (`sliver-server`) with `daemon_mode: true`, Sliver uses `daemon.tailscale` from `server.yaml`.
+- For normal startup (`sliver-server`) with `daemon_mode: true`, Sliver uses `daemon.tailscale` and `daemon.disable_wg` from `server.yaml`.
+- With `--disable-wg` or `daemon.disable_wg: true`, multiplayer falls back to direct TCP mTLS on the configured port.

 ### Example Config

@@ -25,6 +29,7 @@ daemon:
    host: ""
    port: 31337
    tailscale: false
+    disable_wg: false
 logs:
    level: 4
    grpc_unary_payloads: false
@@ -44,6 +49,8 @@ Since daemon mode does not provide an interactive server console, generate opera
 ./sliver-server operator --name zer0cool --lhost 1.2.3.4 --permissions all --save zer0cool.cfg
 ```

+The `operator` CLI matches the daemon's multiplayer exposure by default. If the daemon is running in direct mode or over Tailscale, the generated config omits the multiplayer `wg` block automatically. You can also force a direct-only profile with `--disable-wg`.
+
 ### Shutdown Behavior

 On Unix-like systems, daemon mode handles `SIGTERM` and exits cleanly.
@@ -1,10 +1,10 @@
-This script will install the latest version of Sliver as a systemd service, installs Windows cross-compiler dependencies (mingw), and setup multiplayer for the all local users. After running the script connect locally by running `sliver`.
+This script installs the latest version of Sliver as a systemd service, installs Windows cross-compiler dependencies (mingw), and sets up multiplayer for all local users. After running the script, connect locally by running `sliver`.

 https://sliver.sh/install

 This script should work on Kali, Ubuntu, and RHEL (CentOS, etc) distributions of Linux.

-**⚠️ OPSEC:** By default the Linux install script will bind the multiplayer listener to `:31337` i.e. all interfaces. Ensure your firewalls are properly configured if this is a concern, or reconfigure the server to bind to localhost if you only wish to allow local users. Multiplayer Mode is authenticated using mTLS/gRPC and per-operator bearer tokens, so this doesn't present a security problem (notwithstanding bugs in our implementation), but publicly exposing your multiplayer listener will make it trivial to identify what the server is running.
+**⚠️ OPSEC:** By default the Linux install script will bind the multiplayer listener to `:31337` on all interfaces. In current releases that is the WireGuard-protected multiplayer listener, so the outer service is UDP/31337 and the authenticated gRPC/mTLS server only exists inside the tunnel. Ensure your firewalls are properly configured if this is a concern, or reconfigure the server to bind to localhost if you only wish to allow local users. Publicly exposing the multiplayer listener still makes the server easier to discover and fingerprint.

 ### One Liner

@@ -1,4 +1,6 @@
-Multiplayer-mode allows multiple operators (players) to connect to the same Sliver server and collaborate on engagements. The easiest way to set up a server for multiplayer is to use the [Linux install script](/docs?name=Linux+Install+Script) which will configure the server as a systemd service. However, any Sliver server binary supports multiplayer mode.
+Multiplayer mode allows multiple operators to connect to the same Sliver server and collaborate on engagements. The easiest way to set up a server for multiplayer is to use the [Linux install script](/docs?name=Linux+Install+Script), which configures the server as a systemd service. However, any `sliver-server` binary supports multiplayer mode.
+
+By default, Sliver now protects the operator-facing multiplayer listener with a dedicated WireGuard wrapper. The gRPC/mTLS authentication stack is still used inside the tunnel, but the server no longer exposes the multiplayer gRPC listener directly unless you explicitly opt out with `--disable-wg`.

 ```
                    ┌──────────────────┐  C2
@@ -8,7 +10,8 @@ Multiplayer-mode allows multiple operators (players) to connect to the same Sliv
                    └──────────────────┘
                            ▲
                            │
-         gRPC/mTLS          │
+  UDP/WireGuard (default)   │
+     gRPC/mTLS inside       │
      ┌────────────┬────────┴─────┬───────────┐
      │            │              │           │
 ┌─────┴──┐         │              │        ┌──┴─────┐
@@ -18,32 +21,39 @@ Multiplayer-mode allows multiple operators (players) to connect to the same Sliv
              └────────┘     └────────┘
 ```

-## New Operators
+## Default WireGuard-Protected Mode

 Operators will need to download their preferred platform's client software from the releases page. Clients can connect to servers of differing platforms (e.g. a Windows client can connect to a Linux server). Operators and servers authenticate using Mutual TLS, however all the certificates are managed automatically for you.

 - If you did not install the server as a systemd service, be sure to leave the server console running in screen or [tmux](https://github.com/tmux/tmux) after starting the multiplayer listener.
- If you did install the server as systemd service see the CLI section below for an alternative to the console commands for generating operator configs.
+- If you did install the server as a systemd service, see the CLI section below for an alternative to the console commands for generating operator configs.

 Operators need a configuration file generated by the Sliver server to connect in multiplayer mode. The Sliver client can support multiple configuration files, but you can only be connected to one server at a time (per process).

-From the server use the `new-operator` command to generate a new operator configuration file. You'll need to specify the operator's `--name` and the `--lhost` of the server (e.g., its public IP). Then from the server start a multiplayer listener using the `multiplayer` command to allow operators to connect:
+In the default mode:

-**Note:** The `new-operator` and `multiplayer` commands are only accessible from the server's console
+- `multiplayer` exposes a WireGuard listener on `--lport` (default `31337`) over UDP.
+- The authenticated gRPC/mTLS server only listens inside that WireGuard tunnel.
+- `new-operator` generates a per-operator WireGuard keypair and tunnel IP, then embeds that information in the operator config's `wg` block.
+- The multiplayer listener uses WireGuard keys that are separate from Sliver's implant `wg` C2 listener.
+- `sliver-client` automatically uses the WireGuard wrapper when the imported config contains that `wg` block.
+
+From the server, start the multiplayer listener and generate an operator config with the server's public address or hostname in `--lhost`. Use `--permissions all` for a standard interactive operator profile:
+
+**Note:** The `new-operator` and `multiplayer` commands are only available from the server console.

 ```
-[server] sliver > new-operator --name moloch --lhost 1.2.3.4
-
-[*] Generating new client certificate, please wait ...
-[*] Saved new client config to: /Users/moloch/Desktop/moloch_example.com.cfg
-
 [server] sliver > multiplayer

 [*] Multiplayer mode enabled!

+[server] sliver > new-operator --name moloch --lhost 1.2.3.4 --permissions all
+
+[*] Generating new client certificate, please wait ...
+[*] Saved new client config to: /Users/moloch/Desktop/moloch_example.com.cfg
 ```

-**IMPORTANT:** Before clients can connect to a server you must start an RPC listener with the `multiplayer` command. The default port is TCP/31337.
+**IMPORTANT:** Before clients can connect to a server you must start a multiplayer listener with the `multiplayer` command. In the default WireGuard-protected mode the outer listener is UDP/31337. If you disable the wrapper, multiplayer is exposed directly on TCP/31337 instead.

 You can now give this configuration file `moloch_example.com.cfg` to the operator and they can connect to the server using the `sliver-client` binary. The Sliver client will look for configuration files in `~/.sliver-client/configs/` or you can import configs using the `import` CLI. The configs directory can contain multiple configs for different servers.

@@ -56,19 +66,49 @@ $ ./sliver-client
  localhost
 ```

+## Direct mTLS Mode
+
+If you want the old behavior, or you need compatibility with third-party gRPC clients that do not implement the multiplayer WireGuard wrapper, disable it on both the listener and the generated operator profile:
+
+```
+[server] sliver > multiplayer --disable-wg
+
+[*] Multiplayer mode enabled!
+
+[server] sliver > new-operator --name tester --lhost 1.2.3.4 --permissions all --disable-wg
+
+[*] Generating new client certificate, please wait ...
+[*] Saved new client config to: /Users/tester/Desktop/tester_example.com.cfg
+```
+
+In direct mode:
+
+- Multiplayer is exposed directly over TCP on `--lport` (default `31337`).
+- Generated operator configs omit the `wg` block.
+- `sliver-client --disable-wg` forces a direct connection even if the config includes a `wg` block.
+- `sliver-client --require-wg` fails fast if the config does not contain a valid `wg` block.
+
+The listener mode and the operator config need to match. A WireGuard-enabled config cannot talk to a direct listener, and a direct-only client cannot talk to the default WireGuard-wrapped listener.
+
 ### Server CLI / Daemon Mode Multiplayer

-If the server is running in daemon mode (as is the default with the Linux install script), that means the multiplayer listener is started for you without an interactive console. You can use the server binaries' CLI to generate operator configuration files to connect:
+If the server is running in daemon mode, the multiplayer listener is started for you without an interactive console. By default the daemon uses the same WireGuard-protected multiplayer mode described above. You can switch the daemon back to direct exposure with `sliver-server daemon --disable-wg` or `daemon.disable_wg: true` in `server.yaml`.
+
+Use the server CLI to generate operator configuration files:

 ```
-./sliver-server operator --name zer0cool --lhost 1.2.3.4 --save zer0cool.cfg
+./sliver-server operator --name zer0cool --lhost 1.2.3.4 --permissions all --save zer0cool.cfg
 ```

-The installation scripts by default will place the `sliver-server` binary in `/root`.
+When daemon mode is configured for direct multiplayer or Tailscale, the CLI automatically omits the `wg` block by default. You can also force a direct-only profile with `--disable-wg`.
+
+The installation script places the `sliver-server` binary in `/root` by default.

 ### Tailscale Integration

-Sliver v1.6 supports multiplayer integration with [Tailscale](https://tailscale.com/), which is an excellent option when wanting to maintain operational security.
+Sliver supports multiplayer integration with [Tailscale](https://tailscale.com/), which is an excellent option when you want to keep the multiplayer listener off the public Internet.
+
+Tailscale mode is separate from the default multiplayer WireGuard wrapper. When you use `multiplayer -T`, Sliver exposes the listener only through Tailscale instead of layering its own multiplayer WireGuard tunnel on top.

 ```
 $ export TS_AUTHKEY=<tailscale authkey>
@@ -77,4 +117,4 @@ $ ./sliver-server
 sliver > multiplayer -T
 ```

-You should now see a new Tailscale host named `sliver-server-<machine>`, you can set this using the `--lhost` flag. Use this as the hostname when connecting to the Sliver server from any other host on the Tailscale network.
+You should now see a new Tailscale host named `sliver-server-<machine>`. Use that hostname as `--lhost` when generating operator configs for other hosts on the same tailnet. If you generate the operator config before enabling Tailscale multiplayer, add `--disable-wg` explicitly so the profile does not include the multiplayer `wg` block.
@@ -59,14 +59,16 @@ First, install the sliver-py extension using pip.
 pip3 install sliver-py
 ```

-Since our extension is essentially going to be another client connection to the sliver server, you’ll also need to enable multiplayer mode and generate a new profile
+Since our extension is essentially going to be another client connection to the sliver server, you’ll also need to enable multiplayer mode and generate a new profile.
+
+Current Sliver releases default to a WireGuard-protected multiplayer listener. Because this tutorial uses a third-party Python client, we’ll force direct multiplayer mode so the profile only contains the plain gRPC/mTLS settings:

 ```bash
-[server] sliver > multiplayer
+[server] sliver > multiplayer --disable-wg

 [*] Multiplayer mode enabled!

-[server] sliver > new-operator -n tester -l 127.0.0.1
+[server] sliver > new-operator -n tester -l 127.0.0.1 --permissions all --disable-wg

 [*] Generating new client certificate, please wait ...
 [*] Saved new client config to: /Users/tester/tools/tester_127.0.0.1.cfg
@@ -1 +1 @@
-{"tutorials":[{"name":"1 - Getting Started","content":"`sliver-server` is the binary you want to use to run the Sliver C2 server, `sliver-client` is solely a client to connect to a Sliver C2 server. Sliver server also acts as a client on its own, so you don’t necessarily run sliver server and client separately.\n\nFirst time running Sliver will take a couple seconds as it's retrieving its dependencies. Consecutive executions will be much faster. Go ahead and launch the `sliver-server`.\n\n```asciinema\n{\"src\": \"/asciinema/startup.cast\", \"cols\": \"132\", \"rows\": \"28\", \"idleTimeLimit\": 8}\n```\n\nLet's take a couple minutes to discuss what Sliver actually is and how it's set up.\n\n![Alt text](/images/Architecture.png)\n\nNow that Sliver is running, lets generate and execute your first implant to try out some of the basic features of Sliver, for now we’re going to run everything on the local host.\n\nHere's what we're going to do: \n* Generate your implant using the `generate` command as shown below.\n* Start HTTP listener on port 80\n* Execute implant in a separate terminal\n\n```asciinema\n{\"src\": \"/asciinema/first-implant.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nNow let’s select our implant and run our first command using the `use` command.\n\n```bash\n[server] sliver > use\n? Select a session or beacon: \nSESSION  1884a365  RELATED_EARDRUM  [::1]:49153      test.local  tester  darwin/amd64\n[*] Active session RELATED_EARDRUM (1884a365-085f-4506-b28e-80c481730fd0)\n\n[server] sliver (RELATED_EARDRUM) > pwd\n\n[*] /Users/tester/tools\n```\n\nOnce you have reached this point, go ahead and explore some of the commands listed below. In each case, first check out the command's help using the **`-h`** flag then try it out!\n\n```bash\nExploring and interacting with the filesystem\n\nFilesystem\n  cat               Dump file to stdout\n  cd                Change directory\n  cp                Copy a file\n  download          Download a file\n  grep              Search for strings that match a regex within a file or directory\n  head              Grab the first number of bytes or lines from a file\n  ls                List current directory\n  mkdir             Make a directory\n  mv                Move or rename a file\n  pwd               Print working directory\n  rm                Remove a file or directory\n  tail              Grab the last number of bytes or lines from a file\n  upload            Upload a file\n```\n\n```asciinema\n{\"src\": \"/asciinema/filesystem.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nGetting some environmental information\n```bash\nInfo\n  env               List environment variables\n  getgid            Get session process GID\n  getpid            Get session pid\n  getuid            Get session process UID\n  info              Get session info\n  ping              Send round trip message to implant (does not use ICMP)\n  whoami            Get session user execution context\n```\nExecute a binary\n\n```asciinema\n{\"src\": \"/asciinema/execute.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nRunning an interactive shell\n\n```asciinema\n{\"src\": \"/asciinema/shell.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nNot all commands are supported for all operating systems or meant to be used on all operating systems, here are a few examples:\n\n```\nmount             Get information on mounted filesystems (only for Windows and Linux)\nscreenshot        Take a screenshot (only for Windows and Linux)\nmemfiles          List current memfiles (Linux only)\n```\n\nThis is an open-source project if you see a bug please file an issue! Pull requests are always welcome."},{"name":"2 - Beacons vs Sessions","content":"Sliver implants support two types of connections, sessions and beacons.\n\nSessions use long-polling connections, which means they constantly maintain a single TCP connection open while communicating with the server. Beacons on the other hand call back periodically and will sleep when not active which can help keep their presence hidden. You could limit callbacks to once every 6 hours for example and only 'activate' the beacon when needed by switching its sleeping time to a shorter duration.\n\nTypically during an engagement you will want to deploy a beacon on the target system and switch to a session while doing more active enumeration.\n\nLet’s start with generating and deploying a beacon using `http`.\n\n```asciinema\n{\"src\": \"/asciinema/beacon_generation.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nYou can see the beacon callback times either in the `info` command or using `beacons watch`.\n\n```bash\n[server] sliver > beacons watch\n\n ID         Name            Transport   Username          Operating System   Last Check-In   Next Check-In\n========== =============== =========== ================= ==========Line truncated
+{"tutorials":[{"name":"1 - Getting Started","content":"`sliver-server` is the binary you want to use to run the Sliver C2 server, `sliver-client` is solely a client to connect to a Sliver C2 server. Sliver server also acts as a client on its own, so you don’t necessarily run sliver server and client separately.\n\nFirst time running Sliver will take a couple seconds as it's retrieving its dependencies. Consecutive executions will be much faster. Go ahead and launch the `sliver-server`.\n\n```asciinema\n{\"src\": \"/asciinema/startup.cast\", \"cols\": \"132\", \"rows\": \"28\", \"idleTimeLimit\": 8}\n```\n\nLet's take a couple minutes to discuss what Sliver actually is and how it's set up.\n\n![Alt text](/images/Architecture.png)\n\nNow that Sliver is running, lets generate and execute your first implant to try out some of the basic features of Sliver, for now we’re going to run everything on the local host.\n\nHere's what we're going to do: \n* Generate your implant using the `generate` command as shown below.\n* Start HTTP listener on port 80\n* Execute implant in a separate terminal\n\n```asciinema\n{\"src\": \"/asciinema/first-implant.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nNow let’s select our implant and run our first command using the `use` command.\n\n```bash\n[server] sliver > use\n? Select a session or beacon: \nSESSION  1884a365  RELATED_EARDRUM  [::1]:49153      test.local  tester  darwin/amd64\n[*] Active session RELATED_EARDRUM (1884a365-085f-4506-b28e-80c481730fd0)\n\n[server] sliver (RELATED_EARDRUM) > pwd\n\n[*] /Users/tester/tools\n```\n\nOnce you have reached this point, go ahead and explore some of the commands listed below. In each case, first check out the command's help using the **`-h`** flag then try it out!\n\n```bash\nExploring and interacting with the filesystem\n\nFilesystem\n  cat               Dump file to stdout\n  cd                Change directory\n  cp                Copy a file\n  download          Download a file\n  grep              Search for strings that match a regex within a file or directory\n  head              Grab the first number of bytes or lines from a file\n  ls                List current directory\n  mkdir             Make a directory\n  mv                Move or rename a file\n  pwd               Print working directory\n  rm                Remove a file or directory\n  tail              Grab the last number of bytes or lines from a file\n  upload            Upload a file\n```\n\n```asciinema\n{\"src\": \"/asciinema/filesystem.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nGetting some environmental information\n```bash\nInfo\n  env               List environment variables\n  getgid            Get session process GID\n  getpid            Get session pid\n  getuid            Get session process UID\n  info              Get session info\n  ping              Send round trip message to implant (does not use ICMP)\n  whoami            Get session user execution context\n```\nExecute a binary\n\n```asciinema\n{\"src\": \"/asciinema/execute.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nRunning an interactive shell\n\n```asciinema\n{\"src\": \"/asciinema/shell.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nNot all commands are supported for all operating systems or meant to be used on all operating systems, here are a few examples:\n\n```\nmount             Get information on mounted filesystems (only for Windows and Linux)\nscreenshot        Take a screenshot (only for Windows and Linux)\nmemfiles          List current memfiles (Linux only)\n```\n\nThis is an open-source project if you see a bug please file an issue! Pull requests are always welcome."},{"name":"2 - Beacons vs Sessions","content":"Sliver implants support two types of connections, sessions and beacons.\n\nSessions use long-polling connections, which means they constantly maintain a single TCP connection open while communicating with the server. Beacons on the other hand call back periodically and will sleep when not active which can help keep their presence hidden. You could limit callbacks to once every 6 hours for example and only 'activate' the beacon when needed by switching its sleeping time to a shorter duration.\n\nTypically during an engagement you will want to deploy a beacon on the target system and switch to a session while doing more active enumeration.\n\nLet’s start with generating and deploying a beacon using `http`.\n\n```asciinema\n{\"src\": \"/asciinema/beacon_generation.cast\", \"cols\": \"132\", \"rows\": \"14\", \"idleTimeLimit\": 8}\n```\n\nYou can see the beacon callback times either in the `info` command or using `beacons watch`.\n\n```bash\n[server] sliver > beacons watch\n\n ID         Name            Transport   Username          Operating System   Last Check-In   Next Check-In\n========== =============== =========== ================= ==========Line truncated