Atomic Red Team (Testes de TTPs)

Nota da subpasta 03 - Ferramentas de Emulação e Purple Team, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata do Atomic Red Team em profundidade: estrutura de atomics, execução com Invoke-AtomicRedTeam, cobertura por plataforma e integração em CI para validação de detecções.
Dialoga com a nota de Atomic Red Team do Capítulo 19, com Caldera, C2 frameworks e Temperance da mesma pasta e com o controle SIM.3 de exercícios purple team do Capítulo 15.

1. Contexto e Posicionamento na Biblioteca

O Atomic Red Team é a ferramenta de menor custo de entrada para validar detecções por técnica ATT&CK, e por isso é o ponto de partida natural de qualquer programa de purple teaming. Cada atomic é um teste pequeno, declarativo e independente: um YAML que descreve uma técnica com comandos por plataforma, argumentos, pré-requisitos e comando de limpeza. O operador executa o teste no host de teste, a telemetria chega ao SIEM, e a pergunta da rodada tem resposta em minutos: a detecção correspondente disparou ou não.

A nota aprofunda o conteúdo do Capítulo 19 em três direções. Primeiro, a anatomia completa de um atomic, porque ler e escrever YAML de atomic é habilidade que o time precisa dominar para adaptar testes ao laboratório. Segundo, a operação com o módulo PowerShell Invoke-AtomicRedTeam, com os parâmetros que controlam pré-requisitos, execução e log. Terceiro, a integração em CI, que transforma o teste manual em validação contínua, e o exemplo completo com verificação de telemetria que fecha o ciclo com o capítulo de detecção desta biblioteca.

2. Anatomia de um Atomic

O repositório do projeto organiza os atomics por técnica, um YAML por identifier ATT&CK, e cada arquivo carrega uma lista de testes independentes. Os campos que importam na prática são o nome do teste, as plataformas suportadas, os argumentos de entrada com valores padrão, os comandos de dependência, execução e limpeza, e o executor, que define o shell responsável. A leitura do YAML abaixo, derivado do repositório e ajustado para o laboratório, mostra a estrutura que o time deve saber editar com confiança.

attack_technique: T1053.005
display_name: Scheduled Task/Job - Scheduled Task
atomic_tests:
  - name: Criar tarefa agendada pelo schtasks
    auto_generated_guid: 4aa609d9-cb0d-4fd7-b1b1-3c1f9a2b9e10
    description: Cria tarefa agendada de teste env-diagnostics em host Windows
    supported_platforms:
      - windows
    input_arguments:
      task_name:
        description: Nome da tarefa de teste
        type: string
        default: env-diagnostics
    executor:
      name: command_prompt
      command: |
        schtasks /create /tn #{task_name} /tr "cmd.exe /c echo teste" /sc hourly
      cleanup_command: |
        schtasks /delete /tn #{task_name} /f

Três detalhes de engenharia fazem diferença na operação. O cleanup_command é obrigatório em qualquer atomic adaptado, porque resíduo de teste em host compartilhado é fonte de alerta fantasma e de desconfiança no resultado. Os input_arguments permitem que o mesmo teste sirva a vários laboratórios sem editar o YAML, mudando apenas os argumentos na chamada. E o campo de plataforma é o que o CI usa para decidir em qual runner o teste roda, motivo para mantê-lo exato.

3. Execução com Invoke-AtomicRedTeam

O módulo Invoke-AtomicRedTeam é o executor padrão em Windows e funciona igual em Linux e macOS com PowerShell instalado. O fluxo típico instala o módulo, inspeciona o teste, valida pré-requisitos, executa com log e limpa depois, e a sequência abaixo cobre o ciclo completo para o teste da seção anterior.

Install-Module -Name invoke-atomicredteam -Scope CurrentUser
Import-Module invoke-atomicredteam

# Inspecionar o teste antes de executar
Invoke-AtomicTest T1053.005 -ShowDetails

# Validar e instalar pre-requisitos
Invoke-AtomicTest T1053.005 -TestNumbers 1 -CheckPrereqs
Invoke-AtomicTest T1053.005 -TestNumbers 1 -GetPrereqs

# Executar com argumento customizado e log de execucao
Invoke-AtomicTest T1053.005 -TestNumbers 1 `
  -InputArgs @{"task_name" = "env-diagnostics"} `
  -ExecutionLogPath C:\lab\art-exec-log.json

# Limpar os artefatos do teste
Invoke-AtomicTest T1053.005 -TestNumbers 1 -Cleanup

O parâmetro de log de execução é o elo entre a metade ofensiva e a defensiva da avaliação: o registro contém técnica, teste, timestamp, host e comando executado, e é esse arquivo que permite cruzar com precisão cada evento do SIEM na janela da execução. A disciplina de rodar com log, mesmo na execução manual, evita a improvisação de evidência que contamina a ficha de resultado.

4. Cobertura por Plataforma

O repositório cobre as plataformas principais com profundidade desigual, e a tabela resume o quadro que orienta o planejamento de cobertura do programa.

