Temperance (Framework de Emulação de Adversários)

Nota da pasta 02 - Ferramentas de Emulação, no Capítulo 19 (Purple Teaming Contínuo).
Trata do Temperance, framework leve do SpecterOps para conduzir emulações de adversário de forma estruturada, com planos, tasks e steps, sem a complexidade de um C2 completo.
Dialoga com as notas de Caldera, Atomic Red Team e Sliver e Mythic da mesma pasta e com a nota SIM.3 de exercícios purple team do Capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Entre o teste pontual do Atomic Red Team e a operação orquestrada do Caldera existe uma faixa de trabalho que as equipes encontram toda semana: a emulação curta, de três a dez passos, desenhada para validar uma cadeia específica extraída de um relatório de inteligência, sem montar servidor de C2 nem infraestrutura de agentes. O Temperance, projeto do SpecterOps, foi construído exatamente para essa faixa. É um framework leve que estrutura a condução da emulação de adversário em planos legíveis por humanos e executáveis por qualquer operador, mantendo o registro do que foi feito, quando e com qual evidência.

O valor do Temperance não está em executar comandos por conta própria, e sim em impor disciplina ao processo. Cada plano declara objetivo, escopo e sequência de passos; cada passo referencia uma técnica ATT&CK, descreve a ação e define a evidência esperada. Essa estrutura transforma a emulação em artefato versionável, revisável em pull request e reexecutável meses depois, propriedades que um caderno de notas de operador não oferece. Esta nota posiciona o framework no arsenal do capítulo e demonstra seu uso com um plano completo.

2. Conceito: Planos, Tasks e Steps

A unidade central do Temperance é o plano, um documento estruturado que descreve uma emulação de adversário do início ao fim. Dentro do plano, as tasks representam objetivos intermediários da cadeia, como estabelecer execução inicial, manter persistência ou coletar credenciais, e os steps são as ações concretas que realizam cada task. Cada step carrega o mapeamento para a técnica ATT&CK correspondente, a descrição da ação e o critério de evidência, e a execução segue a ordem declarada, com espaço para pausas e verificações entre passos.

Essa hierarquia espelha a estrutura natural de um relatório de inteligência: a campanha do ator se decompõe em fases, as fases em comportamentos observáveis e os comportamentos em ações verificáveis. Ao transportar essa decomposição para um formato executável, o Temperance elimina a lacuna clássica entre o relatório da CTI e a rodada de teste, em que o operador improvisava a tradução do texto para comandos. O plano é a tradução, e ele vive versionado no repositório do time.

Os campos que um plano bem escrito carrega seguem um padrão reconhecível, e a tabela serve de checklist de redação.

O checklist resolve outro problema recorrente: planos escritos por pessoas diferentes com formatos diferentes. Quando todo plano do repositório segue os mesmos campos, qualquer membro da equipe consegue revisar, executar e auditar o trabalho dos demais, e a automação futura encontra um formato estável para consumir.

A revisão por pares é o controle de qualidade natural do repositório de planos. O revisor avalia três coisas antes da execução: se as técnicas e a ordem fazem sentido contra o relatório de inteligência de origem, se o escopo e a autorização estão completos e se as evidências esperadas são verificáveis na telemetria disponível. Um plano reprovado nessa revisão custa minutos de leitura; um plano reprovado durante a execução custa a rodada inteira.

A execução guiada é o outro pilar. O framework conduz o operador passo a passo, registrando o status de cada step, as anotações e as evidências coletadas, e produz ao final um registro sequencial da emulação. Para o time roxo, esse registro é a metade ofensiva da ficha de resultado: o que foi executado, em que host e em que hora, pronto para o cruzamento com a telemetria do SIEM.

3. Diferença para um C2 Framework Completo

A confusão mais comum sobre o Temperance é tratá-lo como um C2 framework menor. A comparação a seguir explicita as diferenças de propósito e de arquitetura entre os dois tipos de ferramenta.

A implicação prática é que as ferramentas se combinam em vez de competir. Um plano do Temperance pode instruir o operador a usar um atomic do Atomic Red Team no passo de execução inicial e a abrir uma sessão do Sliver no passo de C2, mantendo a estrutura e o registro no plano. O Temperance é o roteiro e o registro; os frameworks fornecem as cenas. Para a maioria das rodadas semanais de validação, o roteiro com comandos nativos e atomics basta, e o C2 completo fica reservado para os cenários que precisam testar o canal.

