DNS: el protocolo que puede exfiltrar tu base de datos sin tocar el firewall
Cierra los puertos de salida que quieras. Aplica el egress filtering más estricto que tu política permita. Si el puerto 53 sigue abierto —y lo está, porque sin resolución DNS tu red no funciona— existe un canal por el que un atacante puede sacar datos de tu organización sin abrir una sola conexión que tu firewall considere sospechosa. No es una vulnerabilidad de día cero ni un exploit exótico: es el uso deliberado de un protocolo de 1987 diseñado para traducir nombres, convertido en un túnel de exfiltración. Para el equipo de seguridad que ya domina lo básico, este artículo desglosa el mecanismo, por qué evade los controles perimetrales tradicionales, qué señales lo delatan y cómo construir una detección que realmente funcione.
Por qué el DNS es el punto ciego perfecto
El DNS es el único protocolo que casi ninguna organización puede bloquear. La navegación web, la resolución de servicios internos, la validación de certificados, la telemetría del sistema operativo: todo depende de resolver nombres. Por eso, incluso en redes con egress filtering agresivo, el tráfico DNS suele tener vía libre hacia el resolver interno, y desde ahí hacia internet a través de la jerarquía recursiva.
Ese privilegio operativo es exactamente lo que lo convierte en un canal encubierto ideal. Cuando un host interno solicita la resolución de a7f3c9d2e1.datos.atacante.com, la consulta no viaja directamente al servidor del atacante: sube por el resolver corporativo, pasa por los servidores raíz y TLD, y finalmente llega al servidor autoritativo del dominio atacante.com, que resulta estar bajo control del adversario. El atacante no necesita que la víctima abra una conexión hacia él; deja que la propia infraestructura DNS de la organización le entregue los datos, salto por salto, como parte de su funcionamiento normal.
El resultado es un flujo que atraviesa firewalls, proxies y segmentación de red apoyándose en un servicio que todos consideran benigno por definición.
El problema: cómo funciona la exfiltración por DNS
El mecanismo es conceptualmente simple y ahí radica su elegancia. El atacante, que ya tiene ejecución de código en un host interno, no intenta conectarse a un IP externo. En su lugar, hace lo siguiente:
Codifica los datos en el nombre de dominio. Toma la información a exfiltrar —un volcado de credenciales, filas de una tabla, una clave privada— y la fragmenta en trozos pequeños. Cada fragmento se codifica (típicamente en Base32 o hexadecimal, para respetar los caracteres válidos en un nombre DNS) y se coloca como subdominio de un dominio que el atacante controla. Así, un registro se convierte en algo como 4b6f6e74.5365637265.74446174.exfil.atacante.com.
Genera consultas de resolución. El malware simplemente pide resolver esos nombres. No importa que no existan como sitios reales: la consulta debe llegar al servidor autoritativo para ser respondida, y en ese viaje el atacante ya recibió el subdominio completo, es decir, el fragmento de datos.
Reconstruye del lado del servidor. El servidor autoritativo malicioso registra cada consulta entrante, extrae los subdominios, los decodifica y reensambla el archivo original. Para comandos entrantes (canal C2), la respuesta DNS —un registro TXT, CNAME o incluso las respuestas de un registro A cuidadosamente elegidas— transporta instrucciones de vuelta al implante.
Las restricciones del protocolo imponen un límite de ancho de banda: cada etiqueta admite hasta 63 caracteres, el nombre completo hasta 253, y hay overhead de codificación. Eso hace que la exfiltración sea lenta —del orden de kilobytes por minuto en canales sigilosos— pero para una clave privada, un token o un volcado selectivo de una base de datos, la velocidad rara vez es el obstáculo. Herramientas como iodine, dnscat2 o DNSExfiltrator llevan más de una década demostrando el concepto, y frameworks de C2 modernos como Cobalt Strike y Sliver incluyen DNS como transporte de primera clase.
Por qué tu firewall y tu stack tradicional no lo ven
Aquí está el núcleo del asunto para quien opera defensas. El tráfico de exfiltración por DNS evade los controles clásicos por razones estructurales, no por configuración deficiente:
El firewall aprueba el puerto, no el contenido. Una regla de egress que permite el puerto 53 (o 853 para DoT) hacia el resolver ve consultas DNS perfectamente formadas. No hay conexión saliente anómala que bloquear porque, técnicamente, el host solo está resolviendo nombres.
El proxy web queda fuera del camino. La exfiltración por DNS no usa HTTP/S, así que no pasa por el proxy corporativo ni por la inspección TLS. El canal es invisible para toda la pila de seguridad web.
El resolver recursivo lava el origen. Cuando las consultas llegan al servidor autoritativo del atacante, provienen del resolver corporativo o de un resolver público, no del host comprometido. La atribución del endpoint específico se pierde salvo que se correlacione con logs internos.
DoH lo empeora. DNS-over-HTTPS encapsula las consultas en tráfico HTTPS hacia resolvers públicos en el puerto 443, mezclándolas con la navegación legítima y sacándolas por completo de la visibilidad del resolver corporativo. Un endpoint con DoH habilitado a nivel de navegador o sistema operativo puede abrir un canal de exfiltración que ni siquiera aparece en los logs del DNS interno.
El punto incómodo es este: si tu detección de exfiltración depende de reglas de firewall y de inspección de proxy, tienes un ángulo muerto del tamaño del puerto 53.
Las señales que sí lo delatan
La buena noticia es que la exfiltración por DNS deja huellas estadísticas y de comportamiento características. No se detecta bloqueando; se detecta observando el DNS como una fuente de telemetría de seguridad, no solo como un servicio de red. Los indicadores clave:
Volumen y frecuencia anómalos. Un host que genera cientos o miles de consultas por minuto hacia subdominios de un mismo dominio padre es sospechoso. El DNS legítimo se beneficia de la caché; la exfiltración no puede, porque cada nombre es único por diseño.
Alta entropía en los subdominios. Los nombres de dominio legítimos son pronunciables y repetitivos. Cadenas largas de caracteres aleatorios de alta entropía (8f3a9b2c7d1e…) son la firma de datos codificados. Medir la entropía de Shannon de las etiquetas es una de las heurísticas más eficaces.
Longitud inusual de las consultas. Los nombres que se aproximan sistemáticamente al límite de 253 caracteres, o etiquetas cercanas a los 63, indican maximización deliberada del ancho de banda por consulta.
Dominios de bajo prestigio y NXDOMAIN. Consultas repetidas a dominios recién registrados, sin reputación, o una tasa elevada de respuestas NXDOMAIN hacia un mismo dominio padre, sugieren un canal que no depende de nombres reales.
Uso intensivo de tipos TXT y NULL. Los registros TXT admiten cargas más grandes y son un vehículo frecuente de datos y comandos. Un pico de consultas TXT desde un host que no debería generarlas es una alerta legítima.
Cómo defenderse: detección y controles en profundidad
Cerrar este vector no depende de un producto único, sino de tratar el DNS como lo que es: un plano de control de seguridad. Las medidas que un equipo maduro debería implementar:
Centraliza y registra todo el DNS. Fuerza a todos los endpoints a usar los resolvers internos y prohíbe el DNS directo a internet. Sin logs de consultas, la detección es imposible. Ingesta esos logs en el SIEM (Wazuh, Graylog o equivalente) como fuente de primera clase, no como ruido.
Controla y monitorea DoH/DoT. Bloquea o canaliza el DNS-over-HTTPS hacia resolvers no autorizados; de lo contrario, anulas tu propia visibilidad. Mantén una lista de resolvers permitidos y alerta sobre conexiones a los conocidos de DoH público desde endpoints corporativos.
Aplica análisis de comportamiento, no solo listas negras. Las reglas basadas en dominios conocidos siempre van por detrás. Implementa detección por entropía, volumen por host, longitud de consulta y ratio de subdominios únicos por dominio padre. Aquí es donde un pipeline de correlación bien afinado marca la diferencia frente a un SIEM que solo acumula logs.
Segmenta y aplica mínimo privilegio a la resolución. No todos los sistemas necesitan resolver dominios externos arbitrarios. Un servidor de base de datos que de repente consulta subdominios aleatorios de un dominio desconocido es una anomalía de alto valor; restringir qué puede resolver cada segmento reduce la superficie.
Correlaciona DNS con contexto de endpoint. Una consulta de alta entropía es una señal; esa misma consulta originada por un proceso que nunca debería hacer DNS, en un host que acaba de ejecutar un binario sospechoso, es un incidente. La detección efectiva vive en la correlación, no en la regla aislada.
Integra la detección en un SOC con operación continua. Ninguna de estas señales sirve si nadie las mira a las 3 a.m. La exfiltración lenta está diseñada precisamente para pasar desapercibida durante días; solo un monitoreo 24/7 con reglas afinadas la atrapa dentro de la ventana que importa.
Conclusión: el perímetro no es donde crees
La exfiltración por DNS es un recordatorio de una verdad que el gremio conoce pero que la práctica olvida: la seguridad perimetral basada en puertos y protocolos “confiables” es una abstracción que los atacantes hace tiempo dejaron de respetar. El puerto 53 no es una excepción benigna; es una superficie de ataque con nombre propio, y tratarlo como plomería invisible es regalar un canal. Defenderse no requiere una herramienta mágica, sino un cambio de perspectiva: convertir el DNS de servicio de red en telemetría de seguridad, y construir sobre esa telemetría la analítica de comportamiento y la operación continua que la detección exige. El firewall nunca vio salir tus datos. La pregunta es si tú sí.
Rescue Bunker
La continuidad del negocio ya no depende de la suerte, sino de la arquitectura que lo sostiene.Suscríbete a Nuestro Blog: Mantente actualizado con las últimas noticias y consejos en ciberseguridad. Suscríbete ahora.
