MITRE Caldera (Emulação Automatizada)

Nota da pasta 02 - Ferramentas de Emulação, no Capítulo 19 (Purple Teaming Contínuo).
Posiciona o MITRE Caldera como a plataforma aberta de referência para emulação automatizada de adversários mapeada em ATT&CK, cobrindo arquitetura, abilities, planners, plugins, extensão OT e leitura de results.
Dialoga com as notas de Atomic Red Team, Sliver e Mythic e Temperance da mesma pasta, com a nota SIM.2 do Capítulo 15 e com a medição de cobertura da pasta 03 deste capítulo.

1. Contexto e Posicionamento na Biblioteca

O purple teaming contínuo exige uma ferramenta capaz de executar cadeias de técnicas sem que um operador humano dispare cada passo manualmente, e é exatamente esse o papel do MITRE Caldera. Mantido pelo mesmo órgão que mantém o ATT&CK, o framework nasce com a taxonomia de táticas e técnicas embutida em cada unidade de execução, o que transforma a emulação e o mapeamento de cobertura em um único fluxo de dados. A nota SIM.2 do Capítulo 15 apresentou o Caldera como controle de simulação do Framework CTH; esta nota aprofunda a operação da ferramenta, mostrando como servidor, agentes, planners e o registro de results se combinam em campanhas repetíveis e auditáveis.

O papel do Caldera neste capítulo é o de motor central de emulação automatizada. As demais ferramentas da pasta ocupam nichos complementares: o Atomic Red Team dispara testes pontuais por técnica, o Sliver e o Mythic fornecem canais de comando e controle realistas e o Temperance estrutura planos curtos de emulação. Dominar o Caldera permite orquestrar esses insumos em operações agendadas, cujos resultados alimentam painéis de cobertura e alertas de regressão de detecção descritos na pasta 03.

2. Arquitetura do Framework: Servidor, Agentes e API REST

A arquitetura do Caldera gira em torno de poucos conceitos bem definidos, e dominá-los é pré-requisito para operar o framework com segurança. O servidor central, escrito em Python, hospeda a interface web, expõe a API REST que permite automatizar tudo o que a interface faz e guarda o estado completo de todas as operações. Os agentes são implantes leves que se conectam ao servidor, registram o host em que rodam e executam as habilidades recebidas; o agente padrão em Go, o Sandcat, compila para Windows e Linux a partir de um binário único. A tabela resume cada componente com as observações operacionais recomendadas para uso defensivo.

A API REST merece atenção especial porque é ela que viabiliza o "contínuo" do capítulo. Criar adversaries, disparar operations, consultar results e exportar relatórios são chamadas HTTP documentadas, o que permite que um agendador externo conduza campanhas periódicas sem abrir a interface web. Em uma rotina madura, a API é o único ponto de contato: a interface fica reservada para o desenvolvimento de novos cenários e para a depuração.

A implantação típica em laboratório usa contêineres, com volume persistente para o estado e portas restritas à rede de gerenciamento. O bloco a seguir ilustra o padrão, que deve ser adaptado à política de contêineres da organização.

# Servidor do Caldera em contêiner, com estado persistente e rede de gerenciamento
docker network create net-gerenciamento
docker run -d --name caldera-server \
  --network net-gerenciamento \
  -p 8888:8888 \
  -v caldera-data:/usr/src/app/data \
  --restart unless-stopped \
  ghcr.io/mitre/caldera:latest

# Confirmação de que somente a rede de gerenciamento alcança a interface
docker inspect caldera-server --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'

O endurecimento do servidor acompanha a implantação e não é opcional. Além da rede isolada, a chave da API deve ser rotacionada por ciclo de campanha, a interface deve exigir autenticação forte desde o primeiro acesso e o servidor deve ser monitorado como ativo crítico, porque quem controla o servidor controla os implantes de todos os hosts de teste. Esses controles custam minutos de configuração e eliminam os cenários de comprometimento mais comuns envolvendo o próprio framework.

3. Abilities, Adversaries e Planners

A ability é o tijolo do Caldera e corresponde, em regra, a uma técnica ATT&CK executável. Cada ability declara seus executores possíveis, como sh, cmd, powershell e pwsh, o comando efetivo, os requisitos de pré-requisito e o comando de limpeza, e carrega identificadores ATT&CK que alimentam automaticamente o mapeamento de cobertura. Essa ligação direta entre execução e taxonomia é o que diferencia o Caldera de um simples runner de scripts: ao final de uma operação, cada link executado já está rotulado com técnica, tática e resultado.

O adversary é a composição de abilities em fases que representam um operador de ameaça, e o planner é quem decide como percorrer essas fases. O planner do tipo batch executa as abilities de uma fase em lote antes de avançar, o sequential segue a ordem estrita declarada no perfil, e planners mais sofisticados consomem os fatos coletados durante a operação para escolher o próximo passo, aproximando o comportamento de um adversário adaptativo. A escolha do planner tem efeito direto na telemetria: sequências estritas facilitam a correlação temporal no SIEM, enquanto operações adaptativas testam a capacidade de detecção sob incerteza.

