Sobre rieles: actores de amenazas abusan de Railway.com PaaS como infraestructura de ataque de token de autenticación de Microsoft 365

Agradecimientos: Un agradecimiento especial a Casey Smith, Tanner Filip, Matt Kiely, y a Aaron Deal por sus contribuciones a esta investigación y redacción.

ACTUALIZACIÓN: 23 de marzo de 2026

En colaboración con nuestros amigos de Flare.io y otros contactos de la comunidad, Huntress ha atribuido el ataque de Railway a la plataforma de phishing como servicio (PhaaS) EvilTokens. Anunciada por primera vez en el canal de Telegram de NOIRLEGACY GROUP, EvilTokens creó sus propios canales de Telegram e hizo su primera publicación pública el 16 de febrero de 2026. Esta actividad coincide con los primeros casos de compromisos que Huntress vio desde la infraestructura de Railway el 19 y 24 de febrero de 2026.

Figura 1a: Primeros mensajes públicos de EvilTokens

EvilTokens ofrece tres “productos” para sus usuarios: un “B2B Sender”, un “Office 365 Capture Link” y un “SMTP Sender”. Tanto el B2B Sender como el Capture Link cuentan con funciones potentes, entre ellas flujos de trabajo de IA que ayudan a evadir el filtrado de correos, personalizar señuelos de phishing y encontrar correos confidenciales para fraude electrónico o actividades de exfiltración de datos. El panel de EvilTokens también ofrece a los clientes enlaces de redirección abierta (Open Redirect) hacia dominios vulnerables, a través de los cuales los CloudFlare workers de los productos “Office 365 Capture Link” y “Sender” pueden robar credenciales adicionales de nuevas víctimas.  La figura 2a muestra la tienda de productos de EvilTokens, junto con sus precios.

Figura 2a: Tienda de productos de EvilTokens

Las figuras 3a y 4a muestran más detalles sobre el Capture Link y el B2B sender, respectivamente:

Figura 3a: Funcionalidad del Capture Link de EvilTokens

Figura 4a: Funcionalidad del BSB Sender de EvilTokens

Figura 5a: Panel de EvilTokens con opciones de personalización de marca para señuelos de phishing

El panel de EvilTokens también permite opciones sencillas de personalización e identidad visual, como se observa en las figuras 5a y 6a.

Figura 6a: Panel de EvilTokens con URL vulnerables disponibles para la ofuscación inicial del enlace de phishing

Figura 7a: Actualización de producto de EvilTokens con anuncio de herramientas de IA integradas

Además del rápido crecimiento en la funcionalidad de la herramienta, el equipo de EvilTokens ha creado un equipo de soporte completo disponible 24/7 y un canal de comentarios de soporte, como se ve en la figura 8a. También tienen comentarios de clientes, como se ve en la figura 9a.

Figura 8a: Anuncio del equipo de soporte de EvilTokens

Figura 9a: Comentarios positivos de la comunidad sobre la plataforma EvilTokens

Huntress continúa bloqueando la autenticación desde la infraestructura de Railway hacia identidades protegidas por Huntress y, a las 12:00 p. m. hora del Este del lunes 23 de marzo de 2026, había bloqueado 113 intentos de compromiso, además de los aproximadamente 350 compromisos informados durante las últimas dos semanas.

-------------------

Publicación original: 20 de marzo

Resumen: Huntress está monitoreando una campaña activa de phishing mediante código de dispositivo que ataca identidades de Microsoft 365 en más de 340 organizaciones en Estados Unidos, Canadá, Australia, Nueva Zelanda y Alemania. El primer caso apareció el 19 de febrero, seguido de dos más el 24 de febrero. Luego, el 2 de marzo, la campaña se disparó y, durante las últimas semanas, ha seguido acelerándose sin señales de disminuir, afectando a organizaciones de todo tipo y tamaño, desde bufetes de abogados hasta empresas constructoras.

