DNSpionage: La campaña que convirtió el DNS en un arma contra gobiernos

La mayoría de los desastres relacionados con dominios tienen que ver con quién posee un nombre. Este caso era sobre quién lo controla — y durante unos meses a finales de 2018, la respuesta para decenas de dominios gubernamentales en Oriente Medio fue: no los propios gobiernos.

No hubo ninguna brecha en un servidor web. No había malware en la página de inicio. Ningún defacement, ninguna nota de rescate, ningún rastro revelador en los registros de aplicaciones. Los atacantes nunca necesitaron irrumpir en los edificios. Entraron por la única puerta que casi nadie vigila: el registro DNS que indica dónde viven realmente el correo electrónico y los sitios web de un dominio. Lo editaron — en silencio, con credenciales válidas, detrás de un certificado TLS válido — y el tráfico mundial siguió las nuevas instrucciones sin rechistar.

Cisco Talos lo denominó DNSpionage. Es una de las demostraciones más limpias registradas de que el Sistema de Nombres de Dominio no es solo fontanería. Es infraestructura de seguridad nacional.

El DNS como arma de política de estado

Para entender por qué DNSpionage sacudió a los gobiernos, hay que recordar qué hace realmente el DNS.

Cada vez que envías un correo a un ministerio, inicias sesión en una VPN corporativa o abres una página de correo web, tu dispositivo primero le hace una pregunta al DNS: ¿cuál es la dirección IP de este nombre? Lo que responda el DNS, tú lo confías. Tu cliente de correo se conecta ahí. Tu VPN se autentica ahí. Tu navegador entrega la sesión ahí. El DNS es la agenda de direcciones de todo internet, y casi nada comprueba si esa agenda ha sido editada.

Esa es la propiedad que DNSpionage explotó. Si puedes cambiar el registro — no romper el cifrado, no descifrar el archivo de contraseñas, solo cambiar el puntero — puedes situarte invisiblemente entre un objetivo y los servicios en los que confía. El correo electrónico pasa por ti. Los inicios de sesión de VPN pasan por ti. Y como el nombre de dominio de la propia víctima sigue apareciendo en la barra del navegador, nada parece mal.

Esto es espionaje en la capa por debajo de la aplicación. Es también, incómodamente, la capa que la mayoría de los programas de seguridad tratan como un problema ya resuelto.

La campaña DNSpionage (2018–2019)

El 27 de noviembre de 2018, Cisco Talos publicó su primer informe. La frase inicial era específica: "Cisco Talos descubrió recientemente una nueva campaña dirigida contra Líbano y los Emiratos Árabes Unidos (EAU) que afecta a dominios .gov, así como a una compañía aérea libanesa privada."

La campaña tenía dos facetas. Una era una operación de malware bastante ordinaria: "Esta campaña en particular utiliza dos sitios web falsos y maliciosos que contienen ofertas de empleo y se usan para comprometer objetivos mediante documentos maliciosos de Microsoft Office con macros incrustadas." Los sitios cebo suplantaban a reclutadores reales — "hr-wipro[.]com (con redirección a wipro.com) y hr-suncor[.]com (con redirección a suncor.com)" — e instalaban una herramienta de acceso remoto personalizada que, de forma característica, podía comunicarse con su servidor de comando a través del propio DNS.

Pero la segunda faceta es la que hizo historia. En palabras de Talos: "En una campaña separada, los atacantes usaron la misma IP para redirigir el DNS de dominios .gov legítimos y de dominios de empresas privadas." Los servidores de nombres gubernamentales reales fueron apuntados a máquinas controladas por los atacantes: "Múltiples servidores de nombres pertenecientes al sector público en Líbano y EAU, así como algunas empresas en Líbano, fueron aparentemente comprometidos, y los nombres de host bajo su control fueron apuntados a direcciones IP controladas por el atacante."

Los sitios de empleo falsos eran la parte que parecía ciberdelincuencia ordinaria. La redirección de DNS era la parte que parecía política de estado.

