Temperance (Emulação de C2)

Nota da subpasta 03 - Ferramentas de Emulação e Purple Team, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata do Temperance do SpecterOps pelo ângulo da mecânica de comando e execução: command server, implant e o ciclo de exercícios purple curtos de emulação de adversário.
Dialoga com a nota de Temperance do Capítulo 19, que cobre os planos, e com Caldera, Atomic Red Team e os C2 frameworks da mesma pasta.

1. Contexto e Posicionamento na Biblioteca

A nota de Temperance do Capítulo 19 cobre a face documental do framework, os planos com tasks, steps e evidência esperada; esta nota cobre a face operacional, como o framework conduz o comando e a execução durante o exercício, e por que esse desenho o distingue tanto do Atomic Red Team, que executa testes isolados, quanto do Sliver e do Mythic, que mantêm canal de C2 real. O Temperance do SpecterOps foi construído com uma premissa de simplicidade: a maior parte das rodadas de purple team não precisa de infraestrutura ofensiva complexa, precisa de ordem, registro e um laço curto entre executar e verificar.

A faixa de trabalho do framework é o exercício curto de três a dez passos, extraído de um relatório de inteligência e desenhado para validar uma cadeia específica. Nessa faixa, o Temperance entrega três coisas ao mesmo tempo: conduz o operador pela sequência do plano, registra o que foi executado com timestamp e anotações, e produz o artefato que se cruza com a telemetria do SIEM. Esta nota descreve os componentes dessa mecânica, o ciclo do exercício, os limites honestos da ferramenta e um exemplo completo de rodada.

2. Posicionamento entre o Plano e o Canal Completo

O jeito mais rápido de fixar o papel do Temperance é por exclusão. Ele não executa testes por conta própria como o módulo do Atomic Red Team, que dispara comandos de um YAML; ele conduz o operador, que executa e registra. Ele não mantém canal persistente de comando e controle como o Sliver e o Mythic, com implante ativo, beacon e listeners; ele coordena a execução do plano e termina com ela. Entre o teste unitário do atomic e a operação com canal realista existe essa faixa de exercício guiado, e é nela que a maioria das rodadas semanais de um programa purple acontece.

O ganho específico dessa posição é a proporção custo e benefício. A infraestrutura exigida é mínima, o risco operacional é baixo porque nada fica ativo após a rodada, e o produto é a ficha de resultado com evidência por passo, que é exatamente o que a engenharia de detecção consome para priorizar backlog. O C2 completo permanece reservado para os cenários que precisam testar o canal, e a nota de Sliver, Mythic e Realm da pasta 03 define quando essa necessidade aparece.

3. Arquitetura: Command Server e Implant

A mecânica de comando e execução do Temperance se apoia em dois componentes. O command server é o lado central: hospeda os planos, mantém o estado da execução, recebe os registros de cada passo e consolida o relatório da rodada. O implant é o lado do host de teste: componente leve que executa as ações do passo sob comando do operador e devolve o resultado com timestamp, na configuração típica de uso em laboratório. Entre os dois, o operador conduz o laço de execução, com pausas e verificações entre passos, que é a assinatura do framework.

O fluxo de uma rodada segue a sequência abaixo, e o desenho deixa claro por que o framework é classificado aqui, junto das ferramentas de emulação com componente de comando.

1. Operador carrega o plano versionado no command server
2. Servidor valida escopo, autorizacao e ordem dos passos
3. Implant no host de teste recebe o passo corrente
4. Operador executa o passo e registra status e anotacao
5. Janela de verificacao: consulta no SIEM para o passo executado
6. Servidor consolida o relatorio da rodada com a ficha por passo
7. Plano concluido versionado com o resultado da rodada

O desenho tem duas consequências práticas. A primeira é auditabilidade por construção: cada comando executado passa pelo registro do servidor, e o relatório final lista o que rodou, em que host e em que hora, sem depender da memória do operador. A segunda é controle de escopo: a validação do plano na carga, com escopo e autorização no documento, reduz o erro de execução fora da área acordada, tema que a nota de engajamento do Capítulo 19 trata em profundidade.

