Aumentan las campañas de suplantación de identidad relacionadas con los códigos de dispositivo de OAuth mediante el kit de herramientas EvilTokens

4 de mayo de 2026

Por Rikesh Vekaria, Archa Archa, Hiwot Mendahun, Samantha Clarke y el equipo de investigación de amenazas de Mimecast

Resumen de la campaña

El equipo de investigación de amenazas de Mimecast ha detectado un aumento significativo de las campañas de phishing relacionadas con el código de dispositivos OAuth dirigidas a usuarios de Microsoft 365 en todas las regiones y sectores. Desde marzo de 2026, más de 50 000 campañas de correo electrónico malicioso han aprovechado el flujo legítimo de autorización de dispositivos OAuth 2.0 de Microsoft —un mecanismo diseñado originalmente para dispositivos sin teclado, como televisores inteligentes y equipos de IoT— con el fin de robar tokens de autenticación y comprometer cuentas en la nube.

Esta técnica se ha convertido rápidamente en el método de ataque preferido por los autores de amenazas, de forma similar a como los ataques de ClickFix dominaron el panorama de las amenazas el año pasado. La facilidad con la que se puede llevar a cabo este ataque se ha visto amplificada por la aparición de EvilTokens, un conjunto de herramientas de «phishing como servicio» (PhaaS) que se comercializa en Telegram y que automatiza toda la cadena de ataque. EvilTokens incorpora contenido de ingeniería social generado por IA, lo que permite incluso a los atacantes con pocos conocimientos llevar a cabo campañas convincentes de suplantación de marcas a gran escala.

Comprender el phishing mediante códigos de dispositivos

Los ataques de phishing tradicionales intentan sustraer credenciales mediante la presentación de páginas de inicio de sesión falsas que imitan servicios legítimos. El phishing mediante código de dispositivo supone una evolución fundamental: en lugar de suplantar la interfaz de inicio de sesión de Microsoft, los atacantes se aprovechan de la propia infraestructura de autenticación de Microsoft para obtener tokens de acceso reales y válidos. El flujo de autorización de dispositivos de OAuth 2.0 funciona de la siguiente manera en un uso legítimo:

1. Un dispositivo (como un televisor inteligente) genera un código de dispositivo y se lo muestra al usuario
2. El usuario accede a microsoft.com/devicelogin en un dispositivo distinto
3. El usuario introduce el código del dispositivo y se autentica con sus credenciales
4. Microsoft emite un token de acceso al dispositivo original, lo que le otorga acceso autorizado

En los ataques de phishing mediante código de dispositivo, los autores de las amenazas se aprovechan de este flujo de la siguiente manera:

1. Registro de una aplicación OAuth maliciosa en Microsoft Azure AD
2. Iniciar un proceso de autorización de dispositivos en su infraestructura de backend
3. Obtención de un código de dispositivo válido de los servidores de autorización de Microsoft
4. La presentación de este código a las víctimas a través de correos electrónicos de phishing y páginas falsas de marcas
5. Convencer a las víctimas de que visiten la página de inicio de sesión oficial de Microsoft para dispositivos e introduzcan el código
6. Capturar los tokens OAuth resultantes cuando la víctima completa la autenticación

Dado que las víctimas se autentican en la infraestructura original de Microsoft y los tokens emitidos son legítimos, esta técnica elude la autenticación multifactorial, supera todas las comprobaciones de reputación del dominio y burla los mecanismos tradicionales de detección de phishing. El ataque no se basa en la captura de credenciales, sino que se aprovecha de la confianza que los usuarios depositan en los flujos de trabajo habituales de la empresa para autorizar aplicaciones maliciosas.

El ecosistema de EvilTokens

Según un estudio de Sekoia, EvilTokens supone una importante innovación en el ámbito de los actores maliciosos: una plataforma de «phishing como servicio» totalmente automatizada que convierte en un producto comercial el abuso sofisticado del protocolo OAuth. Este conjunto de herramientas proporciona a los autores de amenazas:

