La trampa de .arpa: así los atacantes aprovechan la DNS inversa para el phishing

En las últimas semanas investigadores de seguridad han detectado una campaña de phishing que se apropia de una esquina poco habitual de Internet para esconder sus trampas: el dominio especial .arpa, utilizado históricamente para la infraestructura de red y las búsquedas inversas de DNS. Lejos de ser un sitio web común, .arpa no está pensado para alojar contenidos visibles al usuario, sino para permitir que una dirección IP se traduzca de vuelta a un nombre de host; sin embargo, los atacantes han encontrado formas creativas de explotar esa funcionalidad para eludir controles y pasar desapercibidos.

Para entender por qué esto es problemático basta recordar cómo funciona la búsqueda inversa: mientras que una consulta habitual resuelve un nombre de dominio a una IP, la búsqueda inversa —mediante zonas como in-addr.arpa para IPv4 y ip6.arpa para IPv6— transforma una dirección IP en una cadena de etiquetas que apunta a un PTR que normalmente indica el nombre de host asociado. La documentación oficial sobre el propósito del espacio .arpa está disponible en IANA, que describe su papel en la infraestructura de Internet: https://www.iana.org/domains/arpa. Además, proveedores de contenido y operadores de DNS explican cómo funcionan las búsquedas inversas en términos prácticos, por ejemplo en la guía de Cloudflare sobre DNS inverso: https://www.cloudflare.com/learning/dns/dns-records/dns-reverse-lookup/.

La trampa observada por investigadores como los de Infoblox consiste en aprovisionar bloques de direcciones IPv6 —a menudo a través de servicios de tunelización como Hurricane Electric Tunnelbroker— y luego tomar control de la zona de DNS inverso para esa porción de espacio. Una vez que el actor malicioso administra esa zona, algunos paneles de gestión de DNS permiten crear tipos de registro distintos del clásico PTR; los atacantes aprovechan precisamente esa permisividad para definir registros A que apuntan a infraestructura de phishing.

El efecto práctico es inquietante: en lugar de un dominio registrado en un registro público con WHOIS, antigüedad y métricas que las pasarelas antiphishing suelen analizar, el enlace incrustado en un correo puede apuntar a un nombre derivado de la dirección IPv6 dentro de ip6.arpa. Al estar la URL escondida en una imagen o en un elemento visual del correo, muchas víctimas no ven la dirección completa; al hacer clic, el navegador resuelve el nombre en la zona inversa controlada por el atacante y se redirige a través de una plataforma de distribución de tráfico (TDS). Si el visitante cumple ciertos criterios —por ejemplo, tipo de dispositivo, país o referer— se le envía al sitio de phishing; si no, se le remite a contenidos legítimos o a errores, lo que complica aún más el seguimiento y la detección forense.

Los atacantes además han recurrido a proveedores con buena reputación para alojar las zonas autoritativas, lo que les da una capa extra de legitimidad frente a sistemas automatizados que confían en la reputación del proveedor. Infoblox documentó casos en los que se emplearon servicios de operadores respetados como Hurricane Electric o incluso Cloudflare para publicar registros autoritativos que terminaban resolviendo a infraestructuras intermedias y ocultaban la verdadera localización del backend.

Otra pieza del rompecabezas es la corta vida útil de los enlaces maliciosos: suelen estar activos solo unos días antes de caer o redirigir a sitios inocuos. Ese comportamiento reduce las ventanas de observación y dificulta que los investigadores y las herramientas de bloqueo construyan firmas eficaces. En paralelo, los atacantes han combinado esta técnica con otras conocidas, como el secuestro de CNAME olvidados —lo que Infoblox ha descrito en investigaciones previas— y el fenómeno conocido como subdomain shadowing, que permite empujar contenidos maliciosos a subdominios vinculados a organizaciones legítimas.

Desde la perspectiva de los defensores, hay dos razones que hacen este abuso especialmente preocupante. Primero, los dominios dentro de .arpa no contienen la metadata de registro habitual (WHOIS, antigüedad o contactos), por lo que las pasarelas de correo que basan parte de su evaluación en esa información tienen menos palancas de identificación. Segundo, la propia mecánica de delegación reversa y las reglas de algunos paneles de DNS permiten que se publiquen tipos de registros inesperados dentro de zonas de infraestructura, algo que los actores maliciosos explotan.

No todo está perdido: hay medidas tanto a nivel usuario como a nivel operativo que reducen el riesgo. Para las personas, la regla básica sigue siendo válida y urgente: no clicar enlaces inesperados en correos y, cuando sea necesario acceder a un servicio, teclear la URL oficial o usar favoritos y aplicaciones oficiales. Para equipos de seguridad y administradores, conviene revisar las delegaciones de DNS inverso en los bloques que controlan, exigir a los proveedores de túneles y de DNS que restrinjan los tipos de registros permitidos en zonas reversas y vigilar patrones de resolución inusuales hacia zonas .arpa. También es recomendable que las soluciones de filtrado y las pasarelas de correo incluyan controles específicos para detectar y analizar enlaces bajo ip6.arpa y que exista coordinación con los proveedores de DNS cuando se observen abusos.

La comunidad de seguridad ya ha empezado a alertar y a comunicar hallazgos a proveedores y operadores para cerrar huecos operativos. Los artículos de Infoblox sobre este abuso y sus investigaciones previas sobre CNAMEs colgantes son un buen punto de partida para quien quiera profundizar: Abusing .arpa (Infoblox) y Cloudy with a chance of hijacking (Infoblox). Para entender riesgos relacionados como el subdomain shadowing, el análisis de Proofpoint resulta esclarecedor: The Shadow Knows (Proofpoint).

Al final, la lección es clara: las piezas más técnicas de Internet —las que históricamente se dieron por hechas— pueden convertirse en vectores de ataque cuando la visibilidad y las reglas operativas no son las adecuadas. Los atacantes están buscando los espacios "quietos" de la red donde las reglas de confianza funcionan a su favor, y la defensa requiere tanto prácticas de higiene digital por parte de los usuarios como ajustes de política y vigilancia más fino por parte de los operadores y proveedores.