← Volver al blog
Dominios fraudulentos: typosquatting y ataques homográficos (IDN)

Dominios fraudulentos: typosquatting y ataques homográficos (IDN)

Hay un tipo de ataque que no explota un fallo de software, sino un fallo de percepción: el del ojo humano leyendo una barra de direcciones. El usuario hace todo "bien" (comprueba el dominio, ve que es el de su banco, ve el icono del candado) y aun así acaba en manos del atacante. En este post recorro las técnicas reales que se usan para fabricar dominios fraudulentos: typosquatting, combosquatting, bitsquatting y los ataques homográficos IDN con caracteres Unicode. Cómo funcionan, por qué tu cerebro no los detecta, cómo descubrirlos y cómo defenderte.

Entender el lado ofensivo es la única forma de construir una detección que funcione, y esa misma mentalidad práctica es la que aplicamos en nuestro curso Web eXploitation Expert (WXE), el curso de hacking web a nivel experto de SixHack Academy.

Nota: todos los dominios y marcas que aparecen en este artículo son ficticios y se usan solo con fines didácticos. Cualquier parecido con una entidad real es casualidad.


El problema de fondo: el dominio que ves no es el dominio que es

Un nombre de dominio es, para el usuario, una cadena de texto que lee de un vistazo. Pero por debajo hay dos capas que el atacante puede manipular sin que el usuario lo note:

  • La capa cognitiva: el cerebro no lee letra a letra, lee formas de palabra. rnimarca.com (con "r"+"n") se procesa como "mimarca" si no te paras a mirar.
  • La capa de codificación: desde IDN (Internationalized Domain Names), un dominio puede contener caracteres de cualquier alfabeto Unicode. Hay decenas de glifos en cirílico, griego o armenio que son visualmente idénticos a las letras latinas, pero que para el ordenador son caracteres completamente distintos.

El atacante juega con una o ambas capas. Vamos por tipos.


1. Typosquatting

El typosquatting (también "URL hijacking") consiste en registrar dominios que son variaciones de uno legítimo, apostando a que el usuario cometa un error de tecleo o de lectura. No hay Unicode de por medio: son caracteres ASCII normales, ordenados para confundir.

Las cinco familias clásicas

TécnicaDominio legítimoVariante fraudulentaTruco
Omisióntumarca.comtumara.comFalta una letra
Carácter repetidoconnecta.comconecta.comUna letra de menos en un doble
Transposiciónejemplo.comejmeplo.comDos letras intercambiadas
Sustitución (teclas vecinas)tubanco.comtubamco.com"n"→"m", contiguas en el teclado
Inserciónmitienda.commitiendaa.comCarácter de más

A esto se suma el TLD-squatting: mismo nombre, dominio de primer nivel distinto. El usuario que teclea de memoria escribe .com donde la empresa usa .org, o cae en un .co (sin la "m") que históricamente ha sido un nido de typosquatting por su parecido con .com.

Homóglifos ASCII: el truco que no necesita Unicode

Antes incluso de entrar en Unicode, el alfabeto latino ya ofrece parejas de caracteres que se confunden según la tipografía. El más famoso es la "l" minúscula y la "I" mayúscula, que en muchas fuentes sans-serif son indistinguibles, además del número "1":

Mismo aspecto, dominios distintos
miportal.com     ← legítimo (l minúscula)
miportaI.com     ← con I mayúscula, idéntico en Arial/Helvetica
miporta1.com     ← con el número uno

rn  vs  m  →  rnimarca.com   se lee como  "mimarca.com"
vv  vs  w  →  tuvveb.com     se lee como  "tuweb.com"
cl  vs  d  →  miclato.com    se lee como  "midato.com"

Estos son homóglifos (glifos que parecen iguales) pero todavía dentro de ASCII. No requieren IDN ni punycode: son registrables hoy mismo en cualquier registrador. Por eso son tan usados.


2. Combosquatting

El combosquatting no altera el nombre de la marca: lo combina con otra palabra. El dominio contiene la marca real, intacta, lo que lo hace especialmente convincente porque al buscar la marca en la cadena, ahí está.

