Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue

Purple Team nao e workshop trimestral com pizza e slides bonitos, e um ritmo de engenharia onde cada TTP executado pelo Red vira hipotese de deteccao para o Blue em menos de 72 horas. Na Basilisk OffSec rodamos sprints de duas semanas: 10 tecnicas selecionadas do ATT&CK, execucao controlada em lab corporativo, e fechamento com regra Sigma em producao. O KPI nao e quantos shells o Red pegou, e sim quantas tecnicas passaram de 'nao detectado' para 'alertado com baixo falso positivo'. Quem nao mede esse delta esta fazendo teatro de seguranca caro. Este guia decompoe o ciclo em passos reproduziveis, ferramentas concretas e metricas que sobrevivem a uma revisao de diretoria.

O que Purple Team significa de verdade

Rodar Red e Blue isolados produz duas verdades: atacantes que escrevem relatorios que ninguem converte em deteccao, e defensores que constroem regras que nenhum adversario real dispara. Purple Team apaga a fronteira amarrando os dois lados a mesma linha do tempo e ao mesmo artefato. E uma funcao, nao um quadro fixo: as mesmas pessoas trocam de papel a cada exercicio. O objetivo operacional e colapsar o ciclo de feedback de meses para dias. Um ciclo maduro produz ao menos uma deteccao versionada por sprint, um playbook de resposta linkado e uma queda medida do tempo medio de deteccao para a tecnica praticada. Todo o resto e preparacao.

Priorizar tecnicas por threat intel real

O ponto de partida e um catalogo de tecnicas priorizado por threat intel real, nao por moda de conferencia. Pegamos relatorios recentes (Mandiant M-Trends, CrowdStrike OverWatch, CERT.br) e cruzamos com a matriz ATT&CK Enterprise v15. Para uma operacao financeira, por exemplo, T1078.004 (cloud accounts), T1558.003 (Kerberoasting) e T1059.001 (PowerShell) ficam no topo. A priorizacao segue tres eixos: probabilidade contra nosso perfil setorial, raio de impacto em caso de sucesso, e lacuna de deteccao atual segundo o ATT&CK Navigator. As tecnicas que ja detectamos com confianca descem na lista; as celulas escuras do heatmap definem o sprint. Assim o exercicio fica ancorado em risco mensuravel em vez de curiosidade pessoal.

O contrato escrito entre Red e Blue

Antes de executar, o Red documenta o procedimento exato e o Blue desenha qual telemetria deveria capturar cada passo. Esse contrato escrito evita o classico 'a gente nao viu porque o Splunk nao estava ingestionando aquele indice'. O contrato nomeia, por tecnica: fonte de dados esperada (Sysmon Event ID 1, 4688, 4104, um log do Zeek), campo esperado e ruido de base. Se a fonte de dados falta, isso ja e um achado antes do primeiro payload. Esse ensaio a seco revela com frequencia um sensor implantado mas nao coletado, ou o PowerShell Script Block Logging desligado. Esses pontos cegos exatos sao os que salvam um incidente real mais adiante.

Execucao controlada dentro da janela

A execucao acontece em janela combinada, com flag de exercicio nos logs e canal Slack #purple-live aberto. Cada acao do Red recebe timestamp UTC, hostname alvo e hash do binario usado. Quando rodamos Kerberoasting via Rubeus, o operador anota o ticket exato extraido e a conta de servico alvo. Em paralelo, o analista do SOC tenta detectar em tempo real sem saber qual passo vem a seguir, simulando o cenario real. Se detectou em quatro minutos, marcamos verde. Se passou batido, vira ticket no Jira com prioridade definida pela criticidade do ativo tocado. Rodamos deliberadamente com OPSEC desativado (flags barulhentos, named pipes padrao) para que o Blue consiga ver os artefatos.

Do achado a regra duradoura

Pos-execucao, o trabalho duro comeca: transformar um achado em regra duradoura. Convertemos hipoteses primeiro em Sigma como fonte de verdade neutra, depois em EQL no Elastic e KQL no Sentinel. Uma regra so e mergeada em main se atender tres criterios: cobre a tecnica do exercicio, gera menos de 5 falsos positivos por semana em homologacao, e tem playbook de resposta linkado. Tecnicas de evasao forcam o time a sair de assinatura e ir para deteccao comportamental, olhando chamadas a NtAllocateVirtualMemory, padroes parent-child anomalos e acesso a handles do LSASS. Uma regra sem caso de teste que a dispare de forma comprovavel e considerada inacabada.

Infraestrutura de exercicio auditavel

Infra do exercicio precisa ser auditavel. O C2 roda em VLAN isolada com captura PCAP completa, e o trafego e replicado para o SIEM de homologacao via port mirror. A movimentacao lateral segue um playbook fixo com Impacket e Evil-WinRM, sempre com flags barulhentos para que o Blue veja os artefatos. O pivoting interno usa Chisel ou Ligolo-ng sobre tuneis bem documentados. Tudo logado em um repo Git privado: cada commit do Red e referenciado pelo PR de regra do Blue, criando rastreabilidade que auditoria adora e gerente ama mostrar pro board. Snapshots das VMs antes e depois do exercicio permitem repeticao limpa quando uma regra precisa de ajuste.

Metricas e linguagem comum

