Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao

Threat hunting fracassa quando fica no achismo. Um analista busca um hash malicioso, nao acha nada e declara o ambiente limpo, o que so prova que um artefato esta ausente. A equipe Basilisk roda hunting como uma pipeline de engenharia: uma hipotese expressa como regra Sigma portavel, compilada para uma consulta Elastic, validada contra telemetria real, ajustada e entao promovida a uma deteccao permanente. Este texto percorre o caminho completo do indicador a deteccao com regras, consultas e passos de tuning concretos que voce reproduz num lab hoje a noite, e foi construido para parear com uma fonte de emulacao, de modo que voce cace algo real em vez de encarar um indice vazio.

Do indicador a deteccao: a piramide da dor#

A Pyramid of Pain de David Bianco e o modelo mental que faz o hunting valer o esforco. Hashes e IPs ficam embaixo: triviais de trocar para um atacante, entao uma caca baseada neles expira em horas. Dominios e artefatos de rede sao um pouco mais dificeis. No topo estao ferramentas e TTPs, as taticas, tecnicas e procedimentos que um adversario teria de reprojetar para evadir, caro para ele e duravel para voce. Bom hunting mira comportamento, nao indicadores: nao 'ache o hash X' mas 'ache qualquer processo que lance um interpretador de script a partir de um documento do Office e depois faca uma conexao de saida'. Sigma existe justamente para expressar essa logica de comportamento uma vez e roda-la sobre qualquer backend, para que seu trabalho intelectual nao fique preso a uma unica linguagem de consulta.

Anatomia de uma regra Sigma#

Uma regra Sigma e um pequeno documento YAML com esqueleto fixo. O bloco logsource declara a telemetria necessaria, por exemplo product: windows e category: process_creation, que mapeia para Sysmon Event ID 1 ou Windows 4688. O bloco detection guarda uma ou mais selecoes nomeadas e uma condition que as combina com logica booleana. Uma regra LOLBin minima define selection como Image|endswith: '\\certutil.exe' junto com CommandLine|contains: '-urlcache' e entao poe condition: selection. Adicione uma lista falsepositives e um level para a triagem saber como pesar um hit, e marque com a tecnica do ATT&CK que ela cobre. A disciplina que importa: uma regra expressa um comportamento verificavel, com nomes de campo tirados de um schema que voce de fato envia, nao de um print de blog.

Montar o stack Elastic#

Voce precisa de telemetria antes de precisar de regras. Suba Elasticsearch e Kibana, entao inscreva endpoints com o Elastic Agent gerenciado pelo Fleet, enviando as integracoes System e Windows para que criacao de processo, rede e autenticacao caiam em indices normalizados ao Elastic Common Schema (ECS). ECS e a peca-chave: renomeia campos de vendor para nomes estaveis como process.command_line, process.parent.name e destination.ip, para que uma consulta escrita uma vez continue funcionando enquanto as fontes mudam. No Windows, faca deploy do Sysmon com uma configuracao curada (uma config comunitaria mantida e o default sensato) porque o log de auditoria nativo e grosso demais para hunting de comportamento. Verifique a ingestao confirmando que um certutil de teste aparece no Discover com um process.command_line preenchido antes de confiar em qualquer regra.

Compilar Sigma para um backend Elastic#

Sigma e portavel porque um compilador o traduz para o dialeto de cada backend. A toolchain moderna e o sigma-cli dirigindo o pySigma com um plugin por alvo. Instale o plugin de Elasticsearch e rode sigma convert -t elasticsearch -p ecs_windows rules/certutil_urlcache.yml para emitir uma consulta de Elasticsearch, ou mire -t eql para obter a Event Query Language de correlacao entre eventos. Uma pipeline como ecs_windows e o que remapeia os nomes de campo genericos da regra para seus campos ECS, e omiti-la e o motivo mais comum de uma regra convertida devolver zero resultados apesar de um hit real. Para logica de sequencia, o EQL do Elastic expressa 'processo A depois rede B pelo mesmo processo em N segundos', enquanto o mais novo ES|QL e excelente para agregacao exploratoria durante a propria caca.

Uma caca concreta: binarios living-off-the-land#

Atacantes evitam soltar malware abusando de binarios de sistema assinados: certutil para baixar, mshta e rundll32 para executar, regsvr32 para a tecnica Squiblydoo, bitsadmin para transferir. Comece amplo em ES|QL: FROM logs-* | WHERE process.name IN ("certutil.exe","mshta.exe","regsvr32.exe") | STATS count = COUNT(*) BY process.command_line, host.name | SORT count ASC, depois leia as linhas de comando raras, porque uso admin normal e de alto volume e repetitivo enquanto a invocacao do atacante e um outlier solitario. Pivote em cada hit para o processo pai e a conexao de rede seguinte para confirmar a intencao. Os padroes KQL mais profundos por binario, com as baselines benignas a subtrair, estao catalogados em Hunting de Living-off-the-Land Binaries no Windows com KQL.

Hunting guiado por hipotese, mapeado ao ATT&CK#