En nuestro análisis inicial de esta campaña, no hemos visto señuelos de phishing ni dominios iniciales idénticos. Si bien hubo cierta reutilización temática, la variación en los señuelos no tiene precedentes. Cada mensaje estuvo lo suficientemente personalizado para evitar una duplicación exacta. Dado esto, creemos que la campaña aprovecha la automatización o la IA para operar a escala. Debido a que cada señuelo se personaliza para su víctima mientras evita la replicación exacta, los correos de phishing evaden las soluciones de filtrado de correo con una eficacia alarmante.

También creemos que los atacantes están utilizando como arma Railway, una plataforma como servicio (PaaS) creada para la programación asistida por IA, para crear infraestructura de recolección de credenciales bajo demanda a velocidad de máquina. Las funciones de implementación y solución de problemas basadas en indicaciones de Railway hacen que sea trivial poner en marcha y desmantelar servicios expuestos a internet con una fricción mínima. Si bien no observamos directamente a actores de amenazas usando las funciones de IA de Railway en esta campaña, construimos un prototipo para confirmar con qué facilidad ese flujo de trabajo podría acelerar la implementación y rotación de infraestructura de phishing, incluso en el nivel gratuito. Railway, en la práctica, les da a los adversarios un motor de recolección de tokens alojado en la nube que resulta limpio ante el sistema de puntuación de riesgo de Microsoft, y quienquiera que esté detrás de esta campaña lo está usando como arma a plena capacidad.

Lo que también hace inusual a esta campaña no son solo las técnicas de phishing mediante código de dispositivo involucradas, sino la variedad de técnicas observadas. Señuelos de licitaciones de construcción, generación de código de páginas de destino, suplantación de DocuSign, notificaciones de correo de voz y el abuso de páginas de Microsoft Forms, todo está llegando al mismo grupo de víctimas a través de la misma infraestructura de IP de Railway.com. La diversidad de técnicas y tipos de señuelos plantea una pregunta que no tiene una respuesta clara: ¿se trata de un solo actor de amenazas con un conjunto de herramientas inusualmente amplio, o de varios actores que comparten el mismo backend?

Introducción

El 2 de marzo de 2026, el Centro de Operaciones de Seguridad de Huntress (SOC)  detectó un patrón preocupante: una ola de eventos de autenticación anómalos en docenas de organizaciones de forma simultánea. El patrón era inconfundible: Phishing mediante código de dispositivo. Esta técnica explota el flujo de autorización de dispositivos de OAuth para otorgar al atacante tokens de acceso persistentes, que siguen siendo válidos incluso después de restablecer la contraseña. Estos intentos se originaron en un bloque reducido de direcciones IP pertenecientes a Railway.com, un proveedor de hosting en la nube tipo PaaS que la mayoría de los equipos de seguridad nunca ha tenido motivo para bloquear.

Lo que siguió fue una investigación de varios días que reveló una campaña técnicamente sofisticada y operativamente madura dirigida a víctimas de varios sectores empresariales.

Esta publicación documenta partes de la cadena de ataque, los mecanismos técnicos detrás del robo de credenciales y del robo de tokens de autenticación, cómo se abusa de Railway como motor de reenvío de tokens, y qué ha hecho Huntress y qué pueden hacer las empresas y sus clientes ahora mismo.

Antecedentes

¿Qué es el phishing mediante código de dispositivo?

El phishing mediante código de dispositivo de OAuth explota un flujo de autenticación legítimo de Microsoft diseñado para dispositivos con entrada limitada, como televisores inteligentes, impresoras y terminales. En su uso normal, un usuario visita microsoft.com/devicelogin, ingresa un código de 8 caracteres y autoriza un dispositivo. Los atacantes convierten esto en un arma generando ellos mismos los códigos de dispositivo y luego engañando a los usuarios para que los ingresen mediante señuelos de phishing. Cuando la víctima ingresa el código y aprueba la solicitud de autenticación, el backend del atacante recibe de inmediato un conjunto de tokens de OAuth válidos: no se necesita contraseña ni vencer la MFA. El conjunto de tokens incluye un token de acceso, válido para el acceso inmediato a recursos, y un token de actualización, válido por hasta 90 días.