A desigualdade de cobertura não é defeito, é instrução: o atomic cobre o que é seguro e replicável em teste, e as lacunas do acervo são preenchidas com atomics próprios, escritos no mesmo YAML e mantidos no repositório do time. A prática recomendada é manter uma pasta local de atomics customizados versionada junto com os planos de emulação do Temperance da pasta 04, de forma que o CI trate conteúdo próprio e público pelo mesmo fluxo.

5. Integração em CI

A integração em CI transforma a validação manual em contínua: o pipeline agenda a execução dos atomics em runners dedicados, com telemetria enviada ao SIEM de laboratório, e publica a ficha de resultado por técnica. O desenho abaixo mostra o job em sua forma mínima, com runner Windows e log de execução como artefato.

name: emulacao-atomics
on:
  schedule:
    - cron: "0 3 * * 1"
jobs:
  atomic-windows:
    runs-on: [self-hosted, windows, lab]
    steps:
      - uses: actions/checkout@v4
      - name: Executar atomics da rodada
        shell: pwsh
        run: |
          Import-Module invoke-atomicredteam
          Invoke-AtomicTest T1053.005 -TestNumbers 1 `
            -ExecutionLogPath C:\lab\art-T1053-005.json
          Invoke-AtomicTest T1053.005 -TestNumbers 1 -Cleanup
      - name: Publicar log de execucao
        uses: actions/upload-artifact@v4
        with:
          name: art-exec-log
          path: C:\lab\art-*.json

Três salvaguardas separam CI saudável de desastre. O runner é self-hosted dedicado ao laboratório, sem acesso a produção e com snapshot de restauração. O agendamento respeita a janela acordada com o time de detecção, porque execução fora da janela contamina correlações. E o backlog de gaps gerado pela rodada é triado antes da próxima execução, mantendo o ciclo do Capítulo 19 com donos e prazos.

6. Exemplo Completo com Verificação de Telemetria

O ciclo completo liga o atomic da seção 2 à detecção do capítulo de plataformas: a execução cria a tarefa agendada, o SIEM de laboratório recebe o evento de criação, e a consulta abaixo recupera o evento na janela da rodada, com o resultado classificado conforme o quadro de status do capítulo.

// Verificacao do atomic T1053.005 no SIEM de laboratorio
SecurityEvent
| where TimeGenerated between (datetime(2025-11-24 03:00) .. datetime(2025-11-24 04:00))
| where EventID == 4698
| where TaskName == "env-diagnostics"
| project TimeGenerated, Computer, SubjectUserName, TaskName, Command

A ficha de resultado do teste segue o padrão da biblioteca: técnica T1053.005, atomic executado com log anexado, evento 4698 presente no SIEM, alerta da regra correspondente ausente na primeira rodada, status só telemetria, gap registrado no backlog de regras e reexecução agendada após a implantação da regra. Na segunda rodada, com a regra ativa, o status muda para detectado, e a mudança de status entre rodadas é a métrica que prova o valor do programa.

O mesmo ciclo se repete por técnica na rodada, e o painel de cobertura por tática do Capítulo 18 é alimentado com os resultados agregados. Quando a técnica exige cadeia com contexto de C2, o teste passa do atomic para o Temperance ou para o Caldera, e a nota da pasta 01 desta subpasta descreve esse escalonamento de complexidade.

7. Erros Comuns e Pontos de Atenção

• Executar atomics em host de produção por praticidade, o erro que encerra programas: o teste roda em host dedicado, com snapshot e cleanup.
• Esquecer o cleanup e acumular tarefas agendadas, chaves e serviços de teste, gerando alertas fantasmas que ninguém consegue distinguir de ataque real.
• Rodar sem log de execução e tentar reconstruir a evidência depois da consulta no SIEM; o log é a chave do cruzamento preciso.
• Interpretar falta de alerta como falta de detecção sem verificar a telemetria; se o evento bruto não chegou, o gap é de coleta, e não de regra.
• Adaptar atomics com credenciais reais ou dados de produção, violando o escopo do exercício; os argumentos de teste usam nomes e valores de laboratório.
• Medir o programa por número de atomics executados em vez de por status resolvido; volume sem veredito é teatro de métrica.
• Ignorar as plataformas secundárias do parque, deixando macOS e cloud sem qualquer validação; a cobertura segue o inventário de risco, e não o acervo do repositório.

8. Integração com o Restante da Biblioteca

Os atomics são o insumo mais barato para as fichas de emulação do Temperance da pasta 04, que referencia cada teste no step correspondente, e para as operações do Caldera da pasta 01, que podem invocar atomics por plugin. A detecção validada pelo atomic é escrita seguindo o capítulo de plataformas desta pasta, e a regra resultante entra no ciclo de DaC do Capítulo 18 com o link para o teste que a originou. O quadro de status da rodada alimenta as métricas do Capítulo 16 e a agenda de exercícios SIM.3 do Capítulo 15.

Para o hunting, o atomic tem papel inverso ao da detecção: ele planta o comportamento no laboratório para que o hunter valide consultas antes de rodá-las contra produção, prática descrita na nota de simulação de alertas com inputs controlados do Capítulo 18. O fechamento desta nota repete o princípio operacional do capítulo: o atomic é a unidade mínima de emulação, e o programa amadurece na ordem atomic, plano Temperance, operação Caldera, canal realista com C2, sempre com ficha de resultado versionada e gap com dono.