Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

01 - MITRE Caldera (v5+ com OT Extension)

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

MITRE Caldera (v5+ com OT Extension)

Nota da subpasta 03 - Ferramentas de Emulação e Purple Team, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata do Caldera na geração v5: arquitetura atualizada, plugins Sandcat e Stockpile, extensão OT para ambientes industriais e uso em purple team contínuo.
Dialoga com a nota de Caldera do Capítulo 19, com Atomic Red Team, C2 frameworks e Temperance da mesma pasta e com a nota SIM.3 do Capítulo 15.

1. Contexto e Posicionamento na Biblioteca

O Capítulo 19 apresentou o Caldera como ferramenta de emulação automatizada; esta nota cobre a geração atual do projeto, marcada pela série v5, e a extensão para ambientes OT que o posiciona também no território industrial. O Caldera é a plataforma de emulação de referência pública do MITRE: servidor de operações com agentes, abilities mapeadas em ATT&CK, perfis de adversário, planners que decidem a sequência e relatórios por operação. Para o programa de purple team contínuo do Capítulo 19, o Caldera é o motor que transforma o plano de emulação em execução agendada, mensurável e repetível.

A nota avança do conceito para a operação: arquitetura da v5, plugins que compõem o arsenal, extensão OT com suas particularidades de segurança, o ciclo de purple team contínuo apoiado na plataforma, comparação com a geração clássica e um exemplo completo de campanha com ability escrita em YAML. O foco permanece em uso defensivo autorizado, e as regras de engajamento do Capítulo 19 valem integralmente aqui.

2. Arquitetura do Caldera v5

A arquitetura gira em torno de quatro conceitos. O servidor é o núcleo web e de API, onde operações são criadas, monitoradas e reportadas. Os agents são implantes leves que o servidor distribui aos hosts de teste; cada agente registra-se com beaconing configurável e executa as abilities que recebe. As abilities são as unidades de ação, cada uma vinculada a uma tática e técnica ATT&CK, com comandos por plataforma, parser para coletar fatos e cleanup opcional. Os adversaries são perfis que agrupam abilities na ordem desejada, e os planners são as estratégias que decidem a sequência de execução dentro de uma operação, da mais simples, que segue a ordem do perfil, às que reagem aos fatos coletados.

A geração v5 moderniza a base do projeto com interface renovada, arquitetura de serviço mais modular, melhorias na API de automação e no ciclo de plugins, mantendo o modelo conceitual de abilities, fatos e relações que os times já conheciam. Para o operador, o efeito prático é que a automação por API ganhou peso: operações inteiras podem ser criadas, executadas e avaliadas por script, condição necessária para o purple team contínuo em escala.

O agent merece configuração consciente, porque é dele que vem a fidelidade do exercício. O intervalo de beacon e o jitter definem o ritmo da operação e a chance de colisão com outras atividades do laboratório, o mecanismo de pausa entre tasks evita que o host de teste seja inundado, e o comportamento em caso de queda de comunicação deve ser declarado, com retry e expiração, para que nenhum implante fique órfão após o fim da janela. O inventário de agents ativos é checado no início e no fechamento de cada operação, e agent sem dono em laboratório é incidente de teste, não curiosidade.

A anatomia de uma ability explica por que ela é a unidade certa de rastreio. Cada ability declara tática e técnica ATT&CK, um ou mais executors por plataforma, parsers que convertem a saída do comando em fatos, relações que ligam esses fatos a outros objetos conhecidos e um bloco de cleanup que desfaz o efeito quando existe efeito a desfazer. Essa estrutura é o que permite ao relatório automático apontar exatamente o que rodou, quando rodou e o que a execução descobriu do ambiente, e é também o que permite auditar o cleanup, requisito inegociável em ambiente de teste corporativo.

Os planners determinam o custo e o controle da operação, e a escolha é decisão de desenho, não detalhe. O planner sequencial executa a ordem declarada no perfil e é o padrão dos exercícios com ficha de resultado, porque cada timestamp fica previsível; os planners condicionais decidem o próximo passo a partir dos fatos coletados, úteis em emulações de movimento lateral, mas exigem escopo duro e critérios de parada, porque a combinação de fatos pode multiplicar o número de passos. A recomendação operacional é dominar o sequencial antes de liberar qualquer planner guiado por fatos.

