stratum-c2

---

El problema

Tu C2 principal se queda en silencio. El dominio acaba en listas negras. El beacon es detectado. El EDR mata el proceso. Estás fuera.

Necesitas un segundo canal — uno que nunca hubiera sido bloqueado en primer lugar.

---

La idea

¿Y si el tráfico de comando y control se viera exactamente como un empleado sincronizando archivos con Dropbox?

Eso es Stratum. Los comandos y las respuestas viajan como archivos ordinarios dentro de una carpeta de almacenamiento en la nube. El agente nunca se conecta a infraestructura del atacante. El único tráfico observable es HTTPS hacia un proveedor que el firewall del objetivo ya tiene en la lista blanca — porque bloquear Dropbox o OneDrive significa bloquear a todos los empleados que lo usan.

Sin teamserver. Sin dominio propiedad del atacante. Sin certificado TLS sospechoso. Nada que bloquear.

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

El agente se despierta en un intervalo configurable (+ jitter log-normal), lee el archivo de entrada, ejecuta, cifra la respuesta, la sube y duerme. Todo cifrado de extremo a extremo con RSA-4096-OAEP + AES-256-GCM. La IP del operador nunca aparece en ningún registro de red del lado del objetivo.

---

Proveedores en la nube

Los cinco comparten el mismo formato de transmisión, el mismo par de claves RSA y la misma sesión de operador. Cambia de proveedor a mitad de la operación en minutos sin tocar el agente. Ningún otro framework de código abierto incluye esto de serie.

---

Cinco cosas que no existen en ningún otro lugar

1. El canal es estructuralmente imposible de bloquear

Un SOC que quiere detener un C2 bloquea el dominio del teamserver o la infraestructura frontal. Un SOC que quiere detener Stratum tiene que bloquear Dropbox, OneDrive, Google Drive, SharePoint y S3 simultáneamente. Eso no es una regla de firewall: es una decisión de negocio que ninguna empresa va a tomar. La arquitectura de dead-drop no intenta evadir la detección. Opera sobre infraestructura que el defensor ya ha decidido confiar, de forma permanente.

2. Cuatro formatos de agente nativos desde un único flujo de despliegue

Formato	Plataforma	Dependencias
.exe / .dll	Windows	Ninguna — PE compilado en Rust (MSVC-ABI), sin intérprete, sin PowerShell en el árbol de procesos
.elf	Linux	Ninguna — musl-static compilado en Rust, se ejecuta en cualquier Linux x86_64
.bin	Linux / Windows	Shellcode PIC x64 — insértalo en cualquier cargador o inyector externo

El asistente genera todos ellos. Tú respondes a las indicaciones; él compila, cifra y empaqueta. Sin flags de compilador, sin variables de entorno, sin gestión manual de claves.

3. Tres modos de despliegue — adaptados a la operación

Modo	Cómo funciona	Ideal para
staged-enc	Stub mínimo en el objetivo. En la primera ejecución: obtiene la clave de arranque de un solo uso desde la nube, descifra el agente completo en memoria, elimina la clave de la nube. El payload nunca toca el disco en texto claro.	Operaciones estándar — artefacto inicial más pequeño, clave destruida en la entrega
stageless-enc	Agente completo incrustado en un único archivo de entrega, cifrado con una clave integrada en el stub. No se necesita obtener la clave de la nube tras la entrega.	Redes aisladas o restringidas — archivo único autocontenido
stageless-plain	Agente en texto claro. Los comandos y las respuestas permanecen totalmente cifrados en tránsito.	Laboratorios y entornos controlados

Todos los modos comparten el mismo comportamiento tras la ejecución: el stub almacena en caché local un blob cifrado con huella de hardware (HW) para que las ejecuciones posteriores carguen desde el disco sin tocar la nube.

4. Persistencia — sondear, instalar, sobrevivir

Antes de tocar una sola clave de registro o entrada de cron, ejecuta /persist probe. El agente comprueba todas las técnicas disponibles en el nivel de privilegio actual y devuelve un informe de viabilidad. No destructivo — no deja artefactos.

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

Elige lo que funcione, instálalo, elimínalo limpiamente cuando termines. La WebGUI registra cada técnica instalada por sesión. /kill desmonta todo —persistencia, binario, artefactos en la nube— con un solo comando.

5. Barreras operativas integradas en el momento del despliegue

Fecha de terminación, ventana de mantenimiento, jitter log-normal, clave de arranque de un solo uso — todo se configura una vez en el asistente y se compila permanentemente en el agente. Nada que gestionar durante el compromiso, nada que olvidar limpiar al final.

---

Cómo encaja Stratum en un compromiso

Stratum no es un sustituto de Cobalt Strike, Sliver o Havoc. Es la capa que subyace a ellos.