Nao cace ao acaso; cace uma hipotese atada a uma tecnica. Formule como frase: 'Se um adversario fez Kerberoasting (T1558.003), eu veria um pico de requisicoes TGS com criptografia RC4 de uma unica conta.' Depois expresse isso como regra e teste contra atividade emulada, porque uma caca que voce nao consegue disparar sob demanda e uma caca em que voce nao pode confiar. Gere o comportamento com seguranca no lab: rode a cadeia de Kerberoasting de Active Directory Pentest: Kerberoasting Passo a Passo em Lab GOAD, ou automatize uma matriz ATT&CK inteira com Adversary Emulation com Caldera e MITRE ATT&CK em Lab Corporativo. Para movimento leste-oeste, a telemetria e as deteccoes estao em Lateral Movement em Lab: SMB, WMI e WinRM com Foco em Deteccao.

Tuning e falsos positivos#

Uma regra que dispara em todo job de backup e ruido que treina analistas a ignorar alertas, o que e pior que nao ter regra. Ajuste com dados, nao com adivinhacao: rode o candidato sobre 30 dias de historico, leia cada hit e caracterize os clusters benignos, uma conta de servico especifica, uma ferramenta de gestao de patch, um agente de monitoramento. Codifique esses como exclusoes explicitas na selecao filter da regra em vez de alargar o match, para subtrair o conhecido-bom sem se cegar para a variante maliciosa. Acompanhe a precisao como numero e exija que uma regra passe de um limiar antes de promover. Cuidado com a falha oposta: uma regra super-ajustada com tantas exclusoes que o atacante simplesmente reusa uma conta excluida. Tuning e subtracao do explicado, nunca subtracao do inconveniente.

Da caca a deteccao permanente#

Uma caca bem-sucedida e uma hipotese que achou algo ou provou uma lacuna; de qualquer forma ela nao deve evaporar. Promova a regra Sigma validada para seu repositorio de detection-as-code, versione em Git com suas tags de ATT&CK e notas de falsos positivos, e faca deploy como regra de deteccao agendada no Elastic que levanta um alerta com o contexto que um analista precisa para triar numa unica tela. Feche o ciclo com o red team para que cada tecnica emulada produza uma deteccao ou um ponto cego documentado; esse ciclo de feedback e todo o sentido de Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue. Quando uma deteccao dispara pra valer, o respondente precisa de triagem em nivel de host, que e onde DFIR no Linux: Triagem ao Vivo com UAC e Velociraptor assume.

Armadilhas e checklist#

As falhas recorrentes: converter uma regra sem a pipeline ECS e confiar no resultado zero; cacar sobre uma fonte de dados que voce nunca ingeriu, de modo que ausencia nao significa nada; apostar em hashes e IPs que expiram; escrever uma regra que voce nao consegue disparar sob demanda; e subir uma regra barulhenta que erode a confianca em toda a pipeline. O checklist antes de qualquer caca: (1) hipotese escrita como frase atada a uma tecnica do ATT&CK; (2) fonte de log necessaria confirmada presente e preenchida em ECS; (3) regra Sigma que expressa um comportamento, com falsos positivos listados; (4) compilada com a pipeline correta e a consulta revisada a mao; (5) disparada contra atividade emulada para provar que dispara; (6) ajustada sobre dados historicos com a precisao medida; (7) promovida a detection-as-code versionado; (8) religada ao backlog do purple team.

FAQ#

Por que Sigma em vez de escrever consultas Elastic direto? Portabilidade e revisao. Uma regra Sigma e neutra em relacao ao vendor, entao a mesma logica de comportamento compila para Elastic hoje e para outro SIEM amanha, e ela se revisa como um pequeno documento declarativo em vez de uma consulta espalhada. Voce ainda roda ES|QL nativo para exploracao interativa; Sigma e para as deteccoes duraveis e compartilhaveis que sobrevivem a qualquer plataforma. Os dois sao complementares, nao concorrentes.

Em que o hunting difere do alerting? O alerting roda deteccoes de mau-conhecido continuamente; o hunting testa proativamente hipoteses sobre atividade que nenhuma regra pega ainda, e sua saida costuma ser uma regra nova. Um programa maduro alimenta os resultados do hunting no alerting, de modo que a caca manual de hoje vira a deteccao automatizada de amanha. Se uma caca nunca produz um artefato duravel, uma regra ou uma lacuna documentada, foi entretenimento, nao engenharia.

Conclusao#

Trate hunting como pipeline, nao como palpite. Mire comportamento alto na Pyramid of Pain, expresse cada hipotese como uma unica regra Sigma, compile para Elastic com a pipeline ECS correta e prove que ela dispara contra atividade emulada antes de acreditar num resultado limpo. Ajuste com dados reais, meca a precisao e promova os sobreviventes a deteccoes versionadas religadas a um ciclo purple team. Feito assim, um resultado vazio e evidencia significativa em vez de falso conforto, e cada caca deixa o ambiente com uma deteccao duravel a mais ou um ponto cego honestamente documentado. Essa acumulacao, e nao uma unica consulta esperta, e o que de fato move o adversario piramide acima e para fora do seu alcance.