La marca real + una palabra de gancho
tubanco-seguridad.com
tubanco-verificacion.com
login-tubanco.com
tubanco.cuenta-verificar.com    ← "tubanco" es subdominio de cuenta-verificar.com (!)
El truco del subdominio. Fíjate en el último ejemplo. El dominio real es cuenta-verificar.com (controlado por el atacante); tubanco es solo un subdominio. El usuario lee de izquierda a derecha, ve "tubanco" primero y se relaja. La parte que de verdad determina quién controla el sitio (el dominio registrable) está a la derecha, y casi nadie la mira.

Estudios académicos a gran escala han mostrado que el combosquatting es bastante más prevalente que el typosquatting clásico y que muchos de estos dominios permanecen activos durante años, precisamente porque contienen la marca legítima y pasan desapercibidos en revisiones superficiales.


3. Bitsquatting

El bitsquatting es el más curioso de todos porque no asume ningún error humano: asume un error de hardware. Un bit que cambia de 0 a 1 (o al revés) en la memoria RAM por un fallo transitorio (rayos cósmicos, calor, RAM defectuosa) puede transformar un carácter del dominio en otro adyacente en la tabla ASCII.

Un bit cambiado = otra letra
'a' = 0110 0001  (0x61)
'c' = 0110 0011  (0x63)   ← cambia el bit 1 de 'a' y obtienes 'c'
'e' = 0110 0101  (0x65)   ← cambia el bit 2 de 'a' y obtienes 'e'

midato.com  →  midcto.com   (un bit en la 'a' → 'c')
                    mideto.com   (otro bit en la 'a' → 'e')

El atacante registra todas las variantes a un bit de distancia de un dominio muy consultado (un CDN, un servidor de actualizaciones, un dominio de telemetría) y simplemente espera. Con miles de millones de resoluciones DNS al día, la estadística juega a su favor: tarde o temprano, una máquina con un bit corrupto pedirá su dominio. Es de explotación oportunista, pero es real y está documentado.


4. Ataques homográficos IDN: el corazón del problema

Aquí es donde la cosa se pone seria. Desde que los dominios admiten caracteres internacionales (IDN), el atacante ya no está limitado al alfabeto latino. Y resulta que Unicode contiene cientos de caracteres que se renderizan exactamente igual que las letras latinas, pero que son code points distintos.

El ejemplo canónico: la "а" que no era una "a"

CarácterGlifoCode pointAlfabeto
a latinaaU+0061Latín
а cirílicaаU+0430Cirílico
e latinaeU+0065Latín
е cirílicaеU+0435Cirílico
o latinaoU+006FLatín
о cirílicaоU+043ECirílico
c latinacU+0063Latín
с cirílicaсU+0441Cirílico

Las parejas de la tabla son visualmente idénticas en prácticamente cualquier fuente, pero el ordenador las trata como caracteres totalmente diferentes. Eso significa que puedo registrar un dominio que parece el de una marca conocida, pero donde una de las letras es cirílica. Para el sistema de nombres es un dominio nuevo y libre; para el ojo del usuario es indistinguible del real.

Punycode: cómo se codifica realmente

El DNS solo entiende ASCII. Cuando un dominio contiene caracteres Unicode, se traduce a una representación ASCII llamada punycode, con el prefijo xn--. Aquí está la clave defensiva: bajo el capó, el dominio fraudulento no se parece en nada al real.

analista@lab: ~ · inspección de un dominio homográfico
$ python3 -c "print('ассеѕо.com'.encode('idna'))"
# 'acceso' escrito con caracteres cirílicos que parecen latinos
b'xn--80ak1aka5j.com'

$ dig +short xn--80ak1aka5j.com
# El navegador muestra "acceso.com", pero el DNS resuelve ESTO:
203.0.113.42   ← no es la IP de la marca legítima

$ whois xn--80ak1aka5j.com | grep -i registrar
Registrar: Cheap-Registrar-LLC   ← señal de alarma

Demostración del concepto en código, para que se entienda la asimetría entre lo que se ve y lo que es:

python3 · mismo aspecto, distinto code point
legitimo = "acceso.com"          # todo latino
falso    = "\u0430\u0441\u0441\u0435\u0455\u043e.com"  # cirílico

print(legitimo)                  # acceso.com
print(falso)                     # ассеѕо.com   ← se ve igual
print(legitimo == falso)         # False       ← pero NO lo es
print(falso.encode("idna"))      # b'xn--80ak1aka5j.com'