Cuando investigadores independientes terminaron de tirar del hilo, el alcance era mucho mayor que el de dos países. Brian Krebs, trabajando a partir de las direcciones IP de los atacantes, encontró que "en los últimos meses de 2018 los piratas informáticos detrás de DNSpionage lograron comprometer componentes clave de la infraestructura DNS de más de 50 empresas y agencias gubernamentales de Oriente Medio."

Quiénes fueron los objetivos y lo que estaba en juego

La lista de víctimas se lee como un mapa del sistema nervioso de una región: ministerios de asuntos exteriores, aviación civil, operadores de telecomunicaciones, infraestructura de internet y el correo web del ministerio de finanzas nacional. No son objetivos aleatorios. Son los lugares por donde pasan los secretos de una nación.

Dos meses después del primer informe de Talos, FireEye (ahora Mandiant) publicó su propio análisis e hizo la atribución de forma explícita pero cautelosa. Según FireEye, "la investigación inicial sugiere que el actor o actores responsables tienen un nexo con Irán." Al informar sobre los hallazgos de FireEye, SecurityWeek señaló que la firma evaluó con "confianza moderada" que Irán estaba detrás de los ataques, basándose en evidencias técnicas y en el hecho de que la campaña se alineaba con los intereses del gobierno iraní.

Las apuestas se derivan directamente de los objetivos. Cuando puedes leer el correo electrónico de un ministerio de asuntos exteriores en texto claro, no estás robando datos — estás leyendo la mente de un gobierno casi en tiempo real. Por eso una campaña de recolección de credenciales en la capa DNS se entiende correctamente no como fraude, sino como recopilación de inteligencia contra el Estado.

Cómo ocurrió: registros DNS + certificados válidos + sitios de empleo falsos

Vale la pena detenerse aquí, porque la técnica es elegante de la peor manera. Hubo tres movimientos.

Movimiento uno: conseguir las llaves de la agenda de direcciones. Los atacantes no rompieron la criptografía del DNS. Iniciaron sesión. FireEye describió dos métodos: "Un método consiste en iniciar sesión en la interfaz de administración de un proveedor de DNS con credenciales comprometidas y cambiar los registros DNS A para interceptar el tráfico de correo electrónico. Otro método consiste en cambiar los registros DNS NS después de hackear la cuenta del registrador de dominio de la víctima." Las credenciales robadas de registradores y proveedores de DNS eran la llave maestra. Quien tiene el acceso al registrador controla el dominio — y el dominio controla todo lo que apunta a él.

Movimiento dos: redirigir el tráfico de modo que siga funcionando. Apuntar el servidor de correo de un gobierno a tu propia IP normalmente rompería las cosas y haría saltar alarmas. Por eso los atacantes usaron un proxy. El tráfico era retransmitido al destino real después de ser capturado, de modo que los usuarios veían una bandeja de entrada funcional y una VPN funcionando. Como describió FireEye en una tercera variante: "los usuarios eran redirigidos a la infraestructura controlada por el atacante." La interceptación era un ataque de hombre en el medio que reenviaba silenciosamente el tráfico — invisible precisamente porque nada parecía fallar.

Movimiento tres: vencer el candado verde. Los servicios modernos utilizan TLS, que debería lanzar una advertencia de certificado en el momento en que el tráfico llegue al servidor equivocado. Los atacantes cerraron esa brecha obteniendo sus propios certificados legítimos. Talos descubrió que "durante cada compromiso de DNS, el actor generó cuidadosamente certificados de Let's Encrypt para los dominios redirigidos." Como ahora controlaban el DNS del dominio, podían demostrar el control ante una autoridad certificadora — y la validación automática de dominio les entregó un certificado válido. FireEye confirmó el mismo patrón en todos los métodos: "en ambos casos los atacantes usaron certificados de Let's Encrypt para evitar levantar sospechas."

