Análisis de Tráfico de Red
Disciplina de la informática forense que examina el tráfico de red capturado (paquetes, flujos, metadatos) para reconstruir comunicaciones, detectar actividad maliciosa, identificar exfiltración de datos y documentar intrusiones con procedimientos orientados a preservar su valor probatorio.
¿Qué es el análisis de tráfico de red?
El análisis de tráfico de red (network forensics) es la disciplina de la informática forense dedicada a la captura, registro y examen sistemático de los datos que circulan por una red informática. Su objetivo es reconstruir comunicaciones, detectar actividad maliciosa, identificar la exfiltración de datos y documentar intrusiones con procedimientos orientados a preservar el valor probatorio de lo capturado. Que la prueba se admita y con qué alcance lo decide el tribunal, no el método.
A diferencia de otras ramas del forense digital que trabajan con datos almacenados en disco (evidencia en reposo), el análisis de tráfico de red trabaja fundamentalmente con evidencia volátil: los paquetes de datos viajan por la red y, si no son capturados en el momento, se pierden para siempre. Esto convierte a la captura de tráfico en una de las técnicas forenses más sensibles al tiempo y que requiere mayor planificación previa.
El análisis de tráfico de red es determinante en la investigación de una intrusión porque permite responder a preguntas fundamentales: qué sistemas se comunicaron, cuándo, durante cuánto tiempo, qué volumen de datos se transfirió y hacia dónde.
Incluso cuando el contenido está cifrado, los metadatos del tráfico revelan patrones de comportamiento críticos para la investigación.
Evidencia altamente volátil
El tráfico de red no capturado se pierde irremediablemente. A diferencia de un disco duro donde los datos eliminados pueden recuperarse parcialmente, un paquete de red no registrado desaparece. La configuración proactiva de sistemas de captura (taps de red, port mirroring, NetFlow) es esencial para disponer de evidencia forense cuando se produce un incidente.
Fundamentos técnicos
Modelo de captura de tráfico
La captura de tráfico de red puede realizarse en diferentes niveles, cada uno con distinto grado de detalle y requisitos de almacenamiento:
| Nivel de captura | Qué registra | Volumen de datos | Detalle forense |
|---|---|---|---|
| Full packet capture (FPC) | Todos los bytes de cada paquete | Muy alto (GB-TB/día) | Máximo: contenido completo de comunicaciones |
| Cabeceras de paquete | Solo cabeceras IP/TCP/UDP (sin payload) | Medio | IPs, puertos, flags TCP, tamaños |
| NetFlow/IPFIX | Resumen de flujos (IP origen/destino, puerto, bytes, duración) | Bajo | Metadatos de conexiones |
| Logs de firewall/proxy | Conexiones permitidas/denegadas | Bajo | Decisiones de acceso, URLs visitadas |
| DNS logs | Consultas y respuestas DNS | Bajo | Dominios resueltos por cada equipo |
Formato PCAP
El formato estándar para almacenar capturas de tráfico de red es PCAP (Packet Capture) y su versión moderna PCAPNG (PCAP Next Generation). Estos archivos guardan los bytes efectivamente capturados de cada paquete —la longitud capturada puede ser menor que la original—, incluyendo:
Estructura de un archivo PCAP:
+-------------------+
| Global Header | (magic number, version, timezone, max packet length)
+-------------------+
| Packet Header 1 | (timestamp, captured length, original length)
| Packet Data 1 | (bytes completos del paquete)
+-------------------+
| Packet Header 2 | (timestamp, captured length, original length)
| Packet Data 2 | (bytes completos del paquete)
+-------------------+
| ... |
+-------------------+Los archivos PCAP son la materia prima del análisis forense de red. La analogía con la imagen forense de disco ayuda, pero conviene no llevarla lejos: un pcap no es una copia bit a bit del cable. Si hay snaplen que trunca, descarga de segmentación en la tarjeta (offload) que altera lo que se ve, o pérdida de paquetes por saturación, lo que queda en el fichero difiere de lo que circuló.
Puntos de captura en la red
| Punto de captura | Método | Ventaja | Limitación |
|---|---|---|---|
| TAP de red (hardware) | Dispositivo físico en el cable | No consume recursos del equipo de red y es el método menos expuesto a pérdida de paquetes | Requiere acceso físico e instalación, y coste del hardware |
| Port mirroring (SPAN) | Configuración del switch | Sin hardware adicional, y se activa en remoto | El puerto espejo puede saturarse si agrega más tráfico del que soporta, y entonces descarta paquetes sin avisar |
| Host-based (en el equipo) | tcpdump, Wireshark en el endpoint | Ve tráfico descifrado localmente | Solo el tráfico de ese equipo |
| Inline (IDS/IPS) | Suricata, Snort en modo inline | Captura + detección en tiempo real | Punto único de fallo si falla el IDS |
| VPC Flow Logs (AWS) | Servicio cloud | Metadatos de flujo (5-tupla, paquetes, bytes) sin instalar nada | No contiene payload: no sirve para reconstruir contenido |
| Traffic Mirroring (AWS) | Servicio cloud | Copia el tráfico que coincide con el filtro, encapsulado en VXLAN — sí lleva el paquete completo | Filtros y cuotas del servicio, y el destino tiene que absorber el volumen |
Capacidad de almacenamiento
El volumen depende por completo del uso de la red, y no hay una cifra de referencia que sirva para planificar: hay que medirlo antes en la propia red. Lo que sí es seguro es el orden de magnitud del problema — una captura completa y prolongada exige varios órdenes más de almacenamiento. El patrón que resuelve el problema es combinar captura completa con retención corta y datos de flujo con retención larga, pero los días concretos se dimensionan midiendo la propia red: no hay un censo de cuántas organizaciones lo hacen ni una cifra universal de retención.
Técnicas de análisis forense de red
1. Análisis de flujos (flow analysis)
El análisis de flujos examina los metadatos de las conexiones de red sin entrar en el contenido de los paquetes. Es especialmente útil para detectar patrones anómalos a gran escala.
Qué revela un flujo NetFlow:
| Campo | Ejemplo | Información forense |
|---|---|---|
| IP origen | 192.168.1.45 | Equipo interno que inició la conexión |
| IP destino | 185.234.xx.xx | Servidor externo contactado |
| Puerto origen | 49152 | Puerto efímero (cliente) |
| Puerto destino | 443 | HTTPS (comunicación cifrada) |
| Protocolo | TCP | Tipo de transporte |
| Bytes enviados | 2,3 GB | Volumen transferido (posible exfiltración) |
| Bytes recibidos | 45 KB | Respuestas del servidor (asimetría sospechosa) |
| Inicio | 2026-02-09 02:15:23 | Hora de inicio (fuera de horario laboral) |
| Duración | 47 minutos | Conexión prolongada |
| TCP Flags | SYN, ACK, PSH, FIN | Conexión completa establecida |
Patrones sospechosos en flujos:
| Patrón | Descripción | Posible indicador de |
|---|---|---|
| Beaconing | Conexiones periódicas a intervalos regulares (ej. cada 60s) | Comunicación con C2 (Command and Control) |
| Transferencia asimétrica | Mucho tráfico saliente, poco entrante | Exfiltración de datos |
| Conexiones fuera de horario | Tráfico a las 3:00 AM desde estación de trabajo | Actividad automatizada maliciosa |
| Puertos inusuales | HTTPS en puerto 8443, DNS en puerto 5353 | Túneles encubiertos |
| Destinos geográficos anómalos | Conexiones a países sin relación comercial | Servidores de atacantes |
| DNS tunneling | Alto volumen de consultas DNS con subdominios largos | Exfiltración vía DNS |
2. Deep Packet Inspection (DPI)
El análisis profundo de paquetes examina el contenido (payload) de cada paquete para reconstruir comunicaciones, extraer archivos transferidos e identificar protocolos.
Información extraíble con DPI:
Protocolo HTTP (no cifrado):
- URLs completas visitadas
- Cabeceras HTTP (User-Agent, Cookies, Referer)
- Datos enviados en formularios (POST)
- Archivos descargados o subidos
- Credenciales en texto claro (si no hay HTTPS)
Protocolo DNS:
- Todos los dominios consultados por cada equipo
- Respuestas DNS (IPs resueltas)
- Consultas DNS sospechosas (exfiltración vía DNS)
- Fast-flux domains (IPs que cambian rápidamente)
Protocolo SMB/CIFS:
- Archivos compartidos accedidos
- Credenciales NTLM (hashes)
- Movimiento lateral entre equipos Windows
Protocolo SMTP (email no cifrado):
- Remitente y destinatario
- Asunto y cuerpo del mensaje
- Archivos adjuntosLimitación del cifrado
Con la adopción masiva de TLS/HTTPS, el contenido de la mayoría de comunicaciones no es visible mediante DPI. La medida más citada es la del Informe de Transparencia de Google, que en la semana del 26 de julio de 2026 registra un 95 % de páginas cargadas por HTTPS en Chrome sobre Windows, un 99 % en Android y ChromeOS, un 97 % en Mac y un 86 % en Linux. Conviene tomarla por lo que es: Google mide páginas cargadas en su propio navegador, no el tráfico total de internet —del que nadie tiene el censo—, y deja fuera el tráfico que no pasa por un navegador (aplicaciones móviles, IoT, protocolos de servidor a servidor).
Sin embargo, los metadatos (IPs, puertos, volúmenes, certificados TLS, SNI/Server Name Indication) siguen siendo analizables y proporcionan información forense significativa.
3. Análisis de protocolos
El análisis forense de protocolos específicos permite reconstruir actividades concretas:
| Protocolo | Herramienta principal | Artefactos forenses |
|---|---|---|
| HTTP/HTTPS | Wireshark, Fiddler | URLs, headers, archivos, credenciales |
| DNS | Wireshark, passivedns | Dominios resueltos, DNS tunneling |
| SMB | NetworkMiner, Wireshark | Archivos compartidos, autenticación NTLM |
| FTP | Wireshark | Archivos transferidos, credenciales en claro |
| SSH | Solo metadatos (cifrado) | IPs, duración, volumen, versiones |
| RDP | Solo metadatos si NLA | Sesiones remotas, IPs de acceso |
| ICMP | Wireshark | Túneles ICMP, exfiltración encubierta |
| SMTP | Wireshark, NetworkMiner | Emails en tránsito, adjuntos |
4. Detección de movimiento lateral en tráfico de red
La detección de movimiento lateral es una de las aplicaciones más críticas del análisis de tráfico de red en investigaciones de intrusiones:
| Indicador en tráfico | Protocolo | Significado |
|---|---|---|
| Estación A conecta por SMB a estación B | TCP/445 | Transferencia de archivos entre workstations (anómalo) |
| RDP entre estaciones de trabajo | TCP/3389 | Escritorio remoto entre PCs (no habitual) |
| WinRM entre equipos no administrados | TCP/5985/5986 | PowerShell remoting (posible herramienta de ataque) |
| PsExec (tráfico SMB con patrones específicos) | TCP/445 | Ejecución remota de comandos |
| Múltiples conexiones Kerberos desde un equipo | TCP/88 | Posible Pass-the-Ticket o Kerberoasting |
| Conexiones a muchos equipos en poco tiempo | Varios | Escaneo de red o propagación automática |
Caso práctico: exfiltración de datos vía DNS tunneling
Escenario ilustrativo
Escenario construido sobre una tipología real: muestra cómo se detecta y se acota una exfiltración por DNS y qué artefacto sostiene cada paso, no relata un expediente concreto. Los identificadores de equipo y las cifras son de ejemplo; la técnica sí es exacta.
Escenario
Una empresa de ingeniería con propiedad intelectual sensible (planos de diseño, patentes en trámite) detecta anomalías en su tráfico DNS. El volumen de consultas DNS ha aumentado un 400% en las últimas semanas, y los logs del servidor DNS interno muestran patrones inusuales.
Investigación forense
Fase 1: Identificación del tráfico anómalo
## Consulta DNS normal
Query: www.google.com
Type: A
Response: 142.250.185.206
## Consulta DNS sospechosa (DNS tunneling)
Query: aGVsbG8gd29ybGQ.data.atacante-c2-server.invalid
Type: TXT
Response: TXT "dGhpcyBpcyB0aGUgcmVzcG9uc2U="
## El subdominio contiene datos codificados en Base64:
## "aGVsbG8gd29ybGQ" = "hello world" (ejemplo simplificado)
## En la práctica, fragmentos de archivos exfiltradosFase 2: Análisis de la captura pcap
Filtrar tráfico DNS en Wireshark: Aplicar filtro
dnsy ordenar por volumen de consultas por equipo de origen. Identificar el equipo PC-ING-07 como fuente del 85% de las consultas DNS anómalas.Analizar los subdominios consultados: Extraer los subdominios únicos y detectar que todos contienen cadenas codificadas en Base64 dirigidas al dominio
data.atacante-c2-server.invalid, registrado hace 2 semanas con datos de registro anonimizados (Cloudflare).Decodificar los datos exfiltrados: Concatenar las cadenas Base64 de los subdominios en orden cronológico y decodificarlas. El resultado revela fragmentos de archivos CAD (planos de diseño) y documentos PDF internos.
Reconstruir el timeline de exfiltración: Correlacionar los timestamps de las consultas DNS con la actividad del equipo PC-ING-07 (logs de Windows, actividad del usuario). Determinar que la exfiltración ocurre automáticamente cada 15 minutos durante horario laboral.
Identificar el malware responsable: Análisis forense del equipo PC-ING-07 revela un proceso oculto que monitoriza carpetas específicas del proyecto y exfiltra nuevos archivos vía DNS.
Cuantificar el impacto: Calcular el volumen total de datos exfiltrados basándose en el tamaño de las consultas DNS. Identificar exactamente qué archivos fueron comprometidos.
Fase 3: Timeline reconstruido
| Fecha | Evento | Evidencia |
|---|---|---|
| 25 Ene 2026 | Email de spear phishing recibido por ingeniero | Logs del servidor de correo |
| 25 Ene 2026 | Malware instalado en PC-ING-07 | Artefactos forenses del equipo |
| 26 Ene 2026 | Primera exfiltración vía DNS tunneling | Logs DNS: primeras consultas anómalas |
| 26 Ene - 9 Feb | Exfiltración cada 15 minutos en horario laboral | 2.847 consultas DNS con datos codificados |
| 9 Feb 2026 | Detección por anomalía en volumen DNS | Alerta del equipo de sistemas |
Fase 4: Cuantificación
| Métrica | Valor |
|---|---|
| Consultas DNS anómalas totales | 2.847 |
| Volumen estimado exfiltrado | 147 MB |
| Archivos comprometidos | 23 planos CAD + 8 documentos internos |
| Duración de la exfiltración | 15 días |
| Dominio C2 | data.atacante-c2-server.invalid (registrado 23 Ene 2026) |
Valor del análisis de tráfico
Sin captura de tráfico DNS, esta exfiltración es mucho más difícil de ver, aunque no invisible: deja rastro en los registros del propio resolutor y, si la organización los conserva, ahí está el volumen anómalo de consultas. El malware no generó alertas de antivirus, no accedió a servidores no autorizados y utilizó DNS (puerto 53), un protocolo siempre permitido en firewalls corporativos. Solo el análisis de los patrones de tráfico reveló la actividad maliciosa.
Marco legal en España
Licitud de la captura de tráfico
La captura y análisis de tráfico de red en el ámbito corporativo está sujeta a regulación específica:
| Contexto | Marco legal | Qué exige realmente |
|---|---|---|
| Red corporativa | Art. 20.3 ET + art. 87 LOPDGDD | El ET permite medidas de vigilancia y control «guardando en su adopción la consideración debida a su dignidad»; el art. 87 LOPDGDD exige criterios de uso, garantías de intimidad e información previa a los trabajadores. Una política de uso no basta por sí sola: hace falta además base del art. 6 RGPD, finalidad, necesidad, proporcionalidad y minimización |
| Instrucción penal | Arts. 588 bis a y 588 ter a, b y j LECrim | Autorización judicial y los principios de especialidad, idoneidad, excepcionalidad, necesidad y proporcionalidad del 588 bis a. La interceptación de comunicaciones y el acceso a datos de tráfico tienen sus preceptos propios dentro de la serie |
| Respuesta a incidentes | Arts. 32 y 33 RGPD + art. 6.1.f | El 32 exige seguridad adecuada al riesgo y el 33 regula la notificación de brechas. Ninguno de los dos es la base de licitud: el interés legítimo es el art. 6.1.f, y no se puede colgar del 32 ni del 33 |
| Redes ajenas / interceptación | Art. 197.1 y 197 bis.2 CP + art. 58 LGTel | El 197.1 castiga interceptar telecomunicaciones para descubrir secretos o vulnerar la intimidad, sin consentimiento, con prisión de uno a cuatro años y multa de doce a veinticuatro meses; el 197 bis.2 cubre las transmisiones no públicas de datos. El art. 58 LGTel obliga a los operadores a ejecutar las interceptaciones judicialmente autorizadas: no convierte en delito capturar en red propia |
Requisitos para que la evidencia de red sea admisible
| Requisito | Cómo cumplirlo |
|---|---|
| Integridad | Hash SHA-256 del archivo pcap inmediatamente tras la captura |
| Autenticidad | Documentar punto de captura, configuración del TAP/mirror, timestamps NTP |
| Cadena de custodia | Registro de quién accede a los archivos pcap y cuándo |
| Proporcionalidad | Capturar solo lo necesario, minimizar datos personales |
| Licitud | Política corporativa informada o autorización judicial |
Referencia a ISO 27037
La ISO/IEC 27037:2012 es la guía de identificación, recogida, adquisición y preservación de evidencia digital. Su texto oficial no es de acceso abierto, así que no se le atribuyen aquí recomendaciones concretas sobre tráfico de red: citar una norma sin haber leído su tenor literal es precisamente lo que la contraparte verifica primero.
Lo que sí está publicado y es citable son estas prácticas, recogidas en NIST SP 800-86 y en la RFC 3227:
- Priorizar la captura de tráfico en vivo por el orden de volatilidad, antes que la adquisición de discos
- Documentar la topología de red y los puntos de captura
- Sincronizar las marcas de tiempo con fuentes NTP verificables
- Mantener la cadena de custodia desde el momento de la captura
Y una precisión que se repite mal: el bloqueador de escritura se aplica al medio que se clona, no al fichero pcap que se está escribiendo. Un pcap en curso de captura no puede estar en un medio de solo lectura, por definición.
Interceptación de comunicaciones
La interceptación de comunicaciones privadas sin autorización judicial está tipificada en el artículo 197 del Código Penal con penas de 1 a 4 años de prisión. En el ámbito empresarial, la captura de tráfico es lícita si existe política de uso aceptable informada y se respeta el principio de proporcionalidad, pero debe distinguirse claramente de la interceptación de comunicaciones personales del empleado.
Herramientas forenses de análisis de red
Captura de tráfico
| Herramienta | Tipo | Función principal | Sistema operativo |
|---|---|---|---|
| tcpdump | CLI | Captura ligera de paquetes en línea de comandos | Linux/macOS |
| Wireshark (dumpcap) | GUI/CLI | Captura con interfaz gráfica avanzada | Multiplataforma |
| Moloch/Arkime | Servidor | Full packet capture a gran escala con indexación | Linux |
| Stenographer (histórico) | Servidor | Captura continua a disco; proyecto de Google archivado el 4 de noviembre de 2022, repositorio en solo lectura | No usar en despliegues nuevos: el hueco lo cubre Arkime |
Análisis de paquetes
| Herramienta | Especialidad | Uso forense principal |
|---|---|---|
| Wireshark | Análisis de paquetes individual | Reconstruir sesiones, extraer archivos, analizar protocolos |
| tshark | Versión CLI de Wireshark | Procesamiento automatizado de pcaps grandes |
| NetworkMiner | Extracción de artefactos | Recuperar imágenes, archivos, credenciales del tráfico |
| Zeek (antes Bro) | Metadatos de conexiones | Generar logs estructurados de actividad de red |
| Suricata | Detección de amenazas | Aplicar reglas de detección sobre capturas pcap |
Análisis de flujos
| Herramienta | Función |
|---|---|
| nfdump / nfsen | nfdump analiza flujos; nfsen es código legado de visualización |
| SiLK | Suite de análisis de flujos del CERT/CC |
| RITA (Real Intelligence Threat Analytics) | Detección de beaconing y DNS tunneling |
| ElastiFlow | Colector de NetFlow, IPFIX y sFlow |
Análisis avanzado
| Herramienta | Especialidad |
|---|---|
| PcapXray | Visualización gráfica de comunicaciones en pcap |
| CapAnalysis (sin cambios desde 2018) | Análisis estadístico web de archivos pcap |
| Xplico (pie del sitio en 2021) | Reconstrucción automática de sesiones (email, HTTP, VoIP) |
| passivedns | Registra respuestas DNS para alimentar un DNS pasivo |
Filtros de Wireshark esenciales para forense
En investigaciones forenses con Wireshark, estos filtros permiten aislar rápidamente la actividad relevante:
| Filtro | Función |
|---|---|
ip.addr == 192.168.1.45 | Todo el tráfico de un equipo específico |
dns.qry.name contains "atacante" | Consultas DNS a dominio sospechoso |
tcp.port == 4444 | Conexiones en puerto típico de reverse shell |
http.request.method == "POST" | Envíos de datos HTTP (formularios, exfiltración) |
smb2 | Tráfico SMB (movimiento lateral en Windows) |
tcp.flags.syn == 1 and tcp.flags.ack == 0 | Escaneos de puertos (solo paquetes SYN) |
frame.len > 1400 | Paquetes grandes (posible transferencia de archivos) |
dns.qry.type == 16 | Consultas DNS TXT (DNS tunneling) |
tcp.analysis.retransmission | Retransmisiones TCP (problemas de red o evasión) |
Limitaciones del análisis forense de red
Cifrado
El cifrado TLS/HTTPS impide acceder al contenido de la comunicación sin las claves privadas. Alternativas:
| Situación | Solución parcial |
|---|---|
| Servidor propio, sesión sin forward secrecy (RSA estático, TLS ≤1.2) | La clave privada sí descifra en Wireshark. Es el caso cada vez más raro |
| TLS con forward secrecy —(EC)DHE, y siempre en TLS 1.3— | La clave privada del servidor no descifra: haría falta el secreto de sesión (SSLKEYLOGFILE), una PSK, o terminar TLS en un punto instrumentado |
| Proxy corporativo con SSL inspection | El proxy tiene acceso al contenido |
| Tráfico cifrado sin acceso a claves | Análisis de metadatos (JA3 fingerprint, SNI, certificados) |
Volumen de datos
La captura de paquetes completa genera volúmenes enormes. El orden de magnitud sale de una cuenta, no de una medición: 1 Gbps × 30 % sostenido × 86.400 s ÷ 8 = 3,24 TB decimales al día, y eso antes de descontar overhead, filtros, truncado por snaplen, pérdidas y compresión. En una red real el número se mide, no se hereda. Las estrategias de mitigación incluyen captura selectiva, rotación de archivos pcap y uso combinado de full capture (corto plazo) con NetFlow (largo plazo).
Fragmentación y evasión
Atacantes sofisticados pueden utilizar técnicas de evasión:
| Técnica de evasión | Descripción | Contramedida forense |
|---|---|---|
| Fragmentación de paquetes | Dividir payloads maliciosos entre múltiples fragmentos | Reensamblaje con Wireshark/Suricata |
| Cifrado personalizado | Protocolos de comunicación cifrados no estándar | Análisis de patrones y entropía |
| Esteganografía de red | Ocultar datos en campos de protocolo no utilizados | Análisis estadístico de anomalías |
| Covert channels | Comunicación vía DNS, ICMP, o campos TCP opcionales | Análisis de volumen y patrones |
Relación con otros conceptos
El análisis de tráfico de red se conecta con múltiples disciplinas del peritaje informático forense:
Dirección IP: Las direcciones IP de origen y destino son el dato fundamental de toda captura de tráfico de red, permitiendo identificar los equipos involucrados en la comunicación y su ubicación geográfica aproximada.
Trazabilidad de IPs: El análisis de tráfico proporciona la evidencia técnica necesaria para la trazabilidad de IPs, documentando las conexiones establecidas con timestamps verificables que permiten solicitar información a ISPs y proveedores de servicios.
Movimiento lateral: La detección de movimiento lateral en la red (conexiones SMB entre estaciones, RDP anómalo, PsExec) es una de las aplicaciones más críticas del análisis forense de tráfico de red en investigaciones de intrusiones.
Logs de sistema: Los logs del sistema operativo, del firewall y del IDS/IPS complementan las capturas de tráfico, proporcionando contexto adicional sobre las conexiones observadas (usuario asociado, proceso que inició la conexión, reglas de firewall aplicadas).
Data exfiltration: El análisis de tráfico de red es la técnica principal para detectar y cuantificar la exfiltración de datos, identificando transferencias anómalas de volumen, destinos sospechosos y canales encubiertos como DNS tunneling.
¿Necesitas analizar tráfico de red como parte de una investigación forense? Contacta con Digital Perito para un análisis forense de red documentado y ratificable en sala.
Última actualización: 29 de agosto de 2026 Categoría: Técnico Código: NET-001
¿Tienes un caso con evidencia digital de por medio?
Una valoración previa dice qué evidencia existe, en qué estado está y si es técnicamente preservable, antes de invertir en el procedimiento.
Referencias y fuentes
- Google — Informe de Transparencia: cifrado HTTPS en la web. Porcentajes de tráfico cifrado por plataforma, actualizados semanalmente: conviene citar la fecha de consulta, porque el dato cambia.
- ISO/IEC 27037:2012 — principios de identificación, recogida, adquisición y preservación de la evidencia digital, de los que se derivan las prioridades de captura en red.
- RFC 1035 — Domain Names — Implementation and Specification, IETF: estructura de la consulta DNS que hace posible el tunneling.
- MITRE ATT&CK — T1071.004: Application Layer Protocol: DNS, técnica catalogada con sus contramedidas de detección.
Preguntas Frecuentes
¿Qué es el análisis forense de tráfico de red?
Es el proceso de capturar, registrar y analizar el tráfico que circula por una red informática para detectar intrusiones, reconstruir comunicaciones, identificar exfiltración de datos y documentar el incidente con procedimientos orientados a preservar su valor probatorio. La admisión de la prueba la valora el tribunal.
¿Qué herramientas se usan para capturar tráfico de red?
Las principales son Wireshark (análisis gráfico de paquetes), tcpdump (captura en línea de comandos), Zeek/Bro (metadatos de conexiones), NetworkMiner (extracción de artefactos) y NetFlow/sFlow (estadísticas de flujos a nivel de router).
¿Puede un perito informático recuperar el contenido de comunicaciones cifradas?
Desde un punto que solo ve el tramo cifrado, no. Y conviene deshacer un equívoco extendido: la clave privada del servidor no basta, porque con forward secrecy —(EC)DHE, y siempre en TLS 1.3— no descifra la sesión. Harían falta los secretos de sesión (SSLKEYLOGFILE), una PSK, o terminar TLS en un punto instrumentado. Los metadatos (IP de origen y destino, puertos, volúmenes, horarios) sí son analizables y aportan información forense valiosa.
Términos Relacionados
Dirección IP
Identificador numérico único asignado a cada dispositivo conectado a una red, que permite rastrear el origen de conexiones y actividades en Internet.
Trazabilidad de IPs
Proceso de identificar el origen geográfico, proveedor y potencialmente el usuario detrás de una dirección IP utilizada en actividades ilícitas o sospechosas.
Movimiento Lateral
Técnicas utilizadas por atacantes para desplazarse de un sistema comprometido a otros dentro de la misma red, escalando privilegios y ampliando el alcance del ataque.
Logs de Sistema
Archivos que registran automáticamente eventos del sistema operativo, aplicaciones y servicios. Son fuente primaria de evidencia forense para reconstruir actividades, detectar intrusiones y establecer timelines de incidentes.
Data Exfiltration
Extracción no autorizada de datos desde los sistemas de una organización hacia ubicaciones externas controladas por el atacante o empleado desleal.
¿Necesitas un peritaje forense?
Si necesitas ayuda profesional con análisis forense digital, estoy aquí para ayudarte.
Solicitar Consulta Gratuita
