Un ataque homógrafo registra un dominio construido con caracteres que se parecen a los de un dominio real, pero no lo son. Una "о" cirílica ocupa el lugar de una "o" latina, y la dirección que lees y la que resuelve un navegador pasan a ser dos cosas distintas. El truco viaja como punycode: el DNS solo entiende ASCII, así que todo nombre no ASCII se convierte en una etiqueta xn-- antes de tocar la red, y los navegadores la convierten de vuelta para mostrarla. Ese camino de vuelta es donde vive el engaño.
Los navegadores modernos ya detectan los casos evidentes y muestran punycode en bruto cuando una etiqueta mezcla alfabetos de forma sospechosa. Pero esa protección se queda dentro de la barra de direcciones. Este artículo explica cómo funciona el ataque, qué hacen los estándares y los navegadores al respecto, dónde se detienen y qué puede y qué no puede ver un escáner de enlaces. Para la cuestión más amplia de los enlaces cortos, son seguros los acortadores de URL cubre ese terreno; este trata del dominio que hay debajo del enlace.
Qué es el punycode y por qué existe
El DNS se diseñó para ASCII. Y punto. No tiene una forma nativa de almacenar letras acentuadas, cirílico, árabe o chino, lo que se convirtió en un problema en cuanto el registro de dominios se abrió fuera de los mercados de habla inglesa.
El punycode es la solución: una codificación reversible, estandarizada como RFC 3492, que convierte una etiqueta Unicode en letras, dígitos y guiones que el DNS transporta sin cambios. Una panadería alemana con diéresis en el nombre o un comercio ucraniano que se registra en cirílico obtiene un dominio internacionalizado que funciona y se resuelve como cualquier otro. La etiqueta codificada empieza por xn--, lo que significa "decodificar antes de mostrárselo a una persona".
Nada de eso es un fallo. Los dominios internacionalizados son una función necesaria. El problema empieza una capa más arriba. El software decide cómo se muestra el nombre decodificado.
Cómo funciona un ataque homógrafo
El ataque explota la distancia entre lo que contiene un dominio y su aspecto una vez renderizado. El informe de seguridad de Unicode, UTS #39, aporta el vocabulario (consultado el 2026-10-25). Dos cadenas son confundibles (confusable) cuando se reducen al mismo "skeleton". Después distingue el confusable de escritura completa, en el que una cadena escrita por entero en una escritura, como el "scope" latino, tiene un equivalente escrito por entero en otra, aquí el cirílico, del confusable de escritura mixta, en el que el equivalente mezcla escrituras.
La versión de escritura completa necesita un nombre en el que cada letra tenga un equivalente en otra escritura. Es más rara. Pocas marcas reales pueden escribirse así. La versión de escritura mixta solo necesita una sustitución. Toma novacloud.com, cambia la "o" latina por la "о" cirílica (U+043E) y obtienes un dominio con la misma forma y longitud que se codifica como xn--nvacloud-nbh.com. El ojo casi no tiene nada que señalar. Ese es el objetivo.
Una vez registrado el dominio, el resto es phishing corriente. Una página de inicio de sesión copiada, un mensaje urgente, una víctima sin motivo para dudar de una dirección que parece correcta.
Qué hacen los navegadores al respecto
Los navegadores cerraron la versión fácil de este ataque con reglas sobre qué escrituras pueden compartir una etiqueta. La política IDN de Chrome decide por etiqueta y recurre al punycode en muchos casos (consultado el 2026-10-25). Establece que los caracteres latinos, cirílicos y griegos no pueden mezclarse entre sí, y además muestra punycode para los confusables de escritura mixta, para las etiquetas formadas íntegramente por confusables de escritura completa salvo que el dominio de nivel superior esté en el territorio habitual de esa escritura, y para las etiquetas cuyo skeleton coincide con un dominio popular. Firefox aplica una comprobación comparable, descrita en el algoritmo de visualización IDN de Mozilla, y Safari tiene la suya.
El resultado es que nоvacloud.com con una letra cirílica aparece como xn--nvacloud-nbh.com en Chrome. No es una protección completa. Las reglas difieren según el navegador, y una imitación de una sola escritura que ninguna lista previó aún puede mostrarse como un nombre legible y engañoso.
Dónde se acaba esa protección
La comprobación de mezcla de escrituras vive en el renderizado de la barra de direcciones del navegador. No viaja con la URL.
Los clientes de correo pueden mostrar cualquier texto de ancla sobre cualquier destino. Muchos no hacen ninguna comprobación de confusables, y las apps de correo móviles son las más débiles. Las apps de chat despliegan un enlace en una tarjeta de vista previa construida con los metadatos de la página. Los códigos QR eliminan el paso del texto, una brecha que tratamos en son seguros los códigos QR, y el material impreso no tiene ninguna capa de software.
| Canal | Muestra el destino real antes de actuar | Exposición típica |
|---|---|---|
| Navegador de escritorio moderno | Normalmente, con las reglas de mezcla de escrituras | Baja, si está actualizado |
| Cliente de correo | Rara vez, porque el texto del ancla puede decir cualquier cosa | Alta, sobre todo en apps de correo móviles |
| Apps de chat y mensajería | Rara vez, las vistas previas usan metadatos de la página | Alta, los enlaces desplegados se ven idénticos |
| Código QR | No, nada se renderiza hasta después del escaneo | Alta, la decisión lleva un segundo |
| Material impreso | Nunca, no interviene ningún software | La más alta, no es posible ninguna comprobación técnica |
Qué puede comprobar un acortador de enlaces
Un acortador se sitúa entre el remitente y el navegador, así que puede examinar un destino antes de que nadie haga clic. Cuánto ve depende de la implementación, y esto es lo que hace Elido hoy, según el código.
La heurística de url-scanner suma 25 puntos cuando el host de destino empieza por xn-- o contiene una etiqueta que empieza así. Suma más por nombres de marca en el host o la ruta, por una @ que oculta el host real, por hosts con IP directa y por hostnames llenos de guiones. Las puntuaciones de la heurística están limitadas a 75, por debajo de los 80 necesarios para bloquear, así que un host punycode por sí solo se marca como sospechoso, nunca se bloquea. Para cruzar la línea hace falta una coincidencia en un feed de amenazas o una segunda señal. El escáner también consulta feeds de amenazas, que listan dominios calcados una vez que alguien los denuncia.
Hay una brecha, y es real. Esa prueba de xn-- se ejecuta sobre el hostname tal como se envía, y no encontré en api-core ni en el escáner ningún paso que convierta primero un hostname Unicode a su forma ASCII. Un destino pegado en forma Unicode (la versión cirílica) puede por tanto saltarse la señal de punycode que activaría su gemelo ASCII. La comprobación de imitación de marca es además una coincidencia de subcadenas ASCII, así que no detectará en absoluto un "раураl" cirílico. Hemos registrado ambas cosas como tareas pendientes (backlog). Hasta que se arreglen, trata la heurística como un filtro barato de primera línea, no como un detector de homógrafos.
Por otro lado, los dominios personalizados son más estrictos. El gestor de alta de dominios solo acepta letras ASCII, dígitos y guiones, así que un espacio de trabajo no puede añadir un hostname Unicode en bruto, aunque sí puede añadir una forma xn--.
Por qué te ayuda un dominio de marca
Un ataque homógrafo necesita una marca reconocible que falsificar. Eso no es motivo para evitar construir una. Un enlace de marca distintivo que tu audiencia asocia contigo les da algo con lo que comparar un mensaje sospechoso. Un dominio compartido genérico da una plantilla a un atacante. Los clientes no pueden distinguirlo del proveedor real.
Configurar un dominio personalizado significa que cada enlace que envías lleva un nombre que los destinatarios conocen, lo que sube el listón para quien intente falsificarlo. Mira cómo funcionan los dominios personalizados en Elido; tienes uno en Pro y cinco en Business. Es lo contrario del cloaking de enlaces, que es una decisión declarada de enrutar los enlaces por tu propio dominio. Un ataque homógrafo oculta la identidad del atacante mientras imita la tuya.
Controles del registrador para los dominios que posees
El bloqueo de registrador, que suele mostrarse como clientTransferProhibited, impide las transferencias automáticas rutinarias. Actívalo. El registry lock involucra al operador del registro, de modo que cualquier cambio, transferencia o eliminación requiere una verificación manual por otra vía. Resérvalo para los dominios en los que un cambio no autorizado saldría caro.
Ninguno de los dos bloqueos impide que alguien registre un dominio calcado junto al tuyo. Eso solo lo detecta la monitorización: vigila los nuevos registros y los registros de transparencia de certificados en busca de nombres cercanos a tu marca, y ten un responsable con nombre y una vía para denunciar una imitación ante su registrador. La lista de seguridad para elegir un proveedor de enlaces cubre controles de proveedor relacionados.
Una receta de verificación que cualquiera puede seguir
No necesitas entender el punycode. Cuatro pasos detectan casi todo aquello en lo que se apoya este ataque.
- Expande primero el enlace. Cómo ver adónde lleva una URL corta enumera las herramientas, y el verificador de enlaces de Elido es una de ellas. En un enlace corto de Elido, añadir
+al final muestra una página de vista previa con el destino en lugar de redirigir. - Lee el dominio registrable, la parte justo antes del dominio de nivel superior. Es la parte que un atacante tiene que controlar.
- Busca una etiqueta
xn--en la URL expandida o en la barra de direcciones. Donde esperabas un nombre de marca normal, detente y trátalo como una imitación. - Comprueba el nombre del certificado en el destino. Refleja lo que se emitió al titular del dominio, que es más difícil de falsificar de forma convincente que una etiqueta renderizada, aunque ten en cuenta que también se emiten certificados a dominios calcados, así que un candado no prueba honestidad.
Un ataque homógrafo es un problema de visualización, no un fallo de protocolo. El punycode hace lo que se diseñó para hacer; el engaño ocurre entre lo que un dominio es y lo que el software te muestra. Los navegadores han cerrado la mayor parte de esa brecha en la barra de direcciones. En todos los demás sitios sigue abierta. Expandir un enlace y leer el dominio registrable sigue siendo el hábito que funciona, sea cual sea el canal por el que llegó.
Relacionado en el blog
- ¿Son seguros los acortadores de URL? Qué detecta el escaneo
- ¿Son seguros los códigos QR? El quishing y cómo mantenerte protegido
- Seguridad de acortadores de URL: 10 controles a verificar
- Enlaces cortos con dominio personalizado: DNS, TLS y lo que se ejecuta en el edge
- Cómo ver adónde lleva una URL corta antes de hacer clic
Preguntas frecuentes
¿Qué es un ataque homógrafo IDN?
Consiste en registrar un dominio con caracteres de otro alfabeto que se ven igual que los de un dominio real, de modo que el lector no puede distinguirlos. El caso clásico cambia una letra latina por un equivalente cirílico o griego. Los dos dominios difieren a nivel de punto de código, por lo que pueden pertenecer a titulares distintos. El ataque funciona solo por la apariencia, y por eso apunta a nombres de marcas conocidas.
¿Qué es el punycode y para qué existe?
El punycode, definido en el RFC 3492, convierte una etiqueta de dominio no ASCII en una cadena ASCII que el DNS puede almacenar y resolver. Un dominio escrito en cirílico, árabe, chino o con letras latinas acentuadas se convierte así antes de la consulta, y la etiqueta codificada siempre empieza por xn--. Los navegadores la decodifican de vuelta para mostrarla. Es una función legítima, no la vulnerabilidad en sí.
¿Qué significa el prefijo xn-- en una URL?
Marca una etiqueta como la codificación compatible con ASCII de un nombre que contenía caracteres no ASCII. En el ejemplo de aquí, xn--nvacloud-nbh.com se decodifica como un nombre que parece novacloud.com con una o latina sustituida por una cirílica. Un dominio ASCII normal nunca produce una etiqueta xn--, así que verla donde esperabas una marca conocida merece una segunda mirada.
¿Protegen los navegadores contra los ataques homógrafos?
En gran medida, en la barra de direcciones. Chrome muestra punycode en lugar de Unicode cuando una etiqueta mezcla latino, cirílico o griego, cuando es un confusable de escritura mixta o cuando su skeleton coincide con un dominio popular. Firefox y Safari tienen reglas propias. Los atacantes aún pueden usar imitaciones de una sola escritura que se cuelan, y la protección no acompaña al enlace al correo, al chat ni a un código QR.
¿Cómo sé si un enlace es un dominio calcado antes de hacer clic?
Expande el enlace para ver el destino real, lee el dominio registrable justo antes del dominio de nivel superior y busca una etiqueta xn--. Si aparece una donde esperabas un nombre de marca normal, trátalo como una imitación hasta demostrar lo contrario. Escribir tú mismo la dirección o usar un marcador guardado para bancos y páginas de pago evita la cuestión por completo.
¿Qué es el registry lock y mi dominio lo necesita?
El registry lock bloquea cualquier cambio, transferencia o eliminación de un dominio hasta que se verifica por otra vía, normalmente por teléfono o con una frase de paso, de modo que ni siquiera una cuenta de registrador comprometida pueda moverlo. Es más fuerte que un bloqueo de registrador, que solo impide las transferencias automáticas rutinarias. Conviene a los dominios cuyo secuestro saldría caro, normalmente tu dominio principal de marca. No impide que alguien registre un dominio de aspecto similar junto al tuyo; de eso se encarga la monitorización.
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Se necesita una cuenta gratuita. El plan gratuito incluye 25 enlaces en total. ¿Ya tienes una cuenta? Iniciar sesión