Cómo las plataformas de nube legítimas ayudan a los phishers a eludir la autenticación multifactor

Los atacantes recurren cada vez más a servicios legítimos para eludir la detección y simplificar la creación de infraestructura fraudulenta. Entre estos servicios, las plataformas de nube y las redes descentralizadas ocupan un lugar destacado, ya que en ellas se alojan páginas y sitios de phishing. Entre 2025 y 2026 se observa una migración sostenida de los phishers a plataformas como Cloudflare Workers, Vercel, Netlify, GitHub Pages e IPFS. En este artículo no solo analizamos la mecánica de un ataque AiTM (Adversary-in-the-Middle) real en infraestructura en la nube, sino que también aportamos estadísticas detalladas sobre qué plataformas y dominios eligen los atacantes con mayor frecuencia para alojar phishing.

La nube como refugio para los phishers

Los motivos por los que los atacantes eligen PaaS (plataforma como servicio) y otros servicios en la nube (o distribuidos) para alojar sitios de phishing son, en gran medida, los mismos que guían a los desarrolladores legítimos:

• Confianza y reputación: las páginas de phishing publicadas en plataformas legítimas transmiten más confianza y despiertan menos sospechas entre las víctimas potenciales.
• Disponibilidad: la mayoría de las plataformas ofrece planes gratuitos con límites generosos para desarrolladores, y el registro toma minutos y suele prescindir del proceso KYC (“Know Your Customer”, es decir, “conozca a su cliente”, el proceso de verificación de identidad del usuario), lo que permite que un solo atacante cree cientos de cuentas.
• Protección y anonimato: los atacantes aprovechan los mecanismos de protección integrados y ocultan la IP real del servidor detrás de una CDN, lo que dificulta su detección por parte de los proveedores de soluciones de seguridad.

Cabe destacar que estas plataformas asignan subdominios propios a sus usuarios, en los que coexisten millones de proyectos y sitios legítimos. Esto vuelve inviable bloquear el dominio o los subdominios sin afectar a los usuarios legítimos, una circunstancia que los atacantes explotan de forma activa. Para contrarrestar estos ataques, los proveedores de seguridad deben perfeccionar los métodos de detección de amenazas que utilizan el análisis de contenido.

Ataque AiTM multietapa

Analicemos una campaña de phishing actual, construida según el esquema AiTM y que utiliza la popular plataforma en la nube Cloudflare Workers. El ataque se ejecuta mediante varias páginas HTML que los atacantes alojan tanto en el sitio comprometido como en esta plataforma. Cada página cumple una función específica: recopilar las direcciones de correo electrónico de las víctimas, inicializar la infraestructura de proxy y suplantar la ventana de autenticación para interceptar la sesión de autenticación multifactor (MFA).

Etapa 1. Obtención de contactos reales y elusión del monitoreo de red

En el correo de phishing, los atacantes suelen recurrir a un pretexto convincente para que la víctima haga clic en el enlace. Puede tratarse, por ejemplo, de la solicitud de un colega para revisar unos documentos.

