El Análisis Forense de Red en la Respuesta a Incidentes
En el ecosistema de la ciberseguridad defensiva, los registros de eventos (logs) generados por sistemas operativos y soluciones EDR proporcionan una visión valiosa pero a menudo incompleta de un compromiso. Los atacantes avanzados manipulan el visor de eventos de Windows, limpian los archivos de log en Linux (/var/log/syslog) o eluden las alertas mediante técnicas de evasión en memoria (living-off-the-land).
Sin embargo, hay una superficie que ningún actor malicioso puede manipular retrospectivamente una vez que el tráfico ha sido capturado: la red.
El análisis forense de red (Network Forensics) consiste en la captura, inspección y reconstrucción de paquetes de datos transmitidos a través de la infraestructura para determinar con precisión matemática la cronología de un incidente, el vector inicial de acceso, la exfiltración de información y las comunicaciones con la infraestructura de comando y control (C2).
En esta guía técnica abordamos el flujo completo de análisis forense sobre capturas de paquetes (archivos PCAP/PCAPNG): desde la disección avanzada de protocolos en puertos no estándar con Wireshark y el filtrado semántico de tráfico malicioso, hasta el análisis de flujos TLS mediante huellas JA4, la disección de ataques de phishing Adversary-in-the-Middle (AitM) y los estándares de sanitización de medios bajo la normativa NIST SP 800-88.
Flujo Metodológico de Triage Forense de Red
La investigación de un incidente a nivel de red sigue una metodología estructurada que abarca desde la captura bruta hasta la extracción de indicadores de compromiso (IoCs):
flowchart TD
subgraph Capture_Phase ["1. Adquisicion de Evidencia"]
A[Alerta SIEM / EDR / IDS] --> B[Captura de Paquetes Full Packet Capture<br/>tcpdump / tshark / TAP de Red]
B --> C[Sellado Criptografico de la Muestra<br/>Hash SHA-256 / Cadena de Custodia]
end
subgraph Triage_Phase ["2. Triage y Diseccion con Wireshark"]
C --> D[Aplicacion de Filtros BPF y Display Filters]
D --> E{¿Puerto no estandar?}
E -->|Si| F[Forzar Diseccion: Decode As...]
E -->|No| G[Analisis de Flujo TCP / Reensamblado]
end
subgraph Inspection_Phase ["3. Analisis Criptografico y de Protocolo"]
F --> H[Inspeccion de Metadatos TLS 1.3 / SNI]
G --> H
H --> I[Extraccion de Huellas JA3 / JA4]
I --> J[Reconstruccion de Sesiones y Objetos HTTP]
end
subgraph Output_Phase ["4. Mitigacion y Cadena de Custodia"]
J --> K[Extraccion de IoCs: IPs, Dominios, Payloads]
K --> L[Reglas de Bloqueo Firewall / SIEM / EDR]
L --> M[Sanitizacion de Medios Forenses NIST SP 800-88]
end
classDef capture fill:#181825,stroke:#f38ba8,stroke-width:2px,color:#cdd6f4;
classDef triage fill:#1e1e2e,stroke:#6366f1,stroke-width:2px,color:#cdd6f4;
classDef inspect fill:#181825,stroke:#a6e3a1,stroke-width:2px,color:#cdd6f4;
classDef output fill:#181825,stroke:#f9e2af,stroke-width:2px,color:#cdd6f4;
class Capture_Phase capture;
class Triage_Phase triage;
class Inspection_Phase inspect;
class Output_Phase output;1. Wireshark en Profundidad: Triage y Disección de Puertos No Estándar
Wireshark organiza el tráfico basándose en la lista de puertos asignados por la IANA (well-known ports). Por defecto, interpreta el tráfico TCP en el puerto 80 como HTTP, el 443 como TLS y el 3868 como DIAMETER.
En incidentes reales, los atacantes o los servicios corporativos legados a menudo transmiten protocolos sobre puertos no convencionales para evadir sistemas de inspección básica (por ejemplo, túneles SSH sobre el puerto 443 o APIs HTTP en el puerto 8443 o 3879). Ante esto, Wireshark presenta una trama genérica de bytes hexadecimales.
La Función "Decode As..."
Para forzar al motor de Wireshark a aplicar el analizador sintáctico (dissector) correspondiente:
- Localiza el paquete sospechoso en la ventana principal de captura.
- Haz clic derecho y selecciona la opción "Decode As...".
- En la tabla de mapeo, verifica que el campo Field corresponda al puerto en cuestión (ej.
TCP port 3879). - En la columna Current, selecciona el protocolo deseado (ej.
HTTP,TLSoDIAMETER). - Al pulsar Apply, Wireshark reinterpreta toda la conversación TCP en memoria, desglosando las cabeceras estructuradas, parámetros AVP o solicitudes REST.
Filtros de Visualización Forenses Esenciales
A diferencia de los filtros de captura (escritos con sintaxis BPF antes de registrar los paquetes), los filtros de visualización (Display Filters) permiten interrogar interactivamente capturas voluminosas:
- Aislamiento de beacons y solicitudes web salientes:
http.request or (tls.handshake.type == 1)- Detección de túneles DNS y exfiltración de datos:
Las técnicas de DNS Tunneling generan consultas con cadenas codificadas en Base64 o hexadecimal muy largas como subdominios:
dns.flags.response == 0 and dns.qry.name.len > 50- Búsqueda de intentos de inyección y respuestas de error HTTP:
http.response.code >= 400 or http.request.uri matches "(?i)(\\.\\./|union|select|script)"- Identificación de conexiones con anomalías de ventana TCP:
Útil para detectar escaneos de puertos SYN stealth o ataques de denegación de servicio:
tcp.flags.syn == 1 and tcp.flags.ack == 0 and tcp.window_size <= 10242. Análisis Forense de Tráfico TLS y Huellas JA4
Con el 95% del tráfico web protegido por TLS 1.2 y TLS 1.3, los analistas de seguridad deben extraer inteligencia sin necesidad de descifrar el contenido.
Qué revela el Handshake de TLS en Texto Plano:
Durante la negociación inicial de la sesión, antes de que se establezca la clave simétrica efímera (mediante ECDHE), el cliente envía el paquete Client Hello en texto plano. Este paquete contiene artefactos críticos:
- SNI (Server Name Indication): El nombre de dominio completo (FQDN) al que el cliente intenta conectarse (por ejemplo,
login.microsoftonline.com.phishing-site.ru). - Cipher Suites: La lista exacta de algoritmos criptográficos soportados por el binario que inició la conexión.
- Extensiones TLS y Grupos de Curvas Elípticas: Las capacidades del stack de red del cliente.
Fingerprinting de Clientes con JA3 y JA4
Diferentes aplicaciones generan listas de extensiones y suites criptográficas en órdenes distintos. Un navegador Google Chrome en Windows tiene una huella criptográfica distinta a un script malicioso en Python (requests), a una consola de PowerShell o a un implante de Cobalt Strike.
El estándar JA4 calcula un hash criptográfico a partir de estos parámetros:
- Si el tráfico aparenta provenir de un navegador legítimo pero su huella JA4 coincide con la de la librería
go-http-clientocurl, el analista puede confirmar con alta certeza que se trata de un proceso automatizado malicioso.
Descifrado Forense en Laboratorio (SSLKEYLOGFILE)
En entornos de pruebas controladas, auditorías o análisis de malware dinámico, es posible descifrar sesiones TLS registrando las claves de sesión efímeras.
Configurando la variable de entorno en el cliente:
export SSLKEYLOGFILE=/tmp/tls_session_secrets.log
google-chrome --user-data-dir=/tmp/test-profile &Posteriormente, en Wireshark:
- Accede a Edit → Preferences → Protocols → TLS.
- En el campo (Pre)-Master-Secret log filename, selecciona el archivo
/tmp/tlssessionsecrets.log. - Wireshark descifrará instantáneamente las sesiones TLS 1.2 y 1.3 asociadas, mostrando el tráfico HTTP/2 y las cabeceras decrypted en texto claro.
3. Disección Forense de un Ataque de Phishing AitM (Adversary-in-the-Middle)
Los ataques de phishing tradicionales (que se limitaban a clonar una página web y capturar credenciales en un script PHP) han quedado obsoletos frente a la adopción generalizada de la autenticación multifactor (MFA).
Hoy, los ataques avanzados operan bajo la modalidad Adversary-in-the-Middle (AitM) utilizando herramientas como Evilginx, Muraena o Modlishka.
Cómo Opera un Proxy Inverso Malicioso AitM:
- El atacante registra un dominio señuelo (por ejemplo,
login.micros0ft-verify.com) y despliega un servidor proxy inverso transparente. - La víctima hace clic en el enlace malicioso y se conecta al proxy del atacante.
- El proxy se conecta en tiempo real al proveedor de identidad legítimo (ej. Microsoft Entra ID o Google Workspace).
- El proxy retransmite todos los desafíos legítimos (incluyendo peticiones de código TOTP o alertas de Microsoft Authenticator) a la víctima.
- Cuando la víctima completa con éxito el MFA, el servidor de identidad legítimo emite una cookie de sesión de autenticación (
ESTSAUTH,__Secure-o token JWT de sesión). - El proxy intercepta y almacena esta cookie antes de redirigir a la víctima a su bandeja de entrada real. Con esta cookie, el atacante secuestra la sesión sin necesidad de volver a pedir el MFA ni conocer la contraseña.
sequenceDiagram
autonumber
actor V as Victima (Navegador)
participant P as Proxy AitM (Evilginx)
participant IdP as Servidor de Identidad Legitime (IdP)
V->>P: 1. Peticion HTTP inicial al dominio senuelo
P->>IdP: 2. Proxy reenvia la llamada al IdP real
IdP-->>P: 3. Formulario de usuario y desafio MFA
P-->>V: 4. Presenta el portal autentico clonado en vivo
V->>P: 5. Usuario introduce credenciales y codigo MFA
P->>IdP: 6. Proxy inyecta credenciales y MFA en el IdP
IdP-->>P: 7. IdP valida MFA y emite Cookie de Sesion Valida
Note over P: Proxy intercepta y guarda la Cookie de Sesion
P-->>V: 8. Redirige a la victima al portal corporativo real
Note over P: Atacante utiliza la cookie para acceder como el usuarioIndicadores Forenses en la Captura de Red (PCAP):
Al investigar una captura forense sospechosa de un ataque AitM, destacan tres patrones clave:
- Discrepancia en Tiempos de Ida y Vuelta (TCP RTT): Como el proxy actúa como intermediario entre la víctima y el IdP legítimo, el tiempo transcurrido entre una solicitud HTTP POST y su respuesta experimenta un retraso detectable frente a una conexión directa.
- Cabeceras de Proxy en la Sesión: Presencia de cabeceras añadidas o alteradas en las peticiones (
X-Forwarded-For,X-Real-IP, cabecerasHostreescritas). - Defensa Definitiva: FIDO2 y Passkeys: Este vector demuestra por qué los segundos factores basados en códigos SMS o apps de autenticación TOTP son vulnerables. Solo las llaves de seguridad físicas FIDO2 / WebAuthn, analizadas en nuestra guía sobre Autenticación vs. Autorización, son inmunes a ataques AitM al vincular criptográficamente el handshake con el dominio del navegador.
4. Cadena de Custodia y Sanitización de Medios (NIST SP 800-88)
Una investigación forense carece de validez legal si se vulnera la cadena de custodia de las evidencias o si los dispositivos de almacenamiento no se tratan con rigor metodológico.
Preservación de la Muestra (RFC 3227)
Antes de analizar un archivo PCAP o una imagen de disco con Wireshark o Autopsy:
- Generación Inmediata de Hash: Calcula los resúmenes SHA-256 de los artefactos originales:
sha256sum evidencia_red_20261027.pcapng > evidencia_red_20261027.pcapng.sha256- Análisis sobre Copias de Trabajo: Nunca se investiga directamente sobre el archivo original. Se extrae una copia de trabajo y se verifica que su hash coincide con el sellado inicial.
Sanitización Segura de Medios: Más Allá del Simple Formateo
Cuando un dispositivo de almacenamiento, estación forense o servidor cloud finaliza su ciclo de vida, un simple formateo o la ejecución de rm -rf es completamente insuficiente. Estas operaciones se limitan a desvincular los punteros de la tabla de asignación de archivos; los bloques físicos retienen los datos en crudo, siendo trivialmente recuperables con software de carving forense.
El estándar NIST SP 800-88 Rev. 1 define tres niveles de sanitización:
- Clear (Limpieza lógica): Sobreescritura lógica de los sectores de datos accesibles al usuario.
- Purge (Purga): Métodos que impiden la recuperación de datos mediante técnicas avanzadas de laboratorio (incluyendo sectores reasignados o bloques de repuesto).
- Destroy (Destrucción física): Trituración mecánica, desmagnetización (degaussing) o incineración.
Herramientas de Sobreescritura en Linux:
Para dispositivos de almacenamiento mecánico o discos virtuales:
# Sobreescritura criptografica con shred (3 pasadas aleatorias y 1 con ceros)
sudo shred -v -n 3 -z /dev/sdb
# Sobreescritura con dd utilizando el generador de entropia del kernel
sudo dd if=/dev/urandom of=/dev/sdb bs=4M status=progress conv=fdatasyncLa Particularidad de las Unidades SSD y NVMe:
En discos modernos de estado sólido (SSD / NVMe), el controlador utiliza algoritmos de nivelación de desgaste (Wear Leveling) y sobreaprovisionamiento (Over-provisioning). Esto significa que comandos como dd o shred no pueden garantizar la sobreescritura de todos los bloques de memoria flash físicos.
Para unidades NVMe y SSD modernas, se deben utilizar las funciones nativas del firmware:
# Verificacion de soporte de formateo criptografico en unidad NVMe
sudo nvme id-ctrl /dev/nvme0 | grep -E "fna|sanicap"
# Ejecutar borrado seguro criptografico nativo (Cryptographic Erase)
sudo nvme format /dev/nvme0 -n 1 --ses=2Conclusión
El análisis forense de tráfico de red y la gestión de evidencias constituyen la última línea de defensa en la respuesta ante incidentes. Comprender cómo inspeccionar protocolos en puertos no estándar con Wireshark, correlacionar metadatos TLS y huellas JA4, y neutralizar vectores avanzados como el phishing AitM permite a los equipos de seguridad contener brechas antes de que deriven en exfiltraciones masivas.
Integrar estas prácticas forenses con una política rigurosa de Hardening de Servidores SSH, arquitecturas de contenedores aisladas según detalla nuestra guía sobre Arquitectura y Seguridad en Docker y defensas activas en Pipelines DevSecOps consolida un marco de ciberseguridad resiliente y maduro.
Si tu equipo necesita formación en análisis forense de red, auditorías de tráfico para entornos corporativos o consultoría especializada en respuesta a incidentes y prevención de phishing avanzado, puedes explorar mis Servicios de Ciberseguridad y Consultoría o ponerte en contacto directamente conmigo en mi perfil Sobre mí.