Conceito Papel na operação Exemplo concreto
Servidor Orquestra, registra e reporta Instância central com API e interface
Agent Executa abilities no host de teste Sandcat com beacon de 30 a 60 segundos
Ability Ação única mapeada em ATT&CK Criar tarefa agendada com cleanup
Adversary Sequência de abilities do perfil emulado Cadeia de execução e persistência
Planner Estratégia de execução Sequencial ou guiado por fatos
Fact source Base de fatos para planners que decidem Hosts, usuários e credenciais de teste

3. Plugins: Sandcat, Stockpile e o Ecossistema

O Caldera é deliberadamente um sistema de plugins, e dois deles definem a experiência básica. O Sandcat é o agente padrão em Go, multiplataforma, com execução de comandos, coleta de fatos e extensão por extensões próprias; é ele que os exercícios usam como implante de teste na grande maioria dos cenários Enterprise. O Stockpile é o repositório de abilities e perfis mantido pelo projeto, cobrindo centenas de técnicas ATT&CK com comandos por plataforma, e é a fonte a partir da qual a equipe seleciona e adapta as abilities da campanha.

A tabela resumo do conceito já mostrou os papéis; o que merece atenção aqui é a disciplina de curadoria. O Stockpile traz abilities úteis e abilities irrelevantes para a organização, e a prática recomendada é manter um repositório próprio de abilities derivadas, com limpeza de comandos, ajuste de nomes de artefatos para o laboratório e cleanup obrigatório. Plugins adicionais da comunidade acrescentam funções como emulação com atomics, coleta de resposta e interfaces de relatório, e cada plugin instalado deve passar pela mesma avaliação de segurança que qualquer dependência de software, com a instância do Caldera confinada ao segmento de teste.

Categoria de plugin Exemplo representativo Papel no exercício
Agente Sandcat Implante de teste multiplataforma e extensível
Conteúdo de adversário Stockpile Abilities e perfis prontos para seleção
Testes prontos Plugin de atomics Ponte com o Atomic Red Team da pasta 02
Operação Coleta e resposta Enriquecer a operação com evidência e relatório
Treinamento Conteúdo didático Onboarding de novos operadores

A avaliação de segurança de plugin vale três perguntas antes da instalação: o que o plugin executa nos hosts de teste, quais permissões de rede ele exige e quem mantém o código. Plugin que roda comandos opacos nos agentes ou que abre comunicação para fora do segmento de teste é reprovado, e a decisão fica registrada no inventário da plataforma com a data da avaliação. O ciclo de atualização segue a disciplina de dependência de software, com teste em laboratório isolado antes do serviço entrar em uso.

4. Extensão OT para Ambientes Industriais

A extensão OT do Caldera leva o modelo de abilities e operações para o mundo industrial, com conteúdo voltado a protocolos e comportamentos de ambientes de controle, e com premissas próprias de segurança que mudam o desenho do exercício. Em ambiente OT, a regra número um é que nenhuma instrução aleatória chega a controladora real: os exercícios usam laboratório segmentado com controladoras simuladas ou equipamentos dedicados, espelhando a arquitetura da planta, e a emulação executa nesse espelho, nunca na produção. A nota de hunting em OT e ICS do Capítulo 08 descreve o contexto de detecção que o exercício valida.

O conteúdo da extensão cobre comportamentos como varredura de rede industrial, manipulação de pontos em protocolos como Modbus, e coleta de informações de estações de engenharia, sempre com o objetivo defensivo de gerar telemetria para testar detecções específicas de OT. As diferenças operacionais em relação ao ambiente Enterprise merecem tabela própria, porque são o guia de planejamento do exercício industrial.

Aspecto Ambiente Enterprise Ambiente OT com a extensão
Alvo dos agentes Estações e servidores de teste Estações de engenharia e laboratório HMI
Protocolos exercidos HTTP, SMB, serviços de estação Modbus e protocolos industriais simulados
Risco de impacto Baixo em host dedicado Alto, por isso laboratório espelhado
Requisito de rede Segmento de teste padrão Segmento isolado sem rota para a planta
Validação Alertas no SIEM e EDR Detecções de OT e revisão com engenharia
Cleanup Obrigatório e automatizado Obrigatório, auditado com dono da planta