Mixed-script vs single-script

Hay dos sabores de ataque homográfico, y la diferencia importa para la defensa:

  • Mixed-script (mezcla de alfabetos): el dominio combina latino y cirílico, p. ej. una sola "a" cirílica dentro de tubаnco.com. Los navegadores modernos detectan esta mezcla y, por política, muestran el punycode (xn--...) en lugar del glifo bonito. Es el caso más fácil de mitigar.
  • Single-script (un solo alfabeto entero): el caso famoso de 2017, una marca tecnológica muy conocida reproducida íntegramente en cirílico. Como no hay "mezcla", algunos navegadores no aplicaban la heurística de mixed-script y mostraban el dominio en limpio, idéntico al real. Esto obligó a los navegadores principales a endurecer sus reglas de visualización IDN.
analista@lab: ~ · caso mixed-script (una sola letra cambiada)
$ python3 -c "import idna; print(idna.encode('tubаnco.com').decode())"
# 'tubanco' con UNA 'a' cirílica (U+0430), el resto latino
xn--tubnco-5nf.com   ← este es el dominio que de verdad se registra
Estado actual (2026). Los navegadores principales aplican las reglas de detección de scripts confundibles de Unicode (UTS #39) y muestran punycode cuando detectan riesgo. Pero la protección no es total: depende del TLD, de las políticas del registro y de la combinación concreta de caracteres. Y fuera del navegador (clientes de correo, apps de mensajería, terminales, PDFs, notificaciones) la protección suele ser mucho más débil o inexistente. El correo electrónico sigue siendo el vector más explotado.

Reconocimiento: cómo se generan y detectan estas variantes

Desde el lado ofensivo (y por tanto, desde el lado del que tiene que defender una marca), la herramienta de referencia es dnstwist. Genera de forma sistemática todas las permutaciones de un dominio (typos, homóglifos, bitsquatting, combinaciones de TLD, homográficos) y comprueba cuáles están registradas y activas.

analista@lab: ~ · dnstwist sobre un dominio propio
$ pip install dnstwist

# Generar variantes y comprobar cuáles están registradas (--registered)
$ dnstwist --registered --mxcheck tudominio.com

fuzzer       domain                 dns_a            dns_mx
homoglyph    tudоminio.com          203.0.113.40     mail.bad.example  ← 'o' cirílica + MX activo
omission     tudominio.co           203.0.113.7      -
addition     tudominio-soporte.com  203.0.113.9      mail.bad.example  ← combosquat con correo
tld          tudominio.net          203.0.113.2      -

# Exportar a JSON para integrarlo en un pipeline de monitorización
$ dnstwist --format json tudominio.com > variantes.json

La presencia de un registro MX activo en una variante es la señal más preocupante: significa que ese dominio fraudulento puede recibir y enviar correo, es decir, está preparado para phishing, no solo aparcado.

Inspeccionar un dominio sospechoso a mano

bash · desenmascarar caracteres ocultos
# Ver los bytes reales de un dominio (revela code points no-ASCII)
echo -n "tubаnco.com" | hexdump -C
# Si ves bytes como d0 b0 (UTF-8 de U+0430), hay cirílico camuflado

# Convertir a punycode para ver el dominio "real"
python3 -c "import idna; print(idna.encode('tubаnco.com').decode())"
# xn--tubnco-5nf.com   ← este es el dominio que de verdad se registra

# Monitorizar Certificate Transparency: ¿alguien ha sacado un cert
# para una variante de mi marca?
curl -s "https://crt.sh/?q=%25tudominio%25&output=json" | \
  jq -r '.[].name_value' | sort -u

El flujo completo de un ataque real

Juntando las piezas, así encadena un atacante estas técnicas en una campaña de phishing dirigida:

Cadena de ataque típica
1. RECON      → dnstwist sobre la marca objetivo; elige una variante
                 libre y creíble (homográfica o combosquat)
2. REGISTRO   → registra el dominio en un registrador poco estricto; añade
                 registros MX para poder enviar correo
3. TLS        → saca un certificado TLS gratuito: el
                 candado verde aparece igual que en el sitio real
4. CLONADO    → copia el sitio legítimo (login incluido)
5. ENTREGA    → envía el correo desde el dominio fraudulento; el
                 remitente "se ve" idéntico al real
6. CAPTURA    → el usuario introduce credenciales; se reenvían al
                 sitio real para no levantar sospechas
El candado no significa "seguro". Uno de los mitos más peligrosos. El certificado TLS solo garantiza que la conexión está cifrada y que el dominio es el que dice ser, ese dominio, no necesariamente el que el usuario cree. Un dominio homográfico con un certificado gratuito muestra exactamente el mismo candado que el banco real. El candado nunca fue una garantía de legitimidad.

Defensa: qué hacer desde cada lado

Como usuario

  • Desconfía del enlace, escribe tú la URL o usa marcadores guardados para sitios sensibles (banca, correo, trabajo).
  • Si un dominio aparece como xn--... en la barra, es un IDN: párate y verifícalo. No es necesariamente malicioso, pero merece una mirada.
  • El "candado" no valida la identidad del titular. Mira el dominio registrable (la parte justo a la izquierda del TLD), no el principio de la cadena.

Como empresa / equipo de seguridad

  • Registro defensivo: registra las variantes más obvias de tu marca (typos comunes, TLDs principales, y al menos el punycode homográfico de tu nombre). Es barato comparado con el coste de una campaña de phishing exitosa.
  • Monitorización continua: integra dnstwist y vigilancia de Certificate Transparency (crt.sh) en un pipeline que te alerte cuando aparezca una variante registrada o se emita un certificado para una.
  • Endurece el correo: SPF, DKIM y sobre todo DMARC en modo p=reject. No frena el registro de dominios parecidos, pero impide que suplanten tu dominio, que es la mitad del problema.
  • Formación realista: simulacros de phishing que incluyan dominios homográficos y combosquatting, no solo el típico "haz clic aquí" burdo.

Como registro / navegador

  • Aplicar las políticas IDN de cada zona: muchos registros prohíben mezclar scripts en un mismo label.
  • Implementar las reglas de caracteres confundibles de Unicode (UTS #39) para mostrar punycode ante mezclas de riesgo.

¿Quieres llevar tu hacking web al nivel experto?

Si te interesa la explotación de aplicaciones web a nivel profesional, el curso Web eXploitation Expert (WXE) te lleva por el ataque y la defensa de aplicaciones reales, con laboratorios prácticos y la misma metodología que aplicamos en programas de bug bounty y responsible disclosure.


Preguntas frecuentes

¿Es ilegal registrar un dominio parecido a una marca?

Registrar el dominio en sí entra en terreno de propiedad intelectual y disputas tipo UDRP (cibersquatting), no necesariamente penal por sí solo. Lo que sí es claramente ilegal es usarlo para suplantar, estafar o capturar credenciales. En un contexto de auditoría o bug bounty, todo este trabajo se hace sobre dominios propios o con autorización explícita.

¿Los navegadores ya no protegen contra los ataques homográficos?

Protegen parcialmente: muestran punycode cuando detectan mezclas de scripts sospechosas, pero la cobertura depende del TLD y de la combinación de caracteres, y fuera del navegador (correo, apps, terminales) la protección es mucho más débil. No es un problema resuelto.

¿Qué diferencia hay entre typosquatting y combosquatting?

El typosquatting altera el nombre de la marca (letras cambiadas, omitidas o transpuestas). El combosquatting mantiene la marca intacta y le añade otra palabra (tubanco-seguridad.com). El segundo suele ser más convincente porque la marca real aparece tal cual.

¿Sirve de algo el candado HTTPS para detectar estos dominios?

No. El candado solo indica conexión cifrada con ese dominio. Un dominio fraudulento puede tener un certificado válido y gratuito y mostrar el mismo candado que el sitio legítimo. Hay que mirar el dominio, no el candado.


Referencias

  • dnstwist: generación y detección de dominios permutados (typo, homóglifo, bitsquatting, IDN).
  • Unicode UTS #39: mecanismos de seguridad y caracteres confundibles.
  • RFC 3492: Punycode, la codificación de IDN a ASCII.
  • crt.sh: búsqueda en logs de Certificate Transparency.
  • DMARC.org: autenticación de correo para impedir la suplantación de tu propio dominio.
← Volver al blog