Tras hacer clic en el enlace de phishing, la víctima llegaba a una página con un falso captcha, alojada por el atacante en un sitio legítimo comprometido (en este ataque se utilizó un sitio con el formato https://t…e.com, aunque puede ser cualquiera). En este caso, la página pirateada se usaba como material deshechable (por lo general, los proveedores bloquean los enlaces de phishing recibidos en los correos electrónicos) para evitar que el contenido principal de phishing alojado en Cloudflare se detectase rápidamente.

Si el usuario ingresaba su correo y pulsaba el botón “Continuar”, el falso captcha lo consideraba humano y lo redirigía al siguiente paso. El objetivo principal de esta etapa es recopilar direcciones de correo electrónico, filtrar bots primitivos y redirigir al usuario real a la URL .workers.dev. Cloudflare Workers asigna este tipo de direcciones de forma automática y gratuita. El script insertaba el correo de la víctima en el hash de la URL (después del símbolo #) para que la página en .workers.dev pudiera obtener el correo sin contactar al servidor del atacante y eludir así la detección.

Etapa 2. Inicialización del proxy transparente

En el navegador de la víctima se abría una página con el siguiente formato: .workers.dev/..#user@business.com. A la víctima se le mostraba un captcha real (en esta etapa, los atacantes necesitaban confirmar que la página era visitada por una persona real y no por un sandbox).

Otro captcha, esta vez real

Tras superar el captcha, la página del atacante registraba un Service Worker en el navegador de la víctima: un archivo JavaScript especial que se ejecuta en segundo plano y puede interceptar todas las solicitudes de red de la pestaña activa. Este script constituye la base de la tecnología de aplicaciones web progresivas (PWA): acelera la carga de datos y permite que la aplicación web funcione sin conexión a internet. El navegador considera el Service Worker como una función habitual del sitio y, cuando el recurso web opera por HTTPS, no solicita confirmación para que el script empiece a ejecutarse.

Sobre este Service Worker, los atacantes desplegaban Ultraviolet, una biblioteca legítima de código abierto diseñada para crear proxies web. Los atacantes la utilizaban para reescribir en tiempo real todos los enlaces y formularios de la página, de modo que las solicitudes (incluido el ingreso de credenciales en el sitio de Microsoft) no llegaran directo a los servicios originales, sino que transitaran por el servidor de los atacantes.

Justo después de cargar, la página extraía el correo de la víctima del hash de la URL y lo guardaba en el almacenamiento temporal del navegador (sessionStorage) para no perderlo al cargar el captcha. Además, esto permitía completar de forma automática el campo de inicio de sesión en el formulario. El campo que ya había sido completado aumentaba la confianza de la víctima y hacía la página más convincente. Tras superar el captcha, el script del atacante generaba la URL de redirección al tercer paso, devolviendo al hash el correo guardado en sessionStorage. De esta forma, el correo se transmitía por el hash durante tres etapas consecutivas sin activar los mecanismos de detección de ataques de red.

Registro del Service Worker para interceptar el tráfico

Creación de un “proxy transparente” mediante una biblioteca independiente

Etapa 3. Interceptación de la sesión mediante la suplantación de la ventana del navegador

La etapa final tenía lugar en la tercera página: a la técnica AiTM (Adversary-in-the-Middle, ataque a nivel de tráfico) se sumaba la técnica BiTB (Browser-in-the-Browser, ataque a nivel de suplantación de interfaz). La técnica BiTB consiste en lo siguiente: dentro de una página web legítima se abre un bloque diseñado para imitar una ventana emergente auténtica.

En este caso, el script alojado en la página del atacante generaba una ventana emergente visualmente idéntica a una ventana del sistema del navegador (con una barra de direcciones falsa que mostraba una URL confiable de Microsoft, además de los botones de control). Dentro de esta ventana, un iframe cargaba el formulario de inicio de sesión real, cuyo tráfico se enrutaba a través del Service Worker configurado en la segunda etapa. Cuando la víctima ingresaba el usuario, la contraseña y el código MFA dentro del “navegador dentro del navegador”, el script proxy interceptaba no solo las credenciales, sino también los tokens de sesión. La combinación de BiTB con AiTM hace que el ataque sea más peligroso, ya que BiTB genera una interfaz simulada confiable (la víctima ve la URL correcta y los logotipos), mientras que el proxy AiTM oculto tras esa interfaz se encarga de interceptar el tráfico y robar los tokens de sesión.

Tras una autenticación exitosa, el proxy envía un comando para cerrar la ventana y redirige a la víctima a una página con un error del sistema (por ejemplo, SessionExpired). Esto reduce la vigilancia del usuario, quien asume que ocurrió una falla técnica e intenta iniciar sesión de nuevo, mientras el atacante ya cuenta con acceso completo a la sesión.

Estadísticas de ataques de phishing en plataformas en la nube

Analizamos los enlaces de phishing alojados en plataformas en la nube populares (Cloudflare, Netlify, GitHub Pages, entre otras) durante los últimos 12 meses (de julio de 2025 a junio de 2026). A continuación, se muestra la evolución del número de dominios únicos de tercer nivel utilizados para distribuir contenido de phishing. En los últimos 12 meses, nuestras soluciones bloquearon 224 984 dominios de tercer nivel únicos alojados en servicios descentralizados y de nube, empleados en campañas de phishing.

(descargar)

Con estos datos, también elaboramos un top 10 de dominios en la nube más utilizados en campañas de phishing durante el período señalado.

(descargar)

Cloudflare y Vercel se posicionaron como líderes indiscutibles, lo cual resulta lógico: ambas ofrecen planes gratuitos, emisión automática de certificados SSL y redes de entrega de contenido (CDN) globales. GitHub Pages también forma parte del top 3. La popularidad del dominio github.io dificulta el bloqueo masivo de páginas de phishing alojadas en él sin arriesgar el acceso a proyectos legítimos.

Las redes descentralizadas merecen una mención aparte (en 2023 publicamos un artículo sobre este tema): los dominios ipfs.io y dweb.link son puertas de enlace de IPFS. El principal riesgo de estas plataformas radica en la persistencia del contenido: aunque se bloquee un gateway, la página de phishing sigue siendo accesible a través de otros nodos de la red.

El TOP 10 también incluye a los constructores visuales Wix y Webflow (en los puestos 8 y 9, respectivamente). Estas herramientas permiten crear páginas de phishing rápido y sin conocimientos técnicos profundos de código, lo que reduce la barrera de entrada para atacantes menos preparados.

En los últimos 12 meses registramos más de 390 000 páginas de phishing alojadas en plataformas en la nube legítimas y en redes descentralizadas (IPFS). Estos datos confirman que los atacantes explotan de forma activa la confianza depositada en servicios legítimos de PaaS (Cloudflare Workers, Vercel, Netlify, GitHub Pages) e IPFS. La buena reputación de estas plataformas, sus planes gratuitos y sus mecanismos de camuflaje integrados permiten a los phishers desplegar con eficacia ataques AiTM multietapa e interceptar sesiones MFA.

Recomendaciones

Los métodos de protección tradicionales (como verificar el indicador de conexión segura o bloquear dominios mediante listas de bloqueados) resultan insuficientes en estos casos. El dominio principal del proveedor permanece como confiable, mientras que los subdominios maliciosos se crean de forma automática y masiva.

Para contrarrestar estas amenazas se requiere un enfoque integral:

• Actúe con cautela ante solicitudes entrantes inesperadas, incluso si provienen de dominios confiables o la página muestra un certificado SSL válido.
• Por lo general, los captchas no solicitan datos personales (en este caso, la dirección de correo electrónico). Si le piden proporcionar datos personales para  superar una verificación antibots, es muy probable que se trate de un fraude.
• Verifique con atención la URL en la barra de direcciones de la ventana principal del navegador (en la parte superior de la ventana). En ataques del tipo Browser-in-the-Browser, los atacantes pueden mostrar una ventana emergente falsa e insertar en ella cualquier dirección, incluida una legítima. Sin embargo, la barra de direcciones real, ubicada en la parte superior de la pantalla y que incluye los botones de navegación (atrás, adelante, actualizar), seguirá mostrando el dominio real del atacante.
• No ingrese datos en ventanas que aparezcan de forma repentina. Si un formulario para ingresar la contraseña o el código MFA aparece sin una acción explícita de su parte, cierre la pestaña y acceda al servicio deseado de forma manual, escribiendo la dirección en el navegador.
• Las soluciones de correo electrónico, como Kaspersky Secure Mail Gateway para entornos corporativos, y Kaspersky Premium para uso personal, aportan una capa extra de seguridad, pues neutralizan los enlaces de phishing ya en la etapa de entrega del correo.