Los investigadores de ciberseguridad están llamando la atención sobre una campaña activa de phishing de códigos de dispositivos dirigida a identidades de Microsoft 365 en más de 340 organizaciones en EE. UU., Canadá, Australia, Nueva Zelanda y Alemania.

La actividad, según Huntress, fue visto por primera vez el 19 de febrero de 2026, y desde entonces los casos posteriores han aparecido a un ritmo acelerado. En particular, la campaña aprovecha las redirecciones de Cloudflare Workers con sesiones capturadas redirigidas a una infraestructura alojada en una oferta de plataforma como servicio (PaaS) llamada Railway, convirtiéndola efectivamente en un motor de recolección de credenciales.

La construcción, las organizaciones sin fines de lucro, el sector inmobiliario, la manufactura, los servicios financieros, la atención médica, el sector legal y el gobierno son algunos de los sectores destacados a los que se dirige la campaña.

«Lo que también hace que esta campaña sea inusual no son sólo las técnicas de phishing del código del dispositivo involucradas, sino la variedad de técnicas observadas», dijo la compañía. «Las ofertas de construcción, la generación de códigos de páginas de destino, la suplantación de DocuSign, las notificaciones de correo de voz y el abuso de las páginas de Microsoft Forms están afectando al mismo grupo de víctimas a través de la misma infraestructura IP de Railway.com».

El phishing de código de dispositivo se refiere a una técnica que explota el Flujo de autorización de dispositivos OAuth para otorgar al atacante tokens de acceso persistentes, que luego pueden usarse para tomar el control de las cuentas de las víctimas. Lo importante de este método de ataque es que los tokens siguen siendo válidos incluso después de que se restablezca la contraseña de la cuenta.

A un alto nivel, el ataque funciona de la siguiente manera –

• El actor de amenazas solicita un código de dispositivo al proveedor de identidad (por ejemplo, Microsoft Entra ID) a través de la API de código de dispositivo legítimo.
• El servicio responde con un código de dispositivo.
• El actor de amenazas crea un correo electrónico persuasivo y lo envía a la víctima, instándola a visitar una página de inicio de sesión («microsoft[.]com/devicelogin») e ingrese el código del dispositivo.
• Después de que la víctima ingresa el código proporcionado, junto con sus credenciales y el código de autenticación de dos factores (2FA), el servicio crea un token de acceso y un token de actualización para el usuario.

«Una vez que el usuario ha sido víctima del phishing, su autenticación genera un conjunto de tokens que ahora residen en el punto final de la API del token OAuth y se pueden recuperar proporcionando el código de dispositivo correcto», explicó Huntress. «El atacante, por supuesto, conoce el código del dispositivo porque fue generado por la solicitud cURL inicial a la API de inicio de sesión del código del dispositivo».

«Y aunque ese código es inútil por sí solo, una vez que se ha engañado a la víctima para que se autentique, los tokens resultantes ahora pertenecen a cualquiera que sepa qué código de dispositivo se utilizó en la solicitud original».

El uso de phishing de código de dispositivo fue observado por primera vez por Microsoft y Volexity en febrero de 2025, con oleadas posteriores documentadas por Amazon Threat Intelligence y Proofpoint. A estos ataques se les han atribuido múltiples grupos alineados con Rusia, identificados como Storm-2372, APT29, UTA0304, UTA0307 y UNK_AcademicFlare.

La técnica es insidiosa, sobre todo porque aprovecha la infraestructura legítima de Microsoft para realizar el flujo de autenticación del código del dispositivo, sin dar así a los usuarios motivos para sospechar que algo podría estar mal.

En la campaña detectada por Huntress, el abuso de autenticación se origina en un pequeño grupo de direcciones IP de Railway.com, y tres de ellas representan aproximadamente el 84% de los eventos observados.

• 162.220.234[.]41
• 162.220.234[.]66
• 162.220.232[.]57
• 162.220.232[.]99
• 162.220.232[.]235