A governança do exercício OT é o que transforma a extensão em ferramenta defensiva em vez de risco. Cada operação industrial precisa de aprovação registrada do dono da planta, de rota de parada imediata conhecida por todos os participantes, de um responsável por cleanup nomeado no plano e de revisão conjunta com a engenharia antes e depois da execução. A documentação desses quatro itens acompanha a ficha de resultado, e a ausência de qualquer um deles adia a operação, sem exceção e sem discussão.

5. Purple Team Contínuo com Caldera

O uso em purple team contínuo segue o ciclo descrito no Capítulo 19 com a plataforma como executora: a CTI entrega a cadeia emulada a partir do relatório digerido, a equipe de emulação traduz a cadeia em perfil de adversário com abilities ajustadas, a operação roda agendada contra os hosts de teste, e a ficha de resultado cruza cada ability com os alertas e eventos no SIEM. O relatório automático da operação, com timestamps por ability, é a metade ofensiva da ficha, e a consulta por janela no SIEM é a metade defensiva, no formato de status da nota de Temperance da pasta 04.

A automação por API é o que separa o purple team ocasional do contínuo. O fluxo recomendado cria a operação por script a partir do perfil versionado, dispara em janela acordada, coleta o relatório e atualiza o painel de cobertura por técnica do Capítulo 18, tudo sem intervenção manual. A cadência semanal ou quinzenal depende da capacidade do time de detecção em consumir resultados, e a regra de ouro é que nenhuma operação nova entra na agenda enquanto os gaps da anterior não têm dono no backlog.

1. Revisar o backlog de gaps da operacao anterior
2. Criar a operacao via API a partir do perfil versionado
3. Acordar a janela com o time de deteccao e notificar
4. Executar e acompanhar o relatorio por ability
5. Cruzar timestamps com o SIEM e preencher a ficha
6. Abrir gap com dono ou registrar detecco validada
7. Versionar perfil, ficha e diffs no repositorio

6. Comparação entre a Geração Clássica e a v5

A tabela compara a experiência operacional da geração clássica, ainda presente em muitos ambientes, com a série v5, e orienta o momento de migração.

Aspecto Geração clássica Série v5
Interface Funcional, densa para novos operadores Renovada e mais navegável
Arquitetura Monolítica com plugins acoplados Serviço mais modular e API em primeiro lugar
Automação Possível, com esforço maior Pipeline de operações por API como padrão
Plugins Ecossistema amplo e heterogêneo Ciclo de plugin mais controlado
Conteúdo OT Ausente do núcleo Extensão dedicada a ambientes industriais
Base de migração Perfis e abilities reutilizáveis Perfis e abilities reutilizáveis com revisão

A leitura prática é que a migração não é reescrita: abilities e perfis migram com revisão, e o ganho real está na automação e na extensão OT. Times que rodam apenas exercícios manuais trimestrais podem adiar a migração; times com agenda contínua ganham mais ao migrar cedo, porque o custo de automação na geração antiga se paga mal.

7. Exemplo de Campanha com Abilities

O exemplo abaixo mostra uma ability customizada no formato do projeto, derivada do Stockpile e ajustada para o laboratório, seguida do perfil de adversário que a consome. A ability emula a criação de tarefa agendada, técnica que a pasta de detecção desta biblioteca usa como fio condutor.

- id: 9c2e6b1a-7f4d-4b2e-8a11-3f5c6d7e8f90
  name: Criar tarefa agendada de teste
  description: Cria tarefa agendada nomeada env-diagnostics em host Windows de laboratorio
  tactic: execution
  technique:
    attack_id: T1053.005
    name: Scheduled Task
  platforms:
    windows:
      psh:
        command: |
          $action = New-ScheduledTaskAction -Execute "cmd.exe" -Argument "/c echo teste"
          Register-ScheduledTask -TaskName "env-diagnostics" -Action $action
        cleanup: |
          Unregister-ScheduledTask -TaskName "env-diagnostics" -Confirm:$false
        parsers:
          plugins.stockpile.app.parsers.basic:
            - source: host.id
adversary: pt-2025-21-cadeia-ofimatica
description: Execucao inicial por processo ofimatico e persistencia por tarefa agendada
phases:
  1:
    - 9c2e6b1a-7f4d-4b2e-8a11-3f5c6d7e8f90
  2:
    - uuid-da-ability-de-execucao-por-script