O conceito de fact source completa o conjunto. Em vez de codificar nomes de usuário e caminhos dentro das abilities, o operador declara fatos em fontes separadas, e as abilities referenciam essas variáveis. O mesmo adversary que emula um ator de espionagem pode, assim, rodar no laboratório de Active Directory com um fact source e em um laboratório cloud com outro, sem alterar uma linha do perfil. Essa propriedade é indispensável para campanhas agendadas, porque garante que a operação da semana 40 é idêntica à da semana 4.

A escolha do planner merece uma tabela de referência, porque é a decisão que mais afeta a forma como a telemetria chega ao SIEM.

Em rodadas agendadas, o planner batch é o padrão consagrado: o lote por fase produz blocos de telemetria previsíveis, facilita a consulta no SIEM e mantém a operação curta o suficiente para caber na janela autorizada. Planners adaptativos são reservados para avaliações especiais, sempre com operador acompanhando, porque o comportamento imprevisível exige resposta imediata a imprevistos.

4. Plugins e a Extensão para OT

A funcionalidade do Caldera é estendida por plugins, e o conjunto mínimo para uso defensivo inclui o Stockpile, biblioteca padrão de abilities e perfis, o Atomic, ponte com o catálogo do Atomic Red Team, o Sandcat, agente padrão, e o Compass, que visualiza camadas ATT&CK com os resultados das operações. O plugin Debrief, quando disponível na versão em uso, agrega a narrativa da operação em formato de relatório, útil para as reuniões purple team. A regra prática é instalar o mínimo necessário, pois cada plugin amplia a superfície do servidor e o custo de manutenção.

A extensão para OT (Operational Technology) merece destaque em ambientes industriais. O plugin de OT adiciona abilities orientadas a protocolos industriais, como Modbus e S7comm em versões de laboratório, permitindo emular o reconhecimento e a manipulação de controladores dentro de um range isolado. Para uma organização de manufatura ou energia, isso significa validar não apenas detecções de endpoint e rede corporativa, mas também as regras específicas de rede industrial, como o alerta de escrita em registrador de PLC fora da janela de manutenção. A premissa permanece: OT só emula em laboratório dedicado, nunca na planta.

A configuração de plugins vive no arquivo local do servidor, versionado em repositório do time, como mostra o fragmento.

# Fragmento de configuração do servidor com plugins essenciais habilitados
plugins:
  - stockpile
  - atomic
  - sandcat
  - compass
  - debrief
users:
  red: senha-forte-rotacionada-por-ciclo

Versionar essa configuração tem dois efeitos práticos no programa contínuo. Primeiro, garante que a reconstrução do servidor após incidente ou migração seja idêntica, preservando a comparabilidade entre rodadas. Segundo, cria o histórico de mudanças do arsenal de emulação, útil quando uma rodada apresenta resultado diferente do anterior e a suspeita recai sobre uma mudança de plugin ou de ability em vez de sobre a detecção.

5. Fluxo de Campanha de Emulação com Results

Uma campanha de emulação automatizada segue um fluxo padrão: subir o servidor, implantar agentes nos hosts de teste, criar ou escolher o adversary, disparar a operation pelo planner escolhido e ler os results. O registro de resultados é a parte mais valiosa para o purple team contínuo, porque cada link da operação guarda o comando executado, a saída capturada, o status de conclusão e o timestamp, permitindo o cruzamento exato com a janela de telemetria do SIEM. O bloco a seguir ilustra o ciclo em comandos representativos.

# 1. Iniciar o servidor do Caldera na rede de gerenciamento do laboratorio
python3 server.py --insecure -l DEBUG          # apenas em laboratorio isolado

# 2. Implantar o agente Sandcat no host de teste Windows
C:\tmp\sandcat.go-windows -server http://10.20.0.5:8888 -group pt-lab-windows

# 3. Disparar a operação via API REST, com planner batch e objetivo definido
curl -s -X POST http://10.20.0.5:8888/api/v2/operations \
  -H "KEY: ${CALDERA_API_KEY}" -H "Content-Type: application/json" \
  -d '{"name":"pt-2025-40-cadeia-ransomware","adversary_id":"cadeia-ransomware-01","planner":{"id":"batch"},"autonomous":1,"state":"running"}'

# 4. Ao fim da operação, exportar o relatório completo de results
curl -s -H "KEY: ${CALDERA_API_KEY}" \
  http://10.20.0.5:8888/api/v2/operations/PT2025401/report > results-pt-40.json

O relatório exportado contém a cadeia de links com status por ability, como mostra o fragmento a seguir, e é esse arquivo que alimenta o cruzamento com os alertas.

