Ciberseguridad y seguridad de la información

Zeek Logs: Cómo investigar conn.log, dns.log y http.log

7 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre Zeek Logs en el ámbito de Network Security Monitoring

Respuesta rápida

La investigación de Zeek Logs se realiza mapeando Flow, tiempos, protocolos, DNS/TLS/HTTP y el contexto del activo. Un solo paquete o conexión es una evidencia parcial, por lo que se construye una secuencia y se valida con fuentes adicionales.

El tráfico de red proporciona una perspectiva que no depende únicamente del punto final. Permite identificar quién habló con quién, con qué protocolo, en qué orden y con qué volumen, pero requiere una comprensión de los límites de la visibilidad y el cifrado. Este artículo se centra en Zeek Logs y está dirigido a analistas de SOC y Network Hunters. El objetivo es proporcionar una metodología de trabajo que se pueda aplicar en la práctica, en una entrevista profesional y en un entorno de trabajo, sin limitarse a una definición de diccionario.

El desafío central es que los datos casi siempre son parciales. query name, response code, TTL pueden indicar una dirección, pero su significado depende del tiempo, el activo, el usuario y la actividad esperada. Por lo tanto, construiremos la investigación en torno a una pregunta de investigación, la evidencia requerida y un criterio claro para la finalización.

El escenario práctico en el artículo es: investigar una Session a través de cuatro Logs. Todos los ejemplos son datos de laboratorio o descripciones de procesos. Cuando se trata de Penetration Testing, Web o Cloud, solo se debe trabajar con autorización explícita, Scope definido y la capacidad de detener la prueba.

Estructura de Logs y UID

Los campos importantes no son necesariamente los que se muestran en la parte superior de la pantalla. En Zeek Logs, se deben identificar identificadores estables, tiempo, origen, destino, resultado y contexto. Ejemplos útiles son query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, resolver context. El objetivo es permitir la Correlation entre registros y no solo la lectura de un Event individual.

Se recomienda crear un pequeño Data dictionary: nombre del campo, significado, formato, origen, valores Null esperados y si es confiable para la vinculación. Esto permite distinguir entre un campo de visualización y un identificador de investigación, e identificar cuándo un Connector o una versión han cambiado el Schema.

conn.log

El tema 'conn.log' es una parte central del trabajo con Zeek Logs. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se desea tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de la herramienta sin comprender el objetivo.

En la práctica, registre query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, compárelos con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluidas las limitaciones y los pasos siguientes.

dns.log

El tema 'dns.log' es una parte central del trabajo con Zeek Logs. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se desea tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de la herramienta sin comprender el objetivo.

http.log y tls.log

El tema 'http.log y tls.log' es una parte central del trabajo con Zeek Logs. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se desea tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de la herramienta sin comprender el objetivo.

Correlation y Timeline

Timeline es la columna vertebral de Zeek Logs. Se normalizan los tiempos a UTC o se especifica explícitamente la zona horaria, se guardan tanto Event time como Ingestion time, y se conectan los eventos mediante identificadores estables. La línea debe incluir tiempo, origen, entidad, acción, resultado y confiabilidad.

Una brecha o contradicción no es un error en el documento, sino un hallazgo. Clock drift, retraso en la recepción, NAT, reutilización de PID o una Session continua pueden cambiar el orden. Por lo tanto, se indican rangos de incertidumbre y se mantiene un enlace de regreso a la evidencia bruta.

Cuándo volver a PCAP

El tema 'Cuándo volver a PCAP' es una parte central del trabajo con Zeek Logs. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se desea tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de la herramienta sin comprender el objetivo.

Puntos de control únicos

En este tema, se recomienda construir de antemano un mapa de evidencias enfocado. Los puntos de control principales son: query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, resolver context, uid, conn.log, dns.log, http.log. La lista no es un Checklist automático; cada elemento se selecciona porque puede vincular una entidad, una acción y un tiempo, o explicar un comportamiento legítimo.

query name: Defina cuál es el valor esperado, qué se consideraría anómalo y qué fuente adicional confirmaría el hallazgo.
response code: Defina cuál es el valor esperado, qué se consideraría anómalo y qué fuente adicional confirmaría el hallazgo.
TTL: Defina cuál es el valor esperado, qué se consideraría anómalo y qué fuente adicional confirmaría el hallazgo.
subdomain entropy: Defina cuál es el valor esperado, qué se consideraría anómalo y qué fuente adicional confirmaría el hallazgo.
NXDOMAIN ratio: Defina cuál es el valor esperado, qué se consideraría anómalo y qué fuente adicional confirmaría el hallazgo.
resolver context: Defina cuál es el valor esperado, qué se consideraría anómalo y qué fuente adicional confirmaría el hallazgo.