A operação executa o perfil contra o agente Sandcat no host de teste, e a ficha de resultado cruza o timestamp da ability com a janela do SIEM. A consulta KQL do capítulo de detecção recupera o evento de criação da tarefa, e o status por ability segue a classificação canônica: detectado, só telemetria, não detectado ou erro de execução. O perfil concluído com a ficha preenchida versiona no repositório do programa, e a reexecução mede o efeito das correções feitas na detecção.

8. Fluxo de Campanha com Verificação de Resultados

A campanha de emulação só fecha quando cada ability tem veredito, e o veredito nasce do cruzamento entre o relatório da operação e a telemetria do SIEM na janela da execução. O fluxo recomendado parte do perfil versionado, executa com planner sequencial para preservar a separação temporal entre passos, consulta o SIEM ao final de cada fase e preenche a ficha por ability antes da próxima operação. A classificação canônica de status da biblioteca dá vocabulário comum entre red e blue, e a tabela abaixo define o que cada status significa e qual ação ele dispara.

Status da ability Significado operacional Ação que o status dispara
Detectado Alerta correlacionado com a janela da execução Registrar no painel de cobertura e liberar a fase seguinte
Só telemetria Evento presente no SIEM sem alerta correspondente Abrir gap de detecção com dono e prazo no backlog
Não detectado Nem evento nem alerta na janela Gap de coleta: revisar fonte e cobertura antes de regra
Erro de execução Ability falhou no host por ambiente ou comando Corrigir comando ou ambiente e reexecutar a ability

O valor do status está na comparação entre rodadas: a reexecução do mesmo perfil após a implantação da regra deve mover abilities de só telemetria para detectado, e essa diferença é a métrica que prova o efeito do trabalho de detecção. Perfil, ficha e diffs das duas rodadas versionam juntos no repositório do programa, formando a evidência histórica que sustenta o painel de cobertura do Capítulo 18 e as métricas SIM.3 do Capítulo 15.

9. Erros Comuns e Pontos de Atenção

  • Executar operações contra produção por conveniência, o erro grave e definitivo: o Caldera roda contra hosts de teste ou laboratório espelhado, sempre.
  • Usar abilities do Stockpile sem revisar comandos e artefatos, deixando que a emulação crie nomes reais de malware em hosts corporativos de teste; ajuste para o laboratório e documente a diferença.
  • Deixar agents ativos após a operação, sem cleanup e sem inventário; o inventário de agentes e a desinstalação fazem parte do fechamento da operação.
  • Rodar planners guiados por fatos sem entender a explosão de combinações, gerando operações longas e incontroláveis; comece pelo planner sequencial.
  • Tratar o relatório automático como avaliação completa, quando ele é a metade ofensiva; sem o cruzamento com o SIEM, não existe veredito de detecção.
  • Ignorar a revisão de segurança da própria plataforma, com instância exposta além do segmento de teste; o servidor de emulação é alvo de alto valor se exposto.
  • Emular técnicas de OT em equipamento de produção da planta, violando a premissa básica da extensão; o espelho de laboratório com o dono da planta é inegociável.
  • Confiar no cleanup automático sem auditar os artefatos no host de teste; a verificação de limpeza é passagem obrigatória de fechamento da operação.

10. Integração com o Restante da Biblioteca

O ciclo de purple team contínuo descrito no Capítulo 19 usa o Caldera como executor automático, e as fichas de resultado alimentam o painel de cobertura por tática do Capítulo 18 com dados por technique. As abilities derivadas do Stockpile consomem a tradução de relatórios em TTPs do ciclo de CTI do Capítulo 01, e os resultados alimentam o feedback loop CTI.9 do Capítulo 15 quando a emulação revela TTPs sem detecção. As notas de Atomic Red Team e Temperance desta pasta cobrem os degraus de complexidade abaixo do Caldera, e a nota de Sliver e Mythic cobre o degrau acima, quando o teste precisa de canal de C2 realista.

Para ambientes industriais, a extensão OT conecta esta nota ao hunting em OT e ICS do Capítulo 08 e ao cyber range da pasta de Validação Contínua do Capítulo 19, e a recomendação de fechamento é de sequência: consolide o ciclo Enterprise com operações agendadas e fichas versionadas antes de entrar em OT, porque a disciplina de laboratório espelhado e de cleanup auditado se aprende no ambiente de menor risco e se exige no de maior.