El Sistema de Nombres de Dominio (DNS) actúa como el directorio fundamental de Internet, traduciendo los nombres de host, fáciles de entender para las personas, en direcciones IP legibles para las máquinas. Dado que casi todas las aplicaciones de red dependen de la resolución de nombres, las organizaciones suelen permitir el tráfico DNS saliente a través de sus perímetros con un control mínimo. Los cortafuegos que bloquean la navegación web no autorizada, las transferencias de archivos y las conexiones SSH casi siempre dejan el puerto 53 totalmente abierto.
Los actores maliciosos se aprovechan de esta confianza predeterminada. Al canalizar datos no autorizados a través de solicitudes de búsqueda estándar, un atacante puede comunicarse de forma encubierta con hosts internos y sustraer propiedad intelectual sin establecer una conexión TCP directa. Comprender estos canales ocultos, junto con las vulnerabilidades más generales del DNS, es esencial para construir una defensa empresarial resistente.
¿Qué es el túnel DNS?
El túnel DNS es una técnica de ciberataque que consiste en incluir programas ajenos al DNS, cargas útiles de datos o comandos remotos dentro de consultas y respuestas DNS estándar. Dado que los resolutores recursivos redirigen habitualmente estas consultas a través de los perímetros de red, los atacantes pueden establecer un canal de comunicación bidireccional estable que elude por completo los cortafuegos perimetrales, los proxies de red y los filtros de contenido.
A grandes rasgos, el abuso del protocolo se basa en consultas de los clientes dirigidas a un dominio controlado por el atacante. Cuando el software comprometido necesita transmitir datos, los empaqueta en la etiqueta del subdominio de una consulta. Los resolutores recursivos reenvían la consulta hacia arriba hasta que llega al servidor autoritativo del atacante, el cual descomprime la carga útil y devuelve instrucciones incrustadas en registros de respuesta DNS estándar.
Cómo funciona un ataque de túnel DNS
Para crear un túnel DNS no es necesario comprometer los resolutores recursivos de la empresa ni manipular los servidores raíz del DNS. En su lugar, se utilizan los mecanismos estándar de enrutamiento del DNS a lo largo del siguiente ciclo de vida:
1. Preparación de la infraestructura: El atacante registra un nombre de dominio público (como attacker-c2.net) y configura un servidor de nombres autoritativo bajo su control para gestionar todas las consultas relativas a ese dominio y sus subdominios.
2. Entrega de la carga útil: Un terminal interno se ve comprometido mediante phishing, la explotación de vulnerabilidades de software o la manipulación de la cadena de suministro. El malware que se ejecuta en este terminal contiene una lógica diseñada específicamente para empaquetar datos locales en etiquetas compatibles con el sistema DNS.
3. Codificación y segmentación de datos: Dado que las normas del protocolo DNS (RFC 1035) limitan las etiquetas de dominio individuales a 63 caracteres y los nombres de dominio completos a 253 caracteres, el malware fragmenta los conjuntos de datos de gran tamaño en pequeños fragmentos. Codifica cada fragmento utilizando formatos como Base32 o hexadecimal, y añade el resultado como un subdominio (por ejemplo, 4d616c6963696f7573.data.attacker-c2.net). Se suele optar por Base32 porque las búsquedas en el DNS no distinguen entre mayúsculas y minúsculas.
4. Resolución recursiva: El terminal inicia una consulta DNS estándar. Dado que el equipo está configurado para utilizar el resolutor DNS interno de la empresa, la consulta se envía primero al servidor corporativo. El servidor corporativo detecta que se trata de una solicitud rutinaria, determina que no tiene el registro almacenado en caché y reenvía la consulta a través de la jerarquía global del DNS.
5. Extracción de la carga útil: La consulta llega finalmente al servidor de nombres autoritativo del atacante. En lugar de proporcionar una dirección IP válida para el alojamiento del sitio web, el servidor del atacante elimina el nombre de dominio principal, extrae la cadena codificada del subdominio y vuelve a ensamblar los datos originales.
6. Envío de comandos a través de respuestas: Para enviar comandos de vuelta a la red corporativa, el servidor autoritativo crea un registro de respuesta. Los atacantes suelen utilizar registros TXT, ya que admiten hasta 255 caracteres por cadena, o bien registros CNAME y NULL. Cuando el resolutor corporativo devuelve la respuesta al host infectado, el malware del cliente extrae la carga útil y ejecuta las instrucciones del operador.
A lo largo de todo este intercambio, el terminal infectado nunca establece una conexión de red directa con la infraestructura del atacante. Cada byte pasa sin problemas a través de los servidores DNS corporativos legítimos.
Para qué utilizan los atacantes el túnel DNS
Aunque los administradores de red utilizan en ocasiones herramientas de tunelización con fines de diagnóstico, los autores de amenazas aprovechan esta técnica en varias etapas críticas de la cadena de ataque cibernético.

