Clean up docs and files

Author: cbrnrd

REQUIREMENTS.md PROJECT_REQUIREMENTS.md

@@ -7,13 +7,6 @@
 
 Maliketh is a multi-user, customizable C2 framework. The goal of Maliketh is to provide a flexible, easy to use C2 framework that can be customized to fit the needs of the operator. The poster used in the initial presentation is located [here](./data/Maliketh%20C2%20Poster.png).
 
-## Server features
-
-* Multi-user (operators)
-* Easily configurable (via YAML files)
-* Easily deployable (via Docker)
-* Per-operator implant builder
-
 ## Implant features
 
 The implant is written in C++ and targeted for Windows. The main feature of the implant is its ability to change its behavior based on the configuration file it receives from the server. This allows the operator to customize the implant to fit their needs. The implant also has the following features (see [here](./design/opcodes.md) for more info):
@@ -29,34 +22,6 @@ The implant is written in C++ and targeted for Windows. The main feature of the
 * *Very* Basic Anti-VM
 * Sleep skipping detection
 
-## Server deployment
-
-To start the server, 90% of your work can be done by running the following command in the project root:
-
-```bash
-docker-compose -f server/docker-compose.yml --env-file server/.env.example up
-```
-
-Note: You will need to create a `.env` file in the `server/` directory. See `.env.example` for an example.
-
-The only thing left to do is bootstrap the database and create the admin user. To do this, run the following command in the `server` directory:
-
-```bash
-./bootstrap_db.sh
-```
-
-The output of this script will be a JSON configuration for the admin user. You can use this with the maliketh [client](./client/) to connect to the server.
-
-## Ideal server setup
-
-An ideal setup would involve 2 servers. 1 running nginx which the implants connect back to, and 1 running the actual server. This would allow you to use a domain name for the implants to connect to, and also allow you to use SSL. The nginx server would be configured to proxy all traffic to the server. The nginx server would also be configured to use SSL. The server would be configured to only accept connections from the nginx server. This would allow you to use SSL, but not have to worry about the overhead of SSL on the server.
-
-On the server side, Wireguard should be installed and configured. The server should be configured to only accept connections from the Wireguard interface. Wireguard keys should be generated for each operator. The server should be configured to only accept connections from the Wireguard interface.
-
-<p align="center">
-  <img src="./data/Maliketh%20Network%20Diagram.png" alt="Ideal setup" width="500"/>
-</p>
-
 ## Future work
 
 - [ ] Implement Golang client

README.md

@@ -4,10 +4,12 @@ Operators are a single user of the C2 framework. A server can have many operator
 
 ## Creating an operator
 
-In order to create an operator, the admin of the server needs to run the `create_operator.py` script:
+In order to create an operator, the admin of the server needs to run the `create_operator.py` script in the `operator` docker container:
+
+For this example, assume the docker container has ID `37fc3915b843`.
 
 ```bash
-python create_operator.py --name operator_name
+docker exec 37fc3915b843 python create_operator.py --name operator_name
 ```
 
 More options can be found in the help section of that script.

__init__.py