Esta técnica está documentada en la propia investigación de Huntress sobre el phishing mediante código de dispositivo de OAuth en Azure y Google Cloud, y ha sido cubierta ampliamente por analistas de amenazas de ANY.RUN.

¿Qué es Railway.com?

Railway es un proveedor de PaaS pensado para desarrolladores, similar a Heroku o Render. Subes un contenedor o un repositorio de GitHub y obtienes un endpoint HTTPS público con TLS automático, escalado y acceso saliente a internet. El registro solo requiere una dirección de correo electrónico. Los rangos de IP de salida de Railway —162.220.232.0/22 y 162.220.234.0/22— son de un proveedor de nube limpio y legítimo. La Protección de Identidad de Microsoft no tiene motivo para calificar como riesgosos los inicios de sesión provenientes de estas IP. Ese es precisamente el punto.

Railway también refleja un cambio más amplio hacia plataformas en la nube modernas, que reducen cada vez más el trabajo de infraestructura gracias a la simple codificación intuitiva ("vibe coding"), lo que permite a los adversarios crear infraestructura en una fracción del tiempo con instrucciones, plantillas y unos pocos clics. En el caso de Railway, la implementación y la resolución de problemas basadas en instrucciones facilitan construir, probar y exponer servicios rápidamente. Queremos ser precisos aquí: Huntress no observó directamente que el actor de amenazas usara implementación asistida por IA dentro de Railway durante esta campaña. Lo que sí observamos fue el abuso de infraestructura alojada en Railway. Por separado, cuando iniciamos sesión en la plataforma y creamos una implementación de prueba para entender mejor cómo podrían haber salido de Railway estos intentos de autenticación, quedó claro lo poco esfuerzo que se necesitaría para levantar o derribar infraestructura a gran escala. Eso importa porque, incluso cuando la IA no es visible en la telemetría, las plataformas que reducen la configuración y la carga operativa siguen ayudando a los adversarios a moverse más rápido.

Resumen de la cadena de ataque 

La infraestructura de Railway: una fábrica de recolección de tokens

Todo el abuso de autenticación observado en nuestra telemetría se origina en un bloque reducido de IPs de Railway.com. Tres IPs dan cuenta de alrededor del 84% de los eventos observados, lo cual es consistente con un número pequeño de aplicaciones de Railway implementadas, no con un botnet.

La infraestructura de phishing: un ecosistema aparte

Antes del motor de recolección de tokens de Railway hay una infraestructura de entrega de phishing que cuenta su propia historia. Según inteligencia compartida y observaciones de analistas, varias firmas técnicas aparecen de forma constante en esta campaña.

Abuso de reescritores de URL de proveedores de seguridad de correo electrónico

El bypass de entrega más significativo: el atacante envuelve URL maliciosas dentro de servicios de redirección legítimos de proveedores de seguridad. El correo llega con una URL de Cisco, Trend Micro o Mimecast en el cuerpo, de modo que el enlace visible es un dominio de proveedor confiable, no el destino malicioso:

• Cisco Secure Email (secure-web.cisco.com): 5 o más instancias como envoltorio de primer salto
• Trend Micro URL Protection (cas5-0-urlprotect.trendmicro.com):  primer salto en varias cadenas
• Mimecast URL Protection (url.us.m.mimecastprotect.com): envuelve una redirección intermedia

Una cadena observada tenía triple envoltorio: SafeLinks → Trend Micro → Cisco Secure Web → página de phishing final. El stack de seguridad de la víctima ve un enlace de Cisco o Trend Micro y lo deja pasar. El atacante no está venciendo la seguridad del correo; está usando la infraestructura desplegada por la competencia para blanquear sus enlaces y evadir los filtros de spam.

Cadenas de redirección de múltiples saltos (2 a 5 saltos)

