OSINT de un dominio de phishing: metodología completa

¿Qué se puede averiguar de un dominio de phishing sin tocarlo?

Partiendo solo de un dominio sospechoso puedes reconstruir cuándo se registró, quién lo aloja, qué otros dominios comparten su certificado o su servidor, qué kit de phishing utiliza y qué más ha desplegado el mismo actor: todo mediante consultas a registros públicos y a terceros que ya han visitado el sitio, sin enviar ni un paquete al servidor del atacante.

Esta guía recorre esa metodología en orden, de lo más pasivo a lo más intrusivo, y se detiene donde empieza el terreno que puede meterte en problemas legales o delatarte. Los comandos son reproducibles: sustituye el dominio de ejemplo por el tuyo y obtendrás resultados reales.

En este artículo verás ejemplo-malicioso.test como marcador de posición. No uso un dominio de phishing real porque los dominios maliciosos caducan, cambian de manos y las salidas de las herramientas quedarían obsoletas en semanas. La metodología, en cambio, no caduca.

¿Qué es pasivo y qué es activo, y por qué importa tanto?

Antes del primer comando conviene tener clara esta distinción, porque determina tanto tu seguridad legal como la calidad de la investigación:

La solución para ver el contenido sin exponerte es delegar la visita: urlscan.io navega por ti y te devuelve captura, DOM, cadena de peticiones y certificados. Si lo usas, hazlo en modo privado (unlisted): un escaneo público avisa al atacante de que alguien lo está mirando, porque los operadores vigilan estas plataformas buscando sus propios dominios.

Convención de escritura: los indicadores se anotan siempre «desactivados» (hxxps://, ejemplo[.]com) para que nadie los abra por accidente al copiarlos de un informe. Adóptala desde el primer apunte.

¿Qué te dicen las cabeceras del correo que trajo el enlace?

Si el dominio te llegó por correo —el caso habitual—, las cabeceras del mensaje son la fuente más rica de todo el proceso y la que más gente se salta. Pide siempre el mensaje original completo (.eml), no una captura ni un reenvío: reenviar un correo destruye las cabeceras originales, que es justo lo que necesitas.

La cadena de saltos

Las cabeceras Received: se leen de abajo arriba: la de más abajo es el primer servidor que tocó el mensaje y suele ser la más reveladora, porque los siguientes ya son infraestructura legítima de tránsito. Ahí aparecen la IP de origen real y, con suerte, el software de envío.

El desajuste que explica por qué el SPF no basta

Este es el punto que separa un análisis serio de una lectura superficial. El SPF valida el dominio del sobre (Return-Path), no el que ve el usuario en el campo From. Un atacante puede registrar un dominio propio, configurarle un SPF perfecto y enviar desde él un correo cuyo From visible dice ser tu banco: el SPF pasa y el usuario ve el remitente suplantado. Por eso importa DMARC, que es quien exige que ambos dominios estén alineados.

Authentication-Results: mx.ejemplo.com;
  spf=pass       smtp.mailfrom=dominio-del-atacante.test
  dkim=pass      header.d=dominio-del-atacante.test
  dmarc=fail     header.from=marca-suplantada.com

Return-Path: <envios@dominio-del-atacante.test>
From: "Soporte Marca" <soporte@marca-suplantada.com>

¿Qué te dice el registro del dominio?

El primer paso es consultar los datos de registro. Hoy conviene usar RDAP en lugar de WHOIS: es el protocolo que lo sustituye, devuelve JSON estructurado (en vez de texto libre distinto en cada registrador) y está estandarizado en el RFC 9083.

# rdap.org redirige automáticamente al servidor RDAP del TLD correspondiente
curl -s https://rdap.org/domain/ejemplo-malicioso.test | jq '{
  registrar: .entities[]?.vcardArray?[1]?[]? | select(.[0]=="fn") | .[3],
  eventos:   [.events[] | {accion: .eventAction, fecha: .eventDate}],
  estados:   .status,
  ns:        [.nameservers[]?.ldhName]
}'

Lo que de verdad importa de esa salida:

¿Cómo detectas un dominio que imita visualmente a otro?

Los dominios internacionalizados permiten caracteres no latinos, y ahí aparece el ataque homográfico: la «а» cirílica (U+0430) es visualmente idéntica a la «a» latina (U+0061), pero son dominios completamente distintos. A simple vista, en un correo, son indistinguibles.

Bajo el capó esos dominios se codifican en Punycode (RFC 3492), reconocible por el prefijo xn--. La comprobación es trivial y conviene hacerla siempre que un dominio «parezca» legítimo:

# Si el resultado empieza por xn--, el dominio contiene caracteres no ASCII
>>> "аpple.com".encode("idna")
b'xn--pple-43d.com'

# El mismo dominio escrito con la «a» latina no se transforma
>>> "apple.com".encode("idna")
b'apple.com'

Los navegadores modernos mitigan esto mostrando la forma xn-- cuando un dominio mezcla escrituras, pero el cliente de correo no siempre lo hace, y ahí es donde el ataque sigue funcionando. Si estás documentando un caso, anota siempre la forma Punycode además de la visual: es la única representación no ambigua.

El homógrafo es solo una de las familias de imitación. Las demás se enumeran y comprueban de golpe con dnstwist, que ya vimos: sustituciones de caracteres parecidos, letras omitidas o duplicadas, guiones insertados, TLD alternativos y subdominios que colocan la marca a la izquierda del punto real (tu-banco.com.dominio-atacante.test), que es la variante que más engaña en pantallas de móvil.