Exfiltración de datos
La filtración de datos es el objetivo más habitual del túnel DNS. Cuando los atacantes logran acceder a sistemas que contienen registros de pagos, credenciales o código fuente propio, el acceso a Internet saliente suele estar sometido a un filtrado o una inspección exhaustivos por parte de los proxies de prevención de pérdida de datos (DLP).
Al dividir los datos confidenciales en fragmentos serializados y transmitirlos mediante consultas a subdominios, el malware puede canalizar poco a poco gigabytes de información sin necesidad de abrir nunca una sesión HTTP o FTP.
Mando y control (C2)
Una vez que el malware se ha establecido en el sistema, necesita una vía fiable para recibir instrucciones de sus operadores. Los atacantes suelen utilizar utilidades de túnel, como «iodine» o «dnscat2», como canales de reserva cuando se interrumpen las conexiones HTTPS principales. Los equipos de seguridad deben reconocer las firmas de estas herramientas durante la respuesta a incidentes.
A través de túneles DNS bidireccionales, los operadores pueden emitir comandos administrativos, cargar etapas secundarias de malware y coordinar el movimiento lateral en lo más profundo de las redes segmentadas.
Cómo eludir los controles de red y los portales de acceso
En entornos restringidos, como las redes Wi-Fi de hoteles, los puntos de acceso de los aeropuertos o las VLAN corporativas aisladas para invitados, los conmutadores de red suelen bloquear todo el tráfico web saliente hasta que el usuario completa el proceso de autenticación en un portal cautivo.
Sin embargo, para que la propia página del portal pueda resolverse, la red debe permitir las solicitudes DNS en el puerto 53. Los atacantes y los usuarios no autorizados aprovechan los túneles DNS para enrutar tráfico de Internet sin restricciones a través de estos resolutores abiertos, eludiendo así los bloqueos de facturación cautiva y los controles de aislamiento de la red.
Ejemplos reales de ataques de túnel DNS
El túnel DNS dista mucho de ser algo teórico. Grupos de ciberdelincuentes sofisticados y actores estatales han integrado en repetidas ocasiones las comunicaciones DNS en campañas cibernéticas a gran escala.
1. SUNBURST (Vulnerabilidad en la cadena de suministro de SolarWinds)
Una de las intrusiones más graves en la cadena de suministro de la historia de la ciberseguridad se basó en gran medida en la señalización a través del DNS. En la puerta trasera SUNBURST, distribuida a través de actualizaciones maliciosas del software SolarWinds Orion, el malware se comunicaba con los autores de la amenaza utilizando subdominios dinámicos bajo avsvmcloud.com.
La puerta trasera recopilaba información básica del host, codificaba los datos en cadenas alfanuméricas y las añadía al principio de las solicitudes de búsqueda como subdominios. Cuando los servidores de nombres autoritativos controlados por los atacantes recibían estas consultas, respondían con registros CNAME que apuntaban a servidores de comando secundarios o a rangos específicos de direcciones IP que ordenaban a la puerta trasera que entrara en modo de espera, se cerrara o activara canales HTTP secundarios. El alcance completo de esta técnica operativa se documenta en el aviso AA20-352A de la CISA.
2. Puertas traseras de DNS de OilRig (APT34)
El grupo de ciberamenazas iraní financiado por el Estado conocido como OilRig (APT34) ha utilizado de forma sistemática el túnel DNS como arma, tanto para el envío de órdenes como para la exfiltración de datos. A lo largo de múltiples campañas dirigidas contra entidades de los sectores energético, financiero y gubernamental, OilRig ha desplegado familias de malware personalizadas, como ALMA Communicator, DNSpionage y Saitama.
Estos implantes supervisan los equipos de las víctimas, extraen archivos confidenciales y estructuran los datos en consultas DNS de gran volumen dirigidas a servidores de nombres controlados por los atacantes. Si los protocolos de comunicación estándar fallan o los cortafuegos bloquean los canales web, el malware recurre automáticamente al túnel DNS para mantener la persistencia y el control administrativo.
Cómo detectar el túnel de DNS
Dado que las redes legítimas procesan millones de transacciones DNS a diario, para detectar túneles maliciosos es necesario analizar tanto las características de cada consulta como las tendencias generales del tráfico. Las estrategias de detección suelen dividirse en dos disciplinas principales: el análisis de la carga útil y el análisis del tráfico.
Análisis de la carga útil
El análisis de la carga útil examina las cadenas de caracteres, las estructuras y los registros de recursos específicos que contienen las solicitudes y respuestas individuales del DNS.
- Longitud y estructura de los subdominios: Los subdominios estándar suelen ser cortos y fáciles de leer para las personas, como mail.company.com o api.internal.local. Las consultas de tunelización maximizan la transferencia de datos al comprimir largas cadenas codificadas en subdominios, lo que a menudo las acerca al límite de 63 caracteres de la etiqueta.
- Entropía de la información: Las cadenas cifradas o codificadas presentan una elevada entropía estadística (aleatoriedad) en comparación con las palabras del lenguaje natural. Las plataformas de análisis de seguridad evalúan la distribución de los caracteres; las cadenas con variaciones anómalas en los caracteres, patrones alfanuméricos repetitivos o estructuras en las que faltan vocales son indicios claros de que los datos están codificados.
- Tipos de registros de recursos inusuales: El tráfico habitual de una empresa utiliza principalmente registros A, AAAA, MX y, ocasionalmente, CNAME. Una afluencia repentina de consultas que solicitan registros TXT (que contienen cadenas de gran tamaño), registros NULL (que contienen bloques binarios arbitrarios) o registros SRV procedentes de puntos finales que no ejecutan servicios de red indica un uso indebido del protocolo.
- Conjuntos de caracteres no estándar: Las consultas que incluyan caracteres de relleno Base32, secuencias hexadecimales o distribuciones de símbolos no convencionales deben someterse inmediatamente a cuarentena e inspección.
Análisis del tráfico
El análisis del tráfico examina los patrones agregados de consultas a lo largo del tiempo, detectando comportamientos operativos anómalos incluso cuando las consultas individuales parecen inofensivas.
- Volumen anómalo de consultas a un dominio específico: El uso legítimo del DNS se beneficia del almacenamiento en caché. Una vez que un servidor resuelve example.com, el resolutor recursivo almacena en caché el registro durante su tiempo de vida (TTL), lo que evita consultas externas idénticas. Los túneles DNS generan un flujo continuo de solicitudes, ya que cada dato exfiltrado requiere un subdominio nuevo y único que no puede servirse desde la caché.
- Alta proporción de nombres de dominio completos (FQDN): Observar que, en el plazo de una hora, miles de subdominios únicos se resuelven bajo un único dominio de nivel superior es un indicador fiable de la existencia de un túnel activo.
- Dominios de nuevo registro (NRD): Los actores maliciosos recurren habitualmente a dominios efímeros para eludir las listas de bloqueo basadas en la reputación estática. Las consultas dirigidas a dominios creados en las últimas 24 a 72 horas deben dar lugar a una inspección más exhaustiva.
- Conexiones directas salientes al puerto 53: En una arquitectura empresarial segura, las estaciones de trabajo de los usuarios estándar solo deben comunicarse con los servidores de resolución internos designados. Cualquier estación de trabajo que intente enviar solicitudes DNS directamente a servidores de resolución públicos externos (como 8.8.8.8 o 1.1.1.1) suele estar intentando eludir la supervisión interna.
Herramientas y tecnologías que ayudan
Para detectar el túnel de DNS a gran escala se necesitan herramientas defensivas diseñadas específicamente para ello:
- Plataformas de DNS protector (PDNS): Los servicios PDNS en la nube e híbridos se sitúan entre los resolutores internos e Internet en general, y aplican inteligencia sobre amenazas en tiempo real y modelos de comportamiento para interceptar las consultas maliciosas antes de que se complete la resolución.
- Detección y respuesta en red (NDR): Las herramientas modernas de NDR inspeccionan de forma pasiva los tramos de red, identificando subdominios de alta entropía y túneles de protocolos mediante modelos de aprendizaje automático sin introducir latencia.
- Gestión de información y eventos de seguridad (SIEM): Al reenviar los registros de depuración del resolutor DNS interno a un SIEM, los equipos de ingeniería pueden configurar reglas de correlación que señalen los terminales que generan un número anormalmente elevado de consultas de dominio únicas.
- Supervisión unificada de la seguridad del DNS: Una defensa eficaz va más allá de la inspección del tráfico saliente; también requiere supervisar las zonas autorizadas para garantizar que los autores de amenazas no hayan manipulado los registros corporativos. Las soluciones integrales de supervisión de la seguridad del DNS ayudan a las empresas a detectar alteraciones en los registros, cambios no autorizados en la infraestructura y deficiencias de cumplimiento normativo en todos sus dominios públicos.
La solución integral de supervisión de la seguridad del DNS de PowerDMARC ayuda a las empresas a detectar alteraciones en los registros, cambios no autorizados en la infraestructura y deficiencias de cumplimiento normativo en todos sus dominios públicos. Esta supervisión proactiva garantiza que tus zonas DNS autoritativas permanezcan protegidas frente a la manipulación, al tiempo que proporciona la visibilidad detallada necesaria para detectar abusos ocultos del protocolo.
Cómo evitar el túnel de DNS
Detectar la creación de túneles es fundamental, pero los controles proactivos de la arquitectura de red pueden detener muchos intentos de creación de túneles antes de que los datos salgan del entorno. Los equipos de seguridad deben aplicar las siguientes prácticas de refuerzo de la seguridad:

- Restringir el enrutamiento DNS saliente: Configura los cortafuegos perimetrales para bloquear todo el tráfico UDP y TCP saliente en el puerto 53 procedente de terminales estándar. Solo se debe permitir que los resolutores DNS internos designados y reforzados establezcan conexiones salientes a Internet.
- Restringir los protocolos DoH y DoT no autorizados: Los actores maliciosos utilizan cada vez más el túnel DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT) para ocultar consultas dentro del tráfico web cifrado. Bloquea las conexiones salientes hacia direcciones IP públicas conocidas de resolutores DoH/DoT y aplica políticas de proxy corporativas que exijan la inspección de certificados internos.
- Implementar el filtrado de DNS y las fuentes de información sobre amenazas: integrar fuentes dinámicas de información sobre amenazas en los servidores de resolución corporativos. Las listas de bloqueo de alta reputación rechazan inmediatamente las consultas dirigidas a dominios asociados a campañas de malware recién identificadas, proveedores de DNS dinámicos o infraestructura C2 activa.
- Implementar el «sinkholing» de DNS: cuando los resolutores recursivos detectan consultas dirigidas a dominios maliciosos conocidos, el «sinkholing» redirige la solicitud a una dirección IP ficticia interna no enrutable. Esto neutraliza el ataque y alerta inmediatamente al personal de seguridad sobre el host interno infectado.
- Aplicar el principio del mínimo privilegio en los terminales: Los scripts y utilidades maliciosos de tunelización requieren privilegios de ejecución locales para manipular sockets de red o ejecutar servicios en segundo plano. Restringir los derechos administrativos, aplicar listas de aplicaciones permitidas y ejecutar agentes modernos de detección y respuesta en los terminales (EDR) impide, desde el principio, que se ejecute código malicioso.
- Aplica medidas integrales de higiene del DNS: mantén todo el software de DNS actualizado con los parches correspondientes para protegerlo frente a vulnerabilidades conocidas y revisa las configuraciones periódicamente siguiendo las mejores prácticas de seguridad del DNS establecidas.
El túnel DNS frente a otros ataques al DNS
Dado que el Sistema de Nombres de Dominio (DNS) es vulnerable en múltiples capas arquitectónicas, los equipos de seguridad suelen confundir el túnel con otras formas de manipulación del DNS. La siguiente tabla destaca las diferencias operativas:
Si quieres profundizar en las amenazas que afectan a la infraestructura de resolución de nombres, consulta nuestra guía sobre los distintos tipos de ataques al DNS.
Preguntas frecuentes
¿Es ilegal el túnel DNS?
Sí, el uso del túnel DNS para extraer datos sin autorización, instalar malware o establecer un acceso encubierto a una red corporativa sin autorización explícita es ilegal y infringe la legislación sobre delitos informáticos a nivel mundial, como la Ley de Fraude y Abuso Informático (CFAA) de Estados Unidos.
¿Puede un cortafuegos tradicional bloquear el túnel DNS?
Los cortafuegos estándar rara vez bloquean por sí solos el túnel DNS. Dado que los cortafuegos estándar solo comprueban las reglas de origen, destino y puerto (permitiendo el tráfico UDP/TCP en el puerto 53), tratan las consultas de túnel como búsquedas de nombres normales. Para bloquear el túnel se necesitan cortafuegos de nueva generación (NGFW), inspección profunda de paquetes (DPI) o servicios dedicados de DNS protector que evalúen la entropía de la carga útil, la frecuencia de las consultas y la reputación del dominio.
¿El DNS sobre HTTPS (DoH) hace que sea más difícil detectar el túnel?
Sí. El DNS sobre HTTPS cifra las consultas y las respuestas dentro de sesiones TLS estándar a través del puerto 443, lo que hace que el tráfico DNS sea indistinguible de la navegación web HTTPS cifrada habitual. Cuando el malware utiliza DoH para acceder a resolutores públicos externos, los monitores de red tradicionales no pueden inspeccionar los subdominios ni el contenido de la carga útil sin proxies de descifrado TLS activos. Por ello, es fundamental bloquear las conexiones DoH salientes directas hacia resolutores públicos no autorizados.
¿Cuál es la diferencia entre el túnel DNS y la exfiltración de DNS?
La exfiltración de DNS es un objetivo específico, mientras que el túnel de DNS es el mecanismo de transporte más amplio. La exfiltración de DNS se refiere estrictamente a la transmisión saliente y al robo de datos sensibles a través de consultas DNS. Por el contrario, el túnel de DNS también puede ser bidireccional, estableciendo entornos interactivos de comando y control, transmitiendo comandos entrantes de los operadores y enrutando tráfico IP general a través de redes restringidas.
Conclusiones y próximos pasos
El DNS sigue siendo un protocolo esencial que las organizaciones modernas no pueden simplemente desactivar. Lamentablemente, su alcance universal y el tratamiento permisivo que recibe por parte de los cortafuegos garantizan que los atacantes sigan utilizándolo como puerta trasera para apropiarse de propiedad intelectual sensible y mantener un acceso continuo. Para contrarrestar el túnel de DNS se requiere una visibilidad continua de la red, un filtrado de salida robusto en el puerto 53 y una inspección automatizada capaz de detectar comportamientos anómalos en las consultas en tiempo real.
La protección de la red de tu organización comienza por conocer cuál es el estado actual de tu superficie de ataque externa. Además de supervisar los patrones de consultas salientes, las empresas deben asegurarse de que su infraestructura de dominios públicos y sus protocolos de autenticación de correo electrónico estén totalmente protegidos contra la suplantación de identidad, la manipulación no autorizada de registros y las configuraciones erróneas. Utiliza el analizador de dominios gratuito de PowerDMARC para comprobar de inmediato el estado de tu dominio, verificar la configuración de SPF y DMARC y detectar vulnerabilidades de seguridad antes de que los atacantes puedan aprovecharlas.


