Caçando gaps de detecção: testando meu SIEM com Atomic Red Team

Depois de montar um SIEM (Wazuh) integrado com Sysmon numa máquina Windows de laboratório, a pergunta óbvia era: ele realmente detecta alguma coisa, ou só está bonito no dashboard?

A única forma honesta de responder isso é atacar o próprio ambiente de propósito. Usei o Atomic Red Team, um framework open-source com implementações pequenas e isoladas de técnicas reais do MITRE ATT&CK, pra simular comportamento malicioso de forma controlada.

Teste 1: dump de credenciais (T1003.001)

Primeira tentativa: extrair a memória do processo lsass.exe usando comsvcs.dll — uma técnica clássica de roubo de credenciais que não depende de nenhuma ferramenta externa, só binários nativos do Windows.

rundll32.exe comsvcs.dll, MiniDump <PID_do_lsass> dump.dmp full

Resultado: bloqueado antes mesmo de executar, pelo AMSI (Antimalware Scan Interface) do Windows Defender. A defesa nativa reconheceu o padrão do script e recusou rodar.

Isso já é um dado interessante por si só: uma camada de defesa (endpoint) barrou o ataque antes que o SIEM (camada de detecção) precisasse fazer qualquer coisa. Bom lembrete de que segurança em profundidade funciona — nem tudo depende do SIEM pegar.

Teste 2: persistência via tarefa agendada (T1053.005)

Segunda tentativa: criar uma tarefa agendada pra execução futura, técnica comum de persistência usada por praticamente qualquer malware que queira sobreviver a um reboot.

schtasks /create /sc once /tn <nome> /tr <comando> /st <horário>

Esse completou sem bloqueio. E o Sysmon capturou tudo: o processo schtasks.exe, a linha de comando completa, o processo pai, o usuário, hash do binário.

Aqui está o gap: o evento foi capturado e gerou alerta, mas a regra que disparou foi uma genérica de “execução suspeita de shell” (nível de severidade baixo), não uma regra específica reconhecendo “criação de tarefa agendada como técnica de persistência” (que deveria ter severidade mais alta, dado o contexto de MITRE ATT&CK).

Ou seja: o SIEM viu o evento, mas não entendeu a gravidade dele. Isso é exatamente o tipo de lacuna que só aparece testando de verdade — não teria como descobrir isso só lendo documentação.

Bônus: um falso positivo no meio do caminho

Durante os testes, um alerta de severidade crítica disparou: “arquivo executável derrubado em pasta comumente usada por malware”. Motivo? O próprio PowerShell, ao iniciar, cria um arquivo temporário (__PSScriptPolicyTest_*.ps1) pra testar a política de execução de scripts do sistema — comportamento normal e documentado, não malicioso.

A regra que disparou é ampla demais: qualquer .ps1 novo na pasta temp = alerta crítico, sem exceção pro padrão de nome desse arquivo específico do PowerShell.

Investigar isso, confirmar que era comportamento legítimo, e não simplesmente silenciar o alerta sem entender por que ele disparou — isso é o trabalho real de triagem que faz parte do dia a dia de qualquer analista.