El descuido de un atacante expone tres campañas de phishing y una nueva plataforma como servicio: así se roban las cuentas de Microsoft 365

En julio de 2026, dos descubrimientos paralelos revelaron un aumento de ataques de phishing sofisticados contra Microsoft 365 que eluden la autenticación multifactor (MFA) mediante dos métodos fundamentalmente diferentes: ataques de proxy intermediario (AiTM) y abuso de la autenticación mediante código de dispositivo. El primer hallazgo surgió de un error de un atacante: un servidor web Python mal configurado que expuso tres campañas activas. El segundo provino de investigadores que rastreaban una nueva plataforma comercial de phishing llamada Forg365. Entender cómo funciona cada ataque es el primer paso para implementar las defensas adecuadas, porque la solución para uno no detiene al otro.

El servidor mal configurado que reveló tres operaciones de Evilginx

El 13 de julio de 2026, investigadores de la firma de seguridad francesa Lexfo descubrieron tres operaciones de phishing activas basadas en Evilginx dirigidas a Microsoft 365 después de que un atacante dejara un servidor web Python expuesto en un puerto público con la lista de directorios habilitada. El comando python3 -m http.server 8080 aún era visible en el archivo .bash_history del servidor. A partir de ese directorio abierto, Lexfo recuperó todo el kit de herramientas del operador, sus registros, los datos de las víctimas capturadas y logró identificar a otros dos operadores de phishing que ejecutaban campañas separadas .

Las tres operaciones eran campañas de phishing AiTM basadas en Evilginx que utilizaban un proxy para interceptar las páginas de inicio de sesión de Microsoft 365 y robar los tokens de sesión después de que el usuario completara la MFA . Una de las tres campañas había registrado 218 cuentas capturadas en 12 países, de las cuales el 94 % eran buzones corporativos . Las operaciones utilizaban dos rutas de ataque distintas: el robo de tokens de sesión de Evilginx (mediante un proxy AiTM) y el phishing de código de dispositivo: un kit enviaba a las víctimas a la página real de inicio de sesión de dispositivos de Microsoft, donde ellas mismas autorizaban el acceso, y el backend del atacante solicitaba el token .

Forg365: una plataforma comercial de phishing como servicio

Por separado, la plataforma de phishing como servicio (PhaaS) Forg365 fue identificada por investigadores de ZeroBEC (reportada del 9 al 13 de julio de 2026) como un kit comercial distribuido por Telegram que cuesta 400 dólares al mes (o 3800 dólares al año). A diferencia de las bifurcaciones personalizadas de Evilginx encontradas en el servidor expuesto, Forg365 agrupa múltiples métodos y herramientas de ataque en un solo panel de control para el operador .

Forg365 combina tres capacidades principales:

• Proxy AiTM: un proxy inverso transparente que captura los tokens de sesión después de que el usuario completa la MFA
• Phishing de código de dispositivo: abusa del flujo legítimo de código OAuth de dispositivos de Microsoft, lo que significa que el usuario completa la autenticación en una página real de Microsoft sin que el atacante vea nunca su contraseña
• Generación de señuelos asistida por IA: utiliza inteligencia artificial para crear correos electrónicos y páginas de destino convincentes que suplantan a SharePoint, OneDrive, DocuSign y Adobe Acrobat Sign

La plataforma también incluye evasión antibot (detecta entornos de pruebas y rastreadores de seguridad), acceso al buzón después del compromiso (los operadores pueden navegar y extraer correos electrónicos desde el panel), rotación de servidores SMTP y programación de campañas .

Un ataque roba tokens después de la MFA; el otro abusa de un protocolo legítimo

Estos dos descubrimientos ilustran la distinción crítica entre los ataques de proxy AiTM y el abuso del código de dispositivo. Comprender la diferencia es esencial porque la misma defensa no funciona para ambos:

• Ataques de proxy AiTM (estilo Evilginx): El atacante configura una página de inicio de sesión falsa que actúa como proxy del tráfico hacia la página de inicio de sesión real de Microsoft. El usuario ingresa su contraseña y completa la MFA en el proxy del atacante. Después de una autenticación exitosa, Microsoft emite una cookie de sesión para lo que cree que es el navegador del usuario legítimo, pero esa cookie en realidad termina en el proxy del atacante, no en el navegador del usuario. El atacante puede entonces reutilizar esa cookie para acceder a la cuenta de Microsoft 365 de la víctima .