4. Ciclo do Exercício Purple Curto

O ciclo recomendado para a rodada curta tem seis etapas, e a disciplina está em respeitar as pausas. A CTI entrega a cadeia emulada com o relatório de origem; a equipe de emulação escreve o plano no formato do Capítulo 19, com evidência esperada por passo; a rodada executa passo a passo com verificação de telemetria entre eles; a ficha de resultado é preenchida com status canônico por passo; os gaps recebem dono no backlog; e o plano versionado é reexecutado após as correções. A cadência semanal ou quinzenal segue a capacidade de consumo do time de detecção, e não a vontade do time ofensivo.

O laço curto entre execução e verificação é o que dá valor pedagógico ao exercício: o operador vê em minutos se a telemetria chegou, e a conversa entre red e blue acontece com o contexto vivo. Em rodadas com mais de um host, a ordem dos passos segue a cadeia do adversário, e não a ordem das regras a testar, porque a correlação temporal no SIEM é o que valida as regras de sequência do capítulo de detecção.

O ritmo da rodada também é dado: o tempo entre passos e o tempo de verificação aparecem no relatório do servidor, e a tendência de alongamento é o sinal de que a rodada cresceu além da faixa curta. Rodadas que esticam além da janela acordada voltam para o planejamento, com corte de passos ou troca de ferramenta, porque a correlação temporal e a atenção do operador degradam juntas.

5. Anatomia do Plano

O plano é o contrato do exercício, e entender sua anatomia evita os dois erros opostos de autoria: o plano vago, que não permite verificação, e o plano gigante, que ninguém reexecuta. Tasks representam fases da cadeia emulada, steps representam ações observáveis dentro de cada fase, e cada step declara a técnica ATT&CK, a ação em linguagem executável e a evidência esperada com fonte e campo. O gabarito mínimo abaixo cabe em uma tela e cobre tudo que a rodada precisa para ser auditável.

plano: pt-curto-AAAA-NN
objetivo: cadeia emulada resumida em uma frase
escopo:
  hosts: [LAB-PT-WIN-05]
  janela: "inicio e fim com fuso"
  autorizacao: PT-AAAA-NN
tasks:
  - id: 1
    nome: fase da cadeia
    steps:
      - id: 1.1
        tecnica: T1059.001
        acao: acao observavel no host de teste
        evidencia_esperada: fonte e campo que comprovam
verificacao:
  fonte: SIEM ou EDR de laboratorio
  janela_consulta: minutos apos cada passo
limpeza:
  - artefato removido, com auditoria

Três campos merecem rigidez especial porque sustentam a auditoria inteira. O campo de autorização referencia o documento vigente, e não a palavra do operador; a evidência esperada descreve fonte e campo, e não apenas o fenômeno, porque é ela que vira consulta no SIEM; e a limpeza lista artefato por artefato com verificação, porque resíduo de rodada anterior envenena a linha de base da seguinte. Planos que omitem qualquer um dos três voltam para revisão antes de entrar na agenda.

6. Casos de Uso e Limitações

A tabela resume onde o Temperance entrega valor e onde o desenho de simplicidade vira limite objetivo, para consulta no planejamento do programa.

A leitura honesta da tabela é que o framework cobre o segmento de maior frequência do programa e depende de vizinhos para o resto. Times que tentam esticar o Temperance para além da faixa curta terminam com planos longos que ninguém reexecuta, exatamente o erro que a nota do Capítulo 19 lista primeiro, e a resposta correta é trocar de ferramenta na faixa certa.

Há ainda o limite de evidência: como a execução é conduzida por operador, o registro depende da disciplina de anotação em tempo real, e rodadas com muitos passos simultâneos em hosts diferentes exigem mais operadores ou mais disciplina do que o framework assume. O efeito prático é que o tamanho ideal da rodada é aquele que um operador executa com verificação sem estourar a janela autorizada, e esse teto é característica do desenho, não defeito a contornar com scripts improvisados.

7. Exemplo de Exercício com Temperance

O exercício abaixo emula a cadeia de execução inicial e persistência que serve de fio condutor nesta biblioteca, com o plano carregado no command server e execução no host de teste. O plano segue o formato do Capítulo 19, e a mecânica de comando desta nota o conduz.

