Ciberseguridad y seguridad de la información

Construcción de Network Timeline a partir de conexiones TCP, DNS, HTTP y TLS

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre Network Timeline en el campo de Network Security Monitoring

Respuesta rápida

Network Timeline se realiza mediante el mapeo de Flow, tiempos, protocolos, DNS/TLS/HTTP y la conexión con el activo. Un solo paquete o conexión es una evidencia parcial, por lo que se construye una secuencia y se verifica 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 en qué volumen, pero requiere una comprensión de los límites de la visibilidad y el cifrado. Este artículo se centra en Network Timeline y está dirigido a analistas de SOC e investigadores de red. 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 principal es que los datos son casi siempre incompletos. El nombre de la consulta, el código de respuesta, el 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 prueba en torno a una pregunta de investigación, las evidencias necesarias y un criterio claro para su finalización.

El escenario práctico en el artículo es: Timeline de descarga y posterior Beaconing. 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, un alcance definido y la capacidad de detener la prueba.

Selección de Anchor event

El tema 'Selección de Anchor event' es una parte central del trabajo en Network Timeline. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada, qué decisión se quiere 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 el nombre de la consulta, el código de respuesta, el TTL, la entropía del subdominio, la relación NXDOMAIN, compárelos con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y pasos posteriores.

Normalización del tiempo

Para comprender la diferencia en el contexto de Network Timeline, es importante comparar objetivos y no solo herramientas. Una opción proporciona amplitud o velocidad, y otra proporciona una verificación profunda o contexto. La elección correcta depende de la pregunta: ¿Se requiere detección, investigación, prueba de impacto, contención o informe?

Una tabla de comparación profesional debe incluir al menos: tipo de entrada, nivel de confianza, coste operativo, posible impacto, limitaciones y seguimiento requerido. En caso de duda, se utiliza el enfoque menos invasivo y se añade una fuente complementaria en lugar de sacar una conclusión demasiado amplia.

DNS antes de la conexión

El tema 'DNS antes de la conexión' es una parte central del trabajo en Network Timeline. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada, qué decisión se quiere tomar y qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de la herramienta sin comprender el objetivo.

Contexto HTTP/TLS

El tema 'Contexto HTTP/TLS' es una parte central del trabajo en Network Timeline. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada, qué decisión se quiere tomar y qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de la herramienta sin comprender el objetivo.

Presentación de hallazgos

El tema 'Presentación de hallazgos' es una parte central del trabajo en Network Timeline. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada, qué decisión se quiere 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 un mapa de evidencias enfocado con antelación. Los principales puntos de control son: query name, response code, TTL, subdomain entropy, NXDOMAIN ratio, resolver context. La lista no es un Checklist automático; cada elemento se selecciona porque puede vincular una entidad, acción y tiempo, o explicar un comportamiento legítimo.

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

Cuando uno de los puntos de control no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el identificador de proceso no es estable, se puede usar el tiempo, Host, User y Parent; si el Payload está cifrado, se usan los metadatos, el volumen, la frecuencia y el contexto TLS/DNS.

Proceso de trabajo recomendado

Defina el Scope y una pregunta de trabajo sobre Network Timeline.
Registre las fuentes de datos y las evidencias necesarias: query name, response code, TTL, subdomain entropy.
Cree una línea base (Baseline) corta de comportamiento normal o resultado esperado.
Realice la prueba mínima en un entorno de laboratorio y registre el tiempo, la entrada y la salida.
Construya un Timeline o una tabla comparativa y separe los hechos de la interpretación.
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 el criterio de Retest.

Escenario práctico

El escenario elegido es un Timeline de descarga y posterior Beaconing. El propósito del ejercicio no es probar la capacidad de ataque, sino practicar la recopilación, comparación y documentación de manera segura. Antes de comenzar el trabajo, se definen datos simulados, una ventana de tiempo y un resultado esperado.

Al finalizar el ejercicio, se debe entregar un producto que otro analista o evaluador pueda revisar: una captura de pantalla o exportación de la evidencia, un Timeline corto, una hipótesis inicial, una evidencia de confirmación, una limitación y una recomendación. Cuando no hay evidencia suficiente, la conclusión correcta es que el escenario no ha sido probado.

Etapa	Qué se realiza	Producto
Preparación	Defina el Scope, tiempo y objetivo. Registre 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 Network Timeline, sin información real ni 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 la zona horaria, los identificadores y la integridad.	Dos evidencias vinculadas
Análisis	Escriba lo que cada evidencia prueba, lo que 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 metadatos TLS.
Verifique y documente: HTTP method, host y URI cuando sean visibles.
Verifique y documente: flags TCP y stream.
Verifique y documente: relación con Host y Process.
Indique la zona horaria, la versión de la herramienta y la hora de recopilación.
Guarde el dato bruto antes de filtrar o modificar.
Escriba lo que el hallazgo prueba y lo que aún se desconoce.
Defina un propietario y una acción de seguimiento con una fecha límite.

Errores comunes

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

Resumen y CTA

La construcción de Network Timeline a partir de conexiones TCP, DNS, HTTP y TLS es un tema que conecta el conocimiento técnico con la disciplina de trabajo. Comience con una pregunta, recopile solo evidencias relevantes, mantenga el contexto y el tiempo, y elija una acción que pueda justificarse y verificarse.

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

Preguntas frecuentes

¿Network Timeline 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 correcto.

¿Cuánto tiempo se deben conservar las evidencias?

El tiempo depende de la política, la regulación, el coste y el tipo de evento. Es importante definir de antemano la retención, la retención legal y la capacidad de exportar evidencias 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 define el Scope, las condiciones de parada y la copia de seguridad antes de comenzar el trabajo.