BAS (Breach and Attack Simulation)

Nota isolada do capítulo 14, dedicada à simulação contínua de ataques para validar controles sob a ótica do adversário.
O BAS fecha o ciclo threat-informed: a CTI descreve os TTPs do ator, o BAS executa esses TTPs de forma controlada, a detecção prova se funciona.
Dialoga com as notas de ATT&CK do capítulo 04, com o capítulo 08 (técnicas de hunting por TTP) e com os controles SIM.1 a SIM.5 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Todos os capítulos anteriores desta biblioteca constroem capacidades: coleta de telemetria, produção de inteligência, caça, detecção. O BAS (Breach and Attack Simulation) é o capítulo que prova que essas capacidades funcionam, executando de forma contínua e controlada as ações que um adversário real executaria, e medindo se controles preventivos bloquearam e controles de detecção viram. Sem essa prova, a cobertura de detecção é uma afirmação; com ela, é uma medida com data, dono e tendência.

A nota é isolada no capítulo 14 por ser transversal: consome inteligência do começo da biblioteca e devolve resultado para praticamente todos os grupos de controle. No Framework CTH do capítulo 15, o BAS materializa o grupo SIM por inteiro: SIM.1 para plataformas gerenciadas, SIM.2 para emulação com Caldera, SIM.3 para exercícios purple team, SIM.4 para teste de detecção de IOCs e IOAs e SIM.5 para medição de cobertura. O leitor pode tratar esta nota como o manual técnico do grupo SIM.

2. Definição e Diferenças para Pentest e Red Team

BAS é a prática de simular continuamente técnicas e campanhas adversárias conhecidas, de forma automatizada e com escopo declarado, para medir a efetividade de controles de segurança contra elas. A simulação usa os mesmos TTPs catalogados no MITRE ATT&CK, executados em janelas agendadas, sobre alvos autorizados, com carga controlada e reversão previsível. A saída primária não é o relatório narrativo, mas a matriz de resultado: técnica executada, bloqueada ou detectada, por control, por tempo.

A fronteira com as práticas próximas é de objetivo e de cadência, e a tabela abaixo fixa essa distinção:

As três práticas são complementares e não concorrentes. O pentest encontra o que ninguém mapeou; o red team prova a resposta humana e de processo sob pressão; o BAS mantém a régua de cobrança entre os dois, garantindo que o que já foi descoberto ou emulado não regredisse silenciosamente. A analogia útil é a de engenharia de software: pentest é a auditoria, red team é o teste de caos, BAS é a suíte de regressão contínua da segurança.

A posição organizacional também difere: o BAS costuma ser operado pela engenharia de segurança com governança do CISO, enquanto pentest e red team são exercícios contratados ou internos de escopo pontual. Essa diferença de dono define a diferença de produto: o BAS reporta no mesmo painel todos os meses, com comparabilidade entre ciclos, e essa continuidade é justamente o que permite medir regressão e melhoria ao longo do tempo.

3. Capacidades: Simulação Contínua, Validação de Controles e Cobertura ATT&CK

Três capacidades definem uma plataforma de BAS madura. A simulação contínua executa cenários em janelas recorrentes, de modo que a degradação de um controle, um agente desinstalado, uma regra desativada, uma política revertida por mudança, apareça no ciclo seguinte sem depender de denúncia. A validação de controles testa cada camada por sua função: e-mail chegou ao usuário, gateway web bloqueou a URL, EDR bloqueou o processo, SIEM gerou o alerta, SOAR orquestrou a resposta. A cobertura ATT&CK organiza tudo em matriz por técnica e tática, com heatmap que o controle MAP.2 do capítulo 15 consome diretamente.

A amplitude de cenários cobre a cadeia de ataque completa, e vale listar as classes que uma suíte madura deve executar: entrega e phishing com anexo e link; execução e download cradle; persistência em registro, serviço e tarefa agendada; escalação e acesso a credenciais, incluindo acesso a LSASS; movimento lateral com protocolos de administração remota; coleta e exfiltração por canais HTTPS e DNS; e ações de impacto típicas de ransomware, execução de cópia de sombra e criptografia simulada em diretório de teste. Cada classe deve ser executável com variantes de evasão, porque controles que só detectam a variante ingênua dão falsa segurança.

A unidade de teste importa tanto quanto o catálogo: o teste atômico, um comando ou pequeno script que executa uma técnica isolada com parâmetros declarados, é o bloco de construção que permite diagnosticar exatamente qual passo falhou. Cenários compostos, que encadeiam dezenas de técnicas, medem a resposta como um todo; os atômicos isolam a causa. A suíte madura mantém os dois níveis, usando os atômicos para diagnosticar e os compostos para medir o ciclo completo, com a mesma disciplina de versionamento que o capítulo 08 aplica às consultas de caça.

4. Plataformas e Ferramentas de Emulação

O mercado divide-se entre plataformas comerciais de BAS e ferramentas open source de emulação e teste. As primeiras trazem catálogo curado, relatórios executivos e mapeamento automático de cobertura; as segundas dão controle total e custo zero de licença, com esforço de engenharia próprio.

