Análisis DNS en un PCAP: guía para defensores
Cómo leer el DNS en una captura de red: consultas y respuestas, códigos de resultado, dominios raros o aleatorios y señales de tunelización DNS y sus límites.
En resumen. El DNS es el mejor punto de partida en casi cualquier captura: es ligero, casi siempre va sin cifrar y dice qué pretendía alcanzar cada host. Empieza por identificar los resolvers, lee después los nombres consultados, sus códigos de resultado y respuestas, y vincula las respuestas con las conversaciones que siguen. Presta atención a los nombres consultados una sola vez, a las ráfagas de NXDOMAIN para nombres de aspecto aleatorio y a los muchos subdominios largos y únicos bajo un mismo dominio. Esos patrones apuntan a algoritmos de generación de dominios y a tunelización DNS, pero las CDN, los productos de seguridad y los navegadores producen imitaciones, así que trátalos como pistas que confirmar.
El DNS en una captura: lo básico
Un intercambio DNS suele ser una consulta y una respuesta por el puerto UDP 53, emparejadas por un identificador de transacción de 16 bits. Las respuestas grandes y las transferencias de zona usan TCP. La RFC 1035 define el formato de los mensajes y los límites que conviene recordar: una etiqueta (el texto entre dos puntos) tiene como máximo 63 octetos, y un nombre completo, 255.
Los campos que más leerás:
| Campo | Qué te dice |
|---|---|
| Nombre consultado (QNAME) | Qué quería alcanzar el cliente |
| Tipo de consulta | A / AAAA (direcciones), CNAME (alias), MX, TXT, NS, PTR, SRV... |
| Código de resultado (RCODE) | NOERROR, NXDOMAIN (el nombre no existe), SERVFAIL, REFUSED |
| Respuestas | Direcciones, alias o texto devueltos, cada uno con un TTL |
| Cliente y servidor | Qué host preguntó y qué resolver respondió |
Como los resolvers guardan las respuestas en caché durante el TTL, una captura muestra la primera resolución de un nombre, no cada visita. Un host que reutiliza una dirección en caché genera conexiones sin consulta correspondiente en la captura.
Un orden de lectura que funciona
1. Identificar los resolvers
Lista los servidores que responden en el puerto 53. En una red gestionada, los clientes deberían usar los resolvers internos. Un equipo que envía sus consultas directamente a un resolver externo se salta el registro y el filtrado. Busca también DNS sobre TLS en el puerto 853 (RFC 7858) y recuerda que DNS sobre HTTPS (RFC 8484) parece HTTPS normal; el SNI TLS de proveedores DoH conocidos suele ser la única pista visible.
2. Leer los nombres, agrupados por dominio registrable
Agrupa las consultas por dominio registrable (mega.co.nz en lugar de gfs270n.userstorage.mega.co.nz) y cuéntalas. La mayor parte de la lista serán servicios del sistema operativo, del navegador y del negocio. Lo que queda es donde suele estar la historia: servicios para compartir archivos, imitaciones recién registradas de tus propios dominios, proveedores de DNS dinámico.
3. Revisar los códigos de resultado
Unas pocas respuestas NXDOMAIN son normales (errores tipográficos, sufijos de búsqueda obsoletos). Un grupo de ellas desde un mismo host, para nombres que parecen generados por una máquina, no lo es.
4. Vincular respuestas y conversaciones
Para cada nombre interesante, toma las direcciones devueltas y busca las conversaciones hacia ellas justo después de la resolución. Un nombre que se resolvió y luego se contactó es una prueba más sólida que una consulta aislada. Lo contrario también importa: las conexiones a direcciones públicas sin consulta previa pueden usar una IP fija en el código.
Detectar dominios inusuales
Nombres poco vistos
La frecuencia es un filtro sorprendentemente bueno. Un dominio registrable que aparece una sola vez en una captura, y que no es un servicio de fondo habitual, merece una lectura. PCAP Parser los marca como Rarely-seen domain, excluyendo sufijos locales como .local o .corp y una breve lista de servicios comunes. Eso sí, en una captura corta todo es raro, así que esta marca resulta más útil en grabaciones largas.
Nombres largos y de aspecto aleatorio
Los nombres elegidos por personas están hechos de palabras; los generados por máquinas, no. Una forma sencilla de medirlo es la entropía de Shannon: el número medio de bits necesarios por carácter. Las etiquetas parecidas al inglés puntúan más bajo que las formadas por letras y dígitos mezclados de manera uniforme. PCAP Parser marca un nombre como Random-looking / long cuando una etiqueta de 12 caracteres o más tiene una entropía de al menos 3,4 bits por carácter, o cuando el nombre completo supera los 60 caracteres.
La captura de ejemplo ficticia de la herramienta muestra el patrón. El equipo consulta dos nombres que fallan:
q3v9x7kz2m8w4t1r0p6y.info A NXDOMAIN
k7f2p9x4w1q8z3m6hd0s.top A NXDOMAIN
Ambos aparecen marcados como aleatorios y poco vistos. Ninguno se resolvió, así que no hubo conexión posterior, pero el host que los envió pasa a ser prioritario.
Algoritmos de generación de dominios
Algunas familias de malware calculan una lista de dominios candidatos a partir de una semilla, a menudo la fecha, y los prueban hasta que uno se resuelve. MITRE ATT&CK lo describe como Dynamic Resolution: Domain Generation Algorithms (T1568.002). En el tráfico se parece al ejemplo anterior, a mayor escala: muchos nombres aleatorios, casi todos NXDOMAIN, desde un único host, a menudo a intervalos regulares.
Indicadores de tunelización DNS, a grandes rasgos
La tunelización DNS abusa del protocolo para transportar datos: el cliente codifica datos en las etiquetas de consultas a un dominio cuyo servidor autoritativo controla la otra parte, y el servidor responde con datos codificados en las respuestas. MITRE ATT&CK recoge el DNS como canal de mando y control de capa de aplicación en T1071.004.
Desde el punto de vista del defensor, los indicadores en una captura son:
- Muchos subdominios únicos bajo un mismo dominio registrable, cada uno consultado una vez.
- Etiquetas y nombres largos, cerca de los límites de 63 y 255 octetos, con alta entropía o alfabetos de tipo hexadecimal o base32.
- Tipos de registro inusuales en volumen, como respuestas
TXT,NULLoCNAMEcon valores largos. - Volumen y regularidad: un flujo constante de consultas a un dominio desde un host, incluso cuando el usuario está inactivo.
- Tamaños de consulta y respuesta muy por encima de lo que envía el resto de la red.
Ninguno de estos indicadores es una prueba por sí solo. La señal más fuerte es la suma de varios, para un dominio y desde un host.
Falsos positivos habituales
- Las CDN y los servicios en la nube usan nombres de host largos y con hashes para el balanceo de carga.
- Los servicios de seguridad y reputación consultan a menudo, por diseño, hashes o datos codificados como nombres DNS.
- Los navegadores: Chromium consulta al arrancar nombres aleatorios de una sola etiqueta para detectar secuestros de DNS; devuelven
NXDOMAINy parecen tráfico DGA. - El descubrimiento de servicios y los protocolos de nombres locales como mDNS y LLMNR generan consultas de difusión o multidifusión para nombres locales.
- La telemetría de sistemas operativos y agentes puede ser frecuente y regular.
Antes de concluir, comprueba qué proceso del host generó el tráfico, con registros del endpoint o del host.
Límites de la evidencia DNS en una captura
- Punto de captura. Una captura tomada aguas arriba del resolver recursivo muestra al resolver preguntando, no al cliente.
- DNS cifrado. DoH y DoT ocultan los nombres; solo quedan la dirección del resolver y los metadatos TLS.
- Caché. Las visitas repetidas dentro de un TTL no generan consultas nuevas.
- Snaplen y pérdidas. Los paquetes recortados o perdidos hacen desaparecer respuestas. Revisa el snaplen de la captura y las advertencias.
Hacerlo en el navegador
La vista DNS de PCAP Parser lista cada consulta con su tipo, código de resultado, respuestas y resolver, marca los nombres aleatorios y poco vistos, y lleva cada nombre y dirección a la lista de IOC, exportable en CSV o JSON. Filtra por un dominio registrable para ver todos sus subdominios a la vez. El recorrido guiado explica las demás vistas, y huellas JA3 y JA4 cubre qué leer en las sesiones TLS que siguen a una resolución.
FAQ
¿Cómo veo las consultas DNS en un archivo pcap?
Abre la captura en una herramienta que decodifique DNS: Wireshark con el filtro de visualización dns, tshark con -Y dns, o un visor en el navegador como PCAP Parser, que lista cada consulta con su tipo, código de resultado y respuestas en una vista DNS.
¿Qué significa tener muchos NXDOMAIN?
Muchos nombres inexistentes pueden deberse a errores tipográficos, software mal configurado o sufijos de búsqueda obsoletos, pero una ráfaga de nombres de aspecto aleatorio que fallan todos es también una señal clásica de un algoritmo de generación de dominios probando candidatos. Comprueba qué proceso y qué host los enviaron antes de concluir.
¿Se puede detectar la tunelización DNS con una sola captura?
Se pueden ver indicadores: muchos subdominios únicos, largos y de aspecto aleatorio bajo un mismo dominio, tipos de registro poco habituales como TXT en volumen y una cadencia regular. Ninguno prueba la tunelización por sí solo, y hay servicios legítimos que producen algunos de ellos, así que confirma con evidencias del host.