Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion

El threat hunting fracasa cuando se queda en corazonada. Un analista busca un hash malo, no encuentra nada y declara el entorno limpio, lo que solo prueba que un artefacto esta ausente. El equipo Basilisk corre el hunting como una pipeline de ingenieria: una hipotesis expresada como regla Sigma portable, compilada a una consulta Elastic, validada contra telemetria real, ajustada y luego promovida a una deteccion permanente. Este texto recorre el camino completo del indicador a la deteccion con reglas, consultas y pasos de tuning concretos que puedes reproducir en un lab esta noche, y esta construido para emparejarse con una fuente de emulacion, de modo que caces algo real en vez de mirar un indice vacio.

Del indicador a la deteccion: la piramide del dolor

La Pyramid of Pain de David Bianco es el modelo mental que hace que el hunting valga el esfuerzo. Hashes e IPs estan abajo: triviales de cambiar para un atacante, asi que una caza basada en ellos expira en horas. Dominios y artefactos de red son algo mas dificiles. Arriba estan las herramientas y las TTP, las tacticas, tecnicas y procedimientos que un adversario tendria que rehacer para evadir, caro para el y duradero para ti. El buen hunting apunta al comportamiento, no a indicadores: no 'encuentra el hash X' sino 'encuentra cualquier proceso que lance un interprete de scripts desde un documento de Office y luego haga una conexion saliente'. Sigma existe justo para expresar esa logica de comportamiento una vez y correrla sobre cualquier backend, para que tu trabajo intelectual no quede atado a un solo lenguaje de consulta.

Anatomia de una regla Sigma

Una regla Sigma es un pequeno documento YAML con un esqueleto fijo. El bloque logsource declara la telemetria que necesita, por ejemplo product: windows y category: process_creation, que mapea a Sysmon Event ID 1 o Windows 4688. El bloque detection contiene una o mas selecciones nombradas y una condition que las combina con logica booleana. Una regla LOLBin minima define selection como Image|endswith: '\\certutil.exe' junto con CommandLine|contains: '-urlcache' y luego pone condition: selection. Agrega una lista falsepositives y un level para que el triage sepa como pesar un hit, y etiquetala con la tecnica de ATT&CK que cubre. La disciplina que importa: una regla expresa un comportamiento verificable, con nombres de campo tomados de un esquema que realmente envias, no de una captura de blog.

Montar el stack de Elastic

Necesitas telemetria antes que reglas. Levanta Elasticsearch y Kibana, luego inscribe endpoints con el Elastic Agent gestionado por Fleet, enviando las integraciones System y Windows para que creacion de procesos, red y autenticacion caigan en indices normalizados al Elastic Common Schema (ECS). ECS es la pieza clave: renombra los campos de vendor a nombres estables como process.command_line, process.parent.name y destination.ip, para que una consulta escrita una vez siga funcionando mientras las fuentes cambian. En Windows, despliega Sysmon con una configuracion curada (una config comunitaria mantenida es el default sensato) porque el log de auditoria nativo es demasiado grueso para hunting de comportamiento. Verifica la ingesta confirmando que un certutil de prueba aparezca en Discover con un process.command_line poblado antes de confiar en regla alguna.

Compilar Sigma a un backend Elastic

Sigma es portable porque un compilador lo traduce al dialecto de cada backend. La toolchain moderna es sigma-cli impulsando pySigma con un plugin por objetivo. Instala el plugin de Elasticsearch y corre sigma convert -t elasticsearch -p ecs_windows rules/certutil_urlcache.yml para emitir una consulta de Elasticsearch, o apunta a -t eql para obtener Event Query Language para correlacion entre eventos. Una pipeline como ecs_windows es lo que remapea los nombres de campo genericos de la regla a tus campos ECS, y omitirla es la razon mas comun por la que una regla convertida devuelve cero resultados pese a un hit real. Para logica de secuencia, EQL de Elastic expresa 'proceso A luego red B por el mismo proceso en N segundos', mientras que el mas nuevo ES|QL es excelente para agregacion exploratoria durante la caza misma.

Una caza concreta: binarios living-off-the-land

Los atacantes evitan soltar malware abusando de binarios de sistema firmados: certutil para descargar, mshta y rundll32 para ejecutar, regsvr32 para la tecnica Squiblydoo, bitsadmin para transferir. Empieza amplio en 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, luego lee las lineas de comando raras, porque el uso admin normal es de alto volumen y repetitivo mientras la invocacion del atacante es un outlier solitario. Pivota en cada hit al proceso padre y a la conexion de red posterior para confirmar la intencion. Los patrones KQL mas profundos por binario, con las baselines benignas a restar, estan catalogados en Hunting de Living-off-the-Land Binaries en Windows con KQL.

Hunting guiado por hipotesis mapeado a ATT&CK