• Ingeniería social basada en la inteligencia artificial: generación automatizada de correos electrónicos de phishing y páginas de destino convincentes que imitan marcas y procesos empresariales de confianza
• Infraestructura llave en mano: sistemas de backend preconfigurados que gestionan la generación de código para los dispositivos, el seguimiento de las sesiones de las víctimas y la recopilación de tokens
• Supervisión en tiempo real: interfaces de panel de control que muestran las campañas activas, las interacciones con las víctimas y las capturas de tokens realizadas con éxito
• Escalabilidad: Capacidad para lanzar miles de campañas de phishing simultáneas con unos conocimientos técnicos mínimos. Esta democratización de las técnicas de ataque avanzadas explica el crecimiento explosivo observado desde marzo de 2026. Mientras que antes el phishing mediante códigos de dispositivos requería conocimientos técnicos avanzados, EvilTokens permite a cualquier actor malicioso con conocimientos básicos sobre seguridad operativa llevar a cabo campañas de suplantación de cuentas a escala empresarial.

Variaciones de la campaña

Campaña de registro de dispositivos de Mimecast

Esta campaña, detectada por primera vez el 16 de abril, pone de manifiesto una tendencia preocupante: los autores de las amenazas han comenzado a suplantar el proceso de registro de dispositivos de Mimecast, aprovechando el flujo de trabajo de seguridad legítimo que utilizan los clientes para acceder a contenidos protegidos.

Flujo de registro de dispositivos Mimecast falso: Los destinatarios reciben correos electrónicos en los que se afirma que contienen documentos protegidos o enlaces que requieren el registro de un dispositivo Mimecast. Cuando las víctimas hacen clic en el enlace, acceden a una página que, a simple vista, es idéntica a la interfaz de registro de dispositivos de Mimecast.

1. Página inicial: Muestra la imagen de marca de Mimecast junto con instrucciones para acceder a "y obtener el código de autenticación."
2. Visualización del código: Tras hacer clic en el botón, la página se actualiza y muestra el código del dispositivo directamente en la página web
3. Acceso a documentos: En « "» aparece el botón «Ver documento» (" ), que, al hacer clic en él, redirige a microsoft.com/devicelogin
4. Solicitud de autenticación: La página auténtica de Microsoft solicita el código e indica a los usuarios que, en ", introduzcan el código que aparece en su aplicación o dispositivo para conceder permiso total a su cuenta."
5. Robo de tokens: tras la autenticación, el servidor del atacante captura los tokens de OAuth, mientras que las víctimas creen que han completado un proceso legítimo de registro del dispositivo.

Proceso legítimo de registro de dispositivos en Mimecast:

Comprender el proceso auténtico es fundamental para la formación de los usuarios y la detección de amenazas:

1. El usuario hace clic en un enlace reescrito por Mimecast que aparece en un correo electrónico y que requiere el registro del dispositivo, tras lo cual se le redirige a la página de registro de dispositivos de Mimecast.        
2. La página web solicita la dirección de correo electrónico del usuario, que se comprobará con la base de datos de clientes de Mimecast para confirmar que se trata de un usuario legítimo de Mimecast.
3. Tras hacer clic en « "» (Obtener código de inscripción del dispositivo),", la página web se actualiza para mostrar un campo de introducción del código de inscripción e informa al usuario de que el código se ha enviado a su dirección de correo electrónico. NOTA: el código NO aparece en la página web
 
4. El usuario recupera el código de su correo electrónico y lo introduce en el campo de entrada de la página web
5. Una vez validado correctamente, se redirige al usuario al contenido solicitado inicialmente.

La diferencia fundamental es que el proceso legítimo de registro de dispositivos de Mimecast nunca muestra los códigos de registro directamente en las páginas web. Los códigos se envían siempre por correo electrónico como canal de verificación secundario.

Esta suplantación de identidad resulta especialmente eficaz porque:

• Los usuarios esperan que se sigan los procedimientos de seguridad al acceder a contenidos protegidos
• El registro de dispositivos se presenta como un requisito de seguridad legítimo
• La fidelidad visual de las páginas falsas se asemeja mucho a la imagen de marca auténtica de Mimecast

Campaña de revisión de documentos de DocuSign

