Threat Hunting con Zeek: Analisis de Trafico de Red para Detectar Amenazas

Zeek como Fuente de Datos para Hunting

Zeek (anteriormente conocido como Bro) es un framework de analisis de trafico de red que genera logs estructurados de la actividad observada en un punto de captura. A diferencia de un IDS basado en firmas, Zeek no genera alertas: produce datos. Cada conexion TCP/UDP, cada consulta DNS, cada sesion HTTP y cada handshake TLS se registra en un formato tabular que permite busquedas, correlaciones y analisis estadistico.

Para el threat hunter, Zeek proporciona la vista de red que complementa la vista de endpoint de Sysmon. Mientras Sysmon te dice que proceso hizo una conexion, Zeek te dice que ocurrio en esa conexion a nivel de protocolo.

Logs Principales de Zeek

Zeek genera docenas de archivos de log, pero para hunting los mas relevantes son cinco.

conn.log: El log fundamental

Cada conexion TCP/UDP observada genera una entrada en conn.log. Es el log mas voluminoso y el punto de partida para la mayoria de los hunts de red.

Campos clave:

Campo	Descripcion	Uso en hunting
id.orig_h	IP origen	Identificar endpoints internos
id.orig_p	Puerto origen	Puertos efimeros vs persistentes
id.resp_h	IP destino	Detectar destinos sospechosos
id.resp_p	Puerto destino	Puertos no estandar
proto	Protocolo (tcp/udp/icmp)	Filtrar por protocolo
service	Servicio detectado (http/dns/ssl)	Identificar trafico por servicio
duration	Duracion de la conexion	Detectar beaconing, sesiones largas
orig_bytes	Bytes enviados por el origen	Exfiltracion (upload alto)
resp_bytes	Bytes enviados por el destino	Descargas grandes
conn_state	Estado final de la conexion	SF (completada), S0 (SYN sin respuesta)
missed_bytes	Bytes perdidos en la captura	Evaluar calidad de los datos

Ejemplo de hunting: conexiones de larga duracion

Conexiones TCP que duran horas o dias pueden indicar un shell interactivo C2, un tunel o una sesion de exfiltracion lenta.

Buscar en conn.log donde:
  - duration mayor a 3600 (1 hora)
  - id.orig_h es una IP interna
  - id.resp_h es una IP externa
  - service NO es dns, ssl (las VPN y streaming legitimo generan
    conexiones largas, pero no por puertos inusuales)

Ejemplo de hunting: conexiones fallidas masivas

Un volumen alto de conexiones SYN sin respuesta (conn_state: S0) desde un host interno puede indicar escaneo de puertos o un C2 que intenta conectar a una infraestructura caida.

Buscar en conn.log donde:
  - conn_state es S0, S1, o REJ
  - Agrupar por id.orig_h
  - Filtrar hosts con mas de 100 conexiones fallidas por hora

dns.log: Inteligencia en las consultas DNS

El trafico DNS es una mina de informacion para el hunting. Los adversarios usan DNS para resolucion de C2, tunneling de datos, generacion dinamica de dominios (DGA) y reconocimiento.

Campos clave:

Campo	Descripcion	Uso en hunting
query	Dominio consultado	Detectar dominios sospechosos
qtype	Tipo de query (A, AAAA, TXT, MX)	TXT para tunneling
rcode	Codigo de respuesta (0=OK, 3=NXDOMAIN)	Alto NXDOMAIN indica DGA
answers	Respuestas recibidas	IPs de destino resueltas
TTL	Time to Live de la respuesta	TTL bajo indica fast-flux

Ejemplo de hunting: Domain Generation Algorithms (DGA)

Los malware que usan DGA generan muchas consultas a dominios aleatorios que no existen.

Buscar en dns.log donde:
  - rcode es 3 (NXDOMAIN)
  - Agrupar por id.orig_h (host que consulta)
  - Filtrar hosts con mas de 50 NXDOMAIN por hora
  - Examinar los dominios: longitud del subdominio,
    entropia de caracteres, ratio consonante/vocal

Ejemplo de hunting: DNS tunneling

Buscar en dns.log donde:
  - qtype es TXT
  - query tiene subdominios largos (mas de 40 caracteres)
  - Volumen alto de queries al mismo dominio base
  - Agrupar por dominio base y contar

Consulta de ejemplo con zeek-cut y herramientas de linea de comandos:

