Merge branch 'dev': more offensive context, better architecture, improved why section

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: franckferman

README.md

@@ -47,32 +47,40 @@
 
 ## Overview
 
-`do-manager` is built on top of [`godo`](https://github.com/digitalocean/godo), the official DigitalOcean Go client. It is designed as a **dual-purpose project**:
+`do-manager` is built directly on [`godo`](https://github.com/digitalocean/godo), the official DigitalOcean Go client. Two interfaces, one codebase:
 
-- A **CLI tool** for interacting with your DigitalOcean account from the terminal.
-- A **Go library** (`pkg/`) that can be imported directly into other Go programs.
+- A **CLI tool** for operational use from the terminal - campaign orchestration, IP rotation, node rebuild, security audit.
+- A **Go library** (`pkg/`) that can be imported directly into any Go program.
 
-Unlike a wrapper around `doctl`, `do-manager` calls the DigitalOcean API directly via `godo`. No external binary, proper Go types throughout, full composability.
+Unlike `doctl`, `do-manager` calls the API directly via `godo` - no subprocess, no string parsing, proper Go types throughout.
 
-The CLI is designed for **operational use cases**: Red Team infrastructure, lab automation, CI/CD provisioning. It supports campaign orchestration (deploy / rotate IPs / destroy a full stack in one command), VPC-isolated networks, firewall presets for common roles, and a security audit scanner.
+The design targets **Red Team infrastructure**: deploy a full engagement stack in one command, rotate IPs when they get burned, rebuild a single compromised node without touching the rest, tear everything down cleanly. The primitive operations (create/list/delete/power) are there, but the value is in the higher-level abstractions: `campaign`, firewall presets, `rotate-ips`, `rebuild`, `audit`.
 
 ---
 
 ## Why do-manager?
 
-| | doctl | Terraform / Pulumi | do-manager |
-|---|---|---|---|
-| **Type** | CLI binary | Infrastructure-as-Code | CLI + Go library |
-| **Importable as Go lib** | No | No | **Yes** |
-| **Requires external binary** | Yes | Yes | No |
-| **State management** | No | Yes (statefile) | No (stateless) |
-| **Parallel batch ops** | No | Partial | **Yes** |
-| **Campaign orchestration** | No | Partial | **Yes** (deploy/status/destroy/rotate) |
-| **Firewall presets** | No | No | **Yes** (c2/phishing/redirector/bastion/lockdown) |
-| **Security audit** | No | No | **Yes** (exit 1 on CRITICAL/HIGH) |
-| **Multi-role campaign** | No | No | **Yes** (`--role "c2:..."` + `--role "redirector:..."`) |
-| **JSON output** | Yes | N/A | **Yes** (`-o json`) |
-| **Embed in a Go project** | Subprocess + parsing | SDK only | `import "pkg/droplet"` |
+Three tools are commonly used to manage DO infrastructure from a Red Team perspective:
+
+| | doctl | bash + curl | Terraform / Pulumi | do-manager |
+|---|---|---|---|---|
+| **Type** | Official CLI | Ad-hoc scripts | Infrastructure-as-Code | CLI + Go library |
+| **Campaign orchestration** | No | Manual | Partial | **Yes** (deploy/status/destroy/rotate) |
+| **Firewall presets** | No | No | No | **Yes** (c2/phishing/redirector/bastion/lockdown) |
+| **IP rotation** | No | Script it yourself | No | **Yes** (rotate-ips) |
+| **Parallel batch ops** | No | `&` + wait | Partial | **Yes** (goroutines, per-slot errors) |
+| **Security audit** | No | No | No | **Yes** (exit 1 on CRITICAL/HIGH) |
+| **Importable as Go lib** | No | No | No | **Yes** (`import "pkg/droplet"`) |
+| **Requires state file** | No | No | Yes (.tfstate) | No (stateless) |
+| **Requires external binary** | Yes (doctl) | curl, jq | Yes (terraform) | **No** |
+
+**doctl** is fine for manual one-off ops. It covers every DO resource but has no campaign concept, no firewall presets, and no Red Team abstractions.
+
+**bash + curl** is where most people start. It breaks down under engagement pressure: parallel provisioning races, ID extraction with fragile `grep`/`jq`, no error aggregation per Droplet, scripts that diverge between operators.
+
+**Terraform** is the right choice for long-lived stable infrastructure. It is overkill for engagements: statefile management is a liability during ops, the feedback loop is slow, and there are no Red Team primitives.
+
+**do-manager** is the choice when you need to deploy a full stack fast, rotate IPs when they get burned, rebuild a single node without disrupting the campaign, tear everything down cleanly, and optionally embed all of that into a Go automation tool.
 
 ---
 
@@ -373,29 +381,49 @@ do-manager reservedip delete 1.2.3.4
 
 ### Snapshots
 
+Snapshots are the foundation for repeatable deployments. The workflow: provision one Droplet, install and configure your tooling (GoPhish, Havoc, evilginx2, nginx redirector config, WireGuard), take a snapshot, delete the source Droplet. On engagement day, `campaign deploy --snapshot <slug>` restores that exact state across N nodes in parallel. No reinstalling, no drift between nodes.
+
 ```bash
 do-manager snapshot list
 do-manager snapshot get <id>
+
+# Freeze a configured Droplet into a reusable image
 do-manager snapshot create --droplet 12345678 --name gophish-v2 --wait
+
+# Now deploy that exact state to 5 nodes
+do-manager campaign deploy --name phish-q2 --snapshot gophish-v2 --count 5 ...
+
 do-manager snapshot delete <id>
 ```
 
-Workflow: bake your tooling into a snapshot once, then deploy N identical nodes via `campaign deploy --snapshot gophish-v2`.
-
 ---
 
 ### VPC
 
 An isolated private network scoped to a region. Droplets share a private IP range; traffic between them never leaves the DO fabric.
 
+**What VPC is and is not.** A VPC is a network isolation layer - it gives your C2 node a private IP that only other Droplets in the same VPC can reach. It is not the channel you use to proxy C2 traffic; that is the redirector's job. The redirector (nginx, socat, Apache mod_proxy) forwards inbound HTTPS to the C2 over the private IP. No public firewall rule needed on the C2 node.
+
+Three common approaches to route traffic from redirector to C2:
+
+| Method | How it works | Notes |
+|---|---|---|
+| **DO VPC private IP** | Both nodes same region/VPC. nginx forwards to `10.x.x.x:port`. | Zero extra setup. Same region required. |
+| **WireGuard** | VPN tunnel between redirector and C2. C2 listens on `wg0` only. | Cross-provider, cross-region. Extra cloud-init setup. |
+| **SSH reverse tunnel** | C2 runs `ssh -R 8080:localhost:8080 user@redirector`. | Simple. Use autossh/systemd to survive disconnects. |
+
 ```
-Internet
-   |
-[Redirector]  1.2.3.4:443  (public)
-   |
-   |  VPC 10.20.0.0/24 (private, never reaches internet)
-   |
-[C2 Server]  0 public ports for C2 protocol
+           Internet
+               |
+   Agent HTTPS :443
+               |
+        [Redirector]  1.2.3.4  public: 80/443 open
+         nginx proxy_pass http://10.20.0.2:443
+               |
+  VPC 10.20.0.0/24  (private, stays inside datacenter fabric)
+               |
+        [C2 Server]  10.20.0.2  no public C2 port
+                       public firewall: SSH only from operator IP
 ```
 
 ```bash
@@ -407,6 +435,9 @@ do-manager vpc delete <id>
 
 # Attach a Droplet to the VPC at creation time
 do-manager droplet create --name c2-node --vpc-uuid <id> ...
+
+# Or let campaign create the VPC automatically
+do-manager campaign deploy --name op-ghost --vpc-auto ...
 ```
 
 ---
@@ -415,6 +446,8 @@ do-manager droplet create --name c2-node --vpc-uuid <id> ...
 
 Deploy and tear down a complete infrastructure campaign with a single command. A campaign groups all resources under the tag `campaign:<name>`.
 
+The campaign lifecycle exists because Red Team infra has a specific tempo: provision fast, rotate IPs when they get burned, rebuild compromised nodes without disrupting the rest, tear down cleanly at the end. `campaign deploy` creates Droplets, firewall, and reserved IPs in the right order and tags everything. `campaign destroy` deletes all of it in one shot. Nothing left behind.
+
 #### Simple (single role)
 
 ```bash