El resultado, en el resumen de Krebs, fue total: "estos secuestros de DNS también allanaron el camino para que los atacantes obtuvieran certificados de cifrado SSL para los dominios objetivo (p. ej. webmail.finance.gov.lb), lo que les permitió descifrar el correo interceptado y las credenciales de VPN y verlos en texto claro." Correos electrónicos e inicios de sesión de VPN, capturados y legibles, con un candado válido en todo momento.

Nótese lo que no fue necesario. Ningún zero-day. Ningún malware en los servidores de la víctima. Ningún firewall vulnerado. El ataque vivió enteramente en la brecha entre "soy propietario de este dominio" y "puedo demostrar quién controla actualmente sus registros." Esa brecha es donde vivió DNSpionage — y es más amplia de lo que la mayoría de las organizaciones creen.

La respuesta: Directiva de Emergencia CISA 19-01

Las revelaciones combinadas de Talos y FireEye aterrizaron con fuerza en Washington. El 22 de enero de 2019, la Agencia de Ciberseguridad e Infraestructura de los EE. UU. (CISA) emitió la Directiva de Emergencia 19-01, "Mitigar la Manipulación de la Infraestructura DNS" — la primera directiva de emergencia que CISA jamás había emitido, y una rara instrucción vinculante para todo el gobierno civil federal.

El diagnóstico de la directiva coincidía exactamente con la investigación. Según citas de informes contemporáneos, CISA advirtió que "los atacantes han redirigido e interceptado tráfico web y de correo electrónico, y podrían hacerlo con otros servicios en red," y que los actores habían "comprometido las cuentas de los administradores a cargo de los dominios DNS gubernamentales."

Luego ordenó cuatro acciones, con un plazo de 10 días — y leen como una réplica directa a cada uno de los tres movimientos del atacante:

1. Auditar los registros DNS — verificar que nada haya sido manipulado en servidores autoritativos y secundarios.
2. Cambiar las contraseñas de las cuentas DNS — rotar todas las credenciales que pueden editar el DNS.
3. Añadir autenticación multifactor a todas las cuentas de administración de DNS — para que una contraseña robada por sí sola ya no sea la llave maestra.
4. Monitorizar los registros de Transparencia de Certificados — vigilar los certificados emitidos para sus dominios que nunca fueron solicitados por ellos.

Ese cuarto punto es revelador. CISA no solo le decía a las agencias que cerraran la puerta; les decía que vigilaran los registros públicos de certificados en busca de evidencias de que alguien ya había usado una copia de la llave. DNSpionage había convertido la Transparencia de Certificados de una función de nicho de PKI en una herramienta de detección de primera línea contra el secuestro de DNS de estados nación.

Krebs capturó con claridad la excepcionalidad del momento: "el Departamento de Seguridad Nacional de EE. UU. emitió una rara directiva de emergencia ordenando a todas las agencias civiles federales de EE. UU. que aseguraran las credenciales de inicio de sesión de sus registros de dominio de internet."

DNSpionage no actuó solo para provocarla. Una operación paralela, aún más agresiva, que Talos llamó Sea Turtle — que Talos describió como "el primer caso conocido de una organización de registro de nombres de dominio comprometida para operaciones de ciberespionaje," afectando a "aproximadamente 40 organizaciones diferentes en 13 países distintos" — elevó aún más las apuestas. Talos fue cuidadoso en mantener las dos operaciones distintas; en su seguimiento de abril de 2019 señaló que el comportamiento de DNSpionage "probablemente continuará distinguiendo a este actor de campañas más preocupantes como Sea Turtle." Juntas, las dos campañas hicieron el mismo punto desde ángulos diferentes: la cadena de suministro del DNS se había convertido en un teatro de conflicto estatal.

Lo que esto enseña sobre el DNS como infraestructura de seguridad nacional

DNSpionage tiene poco drama de malware pero muchas lecciones incómodas. Algunas que vale la pena conservar:

• La cuenta del registrador es una joya de la corona. Todo lo que depende de un dominio — correo, web, VPN, inicio de sesión único, emisión de certificados — hereda la confianza de quien puede editar su DNS. Una contraseña sin segundo factor en esa cuenta no es una brecha pequeña; es todo el castillo con la puerta abierta. Las primeras instrucciones de CISA fueron sobre credenciales, no sobre firewalls, exactamente por esta razón.
• Un certificado válido no es prueba de legitimidad. El candado verde demuestra que el tráfico está cifrado hacia quien controle el dominio en este momento. Si un atacante controla el DNS, la validación automática de dominio le emitirá alegremente un certificado real. La confianza en TLS se toma prestada de la confianza en el DNS — y el DNS es más frágil de lo que la mayoría de la gente asume.
• Los ataques de DNS son invisibles por diseño. Porque el proxy reenvía el tráfico real, los servicios de la víctima siguen funcionando. No hay ninguna interrupción que investigar. La única señal externa puede ser un certificado apareciendo en un registro CT público — razón por la cual monitorizar esos registros pasó de opcional a obligatorio de la noche a la mañana.
• El control de dominio es un control de seguridad nacional. Cuando la entidad que edita el DNS de un ministerio de asuntos exteriores es un estado hostil, la distinción entre "operaciones de TI" y "contrainteligencia" se desvanece. La agenda de direcciones de internet es terreno estratégico.

El hilo conductor es una sola pregunta que casi ninguna herramienta operativa responde en tiempo real: ¿quién controla realmente este dominio ahora mismo, y puedo probar que no ha cambiado silenciosamente? DNSpionage funcionó porque esa pregunta era tan difícil de responder que los gobiernos de toda una región no podían hacerlo.

El ángulo Namefi

DNSpionage es, en su raíz, un problema de procedencia. Los atacantes nunca fueron propietarios de los dominios objetivo. Tomaron prestado el control de ellos robando las credenciales que permitían a los paneles de registradores y proveedores de DNS realizar ediciones silenciosas e inverificables — y nada en el sistema marcó que la parte en control había cambiado.

Namefi se basa en la premisa de que la propiedad y el control de dominios deben ser verificables, portátiles y a prueba de manipulaciones, en lugar de estar encerrados en un opaco inicio de sesión de registrador. La propiedad tokenizada hace que "quién controla este nombre" sea un hecho que puedes comprobar y auditar, no una configuración oculta detrás de una contraseña que puede que ya esté en manos de otra persona. Eso no reemplaza la higiene de la cuenta del registrador ni la autenticación multifactor — el consejo de CISA sigue siendo completamente correcto — pero ataca la brecha más profunda que DNSpionage explotó: la dificultad de probar, de forma independiente y continua, que la parte que controla un dominio es la parte que debería controlarlo.

La lección de DNSpionage no es que el DNS sea frágil de alguna manera exótica. Es que el hecho más importante sobre un dominio — quién lo controla — estuvo durante demasiado tiempo separado de la respuesta correcta únicamente por una contraseña robada. Hacer ese hecho verificable es todo el objetivo.

Fuentes y lecturas adicionales

• Cisco Talos — DNSpionage Campaign Targets Middle East (27 de noviembre de 2018)
• Cisco Talos — DNSpionage brings out the Karkoff (23 de abril de 2019)
• Krebs on Security — A Deep Dive on the Recent Widespread DNS Hijacking Attacks (18 de febrero de 2019)
• The Register — Baddies linked to Iran fingered for DNS hijacking to read Middle Eastern regimes' emails (10 de enero de 2019)
• SecurityWeek — Iran-Linked DNS Hijacking Attacks Target Organizations Worldwide (10 de enero de 2019)
• BleepingComputer — DHS Issues Emergency Directive to Prevent DNS Hijacking Attacks (enero de 2019)
• Network World — Cisco Talos details exceptionally dangerous DNS hijacking attack (17 de abril de 2019)
• Network World — Cisco: DNSpionage attack adds new tools, morphs tactics
• CERT-IST — DNSpionage and DNS data hijacking
• CISA — Emergency Directive 19-01: Mitigate DNS Infrastructure Tampering (22 de enero de 2019)