SIM.2 - Simulação com Emulação de Adversários (Caldera)

Controle SIM.2 do grupo SIM (Simulação de Ataques), derivado do Capítulo 15 do Framework CTH.
Trata do uso do MITRE Caldera, framework aberto de emulação de TTPs de adversário, para simular operadores de ameaça que encadeiam múltiplas técnicas em sequência.
No programa integrado, complementa a plataforma gerenciada de SIM.1 testando a cadeia completa de ataque e a capacidade de correlação das detecções, sempre em ambiente autorizado e isolado.

1. Contexto e Posicionamento no Framework CTH

Enquanto SIM.1 testa técnicas individuais de forma gerenciada, o controle SIM.2 eleva o realismo e simula
um operador de ameaça que encadeia técnicas conforme o perfil de um adversário. O Framework CTH descreve
essa emulação autônoma como a validação mais realista da capacidade defensiva, porque as detecções mais
valiosas geralmente dependem de correlação entre etapas, e não de um evento isolado. Um dump de
credenciais seguido de movimento lateral é um padrão; cada evento, sozinho, pode parecer administrativo.

O controle é executado em ambiente de teste autorizado e isolado, e seus resultados seguem o mesmo fluxo
dos demais controles do grupo: análise de lacuna e consolidação em SIM.5, engenharia de detecção via
AUT.3 e uso direto nos exercícios purple team de SIM.3, que frequentemente adotam o Caldera como
plataforma de execução. A diferença é a unidade de análise: aqui, o objeto de estudo é a cadeia.

2. O Que é o MITRE Caldera e Por Que é a Referência Aberta

Caldera é uma plataforma de emulação de adversários de código aberto mantida pelo MITRE, o mesmo órgão que
mantém o ATT&CK. Essa origem explica sua posição de referência: perfis de adversário, abilities e
metadados nascem alinhados à taxonomia ATT&CK, e o projeto evolui junto com a matriz enterprise. Além do
custo zero de licença, o código aberto permite auditar cada payload antes da execução, requisito
essencial para times de defesa que precisam confiar na própria cadeia de ferramentas de teste.

É importante delimitar o que o Caldera é e o que não é. Ele não é uma plataforma comercial de BAS, com
suporte, garantias e relatórios executivos prontos; é um framework com o qual a equipe constrói operações.
Não traz biblioteca de cenários por setor, nem responsabilidade de resultado. A contrapartida é controle
total: cada ability pode ser lida, editada e adaptada ao ambiente, e cada operação é reproduzível a partir
do perfil versionado em repositório próprio.

3. Arquitetura: Servidor, Agentes, Abilities, Adversaries e Operations

A arquitetura do Caldera gira em torno de poucos conceitos bem definidos, e dominá-los é pré-requisito para
operar o framework com segurança. A tabela resume cada componente, seu papel e as observações operacionais
recomendadas para uso defensivo.

Na prática, a operação típica envolve subir o servidor, implantar o agente no host de teste, montar um
adversary e disparar a operation com um objective claro. O servidor coordena as abilities na ordem
definida, coleta a saída de cada comando e exporta o relatório completo, evidência da análise de detecção.

4. Plugins Essenciais: Stockpile, Atomic e Sandcat

A funcionalidade do Caldera é estendida por plugins, e três deles formam o conjunto mínimo para o uso
defensivo descrito neste controle. A tabela apresenta o papel de cada um.

A instalação de plugins deve ser mínima e intencional, pois cada plugin amplia a superfície do servidor e
o conjunto de dependências a manter. O Stockpile e o Atomic cobrem a maior parte das necessidades de
validação de detecção; os demais entram quando um cenário específico exige e saem quando deixam de servir.

5. Fluxo Prático de uma Operação

O fluxo recomendado para uma operação de validação de detecção segue seis etapas. Primeiro, definir
objetivo, escopo e janela, com autorização documentada. Segundo, montar o adversary com as técnicas ATT&CK
escolhidas, reaproveitando abilities do Stockpile ou adaptando-as. Terceiro, implantar o agente no host de
laboratório e confirmar a comunicação com o servidor. Quarto, executar a operation com intervalos entre
abilities que permitam a correlação no SIEM. Quinto, ler resultados por técnica, cruzando o registro da
operação com os alertas gerados. Sexto, encerrar, limpar artefatos e registrar a matriz de resultado.

O bloco a seguir ilustra um plano de operação documentado antes da execução.

Plano de operação Caldera: emulacao-cadeia-ransomware-01
Objetivo: validar detecção de cadeia de ransomware em host de laboratório
Fact source: perfil-apt-setor-financeiro
Ambiente: rede isolada LAB-CALDERA, sem rota para produção

Passos:
  1. T1059.001  execução de script PowerShell codificado iniciado por processo de escritório
  2. T1053.005  criação de tarefa agendada persistente
  3. T1003.001  dump de memória do LSASS com utilitário nativo
  4. T1071.001  beacon HTTPS para C2 simulado na sub-rede de teste
  5. T1486      escrita em arquivos armadilha do laboratório

Regras de engajamento:
  - agente autorizado: 4f8c (host LAB-CALDERA-01), nenhum outro
  - intervalo entre passos: 60 segundos
  - parada automática se duas abilities consecutivas forem bloqueadas
  - log completo da operação exportado ao final para o repositório SIM

O registro de execução do Caldera, aliado a esse plano versionado, garante reexecuções idênticas meses
depois, propriedade indispensável para comparar cobertura entre rodadas e provar o efeito dos ajustes.

6. Avaliação de Detecção Cruzada com SIEM e EDR