• Phishing de código de dispositivo: El atacante genera un código de dispositivo legítimo de Microsoft (un código corto que se usa para iniciar sesión en dispositivos sin teclado, como televisores inteligentes) y lo envía a la víctima en un correo electrónico de phishing. La víctima visita la página de inicio de sesión real de Microsoft, ingresa el código, completa la MFA y autoriza la aplicación del atacante. No se "elude" nada: la víctima ha autorizado el acceso. El backend del atacante entonces consulta a Microsoft para obtener el token .

Defensas recomendadas: qué controles detienen cada ataque

Defensas contra ataques de proxy intermediario (estilo Evilginx)

La defensa más efectiva contra los ataques de proxy AiTM es la MFA resistente al phishing, específicamente FIDO2/WebAuthn y passkeys. Estos métodos vinculan las credenciales al nombre de dominio legítimo, por lo que cuando el navegador del usuario se conecta al sitio proxy del atacante (que tiene un dominio diferente), el protocolo de autenticación detecta la discrepancia del dominio y bloquea automáticamente el intercambio de credenciales .

Otras defensas incluyen:

• Políticas de Acceso Condicional (Entra ID): Exigir el cumplimiento de los dispositivos y requisitos de ubicación de confianza para evitar la emisión de tokens desde proxies no confiables
• Evaluación de Acceso Continuo (CAE): Permite la revocación de tokens en tiempo casi real cuando se detectan condiciones de riesgo
• Monitorear el uso anómalo de tokens: Buscar tokens utilizados desde una IP o país diferente al que se emitieron, viajes imposibles y "propiedades de inicio de sesión no familiares"
• Bloquear dominios de phishing recién registrados: Monitorear dominios registrados en los últimos 30 días que resuelvan a rangos de IP de hosting conocidos por ser utilizados para infraestructura de phishing

Defensas contra el abuso de la autenticación mediante código de dispositivo

El phishing de código de dispositivo no requiere que el atacante engañe a la víctima para que ingrese sus credenciales en una página falsa; el usuario interactúa con la página de inicio de sesión real de Microsoft. Esto significa que FIDO2/passkeys por sí solos no protegen completamente contra este ataque porque se está utilizando el flujo OAuth legítimo .

La defensa principal es bloquear la concesión OAuth de código de dispositivo para los usuarios que no la necesiten, utilizando el Acceso Condicional de Microsoft Entra ID:

• Crear una política usando la condición "Flujos de autenticación" para bloquear el flujo de código de dispositivo para todos los usuarios excepto un grupo de excepción documentado
• Antes de bloquear, ejecutar en modo solo informe o revisar los registros de inicio de sesión históricos para identificar el uso legítimo del código de dispositivo (por ejemplo, televisores inteligentes, dispositivos para salas de conferencias)
• Planificar una excepción para el Servicio de Registro de Dispositivos (DRS), porque bloquear el flujo de código de dispositivo puede interferir con Autopilot y la inscripción de dispositivos Windows

Defensas adicionales:

• Restringir el consentimiento de aplicaciones y los alcances de las concesiones OAuth: Limitar qué aplicaciones pueden usar concesiones de código de dispositivo y auditar las aplicaciones consentidas regularmente
• Implementar MFA resistente al phishing incluso para flujos de código de dispositivo: Aunque no es una solución completa, las claves de hardware FIDO2 o la autenticación basada en certificados siguen reduciendo la superficie de ataque

En resumen

El aviso de servicio público del FBI de mayo de 2026 sobre la plataforma PhaaS Kali365 recomendó específicamente bloquear el flujo de código de dispositivo como defensa principal . A medida que plataformas de phishing como Forg365 continúan comercializando estas técnicas de ataque, la urgencia operativa para los defensores es clara: implementar FIDO2/passkeys para todas las cuentas privilegiadas para detener los ataques de proxy AiTM, y usar el Acceso Condicional para deshabilitar la concesión de código de dispositivo para los usuarios que no la necesiten. Un solo directorio abierto pudo haber expuesto tres campañas, pero las lecciones se aplican a cada inquilino de Microsoft 365.