# Extraer queries DNS con subdominios largos
cat dns.log | zeek-cut query | awk 'length > 60' | sort | uniq -c | sort -rn | head 20

# Contar NXDOMAIN por host origen
cat dns.log | zeek-cut id.orig_h rcode | grep "3$" | cut -f1 | sort | uniq -c | sort -rn | head 20

# Queries TXT con alto volumen al mismo dominio
cat dns.log | zeek-cut query qtype | grep "TXT" | sort | uniq -c | sort -rn | head 20

http.log: Trafico web no cifrado

Aunque el trafico HTTPS es dominante, http.log sigue siendo valioso para detectar comunicaciones C2 que usan HTTP plano, descargas de payloads y exfiltracion por POST.

Campos clave:

Campo	Descripcion	Uso en hunting
method	Metodo HTTP (GET, POST, PUT)	POST para exfiltracion
host	Header Host de la peticion	Dominio de destino
uri	URI solicitada	Paths de C2
user_agent	User-Agent del cliente	Agentes anomalos
status_code	Codigo de respuesta	200 OK a destinos sospechosos
request_body_len	Tamano del cuerpo de la peticion	POST grandes para exfiltracion
response_body_len	Tamano del cuerpo de la respuesta	Descargas de payloads

Ejemplo de hunting: User-Agents anomalos

Buscar en http.log donde user_agent:
  - Esta vacio o ausente
  - Contiene nombres de herramientas conocidas (curl, wget, python-requests)
  - No coincide con los navegadores desplegados en la organizacion
  - Tiene formato inusual o strings sospechosos

# User-agents unicos ordenados por frecuencia
cat http.log | zeek-cut user_agent | sort | uniq -c | sort -rn | head 50

# POST requests con cuerpo grande (posible exfiltracion)
cat http.log | zeek-cut ts id.orig_h host uri method request_body_len | awk '$6 > 1000000'

ssl.log: Metadatos de conexiones cifradas

Aunque Zeek no descifra HTTPS, el handshake TLS revela informacion valiosa.

Campos clave:

Campo	Descripcion	Uso en hunting
server_name	SNI (Server Name Indication)	Dominio real de destino
subject	Subject del certificado	Certificados self-signed
issuer	Emisor del certificado	CAs inusuales
validation_status	Estado de validacion	Certificados invalidos
ja3	Hash JA3 del cliente	Fingerprint del software cliente
ja3s	Hash JA3S del servidor	Fingerprint del software servidor

Ejemplo de hunting: certificados self-signed

Los C2 frameworks frecuentemente usan certificados autofirmados. Cobalt Strike, Metasploit y Sliver generan certificados con patrones identificables.

Buscar en ssl.log donde:
  - validation_status NO es "ok"
  - O issuer es igual a subject (self-signed)
  - O subject contiene strings genericos (localhost, test, default)
  - Correlacionar con conn.log para ver duracion y volumen

Ejemplo de hunting: JA3 fingerprinting

JA3 genera un hash unico basado en los parametros del handshake TLS del cliente. Los C2 frameworks tienen hashes JA3 conocidos.

Buscar en ssl.log donde ja3 coincide con hashes conocidos de:
  - Cobalt Strike: varios hashes publicados por Salesforce
  - Metasploit Meterpreter: hashes documentados
  - Sliver C2: hashes especificos
  - Comparar contra la base de datos ja3er.com

files.log: Archivos transferidos por la red

Registra cada archivo observado en el trafico de red.

Campos clave:

Campo	Descripcion	Uso en hunting
mime_type	Tipo MIME detectado	Ejecutables, scripts
filename	Nombre del archivo (si disponible)	Archivos sospechosos
md5 / sha1 / sha256	Hashes del archivo	Busqueda en CTI
total_bytes	Tamano total	Archivos grandes
source	Protocolo de origen (HTTP, SMTP, FTP)	Vector de entrega

Ejemplo de hunting: ejecutables descargados

Buscar en files.log donde:
  - mime_type es application/x-dosexec o application/x-executable
  - source es HTTP (no HTTPS, donde no hay visibilidad de contenido)
  - Cruzar hashes contra MalwareBazaar o VirusTotal

Tecnicas Avanzadas de Hunting con Zeek

Deteccion de beaconing

El beaconing es el patron de comunicacion periodica de un implante C2 con su servidor. Los implantes avanzados introducen jitter (variacion aleatoria) en el intervalo, pero la periodicidad subyacente sigue siendo detectable.

