Atomic Red Team (Testes de TTPs Específicas)

Nota da pasta 02 - Ferramentas de Emulação, no Capítulo 19 (Purple Teaming Contínuo).
Trata do Atomic Red Team como catálogo de testes pontuais por técnica ATT&CK, com estrutura de atomic em YAML, pré-requisitos, cleanup e integração com o Invoke-AtomicRedTeam.
Dialoga com a nota de MITRE Caldera da mesma pasta, com a engenharia de detecção do Capítulo 15 e com o BAS contínuo da pasta 03.

1. Contexto e Posicionamento na Biblioteca

Se o Caldera é o motor de cadeias encadeadas, o Atomic Red Team é o martelo de pregos pequenos: um repositório aberto de testes individuais, os atomics, cada um correspondendo a uma técnica do MITRE ATT&CK e construído para responder uma pergunta objetiva. Esta regra de detecção dispara quando a técnica é executada neste ambiente. Essa granularidade fina é o que faz do projeto a ferramenta do dia a dia do engenheiro de detecção, capaz de validar uma regra recém-publicada em minutos, sem montar servidor, agente ou operação completa.

No fluxo do purple teaming contínuo, o Atomic ocupa a camada de validação rápida. A nota SIM.4 do Capítulo 15 descreve o teste de detecção por IOC e IOA como controle; o Atomic é o instrumento prático que executa esse controle, e a nota SIM.2 já mostrou a ponte pelo plugin do Caldera. Aqui o foco é a ferramenta em si: como um atomic é estruturado, como executá-lo com o módulo PowerShell, como verificar o alerta correspondente e como integrar a execução em rotinas automatizadas.

2. O Conceito de Atomic: Um Teste por Técnica ATT&CK

Cada atomic é uma especificação autocontida de teste, versionada em repositório público e organizada por técnica ATT&CK. Um arquivo de técnica como o T1059.001 pode conter vários testes, cada um simulando uma variação realista do comportamento da técnica, e todos projetados para gerar telemetria verificável. O projeto mantém coberturas para Windows, Linux, macOS, contêineres e nuvem, o que permite usar a mesma metodologia em todo o parque de ativos.

O valor do catálogo está na disciplina que ele impõe ao purple team. Em vez de improvisar comandos soltos, o engenheiro executa um teste padronizado, com parâmetros documentados, pré-requisitos declarados e comando de limpeza, e registra o resultado contra a regra de detecção em avaliação. O teste é repetível por definição, pois o que varia de ambiente para ambiente fica nos input arguments, e o que varia de rodada para rodada fica no agendamento, não no conteúdo do teste.

A organização do repositório acompanha a matriz ATT&CK, e a nomenclatura dos testes é estável o suficiente para entrar em planilhas de cobertura e em automações. A tabela resume as famílias de cobertura que o projeto mantém e o uso típico de cada uma.

Essa amplitude transforma o catálogo em linguagem comum entre times. Um plano de emulação do Temperance pode referenciar atomics por identificador de teste, e um adversary do Caldera pode importá-los pelo plugin, e o mesmo identificador aparece na ficha de resultado e no painel de cobertura.

É importante delimitar o que o Atomic não é. Ele não emula um adversário encadeando técnicas ao longo do kill chain, não mantém infraestrutura de comando e controle e não tem orquestração central. Essa é uma característica deliberada: cada teste é curto, legível e auditável em segundos, o que reduz o risco de dano colateral e torna a ferramenta adequada até para ambientes de produção controlada, sempre com autorização e janela definidas.

3. Estrutura do Arquivo YAML de um Atomic

Cada técnica é descrita em um arquivo YAML com metadados ATT&CK e uma lista de testes. A estrutura canônica inclui nome, descrição, plataformas suportadas, argumentos de entrada com valores padrão, lista de dependências com comandos de verificação e instalação, executor com o comando efetivo e comando de limpeza. O bloco a seguir mostra uma versão simplificada e didática dessa estrutura para a técnica T1059.001.

attack_technique: T1059.001
display_name: Command and Scripting Interpreter: PowerShell
atomic_tests:
- name: Execucao de script PowerShell iniciada por processo de escritorio
  description: Simula a execucao de um script de teste a partir de contexto tipico de phishing
  supported_platforms:
  - windows
  input_arguments:
    mensagem:
      description: Texto impresso pelo script de teste
      type: string
      default: atomic-t1059-001
  executor:
    name: powershell
    command: |
      Write-Host #{mensagem}
    cleanup_command: |
      Write-Host "cleanup concluido"

