▸ Cómo encontrar dominios de typosquatting

Genera permutaciones de tu marca y compáralas con un corpus de dominios que ya se sabe que existen, en vez de lanzar una consulta DNS por candidato. Prioriza lo que quede por tres campos: registro MX, registro A y certificado TLS. Esos tres separan el puñado sobre el que hay que actuar de los varios cientos de cadenas aparcadas que no lo merecen.

• ▸ ¿Auditoría puntual de una marca tuya? dnstwist más una consulta al corpus. Una tarde, sin presupuesto.
• ▸ ¿Detección continua? Filtra el feed diario de dominios nuevos con tu lista de permutaciones y lee Certificate Transparency. Un registro se detecta el día en que ocurre, no el día en que se usa contra ti.
• ▸ ¿Decidir qué escalar? Empieza por tus propios logs de resolución. Un dominio parecido que nadie de tu organización ha resuelto nunca va por debajo de otro que diez personas visitaron la semana pasada.

Typosquatting en sentido estricto es registrar un dominio al que una persona llega escribiendo mal el tuyo. En la práctica, cinco familias distintas se archivan bajo la misma palabra y necesitan métodos de detección distintos: un generador de permutaciones encuentra las dos primeras y es ciego al resto.

• 1. Typosquatting - un error de teclado. exapmle.com, exmple.com, examlpe.com. Lo encuentra la generación de permutaciones.
• 2. TLD squatting - la misma cadena bajo otra extensión. example.co, example.cm, example.app. También es permutación, pero la lista de TLD la pones tú.
• 3. Combosquatting - tu marca bien escrita, más una palabra. example-login.com, secure-example.net, example-support.co. Es la familia más común en el phishing real y ningún generador de erratas la produce. Solo la búsqueda por subcadena en dominios registrados la encuentra.
• 4. Suplantación homógrafa / IDN - caracteres que se ven iguales. a cirílica por a latina, rn por m, 1 por l. Se almacenan como punycode (xn--), así que una comparación de bytes contra tu marca no los detecta nunca.
• 5. Bitsquatting - un solo bit cambiado en el nombre mientras está en memoria o en tránsito. fxample.com por example.com. Raro, real y barato de generar.

dnstwist es la implementación de referencia y lo que casi todo el mundo acaba usando. Aplica todas las familias de permutación en una pasada - omisión, inserción, repetición, transposición, sustitución por tecla adyacente, cambio de vocal, guiones, homoglifos y bitsquatting - y opcionalmente comprueba qué candidatos resuelven. urlcrazy viene con Kali y hace lo mismo con otras listas de palabras.

Tres formas de lanzarlo, de la más barata a la más completa:

# 1. Permutations only, no network - this is your candidate list
dnstwist --format list example.com > candidates.txt
wc -l candidates.txt

# 2. Same sweep, but resolve as it goes and keep only what exists
dnstwist --registered --format csv example.com > registered.csv

# 3. The two fields that decide priority later: MX, and a fuzzy hash of the
#    live page compared against the real one (--ssdeep on older builds)
dnstwist --registered --mx --lsh ssdeep --format json example.com > registered.json

# 4. Cross the brand with a TLD dictionary, not just the suffix you own
printf '%s\n' com net org co io app shop online site xyz > tlds.txt
dnstwist --tld tlds.txt --format list example.com | sort -u > candidates.txt

Un solo token como example produce del orden de mil a tres mil permutaciones antes de añadir TLD. Cruza eso con una lista de TLD y estás en decenas de miles de candidatos, que es justo por lo que el siguiente paso no es «resolverlos todos».

Ahora tienes miles de cadenas y ni idea de cuáles existen. Hay cuatro formas de averiguarlo y tres son peores de lo que parecen:

• ▸ Resolución DNS - rápida y gratis, pero solo demuestra que el nombre tiene registro A o NS. Un dominio registrado sin servidores de nombres no resuelve y se te escapa, y el caché negativo puede seguir devolviendo NXDOMAIN durante todo el mínimo del SOA.
• ▸ RDAP o WHOIS por candidato - autoritativo, y con límites de tasa por registro tan estrictos que 20.000 candidatos son varios días de trabajo. Úsalo con la lista corta, nunca con el conjunto de candidatos.
• ▸ Buscar en el fichero de zona - exacto para los gTLD en los que tengas aprobación de CZDS, varios gigabytes por zona, y ciego a casi todos los ccTLD.
• ▸ Consultar los candidatos en un corpus ya existente - una consulta en lugar de miles, sin límite de tasa y con cobertura de TLD a cuyas zonas no tienes acceso. De eso va la siguiente sección.

Este es el sitio en el que estás, así que pondera la sección en consecuencia. Está aquí por la forma del problema: DNSniffer indexa los ficheros de zona de los gTLD y Certificate Transparency de todos los TLD en una única tabla de dominios consultable - ahora mismo 358.047.798 dominios activos en 9957 TLD, el endpoint de búsqueda es público, no requiere cuenta y admite comodines. Así que en lugar de preguntar «¿existe este candidato?» veinte mil veces, preguntas una sola vez «¿qué existe que se parezca a esto?».

El comodín es lo que importa aquí: * sustituye a cualquier secuencia de caracteres, de modo que exam*le captura inserciones, omisiones y sustituciones en mitad del token con una sola consulta.

# 1. Every indexed domain containing your brand string, any TLD
curl -s 'https://dnsniffer.com/api/v1/domains?q=example&limit=1000' \
  | jq -r '.data[].name'

# 2. "*" is a wildcard, so one query covers a missing, extra or swapped
#    character anywhere in the middle of the token
curl -s 'https://dnsniffer.com/api/v1/domains?q=exam*le&limit=1000' \
  | jq -r '.data[] | [.name, .tld, .cert_issuer.organization // "-"] | @tsv'

# 3. Narrow to one TLD
curl -s 'https://dnsniffer.com/api/v1/domains?q=example&tld=com&limit=1000'

# 4. Screen today's new domains against the candidate list from step 1
URL=$(curl -s 'https://dnsniffer.com/api/v1/datasets?category=newly_detected' \
      | jq -r '.data[] | select(.periodicity=="daily") | .download_url')
curl -sL "https://dnsniffer.com$URL" -o nrd-daily.zip
unzip -p nrd-daily.zip | tail -n +2 | cut -d, -f1 | sort -u > today.txt
comm -12 today.txt <(sort -u candidates.txt) > hits.txt

Dos límites que conviene conocer antes de apoyarte en esto. El corpus se construye a partir de observaciones - delegación en zona y emisión de certificados -, así que un dominio registrado que nunca se delegó ni obtuvo certificado no está. Y un acierto te dice que el nombre existe, no cuándo se registró; verifica con RDAP todo aquello sobre lo que vayas a actuar.

Para detección continua en vez de una auditoría puntual, hay dos cosas que corren en el servidor. El monitor guarda hasta diez vigilancias por subcadena por cuenta y envía un resumen por correo cuando dominios recién indexados coinciden con alguna. Las exportaciones de dominios recién detectados te dan en CSV todos los dominios indexados en las últimas 24 horas, que es contra lo que lanzas tu lista de permutaciones. La página de dominios más nuevos es el mismo flujo en el navegador.

Un dominio parecido se vuelve peligroso cuando empieza a servir una página, y casi todas las páginas de phishing van por HTTPS, lo que implica un certificado y por tanto una entrada pública en los registros de Certificate Transparency segundos después de la emisión. CT es el único método de esta página que te avisa de un dominio parecido antes de que llegue la primera víctima, y el único que ve el spoofing de subdominio.

Dos formas de entrar: consumir un firehose agregado o leer los registros directamente por la API de RFC 6962. En ambos casos el filtro lo escribes tú, y en el filtro es donde encaja la comparación difusa: estás mirando un flujo de nombres, no probando una lista fija de candidatos.

# Aggregated firehose, filtered to names close to your brand
websocat wss://certstream.calidog.io \
  | jq -r '.data.leaf_cert.all_domains[]?' \
  | sed 's/^\*\.//' \
  | python3 -c '
import sys, unicodedata, idna
from rapidfuzz.distance import Levenshtein