El punto de partida del ataque es un correo electrónico de phishing que envuelve URL maliciosas dentro de archivos legítimos. servicios de redireccionamiento de proveedores de seguridad de Cisco, Trend Micro y Mimecast para evitar los filtros de spam y activar una cadena de redireccionamiento de múltiples saltos que presenta una combinación de sitios comprometidos, Cloudflare Workers y Vercel como intermediarios antes de llevar a la víctima al destino final.

«Los sitios de aterrizaje observados solicitan a la víctima que proceda al punto final de autenticación del código del dispositivo legítimo de Microsoft e ingrese un código proporcionado para leer algunos archivos», dijo Huntress. «El código se representa directamente en la página cuando llega la víctima».

«Esta es una iteración interesante de la táctica, ya que, normalmente, el adversario debe producir y luego proporcionar el código a la víctima. Al representar el código directamente en la página, probablemente mediante alguna automatización de generación de código, la víctima recibe inmediatamente el código y el pretexto para el ataque».

La página de inicio también incluye un mensaje «Continuar con Microsoft» que, al hacer clic, muestra una ventana emergente que muestra el punto final de autenticación legítimo de Microsoft («microsoft[.]com/devicelogin»).

Casi todos los sitios de phishing de códigos de dispositivos se han alojado en trabajadores de Cloudflare.[.]ejemplo de desarrollo, que ilustra cómo los actores de amenazas están utilizando como arma la confianza asociada con el servicio en entornos empresariales para eludir los filtros de contenido web. Para combatir la amenaza, se recomienda a los usuarios escanear los registros de inicio de sesión para buscar inicios de sesión de IP ferroviaria, revocar todos los tokens de actualización para los usuarios afectados y bloquear los intentos de autenticación desde la infraestructura ferroviaria si es posible.

Desde entonces, Huntress ha atribuido el ataque a Railway a una nueva plataforma de phishing como servicio (PhaaS) conocida como EvilTokens, que hizo su debut el mes pasado en Telegram. Además de las herramientas publicitarias para enviar correos electrónicos de phishing y evitar los filtros de spam, el panel de EvilTokens proporciona a los clientes enlaces de redireccionamiento abiertos a dominios vulnerables para ocultar los enlaces de phishing.

«Además del rápido crecimiento en la funcionalidad de la herramienta, el equipo de EvilTokens ha creado un equipo de soporte completo 24 horas al día, 7 días a la semana y un canal de comentarios de soporte», dijo la compañía. «También tienen comentarios de los clientes».

La divulgación se produce cuando la Unidad 42 de Palo Alto Networks también prevenido de una campaña similar de phishing de código de dispositivo, destacando el uso por parte del ataque de técnicas anti-bot y anti-análisis para pasar desapercibidas, mientras filtra cookies del navegador al actor de la amenaza al cargar la página. La primera observación de la campaña se remonta al 18 de febrero de 2026.

La página de phishing «deshabilita la funcionalidad de hacer clic con el botón derecho, la selección de texto y las operaciones de arrastre», dijo la compañía, y agregó que «bloquea los atajos de teclado para las herramientas de desarrollo (F12, Ctrl+Shift+I/C/J) y la visualización de fuentes (Ctrl+U)» y «detecta herramientas de desarrollo activas mediante la utilización de una heurística del tamaño de la ventana, que posteriormente inicia un bucle de depuración infinito».

Google está probando una nueva función de seguridad como parte del Modo de protección avanzada de Android (AAPM) que evita que ciertos tipos de aplicaciones utilicen la API de servicios de accesibilidad.

El cambio, incorporado en Android 17 Beta 2, fue reportado por primera vez por Android Authority la semana pasada.