Metodologia con conn.log:

1. Filtrar conexiones salientes a una misma IP o dominio destino
2. Calcular los intervalos entre conexiones consecutivas
3. Analizar la distribucion de intervalos: si es aproximadamente uniforme (desviacion estandar baja relativa a la media), es candidato a beaconing
4. El intervalo tipico de C2 es entre 30 segundos y 15 minutos

# Extraer timestamps de conexiones a una IP sospechosa
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p duration | grep "198.51.100.42" | sort

# Para analisis de beaconing mas avanzado, exportar a CSV
# y analizar con RITA o Python (scipy FFT)

RITA (Real Intelligence Threat Analytics)

RITA es una herramienta open source disenada especificamente para analizar logs de Zeek buscando beaconing, DNS tunneling y otros indicadores de C2.

# Importar logs de Zeek en RITA
rita import /opt/zeek/logs/current hunting-dataset

# Buscar beaconing
rita show-beacons hunting-dataset

# Buscar DNS tunneling
rita show-long-connections hunting-dataset

RITA calcula un score de beaconing (0 a 1) basado en la regularidad de las conexiones, el tamano consistente de los paquetes y el jitter. Scores superiores a 0.7 merecen investigacion.

Analisis de JA3 en profundidad

Los hashes JA3 permiten fingerprinting de software sin depender del User-Agent (que es facilmente falsificable).

Proceso de hunting con JA3:

1. Generar un baseline de hashes JA3 normales en tu red (navegadores, aplicaciones corporativas)
2. Identificar hashes JA3 que no pertenecen al baseline
3. Buscar esos hashes en bases de datos de JA3 conocidos (ja3er.com, ThreatFox)
4. Investigar las conexiones asociadas a hashes JA3 desconocidos

Correlacion DNS con conn.log

Una tecnica poderosa es correlacionar las respuestas DNS con las conexiones posteriores:

1. En dns.log, encontrar queries a un dominio sospechoso y las IPs devueltas en answers
2. En conn.log, buscar conexiones a esas IPs resueltas
3. Correlacionar con ssl.log para ver el certificado y JA3 de esas conexiones

Esta cadena DNS -> IP -> conexion -> TLS proporciona una vista completa de la comunicacion.

Integracion con SIEM

Los logs de Zeek en formato TSV se integran facilmente con cualquier SIEM:

ELK Stack. Filebeat con el modulo Zeek parsea los logs nativos. Elastic Security incluye dashboards y reglas de deteccion predefinidas para datos de Zeek.

Splunk. La app Corelight para Splunk (tambien funciona con Zeek open source) proporciona dashboards, macros y saved searches para hunting.

La clave: centralizar los logs de Zeek junto con los de Sysmon (endpoint) y los de autenticacion (Active Directory) permite correlaciones cross-domain que ninguna fuente individual puede proporcionar.

Limitaciones de Zeek

Trafico cifrado. Zeek solo ve metadatos de HTTPS (SNI, certificado, JA3). El contenido de las comunicaciones cifradas no es visible. Esto limita la deteccion de exfiltracion dentro de sesiones HTTPS legitimas.

Posicion en la red. Zeek solo ve el trafico que pasa por su punto de captura. El trafico este-oeste entre segmentos que no pasa por el sensor no se registra. Multiples sensores en puntos estrategicos mejoran la cobertura.

No es real-time alerting. Zeek genera logs, no alertas. Para deteccion en tiempo real, los logs deben enviarse a un SIEM con reglas de deteccion. El hunting con Zeek es tipicamente analisis retrospectivo.

Volumen de datos. En redes de alto trafico, los logs pueden ser masivos. Estrategias de retencion (comprimir, archivar, purgar por antigeuedad) son necesarias.

Conclusion

Zeek es la herramienta de referencia para hunting de red. Sus logs estructurados proporcionan una vista detallada de la actividad de red que complementa la telemetria de endpoint. La combinacion de conn.log (quien habla con quien), dns.log (que resuelven), ssl.log (como se cifran) y http.log (que transfieren) permite al hunter detectar C2, exfiltracion, tunneling y movimiento lateral con evidencia solida.

La integracion de Zeek con herramientas como RITA para analisis automatizado de beaconing y con un SIEM para correlacion cross-domain multiplica su valor. Un hunter que domine tanto Sysmon (endpoint) como Zeek (red) tiene visibilidad en las dos dimensiones criticas del entorno.