{
  "name": "pt-2025-40-cadeia-ransomware",
  "chain": [
    {"ability": "Executar script PowerShell ofuscado", "technique": "T1059.001", "status": 0, "output": "comando concluido"},
    {"ability": "Criar tarefa agendada persistente", "technique": "T1053.005", "status": 0, "output": "tarefa criada"},
    {"ability": "Dump de memoria do LSASS", "technique": "T1003.001", "status": -1, "output": "bloqueado pelo EDR"}
  ]
}

A leitura correta distingue status de execução de detecção. No exemplo, o status -1 do dump de LSASS indica que a ability foi impedida, e não que a detecção falhou; ao contrário, bloqueio com alerta no EDR é o melhor desfecho possível. Essa distinção entre sucesso de execução e sucesso de detecção é o erro de leitura mais comum entre equipes iniciantes, e a ficha de resultado da pasta 03 existe justamente para formalizá-la.

6. Uso em Purple Teaming e Validação de Detecções

No ciclo purple team, o Caldera atua como a fonte controlada de eventos que a defesa precisa ver. O time roxo executa a operação em janela combinada com o SOC, o time azul acompanha a telemetria chegando e registra, por técnica, se houve evento bruto, alerta de regra e ação de contenção. O encontro dessas duas visões, o relatório do Caldera e a visão do SIEM, produz a matriz de resultado que direciona a engenharia de detecção: técnicas com telemetria sem alerta viram backlog de regras, técnicas sem telemetria viram backlog de coleta.

A validação de detecções por cadeia tem valor próprio e complementa o teste pontual. Regras de correlação que cruzam criação de tarefa agendada com execução de PowerShell iniciada por processo de escritório só podem ser validadas quando os dois eventos ocorrem na mesma janela, e é o que uma operação encadeada produz. Em rodadas periódicas, o mesmo adversary reexecutado gera a série histórica que revela regressões: uma técnica que alertava na rodada anterior e parou de alertar indica quebra de log source, de regra ou de agente.

A dinâmica de papéis na rodada purple merece acordo explícito, porque o Caldera gera eventos reais que o SOC triará. A tabela resume a divisão consagrada.

O acordo entre esses papéis é o que distingue uma rodada purple de uma operação ofensiva solta. Com a janela no calendário do SOC e os entregáveis definidos antes do disparo, a operação do Caldera vira o instrumento de medição que o painel de cobertura da pasta 03 espera consumir.

7. Erros Comuns e Pontos de Atenção

• Executar perfis prontos sem revisar as abilities, o que gera falhas por caminhos, contas ou serviços inexistentes no ambiente; revisar requisitos, variáveis e comandos de limpeza antes da operação economiza rodadas perdidas.
• Confundir falha de execução com ausência de detecção, tratando status de erro como resultado de cobertura; a matriz de resultado precisa separar erro, bloqueio, só telemetria e alerta.
• Deixar agentes instalados indefinidamente após a campanha; agente esquecido é implante esquecido, e o ciclo de vida deve encerrar processos, remover binários e revogar credenciais ao fim de cada rodada.
• Rodar operações em horário de pico de triagem sem avisar o SOC, gerando alertas reais que consomem fila de análise; a janela de teste deve estar no calendário do SOC com o nome da operação.
• Expor o servidor do Caldera em rede ampla ou em estação de analista, transformando a ferramenta de validação em risco interno; servidor vive em rede de gerenciamento isolada e autenticada.
• Medir apenas se a operação rodou até o fim; o entregável do purple team é a matriz de resultado por técnica, e o log do servidor é insumo, não produto.

8. Integração com o Restante da Biblioteca

Os results do Caldera são a entrada primária do pipeline de medição descrito na nota de cobertura em tempo real da pasta 03, que consolida execução, detecção e gaps abertos em painel próprio e em camadas automáticas do ATT&CK Navigator. As técnicas sem detecção fluem para o backlog de engenharia de detecção, e as detecções ajustadas retornam ao Caldera na próxima rodada, fechando o ciclo purple. O Atomic Red Team cobre o dia a dia de teste por técnica, enquanto o Sliver e o Mythic adicionam realismo de comando e controle em cenários específicos, e o Temperance organiza planos curtos quando o Caldera é peso maior.

Na direção da inteligência, os perfis de atores prioritários produzidos pelo ciclo de CTI, incluindo o mapeamento de TTPs do Capítulo 15, se convertem em adversaries customizados, fazendo a emulação testar exatamente o que a organização considera mais provável de enfrentar. Os resultados de cadeias que passam em silêncio alimentam hipóteses de threat hunting, e as métricas de detecção por rodada entram nos KPIs do programa, provando ao leadership que o investimento em telemetria e regras reduz de fato o risco das ameaças priorizadas.