¿Cómo encuentras subdominios que el atacante creía ocultos?

Aquí está la técnica más rentable de todo el proceso. Desde 2018 los navegadores exigen que cada certificado TLS emitido se publique en registros públicos de Certificate Transparency, definidos en el RFC 6962. Consecuencia práctica: cada vez que el atacante pide un certificado, publica el nombre del subdominio para el que lo pide.

# Todos los nombres que han aparecido en certificados del dominio
curl -s "https://crt.sh/?q=%25.ejemplo-malicioso.test&output=json" \
  | jq -r '.[].name_value' \
  | tr '\\n' '\\n' | sort -u

# Y en sentido inverso: otros dominios del mismo actor que comparten
# un certificado, buscando por la organización o el correo del registrante
curl -s "https://crt.sh/?q=cadena-observada&output=json" | jq -r '.[].name_value' | sort -u

Lo interesante es lo que aparece: paneles de administración (admin., panel.), entornos de pruebas (dev., test.) y, sobre todo, otros dominios incluidos como SAN en el mismo certificado. Cuando un operador mete varios dominios de campaña en un único certificado, te está entregando el mapa de su infraestructura.

¿Cómo pivotas desde la dirección IP?

Con la resolución actual y, mejor aún, con el histórico de resoluciones (DNS pasivo), puedes agrupar campañas por infraestructura compartida.

# Resolución actual y registros asociados
dig +short ejemplo-malicioso.test A
dig +short ejemplo-malicioso.test MX
dig +short ejemplo-malicioso.test TXT

# DNS inverso sobre la IP obtenida
dig +short -x 203.0.113.10

# Registro TXT de SPF: revela a veces proveedores de correo del actor
dig +short ejemplo-malicioso.test TXT | grep -i spf

El siguiente salto es preguntarse qué más vive en esa IP. Aquí hay un matiz que separa a quien sabe de quien no: si la IP pertenece a un alojamiento compartido o está detrás de un CDN, los «vecinos» son miles de sitios legítimos y la correlación no vale nada. Comprueba siempre el ASN y el tipo de alojamiento antes de concluir que dos dominios están relacionados por compartir IP.

¿Cómo identificas el mismo kit de phishing en otros servidores?

Los kits de phishing se distribuyen como paquetes y se despliegan tal cual, lo que deja huellas idénticas en todos los despliegues. La más útil es el hash del favicon: Shodan y Censys lo indexan, así que si obtienes el hash del favicon de la campaña puedes buscar todas las demás máquinas de Internet que sirven exactamente ese icono.

# Hash del favicon en el formato que indexa Shodan (MurmurHash3 sobre el
# contenido codificado en base64). Requiere: pip install mmh3 requests
import base64
import mmh3
import requests

resp = requests.get("https://urlscan.io/liveshot/?url=...", timeout=20)
favicon_b64 = base64.encodebytes(resp.content)
print(mmh3.hash(favicon_b64))

# El valor resultante se busca en Shodan como:  http.favicon.hash:<valor>

Otras huellas que funcionan igual de bien: el título exacto de la página, rutas concretas del kit, cadenas del JavaScript de exfiltración, o la combinación de cabeceras HTTP del servidor. Cualquier constante del kit sirve de pivote.

Para el otro lado del problema —qué dominios parecidos al tuyo se han registrado— la herramienta es dnstwist, que genera permutaciones tipográficas de un dominio legítimo y comprueba cuáles están registradas:

# Solo los dominios efectivamente registrados, con su resolución
dnstwist --registered tu-marca.com

¿Cómo se documenta todo esto para que sirva de algo?

Una investigación sin informe es tiempo perdido. Y un informe sin niveles de confianza es peor que nada, porque induce a decisiones equivocadas. Separa siempre lo observado de lo inferido:

La tabla de indicadores final debe ir siempre desactivada y con su fuente, para que quien la reciba pueda reproducir tu trabajo:

Indicador                          Tipo      Confianza  Fuente
ejemplo-malicioso[.]test           dominio   Alta       RDAP + CT
admin.ejemplo-malicioso[.]test     subdom.   Alta       crt.sh
203.0.113[.]10                     IPv4      Alta       dig A
-1234567890                        favicon   Media      Shodan
otra-campana[.]test                dominio   Media      SAN compartido

Los límites que no conviene cruzar

• No introduzcas credenciales falsas en el formulario. Es tentador para ver qué hace el kit, pero es interacción activa y contamina los datos del atacante con basura que después alguien tendrá que interpretar.
• No escanees puertos ni fuerces directorios sin autorización explícita. En muchas jurisdicciones el acceso no autorizado a un sistema es delito, y que el sistema sea de un delincuente no te ampara.
• No descargues el kit desde una supuesta copia de seguridad expuesta salvo que tengas encargo formal para hacerlo.
• No hagas públicos tus escaneos en urlscan y similares mientras la investigación siga abierta.
• No confundas correlación con atribución. Compartir proveedor de alojamiento no convierte a dos campañas en el mismo actor.

El salto de aquí en adelante es pasar de investigar un dominio suelto a seguir campañas completas en el tiempo, correlacionando infraestructura y cabeceras de correo. Ese recorrido, con laboratorios sobre casos reales, es la ruta de Phishing con OSINT; si quieres empezar por lo fundamental, el punto de entrada es el curso de nivel principiante.