plano: emulacao-c2-curta-01
objetivo: validar cadeia de execução inicial e persistência com verificação por passo
escopo:
  hosts: [LAB-PT-WIN-05]
  janela: "2025-11-25 14:00 a 15:30"
  autorizacao: PT-2025-34
tasks:
  - id: 1
    nome: Execução inicial
    steps:
      - id: 1.1
        tecnica: T1059.001
        acao: comando de teste gravando arquivo em diretório temporário
        evidencia_esperada: evento de criação de processo com linha de comando no EDR
  - id: 2
    nome: Persistência
    steps:
      - id: 2.1
        tecnica: T1053.005
        acao: criar tarefa agendada env-diagnostics no host de teste
        evidencia_esperada: evento 4698 no Security log com nome da tarefa
verificacao:
  fonte: SIEM de laboratório
  janela_consulta: 10 minutos após cada passo
limpeza:
  - remover tarefa agendada env-diagnostics
  - remover arquivo de teste do diretório temporário

Durante a rodada, o command server valida o plano, o implant executa cada passo no host e o operador registra o status após a verificação. A consulta abaixo recupera a evidência do passo 2.1 na janela acordada, e o padrão se repete para cada passo antes de avançar.

SecurityEvent
| where TimeGenerated between (datetime(2025-11-25 14:00) .. datetime(2025-11-25 15:30))
| where EventID == 4698
| where TaskName contains "env-diagnostics"
| project TimeGenerated, Computer, SubjectUserName, TaskName, Command

A ficha final da rodada registra os dois passos com status, evidência anexada e anotações, o relatório do servidor é anexado ao plano versionado, e a limpeza é auditada antes do encerramento. Na reexecução, após a implantação da regra de detecção correspondente, o status do passo 2.1 muda de só telemetria para detectado, e essa mudança entre rodadas é a métrica que sustenta o programa.

8. Erros Comuns e Pontos de Atenção

• Encadear passos sem pausa de verificação, perdendo a separação temporal que as regras de sequência precisam; o laço curto é o coração do framework.
• Usar o Temperance para testar canal de C2, que é objetivo fora de sua faixa; a nota da pasta 03 define a ferramenta certa para o canal.
• Deixar a limpeza fora do plano ou sem auditoria, acumulando resíduos no host de teste que geram alertas fantasmas nas rodadas seguintes.
• Registrar status de memória após a rodada, em vez de passo a passo; o registro imediato é o que preserva a correlação com o SIEM.
• Tratar o relatório do servidor como veredito de detecção; o relatório diz o que foi executado, e só a telemetria diz o que a defesa viu.
• Manter planos no computador do operador em vez do repositório, perdendo revisão por pares e histórico de reexecuções.
• Esticar planos para vinte passos e duas janelas de hora, transformando o exercício curto em operação improvisada sem infraestrutura de controle; nesses casos, Caldera.
• Dividir a execução entre dois operadores sem dividir o registro, deixando passos sem dono de anotação; uma rodada, um operador, um registro.

9. Integração com o Restante da Biblioteca

O framework consome os planos descritos no Capítulo 19, executa os atomics da pasta 02 quando o passo pede um teste pronto, e entrega a ficha de resultado para o painel de cobertura do Capítulo 18 e para as métricas SIM.3 do Capítulo 15. Quando o exercício revela gap de canal ou de operação longa, a subpasta oferece o degrau acima, com Caldera para operação agendada e os C2 frameworks para canal realista, e a nota de Temperance do Capítulo 19 permanece como referência de formato de plano.

A recomendação de fechamento é de sequência de adoção para o programa: comece pelos atomics para dominar a telemetria por técnica, adote o Temperance para institucionalizar a rodada curta com ficha versionada, e suba para o Caldera quando a agenda pedir operações agendadas em escala. A disciplina que essa sequência constrói, plano revisado, execução registrada, verificação entre passos e gap com dono, é o ativo real que sobrevive à troca de ferramentas, e é ela que o command server e o implant do Temperance servem de forma tão econômica.