Três campos merecem leitura atenta. Os input arguments parametrizam o teste sem editar o arquivo, permitindo adaptar nomes, caminhos e valores ao ambiente alvo. As dependencies declaram o que precisa existir para o teste rodar de forma confiável, com comandos de verificação e de obtenção automática, evitando o falso negativo de um teste que falhou por ausência de pré-requisito. O cleanup_command garante que o ambiente volte ao estado anterior, propriedade indispensável quando os testes rodam em agendamento recorrente.

4. Execução com Invoke-AtomicRedTeam

No Windows, a interface mais usada é o módulo PowerShell Invoke-AtomicRedTeam, que baixa o catálogo, valida pré-requisitos, executa testes e aplica limpeza com comandos previsíveis. O módulo também expõe detalhes dos testes, o que auxilia a documentação da rodada. A sequência típica de trabalho é mostrada a seguir.

# Instalar o modulo e o guia de execução
Install-Module -Name Invoke-AtomicRedTeam -Force
Install-Module -Name AtomicsT1059.001 -ErrorAction SilentlyContinue   # pacotes de atomics, quando aplicavel

# Revisar detalhes do teste antes de executar
Show-AtomicDetails -Technique T1059.001

# Verificar e instalar pre-requisitos
Invoke-AtomicTest T1059.001 -CheckPrereqs
Invoke-AtomicTest T1059.001 -GetPrereqs

# Executar o teste completo da tecnica
Invoke-AtomicTest T1059.001

# Limpar os artefatos ao final
Invoke-AtomicTest T1059.001 -Cleanup

Em ambientes Linux e macOS, o mesmo catálogo é consumido pelo runner em Python, o atomic-operator, ou por execução direta dos comandos descritos no YAML. Para pipelines e agendadores, o atomic-operator é a escolha natural, pois expõe a execução como comando de linha com saída estruturada, permitindo que o job capture o resultado por teste e publique na plataforma de telemetria. A regra é usar um runner por família de plataforma e manter o catálogo versionado, atualizando o repositório local em janelas controladas para que uma atualização silenciosa não mude o comportamento de um teste em produção de regras.

O exemplo a seguir mostra o atomic-operator em uso dentro de uma rotina agendada em host Linux de teste.

# Instalar o runner e executar uma lista priorizada de técnicas
pip install atomic-operator
atomic-operator --atomics-path /opt/atomics \
  --techniques T1059.004,T1543.002 \
  --input-args '/opt/config/args-producao-regras.yml' \
  --output /opt/results/resultado-rodada-42.json

A saída estruturada por teste é o que permite anexar a rotina ao pipeline de medição do capítulo. Cada registro de resultado carrega o identificador da técnica, o nome do teste, o status de execução e o timestamp, e o agendador publica esses campos no índice de resultados do SIEM, onde a verificação de alerta acontece automaticamente.

5. Exemplo Prático: Teste de T1059.001 e Verificação do Alerta

O cenário de referência é validar uma regra que alerta quando um interpretador PowerShell é iniciado por um processo do pacote de escritório, padrão clássico de execução de phishing. O primeiro passo é executar o teste em um host com o agente de telemetria saudável e a janela autorizada. O segundo é consultar o SIEM na janela do teste, buscando a cadeia de processo que caracteriza a técnica. A consulta KQL a seguir exemplifica a verificação em telemetria de endpoint.

// Cadeia office iniciando PowerShell na janela do teste atomic
DeviceProcessEvents
| where Timestamp between (datetime(2025-10-06 14:00) .. datetime(2025-10-06 14:30))
| where InitiatingProcessFileName in~ ("WINWORD.EXE", "EXCEL.EXE", "OUTLOOK.EXE")
| where FileName =~ "powershell.exe"
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine

O terceiro passo é registrar a ficha de resultado com quatro campos: o teste executado, o evento bruto encontrado, o alerta de regra gerado ou a ausência dele e a ação do EDR. Se a consulta acima mostra o evento, mas nenhuma regra disparou, o resultado é só telemetria e o produto é uma tarefa de engenharia de detecção para a regra ausente. Se nem o evento apareceu, o problema é upstream, na coleta ou no agente, e a regra não deve ser julgada antes do pipeline de dados ser consertado. Essa separação de causas evita o erro clássico de reescrever regras para problemas de coleta.

