Una campaña de phishing contra cuentas de Microsoft 365 está utilizando de forma masiva el device code phishing y servicios en la nube para robar credenciales y tokens de acceso. De acuerdo con datos de Huntress, la actividad se ha dirigido ya a más de 340 organizaciones en Estados Unidos, Canadá, Australia, Nueva Zelanda y Alemania, con un crecimiento sostenido desde el 19 de febrero de 2026.
Alcance del ataque de phishing contra Microsoft 365 y sectores afectados
Los objetivos cubren un abanico muy amplio: construcción, organizaciones sin ánimo de lucro, inmobiliarias y desarrolladoras, manufactura, servicios financieros, sanidad, despachos de abogados y administraciones públicas. Esta diversidad indica que el interés principal de los atacantes es el acceso a correo corporativo y datos en la nube, más que una industria específica.
La infraestructura de la campaña combina Cloudflare Workers para redirigir tráfico y la plataforma PaaS Railway como motor de recolección de credenciales y tokens. Un conjunto reducido de direcciones IP de Railway se utiliza para los flujos de autenticación abusivos; alrededor del 84 % de los eventos observados se origina únicamente en tres IP, lo que facilita su identificación en registros de acceso.
Qué es el device code phishing en OAuth y por qué es especialmente peligroso
El device code phishing explota el OAuth device authorization flow, un mecanismo legítimo diseñado para que dispositivos sin navegador completo (como televisores inteligentes o dispositivos IoT) puedan iniciar sesión. El usuario ve un código corto en pantalla y se le indica que lo introduzca en un dominio confiable, por ejemplo microsoft[.]com/devicelogin.
El riesgo crítico es que el atacante consigue tokens OAuth persistentes asociados a la cuenta de la víctima. Estos tokens pueden seguir siendo válidos incluso tras un cambio de contraseña, lo que permite un acceso prolongado a Microsoft 365 (correo, OneDrive, SharePoint, Teams) sin volver a solicitar credenciales. Este modelo de ataque fue descrito en detalle por Microsoft y Volexity en 2025 y posteriormente observado por Amazon Threat Intelligence y Proofpoint en nuevas oleadas, algunas atribuidas a grupos vinculados a Rusia como Storm‑2372, APT29, UTA0304, UTA0307 y UNK_AcademicFlare.
Cadena de ataque: del correo electrónico al robo de tokens de Microsoft 365
Abuso de redirecciones legítimas, Cloudflare Workers y Railway
La intrusión comienza con correos de phishing cuidadosamente preparados, donde el enlace malicioso se oculta tras servicios de redirección de proveedores de seguridad legítimos como Cisco, Trend Micro o Mimecast. Esto ayuda a eludir filtros antispam y transmite una falsa sensación de confianza al usuario.
A continuación, el clic del usuario desencadena una cadena de redirecciones que pasa por sitios comprometidos, Cloudflare Workers y plataformas como Vercel, hasta llegar a la página de destino de phishing. Estas páginas simulan distintos escenarios creíbles: documentos de licitación en construcción, solicitudes de firma DocuSign, mensajes de voz o notificaciones generadas supuestamente a través de Microsoft Forms.
El elemento común es una invitación a “ver archivos” introduciendo un código de dispositivo ya generado que se muestra directamente en la página. Eso indica un uso automatizado del flujo OAuth por parte del atacante y reduce la fricción para la víctima. Al pulsar “Continue to Microsoft”, se abre una ventana emergente con el endpoint legítimo microsoft[.]com/devicelogin, donde la autenticación tiene lugar realmente sobre infraestructura de Microsoft, sin señales obvias de falsificación.
Una vez que la víctima introduce el código, éste se asocia con la sesión iniciada previamente por el atacante mediante la API, generando tokens de acceso y actualización que quedan bajo control del adversario. La mayoría de los sitios de phishing identificados utilizan dominios workers[.]dev, aprovechando la confianza corporativa en Cloudflare para evadir filtros web y soluciones de inspección de tráfico.
EvilTokens y la consolidación del phishing como servicio (PhaaS)
La actividad observada en Railway se vincula a una nueva plataforma de phishing-as-a-service (PhaaS) denominada EvilTokens, lanzada recientemente a través de canales de Telegram. Este servicio ofrece a los clientes plantillas de correo, infraestructura para evasión de filtros y un panel centralizado para gestionar campañas, reduciendo drásticamente la barrera de entrada para delincuentes con poca capacidad técnica.
EvilTokens proporciona además enlaces con redirección abierta (open redirect) en dominios vulnerables para ofuscar aún más las URL maliciosas. La disponibilidad de soporte 24/7 y canales de atención ilustra la creciente profesionalización de los servicios criminales, una tendencia ya observada en otros mercados ilícitos como RaaS (ransomware-as-a-service).
Técnicas avanzadas de evasión y anti-análisis en las páginas de phishing
Investigadores de Unit 42 (Palo Alto Networks) han documentado una campaña similar de device code phishing, detectada por primera vez el 18 de febrero de 2026, que incorpora un conjunto sofisticado de mecanismos anti‑bot y anti‑análisis. Al cargarse la página, se transmiten furtivamente cookies del navegador al servidor del atacante y se bloquean acciones como clic derecho, selección de texto, arrastrar y soltar o combinaciones de teclas para abrir las herramientas de desarrollador (F12, Ctrl+Shift+I/C/J, Ctrl+U).
Además, el sitio detecta la presencia activa de DevTools mediante el análisis del tamaño de la ventana, y si identifica actividad de análisis, inicia un bucle infinito de depuración que complica considerablemente el trabajo de analistas e instrumentos automatizados. Este tipo de técnicas, combinado con la infraestructura en la nube y PhaaS, sitúa el phishing en un nivel de sofisticación comparable al de muchas campañas de malware avanzado.
Medidas de protección para organizaciones que usan Microsoft 365
Las organizaciones que dependen de Microsoft 365 deberían revisar sus registros de inicio de sesión en busca de accesos provenientes de direcciones IP asociadas a Railway y otros proveedores PaaS sospechosos. Es recomendable revocar todos los refresh tokens de las cuentas potencialmente afectadas, aplicar políticas de acceso condicional y, cuando sea viable, restringir o supervisar estrictamente el uso del flujo de código de dispositivo OAuth.
Las buenas prácticas recogidas en marcos como NIST SP 800‑63 o los Controles CIS sugieren reforzar el gobierno de aplicaciones OAuth: limitar el consentimiento de usuarios a aplicaciones de confianza, revisar periódicamente permisos concedidos a aplicaciones de terceros y monitorizar patrones de inicio de sesión anómalos (ubicaciones inusuales, múltiples inicios fallidos, cambios repentinos de dispositivo).
Resulta igualmente crítico formar a los empleados para reconocer solicitudes de introducción de códigos de dispositivo fuera de contexto, incluso cuando la página de autenticación pertenece realmente a un dominio legítimo de Microsoft. Explicar que el dominio puede ser auténtico pero el flujo haber sido iniciado por un atacante ayuda a romper la falsa sensación de seguridad que estos ataques explotan.
Ante la combinación de PhaaS, flujos OAuth abusados y técnicas anti‑análisis, las empresas deben asumir que el phishing seguirá evolucionando en sofisticación. Reforzar el monitoreo de tokens y aplicaciones en la nube, endurecer las políticas de acceso, invertir en concienciación de usuarios y revisar periódicamente la superficie de ataque en Microsoft 365 son pasos clave para reducir el riesgo de compromisos duraderos y el control clandestino de la infraestructura corporativa en la nube.
