Phishing Kits: Análisis de Infraestructura, Evasión y Phishing-as-a-Service
Análisis de phishing kits modernos: estructura de archivos, técnicas anti-bot, bypass de MFA con reverse proxy, Phishing-as-a-Service (PhaaS), y kits documentados como EvilProxy, Caffeine, NakedPages y Greatness.
El negocio detrás del phishing industrializado
Un analista SOC investiga una campaña de phishing dirigida contra empleados de un banco europeo. La landing page replica con precisión milimétrica el portal corporativo de Microsoft 365, incluye un certificado TLS válido, detecta crawlers de seguridad y los redirige a Google, y captura tokens MFA en tiempo real. El atacante no escribió una sola línea de código. Pagó 250 USD mensuales por un servicio de suscripción.
Los phishing kits han evolucionado desde simples colecciones de archivos HTML hasta plataformas completas con paneles de administración, soporte técnico y actualizaciones regulares. Entender su anatomía, sus mecanismos de evasión y su modelo de negocio es fundamental para detectarlos y neutralizarlos.
Qué es un phishing kit
Un phishing kit es un paquete comprimido (normalmente ZIP o TAR.GZ) que contiene todos los componentes necesarios para desplegar una campaña de phishing funcional sin conocimientos técnicos avanzados. El operador solo necesita un servidor web (a menudo comprometido), un dominio y acceso al kit.
Archivos típicos de un kit básico
Un kit descomprimido contiene una estructura predecible:
| Archivo/Directorio | Función |
|---|---|
index.php / index.html | Página de login clonada (Microsoft, Google, banco, etc.) |
login.php / post.php | Script PHP que recibe credenciales del formulario |
css/ / js/ / images/ | Assets visuales copiados del sitio legítimo |
config.php / settings.ini | Configuración: email del atacante, Telegram bot token, opciones anti-bot |
.htaccess | Reglas de reescritura y bloqueo de IPs/user-agents |
blocker.php / antibot.php | Módulo anti-detección (filtra bots, crawlers, sandboxes) |
result.txt / log.txt | Archivo local donde se almacenan credenciales capturadas |
telegram.php | Exfiltración en tiempo real vía Telegram Bot API |
El flujo es directo: la víctima accede a index.php, introduce sus credenciales, post.php las captura y las envía al atacante (por email, Telegram o panel web), y la víctima es redirigida al sitio legítimo para no levantar sospechas.
Evolución de los phishing kits
Los phishing kits han pasado por cuatro generaciones claramente diferenciadas:
| Generación | Periodo | Características | Ejemplo |
|---|---|---|---|
| Gen 1: Estáticos | 2004-2012 | HTML estático copiado, envío por email SMTP, sin evasión | Kits de Rock Phish gang |
| Gen 2: Dinámicos | 2012-2018 | PHP con backends, múltiples marcas, .htaccess anti-bot, exfil por email | Kit "16Shop", kits de PayPal/Apple |
| Gen 3: Anti-detección | 2018-2023 | Cloaking avanzado, geofencing, CAPTCHA, Cloudflare Turnstile, exfil Telegram | Kr3pto, Ex-Robotos, LogoKit |
| Gen 4: PhaaS + MFA bypass | 2023-presente | Reverse proxy, captura de session cookies, suscripción SaaS, panel completo | EvilProxy, Caffeine, Greatness, Tycoon 2FA |
Cada generación incorporó las capacidades de la anterior. Los kits Gen 4 combinan la sofisticación anti-detección de Gen 3 con la capacidad de interceptar autenticación multifactor en tiempo real.
Anatomía de un kit moderno
Un phishing kit de última generación (Gen 3-4) tiene una estructura considerablemente más compleja que los kits básicos.
Estructura de directorios típica
phishing-kit-v3/
├── config/
│ ├── settings.json # Marca objetivo, idioma, redirect URL
│ ├── telegram.json # Bot token + chat ID para exfil
│ └── antibot.json # Reglas de filtrado (IPs, ASNs, user-agents)
├── pages/
│ ├── microsoft/ # Login Microsoft 365
│ ├── google/ # Login Google Workspace
│ ├── outlook/ # Login Outlook
│ └── custom/ # Template editable
├── modules/
│ ├── antibot.php # Motor anti-detección
│ ├── geofence.php # Filtrado por geolocalización
│ ├── fingerprint.js # Canvas/WebGL fingerprinting del navegador
│ ├── exfil.php # Módulo de exfiltración multi-canal
│ └── mfa_intercept.php # Captura de tokens MFA (Gen 4)
├── panel/
│ ├── dashboard.php # Panel de control del operador
│ ├── victims.php # Lista de víctimas con credenciales
│ ├── stats.php # Estadísticas de campaña
│ └── auth.php # Login del panel (protegido)
├── assets/ # CSS, JS, imágenes, fuentes
├── .htaccess # Reglas Apache
└── index.php # Router principal
Configuración multi-marca
Los kits modernos soportan múltiples marcas desde un solo despliegue. El archivo settings.json determina qué página de login mostrar:
{
"brand": "microsoft",
"language": "es",
"redirect_after": "https://login.microsoftonline.com",
"capture_fields": ["email", "password", "mfa_token"],
"exfil_method": "telegram",
"telegram_bot": "REDACTED",
"telegram_chat": "REDACTED",
"antibot_enabled": true,
"geofence_countries": ["ES", "FR", "DE", "IT"],
"block_vpn": true,
"block_datacenter": true
}
Exfiltración de credenciales
Los canales de exfiltración han evolucionado significativamente:
| Canal | Ventaja | Desventaja |
|---|---|---|
| Email SMTP | Simple, tradicional | Fácil de rastrear, puede ser bloqueado |
| Telegram Bot API | Tiempo real, cifrado, difícil de bloquear | Token puede ser revocado por Telegram |
| Discord Webhooks | Fácil de configurar, logs estructurados | Discord elimina webhooks de phishing |
| Panel web propio | Control total, histórico | Requiere mantener infraestructura |
| Google Forms | Pasa filtros de reputación | Limitado en campos |
| Pastebin/Ghostbin | Anonimato | Puede ser eliminado |
La tendencia dominante en 2025-2026 es Telegram. Más del 60% de los kits analizados por investigadores de seguridad usan Telegram como canal primario de exfiltración, con email como fallback.
Técnicas anti-detección
La supervivencia de una campaña de phishing depende de cuánto tiempo pasa sin ser detectada. Los kits modernos implementan múltiples capas de evasión.
Cloaking (encubrimiento)
El cloaking muestra contenido diferente a visitantes legítimos y a sistemas de detección. El kit inspecciona cada request y decide qué servir:
Para crawlers de seguridad (PhishTank, Google Safe Browsing, VirusTotal): redirige a Google, muestra una página 404, o sirve contenido benigno (blog de cocina, landing corporativa genérica).
Para la víctima real: muestra la página de phishing completa.
La decisión se basa en múltiples señales evaluadas simultáneamente:
User-Agent filtering
El kit mantiene una base de datos de user-agents asociados a crawlers y herramientas de seguridad. Si el user-agent contiene cadenas como bot, crawler, spider, curl, wget, python-requests, headless, PhantomJS, o pertenece a empresas de seguridad (Barracuda, Proofpoint, Microsoft Defender), la request se bloquea o redirige.
Geofencing
Solo muestra la página de phishing a visitantes de países específicos. Si la IP es de un país fuera del target (por ejemplo, la campaña apunta a España pero la IP es de Estados Unidos), el visitante recibe un 404 o una redirección. Los kits avanzados usan bases de datos MaxMind y resuelven ASN para detectar rangos de IPs de proveedores de hosting, VPNs comerciales y redes Tor.
Fingerprinting del navegador
JavaScript ejecutado en el cliente recopila información sobre el entorno:
- Canvas fingerprint y WebGL renderer para detectar VMs y headless browsers
- Lista de plugins instalados (los sandboxes tienen perfiles genéricos)
- Resolución de pantalla y profundidad de color
- Timezone y diferencia con la hora del servidor
- Presencia de herramientas de desarrollo abiertas
- Ratios de movimiento de ratón (bots no mueven el cursor naturalmente)
Si el fingerprint coincide con patrones de sandbox o herramienta automatizada, la página no se muestra.
CAPTCHAs y Cloudflare Turnstile
Kits como Tycoon 2FA y Dadsec/Phoenix colocan un CAPTCHA o un challenge Cloudflare Turnstile antes de la página de phishing. Esto tiene un doble efecto: los crawlers automatizados no pueden pasar el challenge, y los analistas que investigan la URL desde herramientas automatizadas ven solo el CAPTCHA, no la página maliciosa.
Bloqueo por header HTTP
Análisis de headers adicionales: X-Forwarded-For (indica proxying), Via (proxies corporativos), ausencia de Referer (acceso directo, típico de escáneres), y headers propietarios de soluciones de seguridad.
Phishing-as-a-Service: el modelo de negocio
Phishing-as-a-Service (PhaaS) aplica el modelo SaaS al phishing. El operador del kit construye y mantiene la plataforma, el cliente paga una suscripción y lanza campañas sin necesidad de conocimientos técnicos.
Estructura del negocio
El modelo PhaaS tiene tres capas:
Desarrollador/Operador: construye el kit, mantiene las páginas actualizadas (cuando Microsoft cambia su login, el operador actualiza el template), gestiona la infraestructura anti-detección y ofrece soporte técnico. Opera desde foros underground o canales de Telegram.
Reseller (opcional): compra licencias al por mayor y las revende con margen. Algunos ofrecen "paquetes" con dominios y hosting incluido.
Cliente final: paga la suscripción, configura la campaña (marca objetivo, lista de emails, método de envío) y recibe las credenciales capturadas en su panel o Telegram.
Pricing del mercado PhaaS
| Plataforma | Precio mensual | Incluye | MFA bypass |
|---|---|---|---|
| EvilProxy | 150-600 USD | Panel, dominios rotativos, anti-bot, templates multi-marca | Si (reverse proxy) |
| Caffeine | 250 USD/mes (plan básico) | Panel web, soporte Microsoft/Google, anti-bot | Si (AitM) |
| Greatness | 120 USD/mes + 50 USD setup | Microsoft 365 especializado, MFA, panel Telegram | Si |
| NakedPages | 50-100 USD/mes | Templates multi-marca, hosting propio requerido | Parcial |
| Robin Banks | 50 USD/campaña (básico), 200 USD/mes (pro) | Multi-marca, Cloudflare proxy, anti-bot | Si (desde v2) |
| Tycoon 2FA | 120-350 USD/mes | Microsoft 365 y Google, Cloudflare Turnstile, AitM | Si |
| W3LL Panel | 500 USD/3 meses | Microsoft 365 Business, BEC optimizado, seller network | Si (AitM) |
Los precios pueden parecer bajos, pero el ROI es enorme. Una sola campaña exitosa contra un ejecutivo puede generar acceso a cuentas corporativas con valor de miles de dólares en el mercado de acceso inicial.
Plataformas PhaaS documentadas
EvilProxy: la plataforma PhaaS más documentada por investigadores de Proofpoint, Resecurity y Microsoft. Opera como reverse proxy entre la víctima y el proveedor de identidad real (Microsoft Entra ID, Google Workspace, Apple iCloud). Captura session cookies post-MFA. Interfaz web con estadísticas de campaña, filtrado geográfico, y rotación automática de dominios. Observada activamente atacando ejecutivos C-level.
Caffeine: documentada por Mandiant en octubre 2022. Destacable porque permitía registro abierto (cualquiera podía crear una cuenta sin voucher ni vetting previo), aunque esto cambió tras la exposición pública. Panel web con herramientas de generación de emails, templates, y backend de captura. Soporte para Adversary-in-the-Middle (AitM).
Greatness: analizada por Cisco Talos en mayo 2023. Especializada exclusivamente en Microsoft 365. Incluye un flujo completo de bypass MFA donde el operador ve en tiempo real cuándo la víctima introduce su contraseña y cuándo proporciona el segundo factor. Las credenciales y session cookies se envían vía Telegram con un formato estructurado que incluye IP, user-agent, país y organización de la víctima.
NakedPages: orientada a operadores con algo más de conocimiento técnico. Proporciona los templates y el backend, pero el cliente debe configurar su propia infraestructura de hosting. Precio más bajo, pero requiere más trabajo manual.
Robin Banks: documentada por IronNet en julio 2022. Inicialmente usaba Cloudflare como proxy de infraestructura, lo que le proporcionaba certificados TLS gratuitos y ocultaba la IP real del servidor. Tras la exposición pública, Cloudflare terminó sus servicios y Robin Banks migró a un proveedor ruso (DDoS-Guard).
Reverse proxy y MFA bypass
La capacidad más significativa de los kits Gen 4 es el bypass de MFA mediante reverse proxy (Adversary-in-the-Middle o AitM). Esta técnica hace ineficaz la autenticación de dos factores basada en OTP, push notifications o SMS.
Cómo funciona el ataque
El flujo del ataque AitM sigue esta secuencia:
Víctima Proxy del atacante Sitio legítimo
│ │ │
│── 1. Accede a URL ──────────→│ │
│ │── 2. Retransmite request ───→│
│ │←── 3. Login page real ───────│
│←── 4. Login page (proxy) ────│ │
│ │ │
│── 5. Email + password ──────→│ │
│ │── 6. Retransmite creds ─────→│
│ │←── 7. Pide MFA ─────────────│
│←── 8. Pide MFA (proxy) ─────│ │
│ │ │
│── 9. Token MFA ────────────→│ │
│ │── 10. Retransmite MFA ──────→│
│ │←── 11. Session cookie ───────│
│ │ │
│ │── CAPTURA session cookie ────│
│←── 12. Redirect a sitio ────│ │
│ legítimo │ │
El punto clave es el paso 11: el sitio legítimo emite una session cookie de autenticación válida, y el proxy la intercepta antes de entregarla a la víctima. Con esa cookie, el atacante puede acceder a la cuenta sin necesidad de repetir el proceso de autenticación.
Herramientas de reverse proxy phishing
| Herramienta | Tipo | Lenguaje | Capacidades |
|---|---|---|---|
| Evilginx2 | Framework open source | Go | Phishlets configurables por servicio, captura de session cookies, API |
| Modlishka | Reverse proxy | Go | Proxy transparente, modifica respuestas al vuelo, plugin de credenciales |
| Muraena | Reverse proxy | Go | Crawler automático de sitios, reescritura de contenido, captura de sesiones |
| EvilProxy | PhaaS comercial | Propietario | Basado en principios similares a Evilginx2, pero gestionado como servicio |
Qué MFA resiste y qué no
| Método MFA | Vulnerable a AitM | Explicación |
|---|---|---|
| SMS OTP | Si | El token se retransmite en tiempo real |
| App authenticator (TOTP) | Si | El token se retransmite en tiempo real |
| Push notification | Si | La víctima aprueba el push legítimo generado por el proxy |
| Email OTP | Si | Mismo principio que SMS |
| FIDO2/WebAuthn | No | Vinculado criptográficamente al dominio. El proxy tiene un dominio diferente, por lo que la clave no responde |
| Passkeys | No | Basado en FIDO2, mismo principio de vinculación a dominio |
La conclusión técnica es clara: solo la autenticación vinculada criptográficamente al dominio (FIDO2, passkeys) resiste ataques AitM. Todos los métodos basados en tokens transferibles son vulnerables.
Análisis seguro de un phishing kit
Cuando un equipo de seguridad obtiene un phishing kit (interceptado en un servidor comprometido, compartido por un investigador, o recuperado de un repositorio de threat intel), el análisis debe seguir un protocolo seguro.
Entorno de análisis
VM aislada: analizar el kit en una máquina virtual sin acceso a red. Muchos kits incluyen backdoors que envían las credenciales a un segundo destinatario (el desarrollador del kit "roba" a sus propios clientes).
Archivos PHP: revisar todo el código PHP buscando funciones peligrosas: eval(), base64_decode(), gzinflate(), str_rot13(). Los backdoors se ocultan frecuentemente con múltiples capas de ofuscación.
Conexiones ocultas: buscar URLs, IPs, tokens de Telegram, webhooks de Discord, y direcciones de email hardcodeadas en el código. Estos son los canales de exfiltración.
Herramientas de análisis
| Herramienta | Uso |
|---|---|
grep -r "base64_decode|eval|gzinflate" | Detectar ofuscación y backdoors en código PHP |
strings + file | Identificar tipos de archivo y cadenas embebidas |
| URLScan.io | Analizar URLs sospechosas en sandbox |
| PhishTank | Verificar si la URL ya está reportada |
| VirusTotal | Escanear archivos del kit |
diff contra el sitio legítimo | Identificar modificaciones maliciosas en HTML/JS |
| Burp Suite | Interceptar tráfico del kit en ejecución controlada |
Backdoors del desarrollador
Un fenómeno bien documentado: los desarrolladores de phishing kits incluyen backdoors en sus propios kits. Mientras el operador recibe las credenciales en su Telegram, una copia silenciosa se envía al desarrollador.
Investigadores de Akamai y WMC Global han documentado que entre el 25% y el 40% de los kits analizados contienen alguna forma de exfiltración oculta hacia el desarrollador. Esto incluye:
- Un segundo token de Telegram hardcodeado en código ofuscado con
base64_decode() - Un webhook de Discord embebido en una imagen aparentemente inofensiva
- Un
file_get_contents()a una URL del desarrollador con las credenciales en parámetros GET - Código PHP cifrado con IonCube o similar que se ejecuta junto al kit
Indicadores de phishing kits
Los phishing kits dejan huellas reconocibles que facilitan su detección y clasificación.
Patrones en archivos
| Indicador | Detalle |
|---|---|
| Archivos con nombres genéricos | login.php, post.php, next.php, verify.php en el root |
.htaccess con reglas anti-bot | Bloqueo de user-agents de crawlers específicos |
Archivos result.txt o log.txt expuestos | Credenciales en texto plano accesibles por directory listing |
Panel en /admin/, /panel/, /cp/ | Interfaz de administración del kit |
| Tokens de Telegram en código fuente | bot[0-9]+:AA[A-Za-z0-9_-]{33} |
robots.txt agresivo | Disallow: / para evitar indexación |
Patrones en URLs y HTTP
| Indicador | Detalle |
|---|---|
| Certificados Let's Encrypt recién emitidos | Dominio registrado horas antes de la campaña |
| Dominios con typosquatting | micr0soft-login.com, google-verify.net |
| Subdominios largos y descriptivos | login.office365.update-security.verify-account.dominio.com |
| Redirect chains con múltiples dominios | 3 o más redirects antes de llegar a la página de phishing |
| Headers de servidor inconsistentes | Página de "Microsoft" servida por Apache con PHP en un VPS de Hostinger |
| Parámetros en URL con email codificado | ?id=base64(email) para personalizar la página |
Hunting de phishing kits
La búsqueda proactiva de phishing kits requiere combinar múltiples fuentes de datos.
URLScan.io
URLScan.io permite buscar páginas web escaneadas por contenido, estructura y comportamiento. Queries útiles para hunting de phishing kits:
page.title:"Sign in to your account" AND NOT domain:microsoft.com(clonas de Microsoft)filename:antibot.php(kits con módulo anti-bot)filename:telegram.php(exfiltración vía Telegram)page.server:Apache AND page.title:"Google" AND NOT domain:google.com(clonas de Google en Apache)
PhishTank y OpenPhish
Repositorios colaborativos de URLs de phishing verificadas. PhishTank permite descargar datasets completos en formato XML/CSV para análisis masivo. Útil para identificar patrones de infraestructura compartida entre campañas: mismo registrar, mismo hosting, mismos nameservers.
Certificate Transparency logs
Los atacantes necesitan certificados TLS para sus dominios de phishing. Los Certificate Transparency (CT) logs registran todos los certificados emitidos públicamente. Herramientas como crt.sh y Certstream permiten monitorizar en tiempo real la emisión de certificados para dominios sospechosos:
- Dominios con marcas conocidas:
*microsoft*,*office365*,*google*,*outlook* - Certificados wildcard para dominios recién registrados
- Emisión masiva de certificados Let's Encrypt para múltiples subdominios en minutos
Passive DNS y WHOIS
Los dominios de phishing comparten características en su registro:
- Registrados en los mismos registradores (Namecheap, Porkbun, Tucows son frecuentes)
- Registrados horas antes de la campaña
- WHOIS con protección de privacidad activada
- Nameservers apuntando a Cloudflare o servicios de DNS gratuitos
- Resolución DNS hacia rangos de IPs de proveedores de hosting económicos o bulletproof
La correlación de estos datos permite pivotar desde un dominio de phishing conocido hacia toda la infraestructura del operador.
Defensas efectivas contra phishing kits
No existe una defensa única contra los phishing kits modernos. La protección efectiva combina controles técnicos, humanos y organizacionales:
Autenticación resistente a AitM: migrar a FIDO2/passkeys elimina el vector de MFA bypass por reverse proxy. Es la medida técnica más efectiva contra kits Gen 4.
Conditional Access Policies: restringir el acceso por dispositivo gestionado, ubicación, y nivel de riesgo de la sesión. Si un atacante obtiene una session cookie, no podrá usarla desde un dispositivo o IP no autorizada.
Monitorización de CT logs: alertas automáticas cuando se emiten certificados para dominios similares a los de la organización.
Análisis de URLs en tiempo real: soluciones que detonan URLs en sandbox antes de entregar el email al usuario, no solo comprueban reputación estática.
Concienciación focalizada: entrenar a los usuarios para verificar el dominio en la barra de direcciones, no el contenido visual de la página. Los kits replican la apariencia con precisión, pero no pueden replicar el dominio legítimo.
Recursos y referencias
Investigaciones clave
- Proofpoint: "EvilProxy Phishing-as-a-Service" (septiembre 2023). Análisis detallado de la plataforma y sus campañas contra ejecutivos C-level
- Cisco Talos: "Greatness Phishing Kit" (mayo 2023). Desglose del kit con flujo MFA y exfiltración Telegram
- Mandiant: "Caffeine PhaaS Platform" (octubre 2022). Primera documentación del modelo de registro abierto
- IronNet: "Robin Banks PhaaS" (julio 2022). Análisis de infraestructura y uso de Cloudflare
- Microsoft Threat Intelligence: "Adversary-in-the-Middle phishing" (2023-2024). Documentación de campañas AitM a escala
- Sekoia: "Tycoon 2FA PhaaS" (febrero 2024). Kit con Cloudflare Turnstile y AitM
- Resecurity: "W3LL Panel and W3LL Store" (septiembre 2023). Ecosistema completo BEC con más de 500 compradores
Herramientas de detección y hunting
- URLScan.io para análisis y búsqueda de páginas sospechosas
- PhishTank para verificación y reporte de URLs de phishing
- crt.sh para monitorización de Certificate Transparency logs
- Certstream para alertas en tiempo real de nuevos certificados
- OpenPhish para feeds de URLs de phishing verificadas
- CheckPhish para análisis automatizado de URLs con IA
Frameworks y estándares
- MITRE ATT&CK: T1566 (Phishing), T1557 (Adversary-in-the-Middle), T1539 (Steal Web Session Cookie)
- MITRE D3FEND: D3-UA (User Account Authentication), D3-MFA (Multi-Factor Authentication)
- NIST SP 800-63B: directrices de autenticación digital, incluyendo resistencia a phishing
Preguntas frecuentes
Artículos relacionados
Credential Harvesting: Evilginx, Modlishka y Bypass de MFA en Tiempo Real
Anatomía de un Email de Phishing: Headers, SPF, DKIM, DMARC y Red Flags
Detección de Phishing: Reglas Sigma, YARA y Análisis Automatizado de URLs
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.