A combinação prática recomendada para o leitor desta biblioteca é usar a plataforma comercial quando o orçamento existe e o programa precisa de relatório executivo recorrente, e montar a fundação open source com Caldera como motor de emulação e Atomic Red Team como biblioteca de testes atômicos. O Caldera roda servidor e agentes em laboratório ou em zona autorizada, executa perfis de adversário encadeando abilities, e integra-se com coletores de telemetria, o que o torna compatível com o Velociraptor da nota 07 do capítulo 09 para validação de rastros no endpoint.

A governança dos resultados importa tanto quanto a escolha da ferramenta: os registros de execução, com horário, alvo, técnica e resultado, devem cair no mesmo lugar todas as semanas, e a matriz de resultado deve ser publicada para os times de detecção e de resposta no formato acordado. Ferramenta sem repertório versionado de cenários e sem destino definido para o resultado gera execução sem memória, e execução sem memória não permite medir regressão.

5. Ciclo de Uso: Planejar, Simular, Medir, Corrigir

O BAS só gera valor quando circula num ciclo de quatro fases com dono e cadência. Planejar escolhe as técnicas do ciclo a partir da inteligência: atores relevantes para o negócio, técnicas priorizadas no heatmap do MAP.2, mudanças recentes no ambiente que podem ter quebrado detecção. Simular executa os cenários em janela autorizada, com alvos canário, notificação prévia ao SOC para separar simulado de real e registro de horários de cada passo. Medir compara o registro de execução com a telemetria e os alertas efetivamente gerados, produzindo a matriz de bloqueio, detecção e falha. Corrigir transforma cada falha em ação: regra nova, telemetria nova, controle ativado ou exceção documentada.

Duas regras de disciplina sustentam o ciclo. Primeira: nenhuma simulação sem autorização formal e sem janela declarada, porque simulação não autorizada é indistinguível de ataque e consome a confiança do SOC. Segunda: cada ciclo fecha com revisão dos resultados junto ao time de detecção, no formato purple team do SIM.3, com o objetivo de melhorar a próxima rodada, e não de apontar culpados. O BAS é instrumento de melhoria, e quando é usado como ferramenta de cobrança entre equipes, o time de detecção passa a otimizar métrica, não proteção.

6. Integração com CTI e com Threat Hunting

A integração com CTI é o que diferencia BAS de uma suíte de testes genérica: o catálogo de cenários deve ser priorizado pelos atores que ameaçam de fato a organização, conforme o perfil de ameaças do capítulo 01 e o mapeamento do MAP.3. Se o painel de inteligência aponta ransomware do tipo LockBit como ameaça dominante e phishing como vetor inicial recorrente, o ciclo do BAS deve emular as técnicas observadas nesses casos, e não técnicas aleatórias do catálogo. O fluxo inverso também existe: técnicas simuladas que nunca geram detecção viram requisito de inteligência, entrando como PIR para acompanhar como o ator executa aquela técnica em operações reais.

A integração com threat hunting opera em duas direções. Na validação de telemetria, antes de caçar uma técnica, o hunter dispara a simulação atômica dela em um host canário e confere se o rastro esperado aparece na fonte que usará; se o evento não existe na fonte, a caça por aquela hipótese naquela fonte é inútil, e o trabalho correto é pedir a telemetria ao DAT.1. Na medição de lacuna, a simulação é executada contra o parque real e o hunter consulta onde o rastro apareceu; hosts onde o rastro deveria estar e não está são candidatos a agente quebrado, versão antiga ou cobertura falsa, achado que o caça transforma em ação de higiene de telemetria. A nota 07 do capítulo 09 fornece os artifacts para essa conferência de rastro em escala.

A conferência de rastro pode ser automatizada com o mesmo artifact do Velociraptor em todas as rodadas do ciclo, o que transforma checagem manual em regressão executável. O exemplo abaixo consulta o histórico de execução do host canário após a simulação da seção 8, procurando os utilitários que o perfil de adversário emprega:

SELECT Name, LastRunTimes, RunCount
FROM Artifact.Windows.Timeline.Prefetch()
WHERE Name =~ "(?i)(rundll32|comsvcs|powershell|vssadmin)"
  AND LastRunTimes > timestamp(string="2024-04-02T14:00:00Z")

7. Métricas

A medição é o produto central do BAS, e as métricas abaixo formam o painel mínimo do ciclo, alinhado ao SIM.5 e ao grupo MET do capítulo 15:

Duas regras de honestidade analítica completam o painel. Cobertura simulada não é cobertura real: técnica executada com variante ingênua prova pouco sobre adversário sofisticado, e o painel deve registrar a variante usada. E taxa de detecção precisa ser medida por técnica e por fonte, porque a média esconde o que importa: o foco está nas técnicas críticas dos atores prioritários, onde a meta é alta, e não na média global que flerta com números bonitos.

