stratum-c2

---

O problema

Seu C2 principal fica silencioso. O domínio é colocado em listas de bloqueio. O beacon é sinalizado. O EDR mata o processo. Você está fora.

Você precisa de um segundo canal — um que nunca fosse ser bloqueado em primeiro lugar.

---

A ideia

E se o tráfego de comando e controle se parecesse exatamente com um funcionário sincronizando arquivos para o Dropbox?

Isso é o Stratum. Comandos e respostas trafegam como arquivos comuns dentro de uma pasta de armazenamento em nuvem. O agente nunca se conecta à infraestrutura do atacante. O único tráfego observável é HTTPS para um provedor que o firewall do alvo já permite — porque bloquear o Dropbox ou o OneDrive significa bloquear todos os funcionários que os utilizam.

Sem teamserver. Sem domínio controlado pelo atacante. Sem certificado TLS suspeito. Nada para bloquear.

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

O agente desperta em um intervalo configurável (+ jitter log-normal), lê o arquivo de entrada, executa, criptografa a resposta, faz o upload e dorme. Tudo criptografado de ponta a ponta com RSA-4096-OAEP + AES-256-GCM. O IP do operador nunca aparece em nenhum log de rede do lado do alvo.

---

Provedores de Nuvem

Todos os cinco compartilham o mesmo formato de transmissão, o mesmo par de chaves RSA e a mesma sessão de operador. Troque de provedor no meio do engajamento em minutos sem tocar no agente. Nenhum outro framework open-source entrega isso pronto de fábrica.

---

Cinco coisas que não existem em nenhum outro lugar

1. O canal é estruturalmente impossível de bloquear

Um SOC que quer parar um C2 bloqueia o domínio do teamserver ou a infraestrutura de fronting. Um SOC que quer parar o Stratum precisa bloquear Dropbox, OneDrive, Google Drive, SharePoint e S3 simultaneamente. Isso não é uma regra de firewall — é uma decisão de negócio que nenhuma empresa vai tomar. A arquitetura de dead-drop não tenta evadir a detecção. Ela opera sobre infraestrutura que o defensor já decidiu confiar, permanentemente.

2. Quatro formatos nativos de agente a partir de um único fluxo de implantação

Formato	Plataforma	Dependências
.exe / .dll	Windows	Nenhuma — PE compilado em Rust (ABI MSVC), sem interpretador, sem PowerShell na árvore de processos
.elf	Linux	Nenhuma — musl-static compilado em Rust, roda em qualquer Linux x86_64
.bin	Linux / Windows	Shellcode PIC x64 — insira em qualquer loader ou injetor externo

O assistente gera todos eles. Você responde aos prompts; ele compila, criptografa e empacota. Sem flags de compilador, sem variáveis de ambiente, sem gerenciamento manual de chaves.

3. Três modos de implantação — adequados ao engajamento

Modo	Como funciona	Melhor para
staged-enc	Stub mínimo no alvo. Na primeira execução: busca a chave de bootstrap de uso único na nuvem, descriptografa o agente completo em memória, apaga a chave da nuvem. O payload nunca toca o disco em texto claro.	Engajamentos padrão — menor artefato inicial, chave destruída na entrega
stageless-enc	Agente completo embutido em um único arquivo de entrega, criptografado com uma chave embutida no stub. Nenhuma busca de chave na nuvem necessária após a entrega.	Redes isoladas (air-gapped) ou restritas — arquivo único autocontido
stageless-plain	Agente em texto claro. Comandos e respostas permanecem totalmente criptografados em trânsito.	Laboratórios e ambientes controlados

Todos os modos compartilham o mesmo comportamento pós-execução: o stub armazena em cache localmente um blob criptografado com impressão digital de hardware (HW-fingerprinted), de modo que execuções subsequentes carregam do disco sem tocar na nuvem.

4. Persistência — sondar, instalar, sobreviver

Antes de tocar em uma única chave de registro ou entrada de cron, execute /persist probe. O agente verifica cada técnica disponível no nível de privilégio atual e retorna um relatório de viabilidade. Não destrutivo — nenhum artefato deixado para trás.

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

Escolha o que funciona, instale, remova de forma limpa quando terminar. A WebGUI rastreia cada técnica instalada por sessão. /kill desmonta tudo — persistência, binário, artefatos na nuvem — em um único comando.

5. Proteções operacionais incorporadas no momento da implantação

Data de encerramento, janela de manutenção, jitter log-normal, chave de bootstrap de uso único — tudo configurado uma vez no assistente e compilado permanentemente no agente. Nada para gerenciar durante o engajamento, nada para esquecer de limpar no final.

---

Como o Stratum se encaixa em um engajamento

O Stratum não é um substituto para Cobalt Strike, Sliver ou Havoc. É a camada por baixo deles.