Docs/next

docs/sliver-docs/components/code.tsx

@@ -13,6 +13,7 @@ export type CodeSchema = {
 
 export type CodeViewerProps = {
   script: CodeSchema;
+  fontSize?: number;
 
   className?: string;
 };
@@ -58,7 +59,7 @@ const CodeViewer = (props: CodeViewerProps) => {
   const [scriptSourceCode, setScriptSourceCode] = React.useState(
     props.script.source_code
   );
-  const [fontSize, setFontSize] = React.useState(14);
+  const [fontSize, setFontSize] = React.useState(props.fontSize || 14);
   const editorContainerClassName = React.useMemo(() => {
     return theme === Themes.DARK
       ? "col-span-12 mt-4 rounded-2xl overflow-hidden"

docs/sliver-docs/pages/docs/index.tsx

@@ -1,3 +1,4 @@
+import CodeViewer, { CodeSchema } from "@/components/code";
 import { Themes } from "@/util/themes";
 import {
   Card,
@@ -50,7 +51,7 @@ const DocsIndexPage: NextPage = () => {
 
   return (
     <div className="grid grid-cols-12">
-      <div className="col-span-2 mt-6 ml-4">
+      <div className="col-span-3 mt-4 ml-4">
         <div className="flex flex-row justify-center text-lg mb-2 gap-2">
           Topics
         </div>
@@ -77,18 +78,68 @@ const DocsIndexPage: NextPage = () => {
           </Listbox>
         </div>
       </div>
-      <div className="col-span-10">
+      <div className="col-span-9">
         <Card className="mt-8 ml-8 mr-8 mb-8">
           <CardHeader>
             <span className="text-3xl">{name}</span>
           </CardHeader>
           <Divider />
           <CardBody
             className={
-              theme === Themes.DARK ? "prose prose-invert" : "prose prose-slate"
+              theme === Themes.DARK
+                ? "prose prose-sm dark:prose-invert"
+                : "prose prose-sm prose-slate"
             }
           >
-            <Markdown remarkPlugins={[remarkGfm]}>{markdown}</Markdown>
+            <Markdown
+              remarkPlugins={[remarkGfm]}
+              components={{
+                pre(props): any {
+                  const { children, className, node, ...rest } = props;
+                  const childClass = (children as any)?.props?.className;
+                  if (
+                    childClass &&
+                    childClass.startsWith("language-") &&
+                    childClass !== "language-plaintext"
+                  ) {
+                    // @ts-ignore
+                    return <div {...rest}>{children}</div>;
+                  }
+                  return (
+                    <pre {...rest} className={className}>
+                      {children}
+                    </pre>
+                  );
+                },
+                code(props) {
+                  const { children, className, node, ...rest } = props;
+                  const langTag = /language-(\w+)/.exec(className || "");
+                  const lang = langTag ? langTag[1] : "plaintext";
+                  if (lang === "plaintext") {
+                    return (
+                      <code {...rest} className={className}>
+                        {children}
+                      </code>
+                    );
+                  }
+                  return (
+                    <CodeViewer
+                      className="min-h-[250px]"
+                      key={`${Math.random()}`}
+                      fontSize={11}
+                      script={
+                        {
+                          script_type: lang,
+                          source_code: (children as string) || "",
+                        } as CodeSchema
+                      }
+                    />
+                  );
+                },
+              }}
+            >
+              {markdown}
+            </Markdown>
           </CardBody>
         </Card>
       </div>

docs/sliver-docs/pages/docs/md/Anti-virus Evasion.md

@@ -0,0 +1,6 @@
+The Sliver authors do not consider anti-virus evasion to be within the scope of the Sliver project; there is already a myriad of works in this area. That said, Sliver is designed to be interoperable with common techniques for bypassing anti-virus software such as packers, crypters, and [stagers](https://github.com/BishopFox/sliver/wiki/Stagers).
+
+Here are some external resources for anti-virus evasion:
+
+- https://www.veil-framework.com/framework/veil-evasion/
+- https://iwantmore.pizza/posts/PEzor.html

docs/sliver-docs/pages/docs/md/Architecture.md

@@ -0,0 +1,32 @@
+This document describes the technical design of Sliver.
+
+## High Level
+
+There are four major components to the Sliver ecosystem:
+
+- **Server Console -** The server console is the main interface, which is started when you run the `sliver-server` executable. The server console is a superset of the client console. All code is shared between the client/server consoles except server-specific commands related to client (i.e., operator) management. The server console talks over an in-memory gRPC interface to the server.
+- **Sliver Server -** The Sliver server is also part of the `sliver-server` executable and manages the internal database, starts/stops network listeners (such as C2 listeners, though there are other types). The main interface used to interact with the server is the gRPC interface, thru which all functionality is implemented. By default the server will only start an in-memory gRPC listener that can only be communicated with from the server console. However, the gRPC interface can also be exposed to the network (i.e., multiplayer mode) over mutual TLS (mTLS).
+- **Sliver Client -** The client console is the primary user interface that is used to interact with the Sliver server. Note that most of the code in the server console is actually the client console. The client console can also be compiled into a separate client binary file `sliver-client`, which is generally used to connect to the "mutliplayer" gRPC network listener.
+- **Implant -** The implant is the actual malicious code run on the target system you want remote access to.
+
+```
+             In         ┌───────────────┐ C2
+┌─────────┐  Memory     │               │ Protocol ┌─────────┐
+│ Server  ├────────────►│ Sliver Server ├─────────►│ Implant │
+│ Console │             │               │          └─────────┘
+└─────────┘             └───────────────┘
+                               ▲
+                               │
+                               │gRPC/mTLS
+                               │
+                          ┌────┴────┐
+                          │ Sliver  │
+                          │ Client  │
+                          └─────────┘
+```
+
+By implementing all functionality over this gRPC interface, and only differing the in-memory/mTLS connection types the client code doesn't "know" if it's running in the server console or the client console. Due to this, a single command implementation will work in both the server console and over the network in multiplayer mode.
+
+## Sliver Server
+
+WIP

docs/sliver-docs/pages/docs/md/Audit Log.md

@@ -0,0 +1,19 @@
+Sliver keeps an audit log of every command and its arguments executed by the server (including commands executed by operators in multiplayer mode), as well as most events (such as a new session or beacon connecting to the server). The audit log's intended use is for after-action analysis; providing a detailed history of the entire engagement, including which commands were executed on which hosts when. This will include any commands executed by any operator on any session. Note some console commands only perform actions on the "client-side" and may not appear in the audit log, but will still appear in the client's command history. Additionally, interactive commands (e.g., `shell`) may not appear in the logs aside from the initial usage of the `shell` command.
+
+By default the audit log is located on the server at: `~/.sliver/logs/audit.json`. However, this can be changed by modifying the [`SLIVER_ROOT_DIR`](https://github.com/BishopFox/sliver/wiki/Environment-Variables#assets) environment variable.
+
+#### Parsing Audit Logs
+
+The audit log is stored in a newline delimited (one object per line) nested-JSON format designed to be primarily machine readable, an example entry is shown below:
+
+```
+{"level":"info","msg":"{\"request\":\"{\\\"Port\\\":8888}\",\"method\":\"/rpcpb.SliverRPC/StartMTLSListener\"}","time":"2021-06-16T10:22:54-05:00"}
+```
+
+**NOTE:** Due to limitations in the logging APIs the audit log contains nested JSON objects that may require additional parsing.
+
+The top level JSON should always contain:
+
+- `level` - The level indicates the type of action performed. Currently, `info` indicates commands and `warn` indicates events.
+- `msg` - A JSON object encoded as a string. This object should always contain a `request` and a `method`. The contents of `method` indicate which command was executed, `request` will contain parameters to that command. The contents of `request` will vary depending on the command, but it will be based on the corresponding gRPC/Protobuf message.
+- `time` - The server's timestamp of the log entry

docs/sliver-docs/pages/docs/md/BOF and COFF Support.md

@@ -0,0 +1,119 @@
+Sliver v1.5 and later support the loading and execution of BOFs and COFFs, generally no code changes are needed to use BOFs with a Sliver implant. However, you may need to define a manifest file so that Sliver is aware of BOF arguments and their types.
+
+### BOF Extensions
+
+BOF support is provided via the [COFF Loader](https://github.com/sliverarmory/COFFLoader) extension, you'll need it installed to run pretty much any BOF. However, the COFF Loader will be installed automatically if you install a BOF extension from the [armory](https://github.com/BishopFox/sliver/wiki/Armory).
+
+The easiest way to install a BOF extension, for example [`nanodump`](https://github.com/sliverarmory/nanodump), is using the [armory](https://github.com/BishopFox/sliver/wiki/Armory) package manager:
+
+**IMPORTANT:** BOF Extensions are installed per-sliver client, they are not stored on the server. Thus extensions are not shared across operators, each operator must install the extension to use it.
+
+```
+sliver > armory install nanodump
+
+[*] Installing extension 'nanodump' (v0.0.5) ... done!
+
+sliver > nanodump -h
+
+A Beacon Object File that creates a minidump of the LSASS process.
+
+Usage:
+======
+  nanodump [flags] pid dump-name write-file signature
+
+Args:
+=====
+  pid         int       The PID of the process you want to dump.
+  dump-name   string    The name of the dump file.
+  write-file  int       1 = write file, 0 = fileless
+  signature   string    Signature used for evasion, PMDM = default
+
+Flags:
+======
+  -h, --help           display help
+  -s, --save           Save output to disk
+  -t, --timeout int    command timeout in seconds (default: 60)
+```
+
+### Converting BOFs to Sliver
+
+Converting existing BOFs to work with Sliver is usually pretty easy, and shouldn't require any code changes. You'll need to define an `extension.json` though based on what arguments/etc. the BOF accepts.
+
+To determine the arguments a BOF accepts and their types, you'll need to read `.cna` script that accompanies a given BOF. For example, the [CredMan](https://github.com/sliverarmory/CredManBOF/blob/main/CredMan.cna) `.cna` script is show below:
+
+```
+alias CredMan {
+	local('$handle $data $args $2');
+
+    if(size(@_) != 3){
+        berror($1, "CredMan: not enough arguments,Usage: CredMan [user process id] ");
+        return;
+    }
+
+    $handle = openf(script_resource("CredMan.o"));
+    $data   = readb($handle, -1);
+    closef($handle)
+
+    $args = bof_pack($1,"i",$2);
+
+    btask($1, "Running CredMan");
+
+
+    beacon_inline_execute($1,$data,"go",$args);
+}
+
+beacon_command_register(
+"CredMan",
+"Enables SeTrustedCredManAccess Privilege in a token stolen from winlogon.exe to dump Windows Credential Manager");
+```
+
+| Type | Description                      | Sliver Type                  |
+| ---- | -------------------------------- | ---------------------------- |
+| b    | binary data                      | `file` (path to binary data) |
+| i    | 4-byte integer                   | `int` or `integer`           |
+| s    | 2-byte short integer             | `short`                      |
+| z    | zero-terminated+encoded string   | `string`                     |
+| Z    | zero-terminated wide-char string | `wstring`                    |
+
+Looking at the script we can see the BOF requires a single integer argument. The corresponding Sliver `extension.json` file is shown below. Note that BOFs will always rely on the `coff-loader` extension but other kinds of extensions may not. If the `coff-loader` extension is not already installed on your system, it can be installed using `armory install coff-loader`. You can list installed extensions by simply running the `extensions` command with no arguments.
+
+```json
+{
+  "name": "credman",
+  "version": "1.0.0",
+  "command_name": "credman",
+  "extension_author": "lesnuages",
+  "original_author": "jsecu",
+  "repo_url": "https://github.com/sliverarmory/CredManBOF",
+  "help": "Dump credentials using the CredsBackupCredentials API",
+  "long_help": "",
+  "depends_on": "coff-loader",
+  "entrypoint": "go",
+  "files": [
+    {
+      "os": "windows",
+      "arch": "amd64",
+      "path": "credman.x64.o"
+    },
+    {
+      "os": "windows",
+      "arch": "386",
+      "path": "credman.x86.o"
+    }
+  ],
+  "arguments": [
+    {
+      "name": "pid",
+      "desc": "PID of a process started by the target user",
+      "type": "int",
+      "optional": false
+    }
+  ]
+}
+```
+
+Once the manifest is defined load it into your client using `extensions load`, locally loaded extensions do not need to be cryptographically signed. The paths in the manifest should be relative to the manifest file, parent directories are not allowed.
+
+More details can be found on the [Aliases & Extensions](https://github.com/BishopFox/sliver/wiki/Aliases-&-Extensions) page.
+
+**IMPORTANT:** For BOF extensions to be properly detected by the Sliver client, the `path` must use the `.o` file extension.

docs/sliver-docs/pages/docs/md/Beginner's Guide.md

@@ -0,0 +1,37 @@
+⚠️ **NOTE:** This guide is intended for absolute beginners to the red team space, please see the [Getting Started](https://github.com/BishopFox/sliver/wiki/Getting-Started) guide for a more straight forward tutorial if that's not you.
+
+# The Red Team Beginner's Guide to Sliver
+
+⚠️ This page is a work in progress and is incomplete, you may want to read [Getting Started](https://github.com/BishopFox/sliver/wiki/Getting-Started) or the [Community Guides](https://github.com/BishopFox/sliver/wiki/Community-Guides) instead for the time being.
+
+## Introduction
+
+### What's a C2?
+
+A command and control (C2) framework allows attackers to fully leverage existing access to computer systems or networks. C2 frameworks such as Sliver by themselves will generally not get you access to systems that you do not already have. There are many techniques for gaining initial access, however some of the most common are exploiting software vulnerabilities using something like [Metasploit](https://www.metasploit.com/), or by social engineering a user to inadvertently execute a C2 payload. Regardless of the initial access method, the subsequent steps taken by an attacker are referred to as "post-exploitation" activities.
+
+Throughout this guide and the Sliver code base the following terms of art are used. These definitions may vary slightly across the industry but this is how we define them:
+
+- **Implant** - A generic term for piece of software used to maintain access to an environment or system, generally through the use of command and control (C&C, C2, etc.), this is the code that the attack executes on the target machine as well as maintain access. The term "implant" is often interchangeable with "agent."
+
+- **Beacon** - May refer to (1) a communication pattern where an implant periodically connects to the C2 server as apposed to using a stateful/real time connection (2) [Cobalt Strike's](https://www.cobaltstrike.com/) primary implant, more often called "CS Beacon." In the context of Sliver, "Beacon" specifically refers to a Sliver implant that implements definition (1) communication style.
+
+- **Stage** - A "stage" or "staged payload" is a method of loading a piece of code, typically over a network, onto a remote machine. Traditionally staging was used in conjunction with exploits that had size limitations. Typically the goal is to execute a small piece of code, i.e. the "stager," which in turn loads a larger piece of code. Staged payloads are still used in this way today, however they are also often useful for bypassing anti-virus detection since the majority of the malicious code is loaded directly into memory. Stages are sometimes number e.g. a "stage 0" will load a "stage 1" which loads a "stage 2" payload.
+
+### Selecting a C2 Framework
+
+You should always choose the right tool for the right job. There are many open source, as well as commercially available C2 frameworks to choose from. A key element to successful red teams, is the ability understand how all these tools work, and when best to apply them given the contextual variables of an operation or action. The [C2 Matrix](https://www.thec2matrix.com/) has a good overview of both commercial and open source frameworks -though the Sliver entry is a bit out of date.
+
+Here is a high level overview of open source frameworks we recommend in addition to Sliver, and some advantages/disadvantages of each:
+
+#### [Sliver](https://github.com/BishopFox/sliver)
+
+Both the Sliver server and implant are written in Golang (the Go programming language). This makes setup of a basic Sliver deployment as easy as running the server binary. The Sliver implant is also written in Golang, which means it's easy to cross-compile to a variety of platforms. However, the tradeoff here is that the executable files (e.g., a .exe) can be sizable (up to 20Mb depending on options), as in life nothing is free.
+
+#### [Mythic](https://github.com/its-a-feature/Mythic)
+
+A Mythic deployment consists of several components implemented in a variety of languages, setup of a deployment is relatively automated however isn't as simple as Sliver or Merlin. However, Mythic makes it much easier to integrate 3rd party or modified implants to avoid detection in comparison to Sliver or Merlin. Mythic also features a multi-user web interface making collaboration between operators easy. The stability, features, and stealth of Mythic implants varies depending on the agent implementation you choose, which is important to keep in mind during operational planning.
+
+#### [Merlin](https://github.com/Ne0nd0g/merlin)
+
+The Merlin server and implant are also implemented in Golang.