BRAND = "example"

def decode(name):
    try:
        return idna.decode(name) if "xn--" in name else name
    except Exception:
        return name

def fold(s):
    # Cheap confusable folding. A real one uses the Unicode confusables table.
    s = unicodedata.normalize("NFKD", s)
    for a, b in (("rn", "m"), ("vv", "w"), ("1", "l"), ("0", "o"), ("5", "s")):
        s = s.replace(a, b)
    return s

for line in sys.stdin:
    name = line.strip().lower()
    label = fold(decode(name)).split(".")[0]
    if BRAND in label:                       # combosquat
        print("substring", name, flush=True)
    elif Levenshtein.distance(label, BRAND) <= 2:   # typo / homoglyph
        print("distance ", name, flush=True)
'

Los certificados llevan SAN, así que un certificado da muchos nombres. Reduce cada uno al dominio registrable y lanza tres pruebas, porque cada una es ciega a lo que capturan las otras: distancia de edición de 2 o menos contra tu token de marca encuentra la familia de erratas, una prueba de subcadena simple encuentra la familia combosquat, y decodificar las etiquetas xn-- antes de normalizar los caracteres confundibles encuentra la familia homógrafa.

Todo lo anterior encuentra dominios parecidos que existen. Tus logs de resolución encuentran dominios parecidos que funcionan, que es una lista mucho más corta y mucho más urgente. Dos consultas sobre tus logs de DNS o de proxy valen más que la mayoría de feeds de pago:

• ▸ Respuestas NXDOMAIN que se quedan a un carácter de tu propio dominio. Eso es tu propia gente y tus clientes escribiéndolo mal. Cada uno de esos nombres se puede registrar mañana y empezar a recoger correo mal dirigido. Registrar tú la cabecera de esa lista es el control más barato de esta página.
• ▸ Resoluciones correctas de nombres parecidos al tuyo que no son tuyos. Alguien dentro de tu red está llegando a un dominio parecido ahora mismo. Eso es un incidente, no un hallazgo de monitorización.

# Unbound / BIND query log -> names your users typed that do not exist,
# ranked by how many times they typed them
grep NXDOMAIN /var/log/unbound/query.log \
  | awk '{print tolower($NF)}' \
  | python3 -c '
import sys
from rapidfuzz.distance import Levenshtein
for name in sys.stdin:
    name = name.strip().rstrip(".")
    label = name.split(".")[0]
    if 0 < Levenshtein.distance(label, "example") <= 2:
        print(name)
' | sort | uniq -c | sort -rn | head -20

El DNS pasivo extiende la misma idea más allá de tu perímetro: los proveedores registran las resoluciones vistas por resolutores recursivos colaboradores y te dan una marca de primera aparición por nombre. Útil para determinar cuándo se puso en marcha un dominio parecido, y sesgado por construcción, porque solo ves lo que ve su red de sensores.

Los proveedores de protección de marca - MarkMonitor, CSC, ZeroFox, Bolster y una larga cola de otros - venden monitorización de dominios parecidos junto con la ejecución de retiradas. La monitorización no es la parte difícil, y las cinco secciones anteriores reproducen buena parte de ella. Lo que compras es la segunda mitad: relaciones establecidas con registradores y proveedores de hosting, denuncias de abuso presentadas y perseguidas. Si nadie de tu equipo tiene un martes por la tarde para discutir con un registrador de otra jurisdicción, eso vale dinero de verdad.

Cuatro vías una vez confirmado un dominio abusivo, de la más rápida y barata en adelante:

1. 1. Denuncias de abuso al registrador y al hosting - gratis, y con diferencia la vía más rápida para un sitio de phishing activo. Envía las pruebas en paralelo al contacto de abuso del registrador y al del proveedor de hosting: URL, capturas, marcas de tiempo y a quién suplanta. Una página activa de robo de credenciales puede caer en horas. Un dominio parecido aparcado se ignora.
2. 2. Envío a listas de bloqueo - Google Safe Browsing, APWG, PhishTank y tu propio filtro EDR o DNS. Esto protege a tus usuarios en minutos mientras todo lo demás avanza a velocidad jurídica.
3. 3. URS - desde unos 375 USD, resuelto en semanas. Solo suspende el dominio durante el resto de su periodo de registro, no te lo transfiere, y exige pruebas claras y convincentes. Bueno para phishing inequívoco, inútil para cualquier cosa discutible.
4. 4. UDRP - unos 1.500 USD de tasas del proveedor para un caso de panelista único que cubra unos pocos dominios, más abogado y un par de meses. Te transfiere el nombre. Debes acreditar los tres elementos: similitud confusa con tu marca, ausencia de interés legítimo por parte del titular y registro y uso de mala fe.