Comunicacao mata mais programas de Purple Team do que falta de ferramenta. Estabelecemos vocabulario comum: 'detectado' significa alerta gerado e triado, nao apenas log presente em algum indice frio. As retros duram 60 minutos com tres slides: tecnicas executadas, deteccoes criadas, divida tecnica aberta. Metricas que acompanhamos: MTTD por categoria ATT&CK, percentual de cobertura de Tactics no ambiente, e numero de regras com FP acima do threshold. Em seis meses, um cliente saiu de 23% de cobertura em Credential Access para 71%, com queda de 40% em alertas ruidosos. Esses numeros sao a linguagem que libera orcamento.

Armadilhas comuns

A primeira armadilha e a competicao: assim que o Red quer 'ganhar', ele para de jogar barulhento e o Blue nao aprende nada. A segunda e a regra sem playbook que dispara as 3 da manha e nao guia ninguem a agir. A terceira e a regra nunca testada em homologacao que produz 200 falsos positivos por dia em producao e e silenciada em uma semana. A quarta e a ausencia de versionamento: uma deteccao que vive so na cabeca de um analista some com ele. A quinta e pular o ensaio a seco, de modo que a telemetria faltante so aparece no meio da execucao e explode o sprint.

Checklist pratico

Antes do sprint: escolha cinco tecnicas relevantes para seu setor, feche contrato escrito com o SOC, verifique fontes de dados por tecnica. Durante o sprint: execute na janela com flag de exercicio e logging completo, anote cada acao com timestamp e hash, marque deteccoes ao vivo no #purple-live. Depois do sprint: escreva a regra Sigma, traduza para EQL e KQL, teste em homologacao contra o limiar de FP, linke o playbook de resposta, mergeie no Git, meca o MTTD. Nenhum sprint conta como pronto sem um unico artefato versionado. Esse artefato e exatamente o que separa deteccao continua de entretenimento pontual.

Papeis, rotacao e psicologia

Purple Team so funciona quando os papeis rotacionam e ninguem ocupa um assento permanente de vencedor. Na pratica, um analista que jogou Blue por tres sprints muda de proposito para o lado Red para sentir o quao frageis sao suas proprias deteccoes sob uma variacao leve. Essa rotacao constroi empatia e dissolve a mentalidade de silo onde o Red acha os defensores lentos e o Blue acha os atacantes exibidos. O facilitador, muitas vezes um detection engineer, mantem o exercicio honesto: sem momentos gotcha, sem payloads escondidos, sem pisar em cima na retro. Quando uma tecnica passa, isso e uma lacuna sistemica de telemetria, nao uma falha pessoal do analista. Essa cultura exata decide se o programa segue vivo apos o terceiro sprint ou sufoca em culpa mutua. Um board financia maturacao mensuravel, nao uma briga de lama entre dois times. Trate a relacao como um unico time com dois chapeus e os numeros vem sozinhos.

Automacao com Atomic Red Team e CI

Uma vez que o ciclo manual esta solido, automatizamos a regressao. Atomic Red Team entrega testes atomicos descritos em YAML por tecnica ATT&CK que rodam num pipeline contra uma VM descartavel. Apos cada atualizacao de conteudo do SIEM, disparamos de novo os atomics relevantes e verificamos se a regra Sigma associada ainda dispara; se quebra, o build falha, exatamente como um unit test. Isso previne o detection drift, onde uma regra que funcionava fica silenciosa porque um campo foi renomeado no schema de logs. Os resultados ficam como relatorio de cobertura no mesmo repo Git, versionados ao lado das regras. O limite importa: a automacao nao substitui a hipotese humana, so protege o que ja foi conquistado. Tecnicas novas continuam nascendo de threat intel e emulacao manual; o CI so garante que nenhuma deteccao existente se degrade sem ser notada enquanto o ambiente segue evoluindo por baixo.

FAQ: Com que frequencia rodar um ciclo de Purple Team?

Sprints de duas semanas sao o ponto ideal para a maioria dos times: curtos o suficiente para manter o ritmo, longos o suficiente para de fato endurecer uma regra ate producao. Semanal queima o time e entrega deteccoes pela metade; mensal deixa o ciclo de feedback perder o corte. Cinco a dez tecnicas por sprint e realista quando cada uma termina em uma regra versionada.

FAQ: Precisa de ferramenta cara para Purple Team?

Nao. Sysmon com configuracao endurecida, o stack ELK ou Wazuh, Atomic Red Team para a execucao e Sigma para regras portateis bastam para um ciclo completo com custo zero de licenca. O gargalo nunca e a ferramenta, e a disciplina de fechar o ciclo e transformar cada tecnica em um artefato versionado.

Conclusao

Takeaway pratico: comece pequeno e mensuravel. Escolha cinco tecnicas relevantes para seu setor, defina contrato escrito com o SOC, execute em janela curta com logs completos, e nao feche o sprint sem regra Sigma versionada no Git. Purple Team que nao deixa artefato versionado para tras nao escalou, apenas entreteve. O ciclo Red-cria-hipotese, Blue-valida-telemetria, Time-merge-regra-em-producao precisa caber em duas semanas. Se demora mais, voce esta gerenciando projeto, nao operando deteccao continua. Repita o ciclo ate as celulas escuras do heatmap ATT&CK virarem cobertura medida.