Adversary Emulation com Caldera e MITRE ATT&CK em Lab Corporativo
Como a Basilisk usa Caldera, Atomic Red Team e MITRE ATT&CK para simular TTPs reais em lab fechado e medir a maturidade do SOC sem destruir produção.
Quando o cliente liga dizendo que comprou um EDR top de linha e quer saber se 'está bom', a resposta honesta nunca é um relatório de PowerPoint. É uma operação de adversary emulation com cenário escrito, ATT&CK mapeado e métricas frias: quantos passos passaram silenciosos, quantos viraram alerta, quantos viraram resposta humana em até 60 minutos. Na Basilisk OffSec a gente padronizou isso em volta de Caldera 5.x, Atomic Red Team e um lab de domínio Windows com 8 hosts, replicando o ambiente do cliente sem nunca tocar a produção dele. Esse texto descreve a pilha, o fluxo e os erros que cobramos caro para não cometer de novo.
O lab base é simples e replicável: um Windows Server 2022 como DC, dois Server 2019 (file e SQL), três Windows 11 Enterprise como estações com Defender for Endpoint em modo bloqueio, e dois Ubuntu 24.04 com auditd e Wazuh agent. Tudo orquestrado em Proxmox via Terraform, com snapshots nomeados por fase do cenário. Para quem está montando o cenário Windows do zero recomendamos começar pelo Active Directory Pentest: Kerberoasting Passo a Passo em Lab GOAD, que já entrega ACLs propositalmente bagunçadas, e depois acoplar o pivoting descrito em [[pivoting-chisel-ligolo-rede-pentest]] para segmentar VLANs. Sem segmentação realista, qualquer métrica de detecção de lateral movement fica viciada.
Caldera entra como cérebro da operação. Subimos o servidor em um Debian isolado, carregamos os plugins 'atomic', 'stockpile' e o nosso fork interno 'basilisk-ttps' (com TTPs brasileiras como abuso de RustDesk e AnyDesk em PMEs). Cada adversário em Caldera é um arquivo YAML que cita técnicas ATT&CK por ID: T1059.001 para PowerShell, T1021.006 para WinRM, T1003.001 para LSASS dump. Não rodamos adversários prontos sem revisão; eles são úteis para benchmark, mas o valor está em escrever cenários que reproduzam o threat model do cliente. Um varejo com PDV exposto não merece o mesmo adversary de uma fintech com Azure AD federado.
A execução segue um ciclo de quatro fases que aprendemos a respeitar. Primeiro initial access simulado em endpoint controlado, geralmente seguindo o playbook de Initial Access Simulado: Macros, LNK e ISO em Lab Windows 11 Isolado com payload assinado por CA interna. Segundo, execução e descoberta com técnicas pesadas em LOLBins, e aqui o material de Hunting de Living-off-the-Land Binaries no Windows com KQL ajuda o blue team a montar consultas KQL antes do exercício. Terceiro, lateral movement por SMB e WinRM aproveitando contas de serviço fracas. Quarto, ações no objetivo, que pode ser exfil de banco SQL ou cifragem simulada de share. Cada fase tem critério de parada claro: se o EDR matar o processo em até 90 segundos, anotamos como detectado e seguimos por outro caminho.
A parte chata, mas decisiva, é a instrumentação do lado azul. Sem telemetria comparável, adversary emulation vira teatro. Plugamos Sysmon com config do Olaf Hartong, encaminhamos para um Elastic 8.14 e aplicamos regras Sigma convertidas, processo que detalhamos em Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao. Marcamos cada evento gerado pelo Caldera com um header customizado x-caldera-op-id, o que permite consultar no Kibana qual técnica gerou quais eventos e em quanto tempo o analista respondeu. Métricas que sempre reportamos: MTTD por técnica, taxa de detecção por tática ATT&CK, e número de regras Sigma novas escritas como consequência do exercício. Sem esses três números, o cliente acha que comprou pentest e fica frustrado.
Tem armadilha ética e operacional que vale citar. Adversary emulation não é desculpa para rodar evasão de EDR em produção alheia; tudo o que envolve direct syscalls ou patching de AMSI fica restrito ao lab, e quem quiser entender por que reforçamos isso pode ler Evasao de EDR para Pesquisa: Direct Syscalls Explicados sem Romantizacao e Bypass de AMSI e ETW para Pesquisa Defensiva: O que Blue Teams Devem Saber. Também não rodamos C2 com infraestrutura compartilhada com clientes; cada operação ganha um teamserver Sliver dedicado conforme Construindo Infra de C2 com Sliver em Lab Isolado para Estudo Defensivo. E, sempre, o relatório final amarra cada TTP a uma contramedida concreta, virando insumo para o ciclo descrito em Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue.
Takeaway prático: comece pequeno. Suba um Caldera, escreva um adversário com cinco técnicas ATT&CK que casem com o threat model real do seu ambiente, rode contra três endpoints monitorados e meça MTTD por técnica. Repita mensalmente trocando uma técnica de cada vez. Em seis meses você terá uma curva de maturidade defensável em diretoria, sem precisar comprar mais nenhuma ferramenta cara, e o SOC vai parar de reclamar que 'nunca acontece nada' nos treinamentos.