4. Uso em Planos de Emulação Curtos

Planos curtos são o habitat natural do Temperance, e a disciplina de escrita deles é o que garante utilidade. Um bom plano declara o objetivo em uma frase mensurável, fixa o escopo de hosts e janela, lista os passos na ordem de execução e, crucialmente, define a evidência esperada de cada passo antes de executá-lo. Essa definição antecipada evita o vício de interpretar o resultado depois de ver a telemetria, que contamina a avaliação.

A cadência recomendada acompanha o calendário de detecções. Quando a engenharia de detecção publica um conjunto novo de regras de persistência, por exemplo, o plano de emulação correspondente entra na fila da próxima rodada e executa as técnicas na ordem do ator emulado, não na ordem de publicação das regras. A ordem do ator é o que gera correlação temporal realista, e é por isso que o plano, e não a lista de regras, conduz a rodada.

Planos curtos também são a melhor porta de entrada para equipes iniciando em emulação. A infraestrutura exigida é mínima, os riscos são menores do que em operações com implantes e o aprendizado sobre telemetria é imediato, porque cada passo termina com a pergunta: a detecção correspondente apareceu no SIEM. Depois de acumular uma biblioteca de planos versionados, a equipe possui um repositório de emulações reutilizáveis que cresce a cada relatório de inteligência digerido.

A biblioteca de planos ganha valor com um índice simples de reuso. Cada plano declara o ator emulado, as técnicas da cadeia e a última data de execução, e esse índice, mantido no repositório, permite responder em segundos às perguntas da reunião semanal: quando foi a última vez que testamos essa técnica, com qual plano e com que resultado. O índice também evita o caminho contrário, aquele em que dois operadores escrevem planos quase idênticos para a mesma cadeia sem saber do trabalho do colega.

5. Exemplo de Plano de Emulação

O plano a seguir emula uma cadeia curta de comprometimento inicial e persistência em endpoint Windows, inspirada em perfis públicos de crime financeiro, e é representativo do formato estruturado que o Temperance consome.

plano: emulacao-curta-inicial-persistencia-01
objetivo: validar detecção de execução inicial por macro e persistência por tarefa agendada
escopo:
  hosts: [LAB-PT-WIN-03]
  janela: "2025-10-09 14:00 a 16:00"
  autorizacao: PT-2025-21
  referencias_ataque: [T1204.002, T1059.001, T1053.005]
tasks:
  - id: 1
    nome: Execução inicial
    steps:
      - id: 1.1
        tecnica: T1204.002
        acao: abrir documento de teste com macro de escrita simples
        evidencia_esperada: evento de criação de processo WINWORD.EXE iniciando powershell.exe
      - id: 1.2
        tecnica: T1059.001
        acao: macro executa script de teste que escreve arquivo em diretório temporário
        evidencia_esperada: evento de arquivo criado e linha de comando registrada pelo EDR
  - id: 2
    nome: Persistência
    steps:
      - id: 2.1
        tecnica: T1053.005
        acao: criar tarefa agendada de teste nomeada env-diagnostics com comando de eco
        evidencia_esperada: evento 4698 do Security log com nome da tarefa
verificacao:
  fonte: SIEM de laboratório
  janela_consulta: 10 minutos após cada step
  saida: ficha de resultado por step com detectado, só telemetria e não detectado
limpeza:
  - remover tarefa agendada env-diagnostics
  - remover arquivo de teste do diretório temporário
  - registrar hashes e timestamps na ata da rodada

A leitura do plano de cima para baixo mostra a vantagem do formato. O revisor técnico avalia as técnicas e a ordem antes da execução; o revisor de governança confere escopo e autorização; o operador executa seguindo a sequência; e o analista de deteções sabe exatamente o que procurar no SIEM em cada janela de 10 minutos. Um único artefato serve a três públicos sem tradução adicional.

6. Execução, Registro e Cruzamento com Telemetria

A execução guiada pelo Temperance produz um registro sequencial com timestamp, status e anotações por step. Esse registro é a metade ofensiva da avaliação, e o cruzamento com a telemetria completa a ficha. Para o step de tarefa agendada do plano anterior, a consulta KQL a seguir recupera o evento de criação na janela definida, ilustrando o padrão de verificação que se repete para cada step.