O custo de entrada não precisa ser o impedimento. A fundação open source com Caldera, Atomic Red Team e um host canário gerenciado pelo Velociraptor entrega o ciclo completo de planejar, simular, medir e corrigir com custo de engenharia apenas, e a plataforma comercial entra quando o programa precisa de escala de catálogo, de relatórios executivos recorrentes e de suporte contratual. O erro é inverso também: comprar plataforma sem dono do ciclo, sem alvos autorizados e sem integração com o heatmap de cobertura converte licença caríssima em demonstração permanente.

8. Exemplo de Fluxo de Ciclo BAS Mensal

O calendário abaixo descreve um ciclo mensal maduro para um time de segurança com SOC dedicado, e serve como ponto de partida adaptável:

O esqueleto abaixo ilustra o perfil de adversário usado na semana 2, em formato adaptado do Caldera, encadeando três técnicas típicas de ator de ransomware sobre um host canário com telemetria Sysmon e EDR ativa:

perfil: bas-mensal-credenciais
descricao: Emulacao das tecnicas centrais de um ator de ransomware
objetivo: validar bloqueio e deteccao em T1059.001, T1003.001 e T1055
alvo: host-canario-lab
janela: terca, 14h00 a 16h00, aprovada pelo SOC
fases:
  1:
    tecnica: T1059.001
    descricao: PowerShell com download cradle ofuscado em base64
  2:
    tecnica: T1003.001
    descricao: acesso a memoria do LSASS via comsvcs.dll
  3:
    tecnica: T1055
    descricao: injecao de processo com utilitario de laboratorio autorizado

A validação do lado da detecção usa consulta sobre a telemetria do endpoint, e o exemplo abaixo procura o rastro do dump de LSASS via comsvcs.dll, técnica que os controles costumam deixar passar porque o binário é assinado pela Microsoft:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "rundll32.exe"
| where ProcessCommandLine has "comsvcs.dll"
  and ProcessCommandLine has_any ("MiniDump", "24")
| project Timestamp, DeviceName, InitiatingProcessAccountName, ProcessCommandLine

O ciclo fecha quando cada linha da matriz de resultado tem desfecho: técnica bloqueada fica no catálogo como regressão a vigiar, técnica detectada alimenta o heatmap do MAP.2, técnica nem bloqueada nem detectada vira história de usuário para o time de detecção, e técnica sem telemetria vira requisito para o DAT.1.

9. Erros Comuns e Pontos de Atenção

O erro mais frequente é executar BAS como projeto pontual, anualmente ou por pressão de auditoria, e apresentar o resultado como cobertura do ambiente; simulação anual prova apenas o dia em que rodou. O segundo é simular sem notificar o SOC e depois comemorar a detecção de algo que o SOC já sabia que viria, ou pior, não notificar e consumir horas de triagem real; a notificação prévia é obrigatória e documentada. O terceiro é rodar cenários de impacto real, como criptografia ou deleção, sem diretório de teste isolado e sem limites técnicos de execução, transformando simulação em incidente.

Na análise de resultados, dois vieses dominam. O viés de otimismo mede apenas o que a plataforma executa bem, ignorando variantes de evasão que o adversário real usaria, e o correto é sempre executar a variante mais difícil que os controles deveriam aguentar. O viés de métrica leva o time de detecção a criar regras que alertam só para o payload de teste, por assinatura de comando exata; a defesa é o backtest contra variantes e a exigência de que a detecção valide comportamento, não o comando de exemplo do catálogo.

O desenho do escopo merece o mesmo rigor do teste. Simulações de movimento lateral nunca atravessam limites de produção, técnicas de impacto rodam apenas sobre dados sintéticos em diretórios dedicados, e credenciais usadas nas simulações são contas de laboratório com trilha audível, nunca contas reais de serviço. Cada uma dessas restrições deve estar no documento de autorização do ciclo, assinado pelas áreas de segurança e de TI, com contatos de aborto definidos para efeitos colaterais.

10. Integração com o Restante da Biblioteca

Esta nota executa a prova das capacidades construídas em todos os capítulos anteriores: a inteligência do capítulo 01 prioriza as técnicas simuladas, o ATT&CK do capítulo 04 organiza a matriz de cobertura, a telemetria do capítulo 02 e as ferramentas do capítulo 09 fornecem os rastros a validar, e o hunting do capítulo 07 usa a simulação como método de verificação de hipótese sobre a presença de telemetria. No capítulo 15, o grupo SIM inteiro depende desta nota como execução técnica, e os grupos MET e MAP consomem seu painel de cobertura.

O hábito que o leitor deve consolidar é o de tratar detecção como código sujeito a regressão: toda regra nova entra no catálogo de simulação, todo ciclo mensal reexecuta o catálogo, e toda mudança de ambiente entra no plano da semana 1. Com esse hábito, a biblioteca fecha seu argumento central: inteligência orienta o que simular, simulação prova o que funciona, e o ciclo CTI, hunting e BAS se realimenta continuamente, reduzindo dwell time com evidência e não com suposição.