En marzo de 2026, nuestro SOC detectó un aumento de inicios de sesión anómalos en Microsoft 365 en docenas de organizaciones de forma simultánea.
La fuente: un puñado de direcciones IP pertenecientes a Railway.com, una plataforma PaaS para desarrolladores que la mayoría de los equipos de seguridad nunca había tenido motivos para vigilar.
La técnica: phishing mediante código de dispositivo, en el que los atacantes generan un código de autenticación legítimo de Microsoft y engañan a los usuarios para que lo ingresen, entregando así un token de OAuth válido que dura hasta 90 días. No se robó ninguna contraseña. No se instaló ningún malware. La víctima completó la autenticación MFA, así que el atacante obtiene acceso total.
Para cuando publicamos nuestra investigación sobre Railway, ya se habían visto afectadas 344 organizaciones en Estados Unidos, Canadá, Australia, Nueva Zelanda y Alemania.
Tres meses después, nuestro SOC detectó un aumento de otro tipo: 81 millones de intentos de inicio de sesión desde un rango IPv6 controlado por una empresa llamada LSHIY LLC, lo que resultó en 78 cuentas comprometidas en 64 organizaciones. Esta vez la técnica fue ROPC, o Resource Owner Password Credentials, un flujo de OAuth obsoleto que toma un nombre de usuario y una contraseña directamente en el endpoint /token y genera un token de usuario nuevo sin activar, en la mayoría de los casos, ninguna solicitud de MFA.
Ataques distintos. Infraestructura distinta. Pero ambas campañas tuvieron éxito por el mismo tipo de error de configuración: flujos de autenticación que la mayoría de los entornos de Microsoft 365 nunca habían bloqueado explícitamente, y políticas de acceso condicional que parecían correctas pero no lo eran.
Railway: una fábrica de recolección de tokens con direcciones IP limpias
El phishing mediante código de dispositivo es eficaz porque no intenta vencer la autenticación MFA. La evita por completo.
El flujo de código de dispositivo de OAuth de Microsoft fue diseñado para dispositivos con entrada limitada, como televisores inteligentes e impresoras, que no pueden realizar un inicio de sesión interactivo. Los atacantes lo convierten en arma al generar ellos mismos los códigos de dispositivo, incorporarlos en señuelos de phishing y recolectar los tokens de OAuth resultantes cuando las víctimas se autentican. La víctima puede completar la autenticación MFA. No importa. El token ya ha sido robado.
Figura 1: Phishing mediante código de dispositivo usado como táctica
Lo que hizo peligroso a Railway no fue la técnica, que Huntress ha venido rastreando desde hace tiempo. Fue la infraestructura. Railway es una plataforma PaaS legítima para desarrolladores. Sus rangos de IP están limpios. La Protección de identidad de Microsoft no tiene motivos para calificar como riesgoso un inicio de sesión desde Railway. Los atacantes obtuvieron, en la práctica, un motor de recolección de tokens alojado en la nube con reputación de IP confiable ya incorporada, y solo tres direcciones IP de Railway representaron alrededor del 84% de todo el tráfico de ataque. Un número reducido de aplicaciones desplegadas estaba causando mucho daño.
Los señuelos también estaban diseñados para escalar. Predominaron los temas de solicitudes de propuestas (RFP) de construcción, algo lógico dado que esa industria funciona a base de solicitudes de documentos de terceros. Algunas cadenas de phishing pasaban por URL triplemente envueltas, usando en secuencia Cisco, Trend Micro y los propios SafeLinks de Microsoft. El correo llegaba con un dominio de proveedor confiable en el enlace, y el conjunto de filtros lo dejaba pasar.
Esa campaña fue atribuida más tarde a EvilTokens, una plataforma de modelo de phishing como servicio que Huntress rastreó en colaboración con Flare.io. EvilTokens es un producto comercial, con tienda en línea, generación de señuelos asistida por IA, equipo de soporte 24/7 y reseñas de clientes incluidas. El phishing mediante código de dispositivo a esta escala ahora es algo a lo que te puedes suscribir.
Lee nuestro análisis completo de EvilTokens →
LSHIY: la MFA estaba activada. Solo que no funcionaba bien.
La campaña LSHIY llegó de otra manera. Sin señuelos de phishing ni ingeniería social. Solo atacantes reproduciendo credenciales validadas mediante el flujo ROPC contra Azure CLI a una escala masiva.
ROPC es un método heredado de OAuth que evita el endpoint de autorización y va directo al endpoint /token con un nombre de usuario y una contraseña. Como nunca pasa por el endpoint de autorización, la mayoría de las políticas de acceso condicional que exigen MFA no ofrecen protección, porque de forma predeterminada omiten recursos de Azure como Azure CLI.
Aquí está el número que nos detuvo en nuestra investigación: de las 78 cuentas comprometidas, 55 tenían políticas de acceso condicional activas que exigían MFA. Estas organizaciones pensaban que estaban protegidas, pero sus políticas no las protegían.
Algunas habían limitado la MFA a aplicaciones específicas, como Microsoft Admin Portals, pero no a "All Cloud Apps", por lo que el tráfico de Azure CLI pasaba sin problemas. Algunas habían limitado la MFA a grupos de usuarios específicos, y las cuentas comprometidas no estaban en ellos. Algunas tenían la MFA configurada para exigirse solo desde ubicaciones no confiables, y la IP del atacante había sido etiquetada por error como proveniente de EE. UU. Dos tenían la MFA en modo de solo informe, lo que significa que estaba configurada pero nunca se aplicaba en realidad.
Figura 2: Un desglose de las brechas de configuración de MFA en esta campaña
Una organización tenía una política de acceso condicional llamada explícitamente "Block Azure CLI". Esa política, de hecho, no bloqueaba Azure CLI.
Ocho de las 78 cuentas comprometidas no tenían ninguna política de MFA. Pero la lección no es que la MFA no funcione. Es que una MFA configurada de forma demasiado limitada deja brechas predecibles, detectables y que valen la pena para quien está dispuesto a intentar 81 millones de inicios de sesión.
Dos políticas. Ambas ya incluidas en Managed ISPM.
Cuando nuestro equipo de Huntress Managed ISPM revisó ambas campañas, los controles que habrían marcado la diferencia eran los mismos controles ya establecidos de forma predeterminada en Managed ISPM.
Bloquear el flujo de código de dispositivo mediante acceso condicional. Esta política impide que se use el flujo de autorización de código de dispositivo de OAuth en todo el inquilino, o lo restringe a las cuentas específicas que realmente lo necesitan. En el caso de la campaña de Railway, esto desactiva el mecanismo central del ataque sin importar cuán bueno sea el señuelo de phishing. Una víctima puede ingresar el código en el endpoint real de Microsoft. Si el flujo de código de dispositivo está bloqueado, no pasa nada.
Restringir la administración del portal de Azure y los flujos de autenticación heredados. Para LSHIY, la solución fue una cobertura de acceso condicional que realmente coincidiera con lo que usó el ataque: todos los usuarios, todas las aplicaciones en la nube, todos los tipos de aplicaciones cliente, incluidos métodos de autenticación heredados como ROPC. La configuración de autenticación sólida (userStrongAuthClientAuthNRequired) exige la autenticación a nivel del cliente y bloquea los flujos ROPC aunque las credenciales sean correctas.
No es difícil saber que estos controles existen, pero sí es difícil desplegarlos con el alcance correcto, mantenerlos en su lugar y saber cuándo se han desviado de su configuración original.
La razón por la que estas políticas no están activadas
Pregúntale a casi cualquier equipo de TI por qué no ha desplegado estos controles y escucharás lo mismo: "Nos preocupa romper algo".
Eso no es irrazonable. Las políticas de acceso condicional mal configuradas pueden dejar a los usuarios fuera del sistema. Hay equipos que activaron una política y vieron cómo la mesa de ayuda se saturó en menos de una hora. Por eso despliegan los dos controles de los que están seguros y dejan el resto pendiente en la lista.
Learning Mode de Managed ISPM se creó justo para este tipo de indecisión. Cada nueva política de acceso condicional se ejecuta primero en modo de solo informe, por lo general durante 14 días. Durante esa ventana, el sistema analiza qué usuarios se habrían visto afectados si la política hubiera estado activa.
Al terminar el período de aprendizaje, obtienes una lista específica: quién se habría visto afectado, cuándo y cómo. Si el impacto es el esperado, aplicamos la política. Si hay una excepción que definir, hay tiempo para hacerlo antes de que algo falle.
Figura 3: Un ejemplo de los hallazgos de Learning Mode en Managed ISPM
Más allá de la implementación inicial, Managed Deployments te ayuda a priorizar qué implementar y cuándo, y mantiene esas políticas actualizadas a medida que cambia el panorama de amenazas. Cuando nuestro SOC identifica una nueva técnica utilizada a gran escala, esa inteligencia se integra directamente en el marco de políticas de ISPM.
Las organizaciones inscritas en Managed Deployments heredan los controles actualizados. El bloqueo del flujo de código de dispositivo ya estaba implementado para los clientes elegibles de ISPM antes de que ocurriera Railway. Los controles de bloqueo de ROPC ya estaban implementados antes del aumento de LSHIY. Pero si no hubiera sido así, Huntress habría estado actualizando Managed ISPM para garantizar que los inquilinos recibieran protección rápida.
Figura 4: Managed Deployments en Managed ISPM
Eso es lo que significa que la prevención y la detección realmente trabajen juntas. Huntress Managed ITDR detectó los compromisos activos en ambas campañas y generó informes de incidentes para que las organizaciones pudieran responder. Tener ISPM implementado habría evitado que esos compromisos ocurrieran en los clientes con las políticas correctas en vigor. Y cuando el SOC detecta una nueva ruta de ataque a través de ITDR, ISPM cierra esa ruta para que no pueda usarse de la misma forma dos veces.
Qué hacer ahora
Si no estás seguro de si tus políticas de acceso condicional realmente bloquean el flujo de código de dispositivo y la autenticación tipo ROPC, probablemente no lo hagan. Esa es la realidad que encontramos en más de 12.000 inquilinos durante el período de early access de Managed ISPM. Más del 50% de nuestros controles recomendados faltaban en el 60% de los inquilinos, incluidos entornos donde ya se habían implementado herramientas de postura de seguridad.
Railway y LSHIY no son casos aislados. Son ejemplos de lo que pasa cuando los atacantes pueden contar con que estos flujos estén abiertos. Y seguirán creando campañas en torno a ellos mientras sigan estándolo.
Si quieres profundizar en cómo se desarrollan estos ataques en el mundo real, únete a nosotros el 14 de julio para el próximo Tradecraft Tuesday: "The Cost of a Weak CAP: Anatomy of a Major Password Spray Attack." Analizaremos ataques recientes de rociado de credenciales y compartiremos orientación práctica sobre políticas de acceso condicional que tu equipo puede usar para cerrar las brechas que a los atacantes les encanta explotar.
Lee más sobre cómo Managed ISPM cierra estas brechas, y inicia una prueba gratuita para empezar a cerrarlas.