A leitura dos resultados do Caldera por si só não responde se a organização detectou a operação; responde
apenas o que foi executado. A avaliação real acontece no cruzamento temporal entre o registro da operação,
com o timestamp de cada ability, e os eventos e alertas do SIEM e do EDR no mesmo intervalo. Para cada
ability, o analista procura três coisas: o evento bruto correspondente no SIEM, algum alerta de regra
associado à técnica e a ação do EDR, entre permitir, bloquear ou quarentenar.

A consulta abaixo exemplifica a busca no SIEM por eventos de criação de tarefa agendada dentro da janela
da operação, um dos passos do plano do bloco anterior.

// Eventos de criação de tarefa agendada na janela da operação
SecurityEvent
| where EventID == 4698
| where TimeGenerated between (datetime(2025-03-12 02:00) .. datetime(2025-03-12 03:00))
| where SubjectUserName !in~ ("svc_backup", "adm_patch")
| project TimeGenerated, Computer, SubjectUserName, TaskName, Command

Os resultados por ability entram na mesma ficha de resultado usada em SIM.4, com os valores detectado, só
telemetria e não detectado, e alimentam o heatmap do SIM.5. Quando a operação utiliza perfis de atores
prioritários definidos pela CTI, o cruzamento com MAP.4 permite afirmar, com técnica e evidência, quais
partes da cadeia de um adversário real a organização veria e quais passariam em silêncio.

7. Caldera versus Atomic Red Team

As duas ferramentas abertas mais usadas em validação de detecção ocupam papéis complementares, e confundi-las
produz expectativas erradas. A tabela compara os aspectos operacionais que importam na escolha.

A recomendação prática é usar as duas. O Atomic Red Team é a ferramenta do dia a dia da engenharia de
detecção, pela simplicidade de disparar um teste e conferir a regra; o Caldera é a ferramenta das
avaliações periódicas mais profundas, em que a pergunta é se a organização detecta uma cadeia completa, e
não um evento isolado. O plugin Atomic reduz ainda a distância entre os dois mundos, ao importar testes
pontuais como abilities de um adversary.

8. OPSEC e Escopo

O Caldera é, na prática, um framework de comando e controle funcional, e deve ser tratado com o mesmo risco
de um implante real. Ele só deve existir em ambiente autorizado: laboratório dedicado ou rede isolada de
testes, sem rota para produção, com credenciais próprias e revogadas ao final de cada ciclo. O servidor
nunca deve ficar acessível a partir de redes corporativas amplas, e a autenticação forte da interface web,
com certificado e senha dedicados, é obrigatória desde a instalação.

Cuidados adicionais incluem o versionamento dos perfis de adversary em repositório próprio, para que toda
operação seja reproduzível e auditável; a limpeza pós-operação, removendo tarefas agendadas, binários e
artefatos criados pelas abilities; e a verificação de que nenhuma configuração de proxy, VPN ou rota do
laboratório permite egresso para a internet aberta. Por fim, o framework não deve ser instalado em
estações de analista: a separação entre ambiente de operação e ambiente de trabalho impede que um agente
mal configurado encontre caminho para produção.

9. Implementação Prática e Salvaguardas por Nível

O Framework CTH define salvaguardas progressivas para este controle, que indicam o caminho de maturação da
capacidade de emulação. A tabela apresenta cada salvaguarda com sua descrição e prática de mercado.

A progressão entre níveis acompanha a consolidação dos demais grupos do framework. Perfis customizados de
qualidade só existem com CTI madura; heatmaps confiáveis só existem com a ficha de resultado disciplinada;
e a integração avançada pressupõe o pipeline de detecção como código do controle AUT.3.

10. Erros Comuns e Pontos de Atenção

• Executar perfis prontos sem revisar abilities: várias abilities assumem caminhos, contas ou serviços
  inexistentes no ambiente e falham sem explicação; revisar requisitos e variáveis antes da operação
  economiza rodadas perdidas.
• Confundir falha de execução com não detecção: um passo que falha por ausência de pré-requisito não mede
  detecção alguma; o resultado precisa distinguir erro de execução de ausência de alerta.
• Deixar agentes vivos indefinidamente: agente esquecido é implante esquecido; o ciclo de vida deve ter
  desinstalação documentada ao final de cada campanha de testes.
• Rodar operações em horário de pico de triagem: operações geram alertas reais, e o SOC precisa conhecer a
  janela para contextualizar; sem isso, o exercício gera ruído, custo e desgaste.
• Medir apenas a execução: operação que corre até o fim sem pergunta sobre alerta é teatro; o entregável
  do controle é a matriz de resultado por técnica, não o log do servidor.
• Usar o framework como ferramenta de ataque em produção: o atalho de reaproveitar a infraestrutura já
  montada viola o escopo autorizado, contamina evidências e expõe a organização a um risco que o próprio
  controle existe para reduzir; laboratório separado é requisito, não luxo.

11. Integração com Outros Controles do Framework CTH

As operações do Caldera alimentam diretamente SIM.5, que consolida taxa de detecção por tática e por
técnica, e MAP.4, que cruza lacunas com os atores prioritários da organização. As lacunas de regra fluem
para AUT.3, as de telemetria para o grupo DAT, e as abilities mais valiosas tornam-se roteiros fixos dos
exercícios purple team de SIM.3, que reutilizam perfis, fact sources e planos aqui construídos.

Na direção de entrada, o grupo ANA fornece perfis de atores e cadeias de campanha que se transformam em
adversaries customizados, e o grupo HNT consome os resultados para priorizar hipóteses de hunting sobre as
técnicas que passaram em silêncio. O grupo IR aproveita as detecções ajustadas, pois incidentes futuros
chegam com mais contexto correlacionado, e o grupo MET acompanha a taxa de detecção por operação.