Cuando uno de los focos no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el Process identifier no es estable, se puede utilizar el tiempo, Host, User y Parent; si el Payload está cifrado, se utilizan Metadata, volumen, frecuencia y TLS/DNS context.

Proceso de trabajo recomendado

Defina el Scope y una pregunta de trabajo sobre Zeek Logs.
Anote las fuentes de datos y las evidencias necesarias: query name, response code, TTL, subdomain entropy.
Cree un Baseline corto de comportamiento normal o resultado esperado.
Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
Construya un Timeline o tabla comparativa y separe los hechos de las interpretaciones.
Realice un Pivot a una fuente adicional para confirmar o refutar la explicación inicial.
Resuma la decisión, las limitaciones, la acción recomendada y los criterios de Retest.

Escenario práctico

El escenario elegido es la investigación de una Session a través de cuatro Logs. El propósito del ejercicio no es demostrar una capacidad de ataque, sino practicar la recopilación, comparación y documentación de forma segura. Antes de comenzar el trabajo, se definen datos simulados, una ventana de tiempo y un resultado esperado.

Al finalizar el ejercicio, se debe presentar un producto que un analista o verificador pueda revisar: una captura de pantalla o Export de la evidencia, un Timeline corto, una hipótesis inicial, evidencia confirmatoria, una limitación y una recomendación. Cuando no hay evidencia suficiente, la conclusión válida es que el escenario no ha sido probado.

Paso	Qué se realiza	Producto
Preparación	Defina Scope, tiempo y objetivo. Anote qué campos o evidencias de query name, response code, TTL se espera que aparezcan.	Plan de prueba corto
Creación de datos	Realice una acción segura y simulada relacionada con Zeek Logs, sin información real o impacto en un sistema de producción.	Evento/Request/Flow controlado
Recopilación	Recopile la evidencia bruta y el contexto de una fuente adicional. Verifique Time zone, identificadores e integridad.	Dos evidencias vinculadas
Análisis	Escriba qué prueba cada evidencia, qué no prueba y cuál es la posible explicación legítima.	Conclusión intermedia
Finalización	Elija un cierre, escalada, Finding o Tuning; añada una recomendación y Retest.	Producto documentado

Checklist práctico

Verifique y documente: los cinco componentes del Flow.
Verifique y documente: hora de inicio, duración y volumen.
Verifique y documente: DNS name y TLS metadata.
Verifique y documente: HTTP method, host y URI cuando sean visibles.
Verifique y documente: TCP flags y stream.
Verifique y documente: relación con Host y Process.
Indique Time zone, versión de la herramienta y hora de recopilación.
Guarde los datos brutos antes de filtrar o modificar.
Escriba qué demuestra el hallazgo y qué aún se desconoce.
Defina el propietario y la acción de seguimiento con fecha límite.

Errores comunes

Confundir Capture Filter con Display Filter.
Inferir contenido cuando el tráfico está cifrado.
Analizar IP sin DNS/TLS context.
Ignorar NAT o Proxy.
Centrarse en un solo Packet.
No guardar la Captura original.

Resumen y CTA

Zeek Logs: Cómo investigar conn.log, dns.log y http.log es un tema que conecta el conocimiento técnico con la disciplina de trabajo. Comience con una pregunta, recopile solo la evidencia relevante, mantenga el contexto y el tiempo, y elija una acción que pueda justificarse y volver a probarse.

En la ruta de Cybersecurity & AI de HPI, estos principios se practican utilizando sistemas, Logs y laboratorios. Un paso natural es pasar a los artículos vinculados, realizar el ejercicio de laboratorio y guardar el producto como parte de un portafolio profesional.

Preguntas frecuentes

¿Zeek Logs por sí solo prueba un ataque o una debilidad?

No. Proporciona una señal o un hallazgo que necesita contexto, verificación y una fuente adicional. Una conclusión profesional se basa en una secuencia de evidencias y en la conformidad con el comportamiento esperado.

¿Qué se hace cuando faltan algunos datos?

Se documenta lo que falta, se verifica una fuente alternativa y se reduce el nivel de confianza. No se deben completar campos por suposiciones ni presentar Unknown como válido.

¿Cuánto tiempo se debe conservar la evidencia?

El tiempo depende de la política, la regulación, el costo y el tipo de evento. Es importante definir de antemano Retention, Legal hold y la capacidad de exportar evidencia en un formato verificable.

¿Cómo se practica sin poner en riesgo un sistema real?

Se utilizan máquinas virtuales, datos simulados, CTF o un laboratorio dedicado. En pruebas autorizadas, se definen Scope, Stop conditions y una copia de seguridad antes de comenzar el trabajo.