Intermediothreat-huntingELKSIEMKQLherramientasdeteccion

ELK Stack para Threat Hunting: KQL, Dashboards y Reglas de Deteccion

Guia practica de threat hunting con ELK Stack (Elasticsearch, Logstash, Kibana). Consultas KQL y Lucene para hunting, dashboards de investigacion, reglas de deteccion de Elastic Security y workflows de analisis para equipos SOC.

MalwareIntel Research··8 min lectura
Serie: Threat Hunting — Parte 11

ELK Stack como Plataforma de Hunting

El ELK Stack (Elasticsearch, Logstash, Kibana) con Elastic Security es una de las plataformas mas usadas para threat hunting. Su capacidad de busqueda full-text sobre volumenes masivos de datos, combinada con visualizaciones interactivas y reglas de deteccion, proporciona todo lo necesario para ejecutar hunts efectivos.

Para el hunter, ELK ofrece tres capacidades clave: busqueda rapida sobre datos historicos (Elasticsearch), visualizacion y exploracion interactiva (Kibana) y reglas de deteccion automatizadas (Elastic Security Detection Engine).

Arquitectura de Datos para Hunting

Fuentes de datos esenciales

La arquitectura de ingestion determina que hunts son posibles. Las fuentes prioritarias son:

Endpoint (Sysmon via Winlogbeat/Elastic Agent):

  • Indices: winlogbeat-* o logs-windows.sysmon_operational-*
  • Campos clave: event.code, process.name, process.command_line, process.parent.name

Red (Zeek via Filebeat):

  • Indices: filebeat-* con modulo Zeek activado
  • Campos clave: zeek.conn.*, zeek.dns.*, zeek.ssl.*, zeek.http.*

Autenticacion (Windows Security via Winlogbeat):

  • Indices: winlogbeat-* filtrado por event.code: 4624/4625/4768/4769
  • Campos clave: winlog.event_data.LogonType, source.ip, user.name

Index Lifecycle Management (ILM)

Configurar ILM para balancear rendimiento y retencion:

Hot phase:  0-7 dias   (SSD, replicas, busqueda rapida)
Warm phase: 7-30 dias  (SSD, sin replicas, busqueda normal)
Cold phase: 30-90 dias (HDD, sin replicas, busqueda lenta)
Delete:     90+ dias   (purgado automatico)

Para hunting, 90 dias de retencion en logs de seguridad es el minimo recomendado.

KQL: Kibana Query Language

KQL es el lenguaje de consulta principal para hunting en Kibana. Es mas legible que Lucene y suficiente para la mayoria de los escenarios de hunting.

Sintaxis basica de KQL

# Igualdad
process.name: "powershell.exe"

# Wildcards
process.command_line: *encodedcommand*

# AND / OR
process.name: "cmd.exe" AND process.parent.name: "winword.exe"

# NOT
NOT process.name: "chrome.exe"

# Valores multiples
process.name: ("cmd.exe" OR "powershell.exe" OR "wscript.exe")

# Campos nested
winlog.event_data.TargetImage: "*lsass.exe"

# Rango numerico (solo en Lucene, no KQL)
# En KQL, usar filtros de Kibana

Consultas de hunting esenciales en KQL

Ejecucion sospechosa de PowerShell:

event.code: "1" AND
process.name: "powershell.exe" AND (
  process.command_line: *-enc* OR
  process.command_line: *-encodedcommand* OR
  process.command_line: *downloadstring* OR
  process.command_line: *invoke-expression* OR
  process.command_line: *-nop* AND process.command_line: *hidden*
)

LOLBins con parametros de descarga:

event.code: "1" AND (
  (process.name: "certutil.exe" AND process.command_line: (*-urlcache* OR *-split*)) OR
  (process.name: "bitsadmin.exe" AND process.command_line: */transfer*) OR
  (process.name: "mshta.exe" AND process.command_line: *http*) OR
  (process.name: "regsvr32.exe" AND process.command_line: (*/s* AND */i* AND *http*))
)

Procesos lanzados desde rutas temporales:

event.code: "1" AND
process.executable: (*\\Temp\\* OR *\\tmp\\* OR *\\AppData\\Local\\Temp\\*)
AND process.executable: *.exe
AND NOT process.name: (setup* OR install* OR update*)

Acceso a LSASS:

event.code: "10" AND
winlog.event_data.TargetImage: "*\\lsass.exe" AND
winlog.event_data.GrantedAccess: ("0x1010" OR "0x1FFFFF" OR "0x1F1FFF") AND
NOT winlog.event_data.SourceImage: (*MsMpEng* OR *csrss* OR *svchost*)

Lucene: Consultas Avanzadas

Lucene ofrece capacidades que KQL no tiene, especialmente regex y proximity search.

Regex en Lucene

# Buscar dominios con patron de DGA (alta entropia)
dns.question.name: /[a-z0-9]{15,}\.(com|net|org|xyz)/

# Buscar lineas de comandos con Base64
process.command_line: /[A-Za-z0-9+\/]{40,}={0,2}/

# Buscar IPs en rangos especificos
destination.ip: /185\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})/
# Buscar "invoke" cerca de "expression" en la misma linea de comandos
process.command_line: "invoke expression"~3

Dashboards de Hunting

Los dashboards de Kibana proporcionan vistas consolidadas que facilitan la identificacion de anomalias.

Dashboard de Hunting de Endpoint

Visualizaciones recomendadas:

  1. Top procesos ejecutados (bar chart): identifica procesos inusuales por frecuencia
  2. Procesos desde rutas temporales (data table): lista procesos ejecutados desde TEMP/AppData
  3. Cadenas de procesos sospechosas (data table): parent-child inusuales
  4. Timeline de ejecucion (line chart): patron temporal de ejecuciones
  5. Hashes unicos (metric): numero de ejecutables unicos vistos
  6. LOLBins activity (pie chart): distribucion de uso de LOLBins

Dashboard de Hunting de Red

Visualizaciones recomendadas:

  1. Top destinos por volumen (bar chart): IPs/dominios con mayor trafico
  2. Conexiones de larga duracion (data table): sesiones TCP superiores a 1 hora
  3. DNS anomalo (data table): dominios con subdominios largos o alto NXDOMAIN
  4. User-Agents inusuales (data table): agentes no estándar
  5. Beaconing candidates (data table): pares source-dest con intervalos regulares
  6. Certificados self-signed (data table): conexiones SSL con certificados no validos

Dashboard de Hunting de Autenticacion

Visualizaciones recomendadas:

  1. Logon failures por cuenta (bar chart): cuentas con mas fallos
  2. Logon failures por IP origen (bar chart): IPs con mas intentos
  3. RDP sessions (data table): sesiones RDP con IP origen y cuenta
  4. Logons tipo 3 (Network) anomalos (data table): autenticacion de red no habitual
  5. Kerberos TGS requests (line chart): volumen temporal de solicitudes TGS
  6. Nuevos servicios (data table): Event ID 7045 recientes

Elastic Security: Detection Rules

Elastic Security incluye un motor de reglas de deteccion que complementa el hunting manual con deteccion automatizada.

Tipos de reglas

Custom query. La mas simple: una consulta KQL o Lucene que genera alerta cuando encuentra resultados. Ideal para convertir consultas de hunting exitosas en deteccion permanente.

Threshold. Genera alerta cuando un campo supera un umbral. Util para password spraying (mas de N fallos por IP en M minutos).

EQL (Event Query Language). Permite buscar secuencias de eventos. Ideal para cadenas de ejecucion (proceso A lanza B que lanza C en un periodo de tiempo).

ML (Machine Learning). Detecta anomalias usando modelos de ML predefinidos o personalizados. Util para detectar beaconing y comportamiento anomalo.

Ejemplo de regla EQL: cadena de ataque phishing

sequence by host.id with maxspan=5m
  [process where process.name == "outlook.exe"]
  [file where file.extension in ("docx", "xlsx", "one", "lnk")]
  [process where process.parent.name in ("winword.exe", "excel.exe", "onenote.exe")
    and process.name in ("cmd.exe", "powershell.exe", "wscript.exe", "mshta.exe")]