AAPM fue introducido por Google en Android 16, lanzado el año pasado. Cuando activadohace que el dispositivo entre en un estado de mayor seguridad para protegerse contra ataques cibernéticos sofisticados. Al igual que el modo de bloqueo de Apple, la función de inclusión prioriza la seguridad a costa de una funcionalidad y usabilidad disminuidas para minimizar la superficie de ataque.

Algunos de los configuraciones centrales incluyen bloquear la instalación de aplicaciones de fuentes desconocidas, restringir la señalización de datos USB y exigir el escaneo de Google Play Protect.

«Los desarrolladores pueden integrar esta función utilizando el Administrador de protección avanzada API para detectar el estado del modo, lo que permite que las aplicaciones adopten automáticamente una postura de seguridad reforzada o restrinjan la funcionalidad de alto riesgo cuando un usuario ha optado por participar», Google anotado en su documentación que describe las características de Android 17.

La última restricción agregada a la configuración de seguridad de un toque tiene como objetivo evitar que las aplicaciones que no están clasificadas como herramientas de accesibilidad puedan aprovechar las funciones del sistema operativo. API de servicios de accesibilidad. Herramientas de accesibilidad verificadas, identificadas por el isAccessibilityTool=»true» indicadorestán exentos de esta regla.

Según Google, sólo los lectores de pantalla, los sistemas de entrada basados ​​en interruptores, las herramientas de entrada basadas en voz y los programas de acceso basados ​​en Braille están designados como herramientas de accesibilidad. El software antivirus, las herramientas de automatización, los asistentes, las aplicaciones de monitoreo, los limpiadores, los administradores de contraseñas y los lanzadores no entran en esta categoría.

Si bien AccessibilityService tiene sus casos de uso legítimos, como ayudar a usuarios con discapacidades a usar dispositivos y aplicaciones Android, en los últimos años los malos actores han abusado ampliamente de la API para robar datos confidenciales de dispositivos Android comprometidos.

Con el último cambio, a cualquier aplicación que no sea de accesibilidad y que ya tenga el permiso se le revocarán automáticamente sus privilegios cuando AAPM esté activo. Los usuarios tampoco podrán otorgar permisos a las aplicaciones para la API a menos que la configuración esté desactivada.

Android 17 también viene con un nuevo selector de contactos que permite a los desarrolladores de aplicaciones especificar solo los campos a los que desean acceder desde la lista de contactos de un usuario (por ejemplo, números de teléfono o direcciones de correo electrónico) o permitir a los usuarios seleccionar ciertos contactos con una aplicación de terceros.

«Esto le otorga a su aplicación acceso de lectura solo a los datos seleccionados, lo que garantiza un control granular y al mismo tiempo proporciona una experiencia de usuario consistente con capacidades integradas de búsqueda, cambio de perfil y selección múltiple sin tener que crear o mantener la interfaz de usuario», dijo Google.

Las organizaciones suelen implementar la autenticación multifactor (MFA) y suponen que las contraseñas robadas ya no son suficientes para acceder a los sistemas. En entornos Windows, esa suposición suele ser errónea. Los atacantes siguen comprometiendo las redes todos los días utilizando credenciales válidas. La cuestión no es la ayuda macrofinanciera en sí, sino la cobertura.

Se aplica a través de un proveedor de identidad (IdP) como Microsoft Entra ID, Okta o Google Workspace. MFA funciona bien para aplicaciones en la nube e inicios de sesión federados. Pero muchos inicios de sesión de Windows dependen únicamente de rutas de autenticación de Active Directory (AD) que nunca activan mensajes de MFA. Para reducir el riesgo basado en credenciales, los equipos de seguridad deben comprender dónde ocurre la autenticación de Windows fuera de su pila de identidades.

Siete rutas de autenticación de Windows en las que confían los atacantes

1. Inicio de sesión interactivo de Windows (local o unido a un dominio)

Cuando un usuario inicia sesión directamente en una estación de trabajo o servidor de Windows, la autenticación normalmente la maneja AD (a través de Kerberos o NTLM), no mediante un IdP en la nube.

En entornos híbridosincluso si Entra ID aplica MFA para aplicaciones en la nube, los controladores de dominio locales validan los inicios de sesión tradicionales de Windows en sistemas unidos a un dominio. A menos que se implemente Windows Hello for Business, tarjetas inteligentes u otro mecanismo MFA integrado, no hay ningún factor adicional en ese flujo.

Si un atacante obtiene la contraseña de un usuario (o hash NTLM), puede autenticarse en una máquina unida a un dominio sin activar las políticas MFA que protegen las aplicaciones de software como servicio o el inicio de sesión único federado. Desde la perspectiva del controlador de dominio, esta es una solicitud de autenticación estándar.

Herramientas como Acceso seguro a Specops son clave para limitar el riesgo de abuso de credenciales en estos escenarios. Al aplicar MFA para el inicio de sesión de Windows, así como para las conexiones VPN y de Protocolo de escritorio remoto (RDP), esta herramienta dificulta que los atacantes obtengan acceso no autorizado a su red. Esto se extiende incluso a los inicios de sesión fuera de línea, que están protegidos con autenticación con contraseña de un solo uso.

Acceso seguro a Specops

2. Acceso RDP directo que evita el acceso condicional

RDP es uno de los métodos de acceso más específicos en entornos Windows. Incluso cuando RDP no está expuesto a Internet, los atacantes suelen llegar a través de movimiento lateral después del compromiso inicial. Una sesión RDP directa a un servidor no pasa automáticamente por los controles MFA basados ​​en la nube, lo que significa que el inicio de sesión puede depender únicamente de la credencial AD subyacente.

3. Autenticación NTLM

NTLM es un protocolo de autenticación heredado que, a pesar de estar en desuso a favor del protocolo Kerberos, más seguro, todavía existe por razones de compatibilidad. También es un vector de ataque común porque admite técnicas como pass-the-hash.

En los ataques pass-the-hash, el atacante no necesita la contraseña en texto plano; en su lugar, utilizan el hash NTLM para autenticarse. Ministerio de Asuntos Exteriores no ayuda si el sistema acepta el hash como prueba de identidad.

NTLM también puede aparecer en flujos de autenticación internos que las organizaciones tal vez no monitoreen activamente; sólo un incidente o una auditoría lo revelará a los equipos de seguridad.

4. Abuso de tickets de Kerberos

Kerberos es el protocolo de autenticación principal para AD. En lugar de robar contraseñas directamente, Los atacantes roban tickets de Kerberos. desde la memoria o generar tickets falsificados después de comprometer cuentas privilegiadas. Esto permite técnicas como:

• Pase el boleto
• Boleto Dorado
• Boleto de Plata

Estos ataques permiten el acceso a largo plazo y el movimiento lateral y también reducen la necesidad de inicios de sesión repetidos, lo que reduce las posibilidades de detección. Estos ataques pueden persistir incluso después de restablecer la contraseña si el compromiso subyacente no se aborda por completo.

5. Cuentas de administrador local y reutilización de credenciales

Las organizaciones todavía dependen de cuentas de administrador local para tareas de soporte y recuperación del sistema. Si las contraseñas de administrador local se reutilizan en todos los puntos finales, los atacantes pueden escalar un compromiso hacia un acceso amplio.

Las cuentas de administrador local generalmente se autentican directamente en el punto final, evitando por completo los controles de MFA. No se aplican las políticas de acceso condicional de Entra ID. Ésta es una de las razones por las que el volcado de credenciales sigue siendo tan eficaz en entornos Windows.

6. Autenticación y movimiento lateral del Bloque de mensajes del servidor (SMB)

SMB se utiliza para compartir archivos y acceder remotamente a recursos de Windows. También es una de las rutas de movimiento lateral más confiables una vez que un atacante tiene credenciales válidas. Los atacantes suelen utilizar SMB para acceder a recursos compartidos administrativos como C$ o para interactuar con sistemas de forma remota utilizando credenciales válidas.

Si la autenticación SMB se trata como tráfico interno, rara vez se aplica MFA en esta capa. Si el atacante tiene credenciales válidas, puede usar SMB para moverse rápidamente entre sistemas.

7. Cuentas de servicio que nunca activan MFA

cuentas de servicio existen para ejecutar tareas programadas, aplicaciones, integraciones y servicios del sistema. Suelen tener credenciales estables, amplios permisos y una larga vida útil.

En muchas organizaciones, las contraseñas de las cuentas de servicio no caducan y rara vez se controlan. También son difíciles de proteger con MFA porque la autenticación está automatizada. Con frecuencia, estas cuentas se utilizan en aplicaciones heredadas que no pueden admitir controles de autenticación modernos.

Esta es una de las razones por las que los atacantes apuntan credenciales de soporte técnico y acceso de administrador de endpoints en las primeras etapas de una intrusión.

Cómo cerrar las brechas de autenticación de Windows

Los equipos de seguridad deben tratar la autenticación de Windows como su propia superficie de seguridad. Hay varias medidas prácticas que los equipos de seguridad pueden tomar para reducir la exposición:

1. Aplicar políticas de contraseñas más seguras en AD

Se debe aplicar una política de contraseñas segura frases de contraseña más largas de 15 o más caracteres. Las frases de contraseña son más fáciles de recordar para los usuarios y más difíciles de descifrar para los atacantes. Las políticas sólidas también deberían impedir la reutilización de contraseñas y bloquear patrones débiles que los atacantes puedan adivinar.

2. Bloquear continuamente las contraseñas comprometidas

El robo de credenciales no siempre es el resultado de ataques de fuerza bruta. Miles de millones de contraseñas ya están disponibles en conjuntos de datos violados para que los atacantes las reutilicen. ataques de credenciales. El bloqueo de contraseñas comprometidas en el momento de su creación reduce la posibilidad de que los usuarios establezcan credenciales que los atacantes ya tienen.

3. Reducir la exposición a protocolos de autenticación heredados

Siempre que sea posible, las organizaciones deben restringir o eliminar la autenticación NTLM. Los equipos de seguridad deben fijarse el objetivo de comprender dónde existe NTLM, reducirlo cuando sea posible y reforzar los controles cuando no se pueda eliminar.

4. Audite las cuentas de servicio y reduzca la pérdida de privilegios

Trate las cuentas de servicio como identidades de alto riesgo. Las organizaciones deben inventariarlos, reducir privilegios innecesariosrotar credenciales y eliminar cuentas que ya no sean necesarias. Si una cuenta de servicio tiene permisos a nivel de dominio, la organización debe asumir que será el objetivo.

Cómo puede ayudar Specops

Las políticas de contraseñas sólidas y las comprobaciones proactivas de credenciales comprometidas conocidas son dos de las formas más efectivas de reducir el riesgo de ataques basados ​​en credenciales. Política de contraseñas de Specops ayuda aplicando controles de contraseña flexibles que van más allá de lo que está disponible de forma nativa en Microsoft.

Política de contraseñas de Specops

Es Protección de contraseña violada La función verifica continuamente las contraseñas de Active Directory con una base de datos de más de 5,4 mil millones de credenciales expuestas, avisándole rápidamente si se descubre que la contraseña de un usuario está en riesgo. Si está interesado en ver cómo Specops puede ayudar a su organización, hable con un experto o reservar una demostración para ver nuestras soluciones en acción.

Microsoft advirtió el lunes sobre campañas de phishing que emplean correos electrónicos de phishing y OAuth Mecanismos de redireccionamiento de URL para eludir las defensas de phishing convencionales implementadas en el correo electrónico y los navegadores.

La actividad, dijo la compañía, está dirigida a organizaciones gubernamentales y del sector público con el objetivo final de redirigir a las víctimas a la infraestructura controlada por los atacantes sin robar sus tokens. Describió los ataques de phishing como una amenaza basada en la identidad que aprovecha el comportamiento estándar y por diseño de OAuth en lugar de explotar las vulnerabilidades del software o robar credenciales.

«OAuth incluye una característica legítima que permite a los proveedores de identidad redirigir a los usuarios a una página de destino específica bajo ciertas condiciones, generalmente en escenarios de error u otros flujos definidos», dijo el equipo de investigación de seguridad de Microsoft Defender. dicho.

«Los atacantes pueden abusar de esta funcionalidad nativa creando URL con proveedores de identidad populares, como Entra ID o Google Workspace, que utilizan parámetros manipulados o aplicaciones maliciosas asociadas para redirigir a los usuarios a páginas de destino controladas por el atacante. Esta técnica permite la creación de URL que parecen benignas pero que en última instancia conducen a destinos maliciosos».

El punto de partida del ataque es una aplicación maliciosa creada por el actor de la amenaza en un inquilino bajo su control. La aplicación está configurada con una URL de redireccionamiento que apunta a un dominio fraudulento que aloja malware. Luego, los atacantes distribuyen un enlace de phishing OAuth que indica a los destinatarios que se autentiquen en la aplicación maliciosa utilizando un alcance intencionalmente no válido.

El resultado de esta redirección es que los usuarios descargan e infectan inadvertidamente sus propios dispositivos con malware. Las cargas útiles maliciosas se distribuyen en forma de archivos ZIP que, cuando se descomprimen, dan como resultado la ejecución de PowerShell, la carga lateral de DLL y la actividad previa al rescate o de uso del teclado, dijo Microsoft.

El archivo ZIP contiene un acceso directo de Windows (LNK) que ejecuta un comando de PowerShell tan pronto como se abre. La carga útil de PowerShell se utiliza para realizar un reconocimiento del host mediante la ejecución de comandos de descubrimiento. El archivo LNK extrae del archivo ZIP un instalador MSI, que luego suelta un documento señuelo para engañar a la víctima, mientras que una DLL maliciosa («crashhandler.dll») se descarga utilizando el binario legítimo «steam_monitor.exe».

La DLL procede a descifrar otro archivo llamado «crashlog.dat» y ejecuta la carga útil final en la memoria, lo que le permite establecer una conexión saliente a un servidor externo de comando y control (C2).

Microsoft dijo que los correos electrónicos utilizan solicitudes de firma electrónica, grabaciones de Teams, temas de seguridad social, financieros y políticos como señuelos para engañar a los usuarios para que hagan clic en el enlace. Se dice que los correos electrónicos se enviaron a través de herramientas de envío masivo y soluciones personalizadas desarrolladas en Python y Node.js. Los enlaces se incluyen directamente en el cuerpo del correo electrónico o se colocan dentro de un documento PDF.

«Para aumentar la credibilidad, los actores pasaron la dirección de correo electrónico de destino a través del parámetro de estado utilizando varias técnicas de codificación, lo que permitió que se completara automáticamente en la página de phishing», dijo Microsoft. «El parámetro de estado está destinado a generarse aleatoriamente y usarse para correlacionar los valores de solicitud y respuesta, pero en estos casos se reutilizó para llevar direcciones de correo electrónico codificadas».

Si bien se ha descubierto que algunas de las campañas aprovechan la técnica para distribuir malware, otras envían a los usuarios a páginas alojadas en marcos de phishing como EvilProxy, que actúan como un kit de adversario en el medio (AitM) para interceptar credenciales y cookies de sesión.

Desde entonces, Microsoft eliminó varias aplicaciones OAuth maliciosas que fueron identificadas como parte de la investigación. Se recomienda a las organizaciones que limiten el consentimiento del usuario, revisen periódicamente los permisos de las aplicaciones y eliminen las aplicaciones no utilizadas o con privilegios excesivos.