stratum-c2

---

The problem

Your primary C2 goes silent. The domain gets blacklisted. The beacon gets flagged. The EDR kills the process. You're out.

You need a second channel — one that was never going to get blocked in the first place.

---

The idea

What if command-and-control traffic looked exactly like an employee syncing files to Dropbox?

That's Stratum. Commands and responses travel as ordinary files inside a cloud storage folder. The agent never connects to attacker infrastructure. The only observable traffic is HTTPS to a provider the target's firewall already whitelists — because blocking Dropbox or OneDrive means blocking every employee who uses it.

No teamserver. No attacker-owned domain. No suspicious TLS certificate. Nothing to block.

  OPERATOR                   CLOUD PROVIDER               TARGET
  ────────                   ─────────────                ──────
                             /Machine1/
  WebGUI ──HTTPS──►          input.txt   🔒  ◄── poll ── agent
                             output.txt  🔒  ──► read ──┘
                             heartbeat.txt    (encrypted beacon)

The agent wakes on a configurable interval (+ log-normal jitter), reads the input file, executes, encrypts the response, uploads it, and sleeps. Everything encrypted end-to-end with RSA-4096-OAEP + AES-256-GCM. The operator's IP never appears in any network log on the target side.

---

Cloud Providers

All five share the same wire format, the same RSA keypair, and the same operator session. Switch provider mid-engagement in minutes without touching the agent. No other open-source framework ships this out of the box.

---

Five things that don't exist anywhere else

1. The channel is structurally unblockable

A SOC that wants to stop C2 blocks the teamserver domain or fronted infrastructure. A SOC that wants to stop Stratum has to block Dropbox, OneDrive, Google Drive, SharePoint, and S3 simultaneously. That's not a firewall rule — it's a business decision no enterprise is going to make. The dead-drop architecture doesn't try to evade detection. It operates on infrastructure the defender has already decided to trust, permanently.

2. Four native agent formats from a single deploy flow

Format	Platform	Dependencies
.exe / .dll	Windows	None — Rust-compiled PE (MSVC-ABI), no interpreter, no PowerShell in process tree
.elf	Linux	None — Rust-compiled musl-static, runs on any x86_64 Linux
.bin	Linux / Windows	x64 PIC shellcode — drop into any external loader or injector

The wizard generates all of them. You answer prompts; it compiles, encrypts, and packages. No compiler flags, no env vars, no manual key management.

3. Three deploy modes — matched to the engagement

Mode	How it works	Best for
staged-enc	Minimal stub on target. On first run: fetches one-time bootstrap key from cloud, decrypts full agent in memory, deletes key from cloud. Payload never touches disk in cleartext.	Standard engagements — smallest initial artifact, key destroyed on delivery
stageless-enc	Full agent embedded in single delivery file, encrypted with a stub-baked key. No cloud key fetch needed after delivery.	Air-gapped or restricted networks — single self-contained file
stageless-plain	Agent in cleartext. Commands and responses remain fully encrypted in transit.	Labs and controlled environments

All modes share the same post-execution behaviour: the stub caches an HW-fingerprinted encrypted blob locally so subsequent runs load from disk without touching the cloud.

4. Persistence — probe, install, survive

Before touching a single registry key or cron entry, run /persist probe. The agent checks every available technique at the current privilege level and returns a feasibility report. Non-destructive — no artifacts left behind.

/persist probe
  ✓ schtask-logon   — feasible (SYSTEM)
  ✓ registry-run    — feasible
  ✗ schtask-boot    — requires elevation
  ✓ startup-folder  — feasible
  ...

Pick what works, install it, remove it cleanly when done. The WebGUI tracks every installed technique per session. /kill tears everything down — persistence, binary, cloud artifacts — in one command.

5. Operational guardrails baked at deploy time

Kill date, maintenance window, log-normal jitter, one-time bootstrap key — all configured once in the wizard and compiled into the agent permanently. Nothing to manage during the engagement, nothing to forget to clean up at the end.

---

How Stratum fits into an engagement

Stratum is not a replacement for Cobalt Strike, Sliver, or Havoc. It's the layer underneath them.

  Day 1: deploy Stratum alongside your primary C2
  Day 4: primary beacon gets flagged, process killed
  Day 4: open Stratum session, assess what happened
  Day 4: re-introduce primary C2 via Stratum shell
  Day 5: back to full access

Your primary C2 handles post-exploitation. Stratum handles survival. It's the channel that was never going to get detected because it was never trying to hide — it just looks like Dropbox.

This is the same paradigm used in the wild by threat actors documented in 2025–2026: TukTuk (Dropbox + Arweave dead-drop), NarwhalRAT/APT37 (pCloud), COBALT MIRAGE/Drokbk (GitHub). Stratum brings the same architecture to the red team side as a proper framework, not a one-off implant.

---

Quick start