O quarto passo fecha o ciclo purple: o resultado entra na matriz da rodada, a regra nova ou ajustada é versionada no repositório de detecções e o mesmo teste é reexecutado no próximo ciclo para comprovar a correção. Como o atomic é determinístico e parametrizado, a reexecução serve como prova comparável entre rodadas, e a série histórica por técnica alimenta o painel de cobertura do capítulo.

6. Automação e Integração em Rotinas Contínuas

O mesmo catálogo que atende o engenheiro em teste manual atende o agendador em rotina contínua. Um job semanal pode iterar sobre uma lista priorizada de técnicas, executar os atomics correspondentes em hosts de teste, consultar o SIEM por cada janela de execução e publicar a matriz de resultado, tudo sem intervenção humana. O bloco a seguir esboça esse fluxo em pseudocódigo de orquestração.

Rotina semanal de validação com Atomic:
  entrada: lista priorizada de técnicas do painel de cobertura
  para cada técnica T na lista:
    executar Invoke-AtomicTest T no host de teste designado
    aguardar janela de ingestão de 5 minutos
    consultar SIEM por evento bruto e por alerta da técnica T
    classificar resultado: detectado, só telemetria, não detectado, erro de execução
    publicar resultado no índice bas_results com timestamp e host
  fim
  disparar alerta de regressão para toda técnica que era detectado e agora não é

Nessa rotina, o Atomic é o executor e o Caldera, a API do SIEM e o painel de cobertura são consumidores dos resultados. A divisão mantém cada ferramenta no que faz melhor e evita que a automação dependa de capturas de tela manuais ou planilhas paralelas.

O limite prático da rotina é a capacidade de investigação dos resultados. Executar duzentos testes por semana sem gente para classificar e endereçar os estados intermediários produz índice inchado e confiança falsa, e por isso o tamanho da lista priorizada acompanha a capacidade de engenharia, com as técnicas excedentes em fila explícita e não em silêncio.

7. Erros Comuns e Pontos de Atenção

• Executar atomics em produção sem autorização formal e sem avisar o SOC, tratando teste curto como inofensivo; todo teste gera alerta real, e a janela precisa estar acordada.
• Ignorar o CheckPrereqs e julgar a regra de detecção com base em um teste que falhou por dependência ausente; pré-requisito é parte do protocolo, não opcional.
• Esquecer o cleanup e acumular tarefas agendadas, chaves de registro e arquivos de teste no host; a limpeza é obrigatória e deve ser verificada, não presumida.
• Copiar comandos do YAML para execução manual sem registrar a proveniência, quebrando a reprodutibilidade; o valor está em executar o teste versionado, não uma variação ad hoc.
• Atualizar o catálogo no meio de uma rodada de validação, mudando o comportamento dos testes sob avaliação; atualize em janela própria e revalide as técnicas afetadas.
• Medir cobertura apenas das técnicas que têm atomic, tratando a ausência de teste como ausência de risco; o catálogo é amplo, mas não cobre a matriz inteira, e o gap de teste deve ser declarado.
• Tratar o resultado de bloqueio do EDR como falha do teste; o bloqueio com alerta é o melhor desfecho de validação possível, e o registro correto na ficha evita a reexecução inútil do mesmo teste na busca de execução completa.

8. Integração com o Restante da Biblioteca

Os resultados dos atomics alimentam o mesmo índice de resultados que as operações do Caldera, conforme descrito na nota de medição de cobertura da pasta 03, e as técnicas com resultado só telemetria se tornam requisitos de regra no fluxo de engenharia de detecção do Capítulo 15. Em cloud e contêineres, os atomics correspondentes apoiam as notas de purple teaming da pasta 04 deste capítulo, que descrevem os testes específicos de Azure e Kubernetes. Em OT, o catálogo complementa a extensão do Caldera com testes pontuais de script e execução em hosts de engenharia, sempre em range isolado conforme a nota de cyber range.

Na ponta analítica, o catálogo é a ponte entre a inteligência e a engenharia: quando o ciclo de CTI prioriza um ator cuja cadeia usa T1059.001, o primeiro gesto do purple team é verificar a detecção dessa técnica com o atomic correspondente, e a cadeia completa vem depois, com Caldera ou Temperance. Essa sequência, técnica isolada primeiro e cadeia depois, maximiza o retorno de cada rodada e mantém o programa em movimento contínuo.