Un barrido de permutaciones de una marca conocida devuelve rutinariamente varios cientos de dominios parecidos registrados. Casi todos están aparcados, y perseguirlos todos es como muere un programa de protección de marca. Prioriza por indicios de operación, la señal más fuerte primero:

• ▸ Registro MX presente. El dominio puede recibir correo. Esto encabeza la lista siempre: así empiezan el fraude de facturas y el compromiso del correo corporativo, y no hace falta ninguna web.
• ▸ Registro A apuntando a un servicio HTTP vivo. Descárgalo. Una página de aparcamiento del registrador es ruido; una copia de tu formulario de login es un incidente.
• ▸ Certificado emitido. Alguien ha configurado algo. Los certificados DV gratuitos hacen que esto sea prueba débil por sí sola y prueba fuerte combinada con un registro A.
• ▸ Parecido de la página. Compara un hash difuso de la página renderizada, o simplemente el hash del favicon, con el tuyo. dnstwist --lsh hace lo primero por ti; una coincidencia de hash de favicon es tosca y sorprendentemente eficaz.
• ▸ Antigüedad del registro y registrador. Registrado la semana pasada en un registrador con mal historial de abuso es un riesgo distinto de un nombre que alguien tiene desde 2013. Aquí es donde la verificación por RDAP se gana sus límites de tasa.
• ▸ Resuelto por alguien que te importa. Cruza con tus logs de resolución. Eso convierte un acierto de monitorización en un ticket con radio de impacto.

# Rank confirmed lookalikes by how operational they are
while read -r d; do
  a=$(dig +short A "$d" | head -1)
  mx=$(dig +short MX "$d" | head -1)
  [ -n "$a$mx" ] && printf '%s\tA=%s\tMX=%s\n' "$d" "${a:--}" "${mx:--}"
done < hits.txt | sort -t= -k3 -r

# Authoritative registration date for the shortlist only - RDAP rate-limits
while read -r d; do
  curl -s "https://rdap.org/domain/$d" \
    | jq -r --arg d "$d" '.events[]? | select(.eventAction=="registration")
                          | "\($d),\(.eventDate)"'
  sleep 1
done < shortlist.txt > shortlist-dates.csv

• ▸ Medir distancia contra punycode. xn--exmple-4of.com está lejísimos de example.com en bytes y es idéntico en pantalla. Decodifica cada etiqueta xn-- antes de comparar nada.
• ▸ Fiarse de NXDOMAIN. Un dominio registrado sin servidores de nombres no resuelve. La ausencia de respuesta DNS no es ausencia de registro.
• ▸ Contar puntos para hallar el dominio registrable. foo.co.uk y foo.uk siguen reglas distintas. Usa la Public Suffix List.
• ▸ Solo generar y nunca buscar. Ningún generador de permutaciones producirá example-account-verify.com. Sáltate la búsqueda por subcadena en dominios registrados y toda la familia combosquat te será invisible, y es justo la familia que aparece en el phishing real.
• ▸ Volver a alertar en las renovaciones. Sin un conjunto permanente de primeras apariciones, cada renovación de certificado parece un hallazgo nuevo y tu cola se llena de dominios que ya triaste en marzo.
• ▸ Registrar defensivamente sin plan. Comprar las cincuenta erratas principales es sensato; comprar cinco mil es una factura recurrente sin salida, y el espacio de permutaciones es prácticamente infinito. Registra lo que tus propios logs de NXDOMAIN demuestren que la gente escribe de verdad, redirígelo a tu sitio real y deja el resto a la monitorización.