Las "plataformas conocidas como confiables" en medio de estas cadenas son sitios web comprometidos. Son negocios reales cuyo CMS era vulnerable y fue inyectado con páginas de redirección. Estos sitios tienen una reputación de dominio legítima, lo que hace que la inspección de URL en cualquier salto individual no sea concluyente. Hablaremos del señuelo que usa customervoice.microsoft.com un poco más adelante.

Táctica observada: phishing mediante código de dispositivo con códigos en la página de destino

La mayoría de los casos de phishing mediante código de dispositivo que hemos observado antes usaban el correo electrónico como pretexto. Esta campaña es notablemente diferente. Los sitios de destino observados le piden a la víctima que continúe hacia el endpoint legítimo de autenticación por código de dispositivo de Microsoft e ingrese un código provisto para poder leer algunos archivos. El código se muestra directamente en la página cuando la víctima llega. Esta es una iteración interesante de la táctica, ya que normalmente el adversario debe generar el código y luego proporcionárselo a la víctima. Al mostrar el código directamente en la página, probablemente mediante alguna automatización de generación de códigos, la víctima recibe de inmediato el código y el pretexto para el ataque.

La página le muestra al usuario un botón "Continuar a Microsoft", que abre una ventana emergente. En este caso, la ventana emergente muestra el endpoint legítimo de autenticación de Microsoft. Las ventanas emergentes en el contexto del phishing a menudo pueden significar que el adversario está usando browser-in-the-browser para manipular la URL de la ventana emergente. En este caso, se confirmó que la ventana emergente era el endpoint legítimo de Microsoft, lo que descarta el browser-in-the-browser.

Figura 1: Phishing mediante código de dispositivo usado como táctica

El phishing mediante código de dispositivo es notablemente distinto de un AiTM, porque el adversario no está verdaderamente "en el medio". En cambio, usa la función legítima de autenticación por código de dispositivo de Microsoft y le pide al usuario que se autentique bajo circunstancias que el adversario controla. La autenticación multifactor no es una mitigación eficaz para este ataque, porque la víctima ingresa el código, luego su nombre de usuario y contraseña, y después el código MFA si corresponde. La autenticación resultante genera un token que el atacante puede obtener, con lo que se anula la protección de MFA.

La diversidad de señuelos: ¿una campaña o varias?

Los temas de señuelo de phishing observados representan una gama sorprendente. Los señuelos de solicitudes de propuesta (RFP) de construcción predominan, y la lista de víctimas incluye a 24 organizaciones de construcción y oficios, lo que sugiere una selección deliberada de ese sector o simplemente su efectividad en esa audiencia.

Táctica observada: señuelos de phishing eficaces

Abuso de la función “Customer Voice” de Microsoft Dynamics 365

Uno de los señuelos de phishing comenzó con el uso de un formulario “Customer Voice”, como se mencionó antes. Estos formularios son una función de Microsoft Dynamics 365 pensada para recopilar comentarios de clientes. Se identificaron por su URL, que comenzaba con customervoice.microsoft[.]com/Pages/ResponsePage.aspx?id= seguido del identificador único del formulario. El formulario mostraba una página de destino con la marca de SharePoint:

Figura 2: Ejemplo de un señuelo de phishing de Microsoft Dynamics 365 que lleva a SharePoint

Páginas sofisticadas de “descarga de archivos”

A partir de lo anterior, el enlace “Access SharePoint” llevaba a un sitio web de descarga de archivos convincente alojado en vercel[.]app. Se vieron otros ejemplos de esto alojados en amplifyapp[.]com. Este estilo de señuelo requiere que el usuario marque al menos un archivo y haga clic en “View Selected” para continuar.

Figura 3: Ejemplo de un señuelo de descarga de archivos

Al hacer clic en “View Selected”, el usuario llega a la página de phishing mediante código de dispositivo, como se muestra en la figura 3.

Abuso de la plataforma workers.dev de Cloudflare

Casi todos los sitios de phishing mediante código de dispositivo observados estaban alojados en una instancia de Cloudflare workers.dev. Esta plataforma permite a los desarrolladores ejecutar aplicaciones sin servidor en la plataforma de Cloudflare. Esto permite a los actores de amenazas evadir el filtrado de DNS y de contenido web, ya que Cloudflare es una plataforma confiable a nivel global. Los dominios workers.dev son efímeros y se generan sistemáticamente según el usuario que crea la instancia. Aparecen con este formato:

[lure-type]-[3char-id].[username]-[domain]-s-account.workers.dev/[tracking-hash]

• [lure-type] por lo general contenía los valores “adobe”, “docusign”, “index”, “onedrive”, “page” o “voicemail”
• [3char-id] es un valor alfanumérico aparentemente aleatorio
• [username]-[domain] representa una dirección de correo normalizada donde [email protected] se convertiría en user-domain-com
• [tracking-hash] variaba de formato entre un valor [16 character hex], un 32 character hex].[64 character hex]&ab=1, y ?email=(value)

Huntress reportó a Cloudflare todas las instancias de workers.dev observadas hasta el momento, y la mayoría, si no todas, ya han sido dadas de baja.

Abuso de servicios de terceros y sitios web comprometidos

En un esfuerzo por evadir las herramientas de seguridad de correo electrónico que pueden depender de la reputación de URL o dominio, los actores de amenazas utilizaron una variedad de servicios de terceros y sitios web comprometidos de diversas organizaciones. En muchos casos, las víctimas hacían clic a través de dos o tres capas para llegar a la etapa final del ataque. Ejemplos de servicios vistos en los ataques:

• wixsite[.].com - plataforma de alojamiento y creación web para el sitio de señuelo de phishing
• www.taskade[.]com - plataforma de creación de aplicaciones con IA para el sitio de señuelo de phishing
• app.usewhale[.]io - plataforma de creación de documentos con capacidad de IA para el sitio de señuelo de phishing
• r.brandreward[.]com - seguimiento/redirección de enlaces usado para ocultar el destino real del enlace
• 2nco[.[com - servicio de acortamiento de URL usado para ocultar el destino real del enlace
• track.tec35[.]com - seguimiento/redirección de enlaces usado para ocultar el destino real del enlace
• www.hits2babi[.]com - seguimiento/redirección de enlaces usado para ocultar el destino real del enlace
• appspot[.]com - App Engine de Google para el sitio de señuelo de phishing
• amplifyapp[.]com - AWS Amplify para el sitio de señuelo de phishing
• vercel[.]app - Vercel para el sitio de señuelo de phishing
• amazonaws[.]com - AWS S3 para el sitio de señuelo de phishing

Además del abuso de herramientas comerciales conocidas, hubo una gran cantidad de sitios web de organizaciones comprometidas que alojaban uno de los saltos en la cadena de ataque. La página maliciosa solía estar alojada fuera del sitio web principal, en una carpeta con un nombre muy genérico como /project/ o /voip/. Otras estaban alojadas desde un archivo .html en la raíz del dominio.

Análisis del user agent: el vestuario digital del atacante

Las cadenas de user agent (UA) presentadas durante los eventos de autenticación provenientes de Railway revelan un conjunto de UA deliberadamente seleccionado que imita poblaciones realistas de navegadores empresariales. El motor de reproducción rota entre ellos para evitar las reglas de detección de UA uniformes.

• El atacante investigó a su grupo demográfico objetivo. Las cadenas de compilación del sistema operativo (OS/10.0.26200 = Win11 24H2, OS/10.0.26100 = Win11 23H2, OS/10.0.22631 = Win11 22H2) reflejan versiones actuales reales de Windows, no valores desactualizados o sintéticos. Esto es investigación deliberada, no un comportamiento predeterminado de herramientas.
• El UA del iPhone es una oportunidad de detección. iPhone OS 18_7 combinado con Version/26.3 Nota: Version/26. iOS 26 es una versión futura que no existe a comienzos de 2026. Una regla de detección basada en iPhone OS 18 + Version/26 desde rangos de IP de proveedores de nube tendría alta fidelidad con muy pocos falsos positivos.
• BAV2ROPC es programático y está programado, no es humano. La programación dos veces al día visible en los eventos (11:00 a. m. y 8:00 p. m.) confirma que se trata de un script automatizado, no de un operador humano. Este es el mecanismo de persistencia de "configúralo y olvídate" para objetivos de alto valor.
• Linux Chrome puede ser indicativo de una filtración del sistema operativo del servidor. X11; Linux x86_64 en 15 eventos podría representar intercambios de tokens a nivel de API donde el contenedor de Railway no se molestó en configurar un UA falsificado y el entorno de ejecución real queda visible.

Escala y perfil de las víctimas

Sectores afectados

La respuesta de Huntress

Cuando Huntress detecta que los actores de amenazas usan nuevas tácticas que están funcionando a gran escala, actuamos. Para mitigar la amenaza para nuestros partners, Huntress implementó una Política de acceso condicional (CAP) en todos los inquilinos elegibles (es decir, inquilinos con Microsoft Entra ID P1 y valores de seguridad predeterminados deshabilitados) para impedir inicios de sesión desde toda la infraestructura propiedad de Railway, además de interrumpir la ruta de acceso del adversario desde el origen. Esto se logró creando una Ubicación con nombre que contiene las IP asociadas con Railway. Validamos que no se había detectado actividad legítima desde la infraestructura propiedad de Railway en los 14 días previos en toda nuestra base de clientes, e hicimos todo lo posible para garantizar que el impacto negativo fuera prácticamente nulo. Esta no fue una decisión tomada a la ligera, ni en el vacío. Se sometió a una revisión interna en nuestro SOC, producto, liderazgo y equipos de cara al cliente, con una consideración cuidadosa tanto del impacto en la seguridad como en las operaciones.

Lo interesante no es que hayamos sorprendido a un atacante escribiendo indicaciones en Railway en tiempo real; no fue así. Lo interesante es que las mismas funciones del producto diseñadas para ayudar a los desarrolladores legítimos a moverse más rápido también pueden ayudar a los adversarios a industrializar la infraestructura de phishing. Cuando una plataforma hace que la implementación, la solución de problemas y el desmantelamiento sean rápidos y de baja fricción, reduce la brecha entre una idea y un servicio de ataque activo. Esa es la verdadera preocupación: los flujos de trabajo asistidos por IA y basados en indicaciones no necesitan aparecer explícitamente en los registros para seguir cambiando la velocidad, la escala y la economía del abuso.

Cuando los atacantes explotan activamente una campaña de rápido movimiento como esta, deja de ser una discusión normal de gestión de cambios y se convierte en una decisión de respuesta de emergencia. Nuestro deber es proteger a los clientes, incluso cuando eso signifique actuar con rapidez y decisión frente a tácticas novedosas. Cuando los entornos de los clientes están en riesgo, seguiremos tomando las medidas necesarias para detener las amenazas activas.

Lo que estamos escuchando (opiniones de la comunidad)

Antes de publicar este blog, compartimos detalles generales sobre la campaña y las medidas de protección en Reddit. La conversación que siguió aportó muy buenos comentarios, y queremos abordar dos preocupaciones clave directamente.

Algunos clientes señalaron que habrían preferido una notificación o la opción de aceptar este cambio antes de aplicarlo. Es un comentario justo, y lo estamos tomando en serio. Durante una campaña activa con credenciales siendo recolectadas en tiempo real, esperar significa dejar a los clientes expuestos. En este caso, priorizamos detener la amenaza de inmediato. De cara al futuro, estamos trabajando en formas de dar a los clientes más visibilidad sobre estas decisiones, manteniendo nuestra capacidad de actuar rápidamente cuando las amenazas apuntan activamente a nuestra base de clientes.

Los clientes que cumplen con CMMC también plantearon preguntas importantes sobre cómo esta acción se alinea con los requisitos de cumplimiento. Huntress realiza consultas continuas con expertos en CMMC, quienes han verificado que esta acción está cubierta bajo la respuesta a incidentes como una SPA.

Recomendaciones de respuesta

Acciones inmediatas

• Buscar inicios de sesión desde IP de Railway. Ejecuta las consultas de Sentinel anteriores contra tus registros de inicio de sesión. Cualquier autenticación exitosa es un compromiso confirmado.
• Revoca todos los tokens de actualización de los usuarios afectados. Revoke-AzureADUserAllRefreshTokens o el portal de Entra ID. Sin embargo, esto NO revoca de inmediato los tokens de acceso de OAuth en curso, ya que estos expiran en ~1 hora a menos que CAE esté habilitado.
• Bloquea los bloques CIDR de Railway mediante Ubicaciones con nombre de Acceso condicional. Si no existen aplicaciones legítimas implementadas en Railway en tu entorno.

Fortalecimiento a mediano plazo

• Bloquea los flujos de autenticación por código de dispositivo en tu entorno de Microsoft 365 usando Acceso condicional. Restringe el flujo de código de dispositivo únicamente a las identidades específicas que necesitan este método.
• Exige un dispositivo que cumpla con las políticas para Exchange Online / SharePoint. La autenticación por código de dispositivo no puede continuar si el dispositivo no cumple con las políticas cuando se exigen dispositivos conformes.
• Habilita la evaluación continua de acceso (CAE). Reduce la latencia de revocación de tókenes de ~1 hora a minutos.
• Capacita a los usuarios finales específicamente sobre señuelos de código de dispositivo. Edúcalos en que ingresar códigos de dispositivo, incluso en el endpoint de autenticación legítimo de Microsoft, no es necesariamente seguro.

Conclusión

Railway.com ha reducido el costo de infraestructura y la complejidad operativa de las campañas de phishing mediante código de dispositivo a gran escala. Un servicio que le permite a un atacante desplegar un framework de ataque a identidades en contenedores en minutos, con reputación de IP limpia, TLS automático y sin verificación de identidad, es un multiplicador de fuerza considerable para cualquier actor de amenazas interesado en obtener una ganancia por compromiso de correo empresarial.

La diversidad de técnicas y tipos de señuelos en esta campaña, ya sea de un solo actor con un amplio conjunto de herramientas o de varios actores que comparten infraestructura común, señala el mismo desafío práctico para los defensores. No puedes bloquear esta campaña por dominio. No puedes bloquearla por tipo de señuelo. Sí puedes bloquearla por rango de IP, y puedes detectarla en la telemetría de autenticación. El ataque es visible en la capa de identidad aun cuando es invisible en cualquier otra capa.

Si tus inquilinos de Microsoft 365 no están cubiertos por una plataforma de detección y respuesta de identidad con visibilidad entre inquilinos, esta campaña ilustra exactamente lo que te estás perdiendo.

Consultas de detección

Microsoft Sentinel — búsqueda de inicios de sesión de Railway (interactiva):

SigninLogs

| where IPAddress startswith "162.220.234." or IPAddress startswith "162.220.232."

| where ResultType == 0

| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,

          AuthenticationRequirement, ConditionalAccessStatus

| order by TimeGenerated desc

Búsqueda de acceso programático a tókenes mediante BAV2ROPC desde Railway:

AADNonInteractiveUserSignInLogs

| where IPAddress startswith "162.220.232." or IPAddress startswith "162.220.234."

| where UserAgent contains "BAV2ROPC"

| project TimeGenerated, UserPrincipalName, ResourceDisplayName, IPAddress

Indicadores de compromiso (IOC)

Todos los IOC están desactivados. Elimina los corchetes antes de usarlos en reglas de bloqueo.

Bloques CIDR para bloqueo perimetral:

• 162.220.232[.]0/22
• 162.220.234[.]0/22
• 152.55.176.0/20
• 208.77.244.0/22
• 66.33.22.0/23
• 69.46.46.0/24
• 69.9.164.0/22
• 2607:99c0::/32

IOC de autenticación conductual