@@ -13,6 +13,7 @@ These are the *default* endpoints for the operator HTTP server. These endpoints
 | `/op/implant/config/:implant_id` | `POST` | Updates the malleable configuration of the implant with the given ID | [example](#post-opimplantconfigimplant_id) |
 | `/op/implant/list` | `GET` | Lists all implants | [example](#opimplantlist) |
 | `/op/implant/kill/:id` | `GET` | Removes the given implant from the database and purges it from the affected system. | [example](#opimplantkillimplant_id) |
+| `/op/implant/build` | `POST` | Builds an implant with the given configuration | [example](#opimplantbuild) |
 | `/op/auth/token/request` | `GET` | Used for fetching an operators authentication token | [example](#opauthtokenrequest) |
 | `/op/auth/token/revoke` | `DELETE` | Revokes the current operator authentication token | [example](#opauthtokenrevoke) |
 | `/op/auth/token/status` | `GET` | Checks the status of the current operator authentication token | [example](#opauthtokenstatus) |
@@ -411,3 +412,39 @@ Failure:
   "message": "Invalid token"
 }
 ```
+
+### `/op/implant/build`
+
+This endpoint is used to build a new implant. Note that depending on the power of the C2 server, this may take a while (a few minutes). The request should be a valid JSON object with any of the following fields:
+
+| Name | Meaning | Default |
+| :-- | :----- | :----- |
+| `initial_sleep_seconds` | The number of seconds to wait before connecting to the server | `180` |
+| `schtask_persist` | Whether or not to use schtasks for persistence | `true` |
+| `use_antidebug` | Whether or not to use antidebugging techniques | `true` |
+| `kill_parent` | Whether or not to kill the parent process after spawning (unused) | `true` |
+| `use_antivm` | Whether or not to use antivm techniques | `true` |
+| `scheduled_task_name` | The name of the scheduled task | `MicrosoftEdgeUpdateTaskMachineUA` |
+| `register_max_retries` | The maximum number of times to retry registering with the server | `5` |
+
+__Example request__:
+
+```json
+{
+  "initial_sleep_seconds": 180,
+  "schtask_persist": true,
+  "use_antidebug": true,
+  "kill_parent": true,
+  "use_antivm": true,
+  "scheduled_task_name": "MicrosoftEdgeUpdateTaskMachineUA",
+  "register_max_retries": 5
+}
+```
+
+__Example response__:
+
+```json
+{
+  "implant": "base64_encoded_implant_pe"
+}
+```

design/operator.md

@@ -2,6 +2,9 @@ FROM nginx:alpine
 
 WORKDIR /app
 
+ENV PROXY_HOST=proxy.example.com
+ENV C2_HOST=c2.example.com
+
 COPY nginx.conf /etc/nginx/nginx.conf
 COPY fullchain.pem  /app/fullchain.pem
 COPY privkey.pem /app/privkey.pem

design/specs/operator-c2-http.md

@@ -5,12 +5,12 @@ http {
   server {
       listen 80;
       server_name _;
-      return 301 https://kjh2iur80in12rjfbjn.ddns.net$request_uri;
+      return 301 https://${PROXY_HOST}$request_uri;
   }
 
   server {
       listen 443 ssl;
-      server_name kjh2iur80in12rjfbjn.ddns.net;
+      server_name ${PROXY_HOST};
 
       ssl_certificate /app/fullchain.pem;
       ssl_certificate_key /app/privkey.pem;
@@ -20,7 +20,7 @@ http {
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
-        proxy_pass http://neuredirector.redirectme.net;
+        proxy_pass http://${C2_HOST};
       }
   }
 }

design/structs/README.md

@@ -0,0 +1,38 @@
+# Maliketh - Server
+
+## Features
+
+* Multi-user (operators)
+* Easily configurable (via YAML files)
+* Easily deployable (via Docker)
+* Per-operator implant builder
+
+
+## Setup
+
+To start the server, 90% of your work can be done by running the following command in the project root:
+
+```bash
+docker-compose -f server/docker-compose.yml --env-file server/.env.example up
+```
+
+Note: You will need to create a `.env` file in the `server/` directory. See `.env.example` for an example.
+
+The only thing left to do is bootstrap the database and create the admin user. To do this, run the following command in the `server` directory:
+
+```bash
+./bootstrap_db.sh
+```
+
+The output of this script will be a JSON configuration for the admin user. You can use this with the maliketh [client](../client/) to connect to the server.
+
+
+## Ideal server setup
+
+An ideal setup would involve 2 servers. 1 running nginx which the implants connect back to, and 1 running the actual server. This would allow you to use a domain name for the implants to connect to, and also allow you to use SSL. The nginx server would be configured to proxy all traffic to the server. The nginx server would also be configured to use SSL. The server would be configured to only accept connections from the nginx server. This would allow you to use SSL, but not have to worry about the overhead of SSL on the server.
+
+On the server side, Wireguard should be installed and unique WireGuard keys should be given to each operator along with their operator configuration. The server should be configured to only accept connections from the Wireguard interface. Wireguard keys should be generated for each operator. The server should be configured to only accept connections from the Wireguard interface.
+
+<p align="center">
+  <img src="./data/Maliketh%20Network%20Diagram.png" alt="Ideal setup" width="500"/>
+</p>