Docs
Referencia educativa abierta y guía de integración para phishunt: cómo funcionan los kits de phishing, qué señales rastrean los defensores y cómo enchufar los datos a tu tooling.
Qué es el phishing
Definición
El phishing es un ataque de ingeniería social donde el adversario suplanta una marca, servicio o individuo de confianza para engañar al objetivo y conseguir credenciales, desplegar malware o transferir fondos.
MITRE ATT&CK lo clasifica como técnica T1566 con varias sub-técnicas.
Sub-técnicas
- T1566.001 Spearphishing Attachment - fichero armado
- T1566.002 Spearphishing Link - URL a login falso
- T1566.003 Spearphishing via Service - DM / SaaS
- T1566.004 Spearphishing Voice - vishing
Qué NO es phishing
El phishing se distingue del despliegue de malware (el kit puede dejar caer malware, pero la técnica está orientada a la identidad), del spam genérico (sin paso de suplantación de identidad) y del Business Email Compromise (BEC), que manipula el buzón real de una persona sin la página de login con dominio falsificado que define al phishing.
Cómo funcionan los kits
Los kits modernos encadenan cuatro etapas. Detectar en cada una alimenta señales distintas al pipeline que mantiene el feed activo de phishunt.
1. Cebo
Email, SMS (smishing), mensajería instantánea o código QR (quishing) con un gancho contextual: aviso de envío, nómina, reset de MFA, factura falsa.
Señal para el defensor: alineación SPF / DKIM / DMARC, reputación del remitente, dominio typosquat en el enlace.
2. Landing page
La página de login falsa hospedada. Los kits actuales son bundles HTML / JS desplegados en hostings compartidos baratos, con exfil por bot de Telegram incluida por defecto.
Señal para el defensor: keyword de marca en el dominio, certificado TLS recién emitido en logs CT, colisión de hash de assets con un kit conocido, patrones de ofuscación JavaScript.
3. Captura de credenciales
El formulario envía usuario + contraseña (y cualquier campo de segundo factor) a un endpoint del operador. Los kits adversary-in-the-middle reenvían en vivo al servicio real para capturar la cookie de sesión post-MFA.
Señal para el defensor: atributo action= apuntando fuera del dominio, cifrado del formulario incoherente, ausencia de token CSRF.
4. Exfiltración
Bot de Telegram, email simple a un buzón Gmail dropbox o POST HTTP a un servidor de staging. La cookie de sesión o el par de credenciales se vende o se reproduce contra el SSO empresarial de la víctima.
Señal para el defensor: tráfico saliente desde endpoints comprometidos hacia hosts de staging conocidos del operador; phishunt incluye en la blocklist los hosts de staging cuando el operador pivota a través de certs visibles en CT.
Señales de detección
Los defensores combinan tres capas de señales. Ninguna por sí sola es suficiente; los kits actuales suelen sortear cualquiera de ellas si se usa en aislamiento.
| Capa | Qué observa | Señales típicas |
|---|---|---|
| Red | Todo lo visible antes de que la página renderice. | Streams de logs Certificate Transparency, reputación DNS, scoring léxico de keywords de marca en dominios recién registrados, fingerprints TLS JA3 / JA4, MX/SPF del dominio del cebo. |
| Contenido | La página renderizada en sí. | Colisión de image-hash de assets de marca, action= del formulario fuera del dominio, BIMI ausente en el remitente del cebo, patrones de HTML smuggling, match de hash perceptual del DOM contra un kit conocido. |
| Comportamiento | Cómo reacciona la página ante visitantes. | Filtrado Geo / IP (solo el país de la víctima ve la página real), gate CAPTCHA / Turnstile antes de revelar el kit, evidencia OAST de canary-callback (p. ej. interactsh) al sondear SSRF. |
Frameworks de la industria
OWASP Top 10
El phishing mapea principalmente a A07:2021 Identification and Authentication Failures, ya que el objetivo del kit es derrotar la autenticación. Los controles anti-phishing también tocan A05:2021 Security Misconfiguration cuando el sitio suplantado falla en aplicar HSTS, cookies seguras o CSP estricto.
NIST SP 800-53 / 800-46
Las familias de control relevantes son AC-2 account management, IA-2 identification and authentication of organizational users, AT-2 security awareness training y SI-3 malicious code protection. NIST SP 800-46 (Telework) menciona explícitamente la MFA resistente al phishing.
Árbol de técnicas MITRE ATT&CK
T1566 (Phishing) está dentro de la táctica Initial Access (TA0001). Una vez robada la credencial, los TTPs siguientes suelen encadenar a través de TA0006 Credential Access (T1078 Valid Accounts) y TA0008 Lateral Movement. El mapeo del defensor debería incluir controles detectivos en cada transición de táctica, no solo en T1566.
MFA resistente al phishing
Los kits AitM modernos reenvían credenciales y cookies de sesión post-MFA en vivo al servicio real. SMS-OTP, OTP basado en tiempo y notificaciones push caen ante AitM. Solo MFA atado al origen lo derrota.
| Factor | ¿Resiste phishing? | Por qué / por qué no |
|---|---|---|
| SMS OTP | No | El código es transferible; el kit AitM lo reenvía al instante. También vulnerable a SIM-swap. |
| TOTP (Google Authenticator, Authy) | No | La ventana de 30 segundos sobra para que un AitM lo reenvíe. |
| Push approval (Duo, Microsoft Authenticator) | Parcial | El number-matching ayuda; los prompts simples "aprobar / denegar" caen a fatiga y AitM. |
| FIDO2 / WebAuthn passkey | Sí | Reto criptográfico ligado al origen (RP ID). El dominio falso del atacante tiene un RP ID distinto, así que el autenticador se niega a firmar. |
| Smartcard / PIV | Sí | Misma propiedad de binding al origen que WebAuthn. |
Técnicas de evasión comunes
Adversary-in-the-Middle (AitM)
Kits como Evilginx, Tycoon-2FA o Modlishka hacen reverse-proxy del sitio de login real y capturan la cookie de sesión post-MFA. Derrotan SMS / TOTP / push-approval.
Puertas CAPTCHA / Turnstile
Los kits ponen la página maliciosa detrás de un Cloudflare Turnstile o Google reCAPTCHA. Crawlers automatizados (y muchos sandboxes) fallan el reto y nunca ven el kit; la víctima sí.
Filtrado Geo / IP
Filtros server-side devuelven una página benigna a cualquier IP fuera del país, ASN o rango específico de la víctima. Detectarlo requiere fetchear desde el mismo egress que la audiencia objetivo.
HTML smuggling
El email / página del cebo contiene un blob JavaScript que Blob-reconstruye el payload malicioso en cliente, esquivando los gateways de email que inspeccionan adjuntos en reposo.
Glosario
- ACME
- Automatic Certificate Management Environment - el protocolo que Let's Encrypt y Google Trust Services usan para emisión TLS gratis / automatizada.
- AitM
- Adversary-in-the-Middle - patrón de kit que hace reverse-proxy del sitio real para cosechar la cookie de sesión post-MFA.
- BIMI
- Brand Indicators for Message Identification - señal de logo verificado en el sobre del email; un BIMI ausente en un remitente que dice ser una marca es un indicio de phishing.
- CT log
- Certificate Transparency log - log público append-only al que toda CA pública debe enviar certificados. Los defensores monitorizan los CT logs buscando dominios con keyword de marca como señal temprana.
- DV / OV / EV
- Niveles de validación de certificado: Domain Validated (prueba de control del dominio), Organization Validated, Extended Validation. DV es el más común y el más barato de abusar.
- HSTS
- HTTP Strict Transport Security - fuerza a los navegadores a usar solo HTTPS. HSTS preload (la lista compilada en el navegador) es casi irreversible y no debería activarse a la ligera.
- JA3 / JA4
- Fingerprints del handshake TLS. Los kits de phishing reutilizan a menudo el mismo stack TLS en miles de dominios staged, produciendo fingerprints reconocibles.
- MTA-STS
- SMTP MTA Strict Transport Security - análogo de HSTS para servidores de correo. Reduce la capacidad del atacante de degradar SMTP a texto plano para MITM.
- OAST
- Out-of-band Application Security Testing - URLs canary (p. ej. interactsh, Burp Collaborator) que registran peticiones DNS / HTTP / SMTP, usadas para confirmar vulnerabilidades ciegas.
- RP ID
- Relying Party ID en WebAuthn - el origen al que el autenticador liga la credencial. La propiedad central de la MFA resistente al phishing.
FAQ
¿Los datos de phishunt están bajo CC0?
Sí. Los datos publicados a través de los feeds TXT, JSON, CSV y la API REST pública se distribuyen bajo Creative Commons CC0 1.0. El código de la web, el branding y las marcas no están cubiertos por CC0.
¿Con qué frecuencia se actualizan los datos?
El pipeline de detección corre cada hora y los sitios activos se rechequean cada seis horas. Los dominios permanecen en el feed activo solo mientras siguen devolviendo una página de phishing; los que caen o se limpian salen del feed.
¿Cómo se compara phishunt con PhishTank u OpenPhish?
Los tres publican IOCs de phishing pero con modos de ingesta distintos: PhishTank es curado por la comunidad, OpenPhish es un feed comercial de pago, y phishunt se basa en detección automática a partir de logs de CT y dominios recién registrados. Los tres feeds se complementan en vez de reemplazarse.
¿Cómo reporto un falso positivo?
Escribe a [email protected] con la URL y una breve justificación. Se revisa y elimina en 24 horas en días laborables.
phishunt no acepta actualmente envíos de nuevos sitios de phishing por email; el feed se alimenta del pipeline de detección automatizado. Es posible que se añada un flujo de envío para usuarios más adelante.
¿Puedo integrar phishunt en mi tooling SOC?
Sí. La página de /api/ documenta los endpoints REST (gratis, sin auth, datos CC0). Para flujos agentic / LLM, el servidor MCP en mcp.phishunt.io expone los mismos datos como herramientas JSON-RPC (ver /agents/ para snippets de configuración).
¿Por qué "sospechoso" y no "malicioso confirmado"?
phishunt prioriza recall sobre precisión. Los sitios que pasan el umbral de suplantación de marca van al feed activo sin confirmación de terceros. Combina con Google Safe Browsing, urlscan o VirusTotal cuando necesites verdicts confirmados.
Referencia educativa abierta. Última actualización 2026-05-04. Sugerencias y correcciones por [email protected].