Esta regla detecta la secuencia: Outlook abre un adjunto que Office ejecuta como script. La clausula maxspan=5m limita la secuencia a 5 minutos.

Ejemplo de regla threshold: password spraying

{
  "type": "threshold",
  "query": "event.code: 4625 AND winlog.event_data.SubStatus: 0xC000006A",
  "threshold": {
    "field": "source.ip",
    "value": 20
  },
  "timeline": "5m"
}

Genera alerta cuando una IP tiene mas de 20 fallos de autenticacion (contrasena incorrecta) en 5 minutos.

Elastic Security Timeline

Timeline es la herramienta de investigacion de Elastic Security. Funciona como un workbench donde el hunter puede:

  1. Arrastrar eventos desde cualquier dashboard o busqueda
  2. Filtrar y correlacionar eventos por campos comunes (host, usuario, proceso)
  3. Construir la narrativa de un incidente ordenando eventos cronologicamente
  4. Anotar eventos con notas
  5. Exportar la investigacion como caso (Case)

Workflow de hunting con Timeline

  1. Ejecutar consulta de hunting en Discover o en un dashboard
  2. Identificar eventos sospechosos
  3. Enviar eventos a una Timeline nueva
  4. En la Timeline, pivotar sobre campos (buscar mas actividad del mismo host, usuario o proceso)
  5. Agregar eventos correlacionados de otras fuentes (red, autenticacion)
  6. Documentar hallazgos con notas en cada evento
  7. Si se confirma actividad maliciosa, crear un Case con la Timeline adjunta

Integracion con Sigma Rules

Las reglas Sigma son un formato abierto para reglas de deteccion que se puede convertir a multiples formatos de SIEM, incluyendo KQL de Elastic.

Conversion de Sigma a Elastic

# Usando sigma-cli (pySigma)
sigma convert -t elasticsearch -p ecs_windows -f lucene regla.yml

# Ejemplo de regla Sigma
title: Suspicious PowerShell Download
status: stable
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\powershell.exe'
    CommandLine|contains:
      - 'downloadstring'
      - 'downloadfile'
      - 'invoke-webrequest'
  condition: selection

# Convertida a Lucene/KQL:
process.name: *\\powershell.exe AND
process.command_line: (*downloadstring* OR *downloadfile* OR *invoke-webrequest*)

Repositorio SigmaHQ

El repositorio SigmaHQ en GitHub contiene miles de reglas de deteccion mantenidas por la comunidad. Integrar las reglas relevantes al cluster de Elastic proporciona una base de deteccion solida que complementa el hunting manual.

Buenas Practicas para Hunting con ELK

Usar Saved Searches. Guardar las consultas de hunting como Saved Searches en Kibana permite reutilizarlas y compartirlas con el equipo.

Crear Spaces separados. Usar Kibana Spaces para separar los dashboards de hunting de los de operaciones del SOC.

Documentar en Cases. Cada hunt deberia documentarse como un Case de Elastic Security, con la hipotesis, las consultas usadas, los hallazgos y las recomendaciones.

Automatizar hallazgos. Cuando un hunt descubre una tecnica nueva, crear una Detection Rule que detecte esa tecnica automaticamente.

Optimizar consultas. En clusters grandes, las consultas con wildcards al inicio (*malware*) son lentas. Usar campos indexados y filtros de tiempo para acotar las busquedas.

Conclusion

ELK Stack con Elastic Security proporciona una plataforma completa para threat hunting: busqueda rapida sobre datos masivos (Elasticsearch), visualizacion interactiva (Kibana dashboards), investigacion guiada (Timeline), deteccion automatizada (Detection Engine) y documentacion (Cases).

La combinacion de KQL para busquedas rapidas, Lucene para regex avanzado y EQL para secuencias de eventos cubre la mayoria de los escenarios de hunting. La integracion con Sigma Rules y la capacidad de convertir hunts exitosos en reglas de deteccion cierra el ciclo del threat hunting de forma natural dentro de la misma plataforma.

Preguntas frecuentes

Artículos relacionados

Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.