// Evento 4698 na janela do step 2.1 do plano de emulação
SecurityEvent
| where TimeGenerated between (datetime(2025-10-09 14:00) .. datetime(2025-10-09 16:00))
| where EventID == 4698
| where TaskName contains "env-diagnostics"
| project TimeGenerated, Computer, SubjectUserName, TaskName, Command

O resultado por step segue a classificação canônica do capítulo: detectado quando há alerta da regra correspondente, só telemetria quando o evento bruto existe sem alerta, e não detectado quando nem a telemetria chegou, caso em que o plano registra um gap de coleta e não um gap de regra. Ao fim da rodada, o plano concluído com a ficha preenchida é commitado no repositório, e a próxima execução do mesmo plano mede o efeito das correções.

A semântica dos status merece uma tabela de referência, porque é ela que evita a leitura otimista dos resultados.

Com a tabela em mãos, a ata da rodada se preenche em minutos e sem ambiguidade. A regra de ouro é que nenhum step termina sem status, e nenhum status sem evidência anexada, seja o identificador do alerta no SIEM, seja o identificador do evento bruto consultado.

Esse ciclo de plano, execução, cruzamento e reexecução é o mecanismo mais barato de purple teaming contínuo que existe, porque exige apenas repositório, host de teste e SIEM. Quando a maturidade cresce, os mesmos planos podem ser automatizados, com os steps chamando atomics ou a API do Caldera, e o Temperance mantém o papel de documento mestre que explica por que cada passo existe.

A herança do ciclo é o repositório de planos executados, que vira patrimônio do programa. Cada plano com histórico de execuções e resultados acumulados responde perguntas que nenhuma ferramenta isolada responde, como quantas vezes aquela cadeia foi testada neste ano e qual era o resultado na primeira rodada, e é esse patrimônio que diferencia um programa que emula há meses de um que emulou uma vez.

7. Erros Comuns e Pontos de Atenção

• Escrever planos sem evidência esperada por step, o que reduz a emulação a uma lista de comandos e deixa a avaliação para a improvisação; a evidência esperada é o coração do plano.
• Deixar escopo e autorização fora do documento, obrigando o revisor a caçar a autorização em outro sistema; escopo e autorização vivem no plano.
• Usar planos como registro pós-fato, escrevendo depois de executar; o plano guia a execução, e o registro preenche status e anotações, não o contrário.
• Encadear mais passos do que a janela de verificação suporta, perdendo a separação temporal que a correlação no SIEM precisa; espaço os steps e verifique entre eles.
• Tratar o plano como artefato descartável, sem versionar; a série histórica de execuções do mesmo plano é o que revela regressão e progresso.
• Acreditar que o registro do Temperance substitui a telemetria do SIEM; o registro diz o que foi feito, e só a telemetria diz o que a defesa viu.
• Emular a cadeia completa de um ator em um único plano longo, sem cortes verificáveis entre os passos; planos curtos com verificação entre steps capturam mais por rodada do que emulações monolíticas que ninguém reexecuta.
• Migrar o plano para automação sem atualizar a evidência esperada, herdando critérios desatualizados para uma execução que agora corre sem operador; o plano automatizado mantém os mesmos campos e ganha o registro automático de status.

8. Integração com o Restante da Biblioteca

Os planos do Temperance se alimentam diretamente da tradução de relatórios de inteligência em TTPs executáveis, descrita no ciclo de CTI do Capítulo 01 e no mapeamento ATT&CK do Capítulo 15, e entregam os resultados para o mesmo índice que alimenta o painel de cobertura da pasta 03 deste capítulo. Quando o plano invoca atomics, a nota de Atomic Red Team define os detalhes de pré-requisitos e limpeza; quando invoca um canal de C2, a nota de Sliver e Mythic define os limites de engajamento. A nota de cyber range da pasta 03 descreve os hosts de teste em que os planos rodam com segurança.

No fluxo de maturação do programa, o Temperance é o degrau entre a validação manual inicial e a automação completa. Equipes que começam com planos curtos versionados evoluem naturalmente para rotinas agendadas com Caldera e gate de detecção em CI/CD, mantendo os planos como documentação viva do que cada rodada testou. Essa progressão, de plano versionado a automação com histórico, é a espinha dorsal do purple teaming contínuo que o capítulo descreve.