03 - SIM.3 - Exercícios de Ataque Purple Team
video: https://youtu.be/... no frontmatter da nota.SIM.3 - Exercícios de Ataque Purple Team
Controle SIM.3 do grupo SIM (Simulação de Ataques), derivado do Capítulo 15 do Framework CTH.
Estrutura exercícios colaborativos entre ataque e defesa para melhorar detecções em tempo real, transformando cada técnica executada em ajuste imediato de regra e de telemetria.
No programa integrado, é o momento em que os resultados de SIM.1 e SIM.2 viram aprendizado aplicado, alimentando os heatmaps do grupo MAP e os indicadores do grupo MET.
1. Contexto e Posicionamento no Framework CTH
O Framework CTH define o exercício purple team como o alinhamento estruturado das capacidades ofensivas e
defensivas da organização, maximizando o aprendizado de ambas as equipes. Testes isolados de red team ou
de blue team produzem insights limitados; a colaboração direta durante o exercício revela lacunas de
detecção em tempo real, permite ajustes imediatos e cria um ciclo de feedback que acelera de forma
significativa a melhoria da postura defensiva.
O diferencial do purple teaming não está em quem executa, mas no que acontece depois da execução. Em um
red team tradicional, o resultado é um relatório entregue semanas depois, quando o contexto dos alertas já
esfriou e as evidências se dispersaram. Em um exercício purple team, cada técnica é executada, avaliada,
ajustada e reexecutada dentro do mesmo ciclo, com as duas equipes em comunicação constante. O controle
exige escopo definido, duração limitada e regras de engajamento claras, exatamente para que o formato não
degenere em apresentação ofensiva sem ganho defensivo.
2. O Que é Purple Teaming
Purple teaming é a colaboração estruturada entre quem emula o adversário e quem defende o ambiente, com o
objetivo explícito de melhorar detecção e resposta, e não de demonstrar habilidade ofensiva ou de produzir
mais um relatório. O nome vem da mistura das cores das duas equipes tradicionais, vermelho e azul, e
descreve bem a dinâmica: as duas funções continuam existindo, mas passam a operar em loop conjunto, com
informação compartilhada em tempo real durante a execução.
Duas precisões evitam confusões recorrentes. Primeiro, purple team não é obrigatoriamente um time
permanente; é um modo de operar que qualquer dupla ofensiva-defensiva pode adotar em ciclos recorrentes.
Segundo, a presença de ferramentas de simulação não configura, por si só, um exercício purple team; uma
plataforma BAS dispara técnicas, mas o exercício só se materializa quando existe alguém observando
telemetria, alguém ajustando a detecção e alguém reexecutando para provar a melhoria. O aprendizado é o
entregável central, e ele precisa ser capturado em documentação estruturada, conforme o formato da seção 5.
3. Estrutura de um Exercício
Um exercício purple team bem conduzido alterna planejamento e ciclos curtos de execução. O planejamento
escolhe as técnicas ATT&CK do escopo, define as regras de engajamento, as janelas, os ativos de teste e os
tempos-alvo de detecção; sem esse contrato, os ciclos perdem direção. A execução, por sua vez, segue o
ciclo de seis etapas da tabela, repetido para cada técnica do escopo.
| Etapa do ciclo | Atividade principal | Saída esperada |
|---|---|---|
| 1. Preparação | Emulador revisa ability ou teste da técnica e confere ambiente | Comando pronto, ambiente limpo, observador avisado |
| 2. Execução | Técnica disparada em host autorizado, com horário registrado | Linha de execução com timestamp inicial e final |
| 3. Verificação | Observador procura telemetria e alertas no SIEM e no EDR | Registro do que apareceu, com regra e horário |
| 4. Ajuste | Engenheiro de detecção corrige regra, consulta ou política | Nova versão da regra publicada no pipeline |
| 5. Reexecução | Técnica reexecutada para provar o efeito do ajuste | Alerta correto dentro do tempo-alvo, ou lacuna documentada |
| 6. Registro | Ficha de resultado preenchida e arquivo no repositório | Documentação esperado versus observado, base para métricas |
A duração dos ciclos deve caber na janela do exercício, tipicamente quinze a trinta minutos por técnica
nos casos simples, e a lista de técnicas por sessão raramente passa de oito, porque a qualidade do ajuste
vale mais do que a quantidade de execuções. Sessões longas cansam os observadores e degradam a rigorosidade
da verificação, produzindo fichas incompletas que inutilizam a métrica do controle SIM.5.
4. Papéis e Responsabilidades
O exercício exige papéis explícitos, mesmo em equipes pequenas; uma mesma pessoa pode acumular papéis, mas
nunca os de emulador e observador, que precisam de independência para que o resultado tenha valor. A tabela
a seguir define os papéis e os perfis usuais, com a responsabilidade central de cada um.
| Papel | Responsabilidade central | Perfil típico |
|---|---|---|
| Emulador (ataque) | Executar as técnicas com fidelidade ao adversário e registrar a saída de cada comando | Red team, engenheiro ofensivo ou analista com domínio de Atomic Red Team e Caldera |
| Observador (defesa) | Monitorar SIEM e EDR em tempo real e reportar telemetria e alertas como aparecem | Analista de SOC com acesso às fontes de dados do escopo |
| Ajustador de detecção | Editar regra, consulta ou política, versionar e republicar a detecção | Engenheiro de detecção ou analista sênior responsável pelo pipeline |
| Facilitador | Cronometrar ciclos, manter o roteiro, registrar decisões e arbitrar discussões | Coordenador do programa CTH ou líder técnico do grupo SIM |
| Observador de negócio (opcional) | Acompanhar impacto em ativos e janelas críticas, autorizar desvios de escopo | Gestor de infraestrutura ou responsável pelo ativo |
A presença do facilitador é frequentemente subestimada e é ela que separa o exercício produtivo da sessão
de demonstração. Sem controle de tempo, as discussões técnicas se estendem, o roteiro morre na segunda
técnica e metade do escopo não é executada. O facilitador também garante que cada ajuste seja registrado
com autor e data, informação indispensável para interpretar a evolução das métricas entre exercícios.
5. Documentação: Detecção Esperada versus Observada
Cada técnica executada gera uma ficha de resultado com o que se esperava e o que se observou. Essa ficha é
o registro central do exercício, a matéria-prima das métricas e a prova de melhoria entre rodadas. O
template a seguir ilustra o formato mínimo recomendado.
ficha_purple:
exercicio: purple-2025-03
tecnica: T1053.005
nome: Scheduled Task-Job
execucao: schtasks /create /tn "At1" /tr "cmd.exe /c calc.exe" /sc once
origem: operação Caldera de 12/03 (SIM.2)
deteccao_esperada:
regra_id: DET-0142
alerta: criação de tarefa agendada por processo fora da allowlist
fonte: Sysmon EventID 1 e Windows EventID 4698
tempo_alvo: 10 minutos
deteccao_observada:
telemetria: presente
alerta_gerado: sim
alerta_correto: sim
tempo_deteccao: 4 minutos
falsos_positivos_laterais: 2 alertas benignos no mesmo dia
ajuste_aplicado: exigir processo pai fora da allowlist padrão de TI
reexecucao: 12/03, segunda passada, aprovada
resultado: cobertura testada
responsaveis: emulador 1, observador 2, ajustador 1
Três campos merecem disciplina especial. O campo de detecção esperada deve ser preenchido antes da
execução, porque declarar a expectativa depois de ver o alerta destrói a honestidade do registro. O campo
de falsos positivos laterais captura o custo do ajuste em alertas benignos, informação que o ajustador
precisa para calibrar sem sufocar o SOC. E o campo de resultado deve usar o vocabulário de níveis da
seção 6, para que as fichas sejam somáveis entre exercícios.
6. Critérios de Sucesso por Técnica
O resultado de cada técnica é classificado em quatro níveis crescentes, e a graduação evita o "detectado"
genérico que não diz se o alerta era o certo, no tempo certo. A ficha do exercício registra o nível
alcançado, e não apenas a presença ou a ausência de alerta.
| Nível | Critério | Pergunta-chave | Evidência exigida |
|---|---|---|---|
| 1 | Gera telemetria | O evento bruto chegou ao SIEM com os campos obrigatórios populados? | Evento indexado com processo, usuário e host |
| 2 | Gera alerta | Alguma regra disparou a partir dessa telemetria? | Identificador da regra e alerta vinculado ao horário do teste |
| 3 | Gera alerta correto | O alerta descreve a técnica executada, sem contexto equivocado? | Correspondência entre regra e técnica revisada por duas pessoas |
| 4 | Gera alerta a tempo | O alerta chegou dentro do tempo-alvo definido no planejamento? | Diferença entre timestamp do evento e do alerta |
A escala também orienta a prioridade do trabalho de ajuste. Uma técnica que falha no nível 1 é problema de
coleta, e vai para o grupo DAT; uma que falha no nível 2 precisa de regra nova ou corrigida, e vai para o
pipeline do AUT.3; uma que falha nos níveis 3 e 4 exige refino semântico ou arquitetural da detecção, com
atenção especial a falsos positivos. Registrar apenas detectado ou não detectado, sem o nível, esconde
exatamente a informação que o exercício produziu.
7. Cadência e Temas por Rodada
A cadência recomendada é mensal, em sessões de duas a quatro horas, ou por sprint de detecção, de modo que
o exercício acompanhe o ritmo natural de entrega de regras do time de engenharia. O mínimo aceitável pelo
controle é um exercício por trimestre com escopo e regras de engajamento documentados (SIM.3.1), mas a
prática de mercado madura situa o purple teaming no mesmo trem das releases de detecção: o que muda de
detecção precisa ser retestado, e o exercício é o palco natural desse reteste.
Tematizar cada rodada aumenta o valor do exercício, porque concentra preparação e permite medir evolução
dentro de uma tática. A rotação também distribui o esforço de estudo entre os analistas, que chegam à
sessão conhecendo o tema. A tabela ilustra uma rotação semestral possível.
| Rodada | Tema | Exemplo de foco técnico |
|---|---|---|
| Mês 1 | Persistência | Tarefas agendadas, chaves de Run, contas criadas |
| Mês 2 | Defesa Evasion | Desabilitação de proteções, ofuscação de scripts, T1562 |
| Mês 3 | Acesso a credenciais | Dump de LSASS, extração de browsers, T1003 |
| Mês 4 | Movimento lateral | Serviços remotos, WMI, administração compartilhada |
| Mês 5 | Comando e controle | Beaconing HTTPS, DNS tunneling, T1071 |
| Mês 6 | Revisão | Reexecução das técnicas que falharam nos meses anteriores |
8. Dos Resultados aos Controles MAP.x e MET.x
Os resultados das fichas se consolidam em duas direções. Para o grupo MAP, cada ficha atualiza o estado de
cobertura da técnica executada: MAP.2 recebe o heatmap por tática com os níveis da seção 6, e MAP.4 recebe
as lacunas priorizadas, cruzadas com os atores de ameaça relevantes. Uma técnica em nível 1, por exemplo,
alimenta o mapa de visibilidade; uma em nível 4 prova detecção testada; a diferença entre esses estados é
exatamente o que o mapa precisa retratar com honestidade.
Para o grupo MET, o exercício produz indicadores comparáveis ao longo do tempo, como previsto em SIM.3.4:
taxa de detecção por tática ATT&CK, tempo médio entre execução e alerta, número de técnicas sem cobertura
e evolução desses números entre exercícios consecutivos. Esses indicadores alimentam MET.2 e MET.5, e
permitem demonstrar à liderança que o programa melhora de rodada para rodada, com evidência de cada ajuste
aplicado e revalidado.
9. Implementação Prática e Salvaguardas por Nível
O Framework CTH define salvaguardas progressivas para o exercício purple team, que orientam a maturação do
formato. A tabela apresenta cada salvaguarda com sua descrição e a prática de mercado correspondente.
| Nível | Salvaguarda | Descrição e prática de mercado |
|---|---|---|
| Básico | SIM.3.1 | Realizar pelo menos um exercício purple team por trimestre, com escopo definido, objetivos claros, regras de engajamento documentadas e cronograma acordado entre as equipes |
| Básico | SIM.3.2 | Documentar sistematicamente os resultados de cada exercício: técnicas executadas, detectadas, tempo de detecção, não detectadas, ações de resposta e lições de ambas as equipes |
| Intermediário | SIM.3.3 | Adotar formato progressivo, em que a equipe azul ajusta detecções em tempo real após cada técnica e a técnica é reexecutada para validar o ajuste |
| Intermediário | SIM.3.4 | Medir e comparar a melhoria de cobertura entre exercícios consecutivos, usando taxa de detecção por tática, tempo médio de detecção e número de técnicas sem cobertura |
| Avançado | SIM.3.5 | Integrar os resultados a um programa contínuo de melhoria, em que cada lacuna gera automaticamente tarefa de desenvolvimento de detecção, priorizada por risco e acompanhada até a resolução |
10. Erros Comuns e Pontos de Atenção
- Exercício que vira show de red team: quando o objetivo se desloca para demonstrar ataques impressionantes,
os ciclos de ajuste e reexecução desaparecem e o ganho defensivo cai a zero; o roteiro e o facilitador
existem para impedir esse desvio. - Ajuste sem reexecução: regra alterada e não retestada é hipótese, não melhoria; a reexecução no mesmo
ciclo é o que converte ajuste em evidência. - Documentação tardia: fichas preenchidas dias depois perdem horários, regras e contexto; o registro é
etapa do ciclo, não tarefa administrativa posterior. - Emulador e observador na mesma pessoa: a independência entre quem executa e quem observa é o que dá
valor ao resultado; a acumulação elimina o teste real da detecção. - Falta de notificação aos plantões: alertas gerados durante o exercício chegam ao SOC como possíveis
incidentes reais, e sem aviso prévio o custo é triagem desperdiçada e confiança corroída.
11. Integração com Outros Controles do Framework CTH
O exercício purple team é o consumidor natural dos cenários de SIM.1 e das operações de SIM.2, que
fornecem técnicas prontas e reprodutíveis, e do catálogo de testes de SIM.4, que supre as execuções
pontuais. Seus resultados alimentam SIM.5 com os níveis de cobertura por técnica, MAP.2 e MAP.4 com os
heatmaps e as lacunas priorizadas, e AUT.3 com as regras novas e refinadas que saem dos ciclos de ajuste.
Na direção da inteligência, o grupo ANA fornece as TTPs dos atores prioritários que definem os temas das
rodadas, e o grupo HNT recebe técnicas fracamente detectadas como matérias-prima para hipóteses de
hunting. O grupo IR aproveita o tempo de detecção medido para calibrar expectativas de resposta, e o
grupo MET consolida a evolução entre exercícios como indicador executivo. O GOV, por fim, usa o histórico
de exercícios como evidência de diligência e de aprendizado organizacional contínuo.