No caces al azar; caza una hipotesis atada a una tecnica. Formulala como frase: 'Si un adversario ejecuto Kerberoasting (T1558.003), veria un pico de solicitudes TGS con cifrado RC4 desde una sola cuenta.' Luego exprésalo como regla y pruebalo contra actividad emulada, porque una caza que no puedes disparar a demanda es una caza en la que no puedes confiar. Genera el comportamiento de forma segura en el lab: corre la cadena de Kerberoasting de Pentest de Active Directory: Kerberoasting Paso a Paso en Lab GOAD, o automatiza una matriz ATT&CK entera con Adversary Emulation con Caldera y MITRE ATT&CK en Laboratorio Corporativo. Para movimiento este-oeste, la telemetria y las detecciones estan en Movimiento Lateral en Lab: SMB, WMI y WinRM con Foco en Deteccion.

Tuning y falsos positivos

Una regla que dispara en cada job de backup es ruido que entrena a los analistas a ignorar alertas, lo cual es peor que no tener regla. Ajusta con datos, no con adivinanzas: corre el candidato sobre 30 dias de historia, lee cada hit y caracteriza los clusters benignos, una cuenta de servicio especifica, una herramienta de gestion de parches, un agente de monitoreo. Codifica esos como exclusiones explicitas en la seleccion filter de la regla en vez de ampliar el match, para restar lo conocido-bueno sin cegarte a la variante maliciosa. Mide la precision como numero y exige que una regla supere un umbral antes de promoverla. Cuidado con el fallo opuesto: una regla sobre-ajustada con tantas exclusiones que el atacante simplemente reutiliza una cuenta excluida. El tuning es resta de lo explicado, nunca resta de lo inconveniente.

De la caza a la deteccion permanente

Una caza exitosa es una hipotesis que encontro algo o probo un hueco; de cualquier modo no debe evaporarse. Promueve la regla Sigma validada a tu repositorio de detection-as-code, versionala en Git con sus tags de ATT&CK y notas de falsos positivos, y despliegala como regla de deteccion programada en Elastic que levante una alerta con el contexto que un analista necesita para triar en una sola pantalla. Cierra el ciclo con el red team para que cada tecnica emulada produzca una deteccion o un punto ciego documentado; ese ciclo de feedback es todo el sentido de Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue. Cuando una deteccion dispara en serio, el respondedor necesita triage a nivel de host, que es donde toma el relevo DFIR en Linux: Triaje en Vivo con UAC y Velociraptor.

Trampas y checklist

Los fallos recurrentes: convertir una regla sin la pipeline ECS y confiar en el resultado cero; cazar sobre una fuente de datos que nunca ingeriste, de modo que la ausencia no significa nada; basarte en hashes e IPs que expiran; escribir una regla que no puedes disparar a demanda; y desplegar una regla ruidosa que erosiona la confianza en toda la pipeline. El checklist antes de cualquier caza: (1) hipotesis escrita como frase atada a una tecnica de ATT&CK; (2) fuente de log requerida confirmada presente y poblada en ECS; (3) regla Sigma que expresa un comportamiento, con falsos positivos listados; (4) compilada con la pipeline correcta y la consulta revisada a mano; (5) disparada contra actividad emulada para probar que dispara; (6) ajustada sobre datos historicos con la precision medida; (7) promovida a detection-as-code versionado; (8) enlazada de vuelta al backlog del purple team.

FAQ

Por que Sigma en vez de escribir consultas Elastic directas? Portabilidad y revision. Una regla Sigma es neutral respecto al vendor, asi que la misma logica de comportamiento compila a Elastic hoy y a otro SIEM manana, y se revisa como un pequeno documento declarativo en vez de una consulta desparramada. Igual corres ES|QL nativo para exploracion interactiva; Sigma es para las detecciones duraderas y compartibles que sobreviven a cualquier plataforma. Los dos son complementarios, no competidores.

En que difiere el hunting del alerting? El alerting corre detecciones de bad-conocido de forma continua; el hunting prueba proactivamente hipotesis sobre actividad que ninguna regla atrapa aun, y su salida suele ser una regla nueva. Un programa maduro alimenta los resultados del hunting al alerting, de modo que la caza manual de hoy se vuelve la deteccion automatizada de manana. Si una caza nunca produce un artefacto duradero, una regla o un hueco documentado, fue entretenimiento, no ingenieria.

Conclusion

Trata el hunting como una pipeline, no como una corazonada. Apunta a comportamiento alto en la Pyramid of Pain, expresa cada hipotesis como una sola regla Sigma, compilala a Elastic con la pipeline ECS correcta y prueba que dispara contra actividad emulada antes de creer en un resultado limpio. Ajusta con datos reales, mide la precision y promueve a los sobrevivientes a detecciones versionadas cableadas de vuelta a un ciclo purple team. Hecho asi, un resultado vacio es evidencia significativa en vez de falso consuelo, y cada caza deja el entorno con una deteccion duradera mas o un punto ciego honestamente documentado. Esa acumulacion, no una sola consulta ingeniosa, es lo que de verdad mueve al adversario piramide arriba y fuera de tu alcance.