La variante más extendida de la campaña se basa en suplantar la identidad de la marca DocuSign, aprovechando el uso generalizado en el ámbito empresarial de los procesos de firma electrónica. Los destinatarios reciben correos electrónicos en los que se alega que es necesario revisar o firmar un documento, con asuntos del tipo:

• "DocuSign - Revisar documento"
• "Agreement_Review.pdf - Se requiere firma"
• "Urgente: contrato pendiente de su firma"

La eficacia de la campaña radica en el aprovechamiento de un proceso empresarial real: muchas organizaciones integran DocuSign con Microsoft 365 para la verificación de identidad, lo que hace que la solicitud de verificación parezca una gestión rutinaria en lugar de sospechosa.

Campaña de notificación de mensajes de voz de Microsoft Teams

Otra variante de la campaña aprovecha la omnipresencia de las notificaciones del buzón de voz de Microsoft en los entornos empresariales. A medida que las organizaciones recurren cada vez más a plataformas de comunicaciones unificadas, las alertas del buzón de voz se han convertido en comunicaciones habituales y previsibles que los empleados rara vez examinan con detenimiento. Los destinatarios reciben correos electrónicos diseñados para parecer notificaciones legítimas del buzón de voz de Microsoft, con asuntos como:

• "Tiene un nuevo mensaje de voz de [Nombre]"
• "Llamada perdida - Nuevo mensaje de buzón de voz"
• "Microsoft Teams: Nuevo mensaje de voz"
• "Notificación de mensaje de voz: se requiere una acción"

Análisis técnico: ofuscación y evasión

Esquema de cifrado multicapa

Las campañas recientes aplican medidas contra el análisis para impedir que los investigadores de seguridad y los sistemas automatizados examinen la infraestructura de phishing. El mecanismo principal de ofuscación utiliza el cifrado AES-GCM con descifrado en el lado del cliente.

Etapa 1: Carga útil inicial. Cuando las víctimas acceden por primera vez a una URL de phishing, reciben un documento HTML que contiene código JavaScript

Una pequeña función de carga de JavaScript descodifica las cadenas Base64 en matrices de bytes, importa la clave AES-GCM mediante la API Web Crypto y descifra el texto cifrado utilizando el IV facilitado.

Etapa 2: Sustitución dinámica del contenido. Una vez completado con éxito el descifrado, el script sustituye todo el documento HTML por el contenido descifrado:

Este enfoque garantiza que la página de phishing real —que contiene logotipos de marcas, texto de ingeniería social y elementos de formulario maliciosos— permanezca invisible para:

• Escáneres de seguridad para el correo electrónico que analizan los destinos de los enlaces
• Servicios de reputación de URL que rastrean y analizan páginas
• Investigadores de seguridad que realizan una evaluación inicial
• Recopilación automatizada de información sobre amenazas

Solo cuando JavaScript se ejecuta en un contexto completo del navegador se hace visible el contenido real de phishing. Las herramientas de análisis estático que examinan el código fuente HTML solo ven la carga útil cifrada y el script de carga.

Etapa 3: Coordinación del backend. La página de phishing descifrada se comunica con la infraestructura de backend controlada por el atacante para coordinar el flujo de código del dispositivo:

Inicio de la sesión:

Esta solicitud hace que el backend inicie un flujo legítimo de autorización de dispositivos mediante OAuth con Microsoft. La respuesta contiene:

• userCode: El código real del dispositivo obtenido de los servidores de autorización de Microsoft
• sessionId: Un identificador único para el seguimiento de la sesión de esta víctima

Consulta de estado:

La página de phishing realiza consultas continuas al servidor para determinar cuándo la víctima ha completado el proceso de autenticación en la plataforma de Microsoft. Cuando el backend cambia correctamente el código del dispositivo por tokens OAuth, responde con el estado: « "» y «" », lo que hace que la página de phishing muestre un mensaje de éxito y redirija al sitio web legítimo de la marca.

Infraestructura y alojamiento web

Las páginas de phishing suelen estar alojadas en:

• Depósitos de AWS S3: un servicio de almacenamiento en la nube fiable que ofrece alta disponibilidad y una infraestructura de confianza
• Servidores web comprometidos: dominios existentes con una reputación consolidada para eludir las listas de bloqueo
• Dominios de nuevo registro: dominios de baja reputación con variaciones de typosquatting de marcas legítimas

Los puntos de conexión de la API de backend que gestionan la generación de códigos de dispositivos y la captura de tokens operan en una infraestructura independiente, y suelen utilizar:

• Servidores privados virtuales (VPS) de proveedores que exigen una verificación de identidad mínima
• Direcciones IP con certificados TLS válidos de Let's Encrypt, que les confieren una falsa legitimidad

Esta separación entre las páginas de phishing visibles y la infraestructura de captura de tokens complica las labores de desmantelamiento y la atribución.

Indicadores de compromiso (IOC)

Campaña de DocuSign

Dominios de phishing:

• 00a7af15-a112-4457-86c2-5c56751f0f47-endpoint[.]com
• index-yfb.kpenza-htrenchless-com-s-account.workers[.]dev

Ejemplos de asuntos de correo electrónico:

• "DocuSign - Revisar documento"
• "Agreement_Review.pdf - Se requiere firma"
• "Urgente: contrato pendiente de su firma"
• "Documento pendiente de su firma electrónica"

Campaña de buzón de voz de Microsoft

Dominios de phishing:

• voice-mail-auth-office-com.saxeco7653.workers[.]dev
• auth-login-office-com.saxeco7653.workers[.]dev
• delicate-poetry-debc.dporozok.workers[.]dev

Ejemplos de asuntos de correo electrónico:

• "Notificación de mensaje de voz: se requiere una acción"
• "Llamada perdida - Nuevo mensaje de buzón de voz"
• "Tiene un nuevo mensaje de voz de [Nombre]"

Campaña de inscripción de dispositivos de Mimecast

Dominios de phishing:

• sso-nodeconnect[.]icu/

Ejemplos de asuntos de correo electrónico:

• "Ver documento"
• "Agreement_Review.pdf - Se requiere firma"

Destinatarios

Ámbito geográfico: Mundial — todas las regiones

Sector vertical: Multisectorial; resulta especialmente eficaz frente a organizaciones que utilizan DocuSign, Microsoft o Mimecast

Recomendaciones

Formación en concienciación sobre seguridad para usuarios

• Informe a los empleados sobre las características específicas de estas campañas
• Los usuarios no deben introducir nunca códigos de dispositivos que procedan de correos electrónicos no solicitados, aunque la página de inicio de sesión de Microsoft parezca legítima. Los procesos auténticos de registro de dispositivos de Mimecast y otros servicios siguen unos patrones específicos: los códigos se envían por correo electrónico, no se muestran en páginas web y nunca requieren autenticación en la página de inicio de sesión de dispositivos de Microsoft.
• Revise los consentimientos de la aplicación OAuth. Las organizaciones deben revisar los consentimientos existentes para aplicaciones de terceros en todos sus inquilinos de Microsoft 365, identificando y revocando aquellas aplicaciones con nombres sospechosos, fechas de autorización recientes o editores desconocidos.

Detección proactiva de amenazas

• Busque en los registros de recepción de correos electrónicos utilizando los indicadores de amenaza (IOC) que figuran en la lista

El phishing de códigos de dispositivo supone un reto fundamental para la autenticación basada en la nube: el ataque aprovecha una funcionalidad legítima del diseño de OAuth 2.0, y no una vulnerabilidad que pueda corregirse. Dado que los kits de herramientas de «phishing como servicio», como EvilTokens, siguen democratizando las técnicas sofisticadas, las organizaciones deben desarrollar sus defensas más allá de los controles perimetrales tradicionales. Microsoft ha introducido políticas de autenticación basadas en el riesgo y funciones de gobernanza de aplicaciones, pero para lograr una protección óptima es necesaria una defensa en profundidad: controles técnicos que restrinjan la autorización OAuth, formación de los usuarios para que sepan reconocer el uso indebido de los códigos de los dispositivos y operaciones de seguridad que detecten rápidamente los indicadores de compromiso posterior. El auge del phishing mediante códigos de dispositivos pone de manifiesto que los modelos de autenticación basados en la confianza, diseñados para facilitar la vida al usuario, también crean oportunidades para la ingeniería social a una escala sin precedentes.