Cuando no basta con verificar la URL: ataque de Device Code Phishing mediante un recurso de Microsoft

Una de las recomendaciones más habituales para protegerse del phishing consiste en verificar el dominio del sitio que solicita credenciales. Por lo general, un dominio ilegítimo salta a la vista, porque difiere del oficial en al menos algunos caracteres. Pero hace poco identificamos un esquema en el que el atacante induce a la víctima a introducir sus datos en el sitio web legítimo de una empresa reconocida. Se trata de Microsoft Identity Platform, que admite una especificación del protocolo OAuth 2.0 llamada Device Authorization Grant.

Esta especificación se diseñó para facilitar el acceso a usuarios de televisores inteligentes, dispositivos IoT, impresoras y otros dispositivos con capacidades limitadas de entrada, y que no cuentan con navegador ni teclado propiamente dichos. Su tarea es autorizar dicho dispositivo para acceder a los recursos del usuario desde un smartphone o una PC. Para ello, el usuario debe introducir un código de un solo uso en una página de autorización. Microsoft Identity Platform genera ese código junto con el enlace donde debe introducirse, en respuesta a una solicitud enviada a https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, por lo cual el escenario de ataque que abusa de este mecanismo se denomina Device Code Phishing.

En este artículo explicamos el funcionamiento de la especificación Device Authorization Grant (también conocida como Device authorization grant flow o Device code flow), analizamos ataques reales que explotan esta tecnología y describimos cómo protegerse del Device Code Phishing.

Etapas principales de Device Authorization Grant

1. Solicitud del código de autorización
   Cuando el usuario inicia una aplicación en el dispositivo cliente (por ejemplo, una app de streaming en un televisor inteligente), esta detecta la ausencia de autorización y envía una solicitud POST a https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode con los parámetros client_id (identificador único de la aplicación registrada en Microsoft Entra ID, antes Azure AD) y scope (lista de permisos de acceso solicitados). El servidor devuelve a la aplicación los parámetros device_code (un código secreto de uso interno), user_code (el código corto que verá el usuario), verification_uri (enlace al que debe acceder), expires_in (vigencia del código) e interval (frecuencia de consultas al servidor).
2. Visualización del código al usuario
   El dispositivo muestra al usuario los parámetros user_code y verification_uri, e indica que debe hacer la autorización desde otro dispositivo. Por ejemplo, el televisor inteligente muestra el código y el enlace para que el usuario lo introduzca desde un smartphone, y verification_uri puede presentarse también como código QR.
3. Introducción del código y confirmación del acceso
   Con la cámara del smartphone (en el caso del código QR) o escribiendo la dirección a mano, el usuario abre la verification_uri (por ejemplo, https://microsoft.com/devicelogin) e introduce el user_code.
4. Consulta al servidor
   El dispositivo (el televisor inteligente) comienza a enviar solicitudes al servidor para conocer el estado de la autorización (si el usuario confirmó el acceso), mediante solicitudes POST al endpoint https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. La solicitud incluye el parámetro grant_type con el valor urn:ietf:params:oauth:grant-type:device_code, que indica el uso del método Device Authorization Grant. Este parámetro le indica al servidor de autorización qué método se emplea para obtener los tokens de acceso. El servidor espera hasta que el usuario introduzca el user_code en el otro dispositivo y confirme el acceso a sus recursos o datos. Mientras el usuario no confirme esto, el servidor devuelve authorization_pending (autorización pendiente) o slow_down (reducir frecuencia de consulta).
5. Obtención de los tokens de acceso
   Una vez que el usuario confirma el acceso a la aplicación, el servidor le entrega el access_token (clave de acceso a los datos), el refresh_token (clave para renovar el acceso) y el id_token (token con información del usuario: nombre, correo electrónico y otros datos), además de varios parámetros de servicio adicionales.
6. Renovación automática del acceso
   El dispositivo, en este caso nuestro televisor inteligente, usa el refresh_token para renovar el access_token sin requerir una nueva autorización del usuario. Cuando vence el access_token vigente (en alrededor de una hora), el dispositivo envía una solicitud con el parámetro refresh_token al endpoint /token y recibe un nuevo access_token y un nuevo refresh_token, para que el usuario no tenga que autenticarse de nuevo.

Este esquema resulta práctico para dispositivos sin interfaz de entrada de texto o con capacidades limitadas. Sin embargo, los atacantes pueden abusar de él para obtener acceso a la cuenta del usuario, así como mantener ese acceso durante un período prolongado mediante el refresh_token. Analicemos este vector de ataque con un ejemplo.

Análisis del ataque de Device Code Phishing

Correo de phishing

En una campaña de phishing que observamos desde principios de abril hasta mediados de mayo de 2026, el correo se presentaba como una notificación de un estudio jurídico. El mensaje tenía adjunto un archivo PDF protegido con contraseña.

Tras abrir el PDF e introducir la contraseña, el usuario veía una página con un listado de documentos, pero debía hacer clic en un enlace para visualizarlos.

PDF con enlace malicioso

Si prestamos atención al enlace propuesto, en lugar del recurso de phishing habitual aparece una dirección legítima de Microsoft. Sin embargo, los parámetros del enlace incluyen una redirección al recurso de phishing.

El enlace del documento no conduce al sitio de Microsoft, sino que redirige al recurso de phishing

El enlace redirigía al usuario a una página de phishing que simulaba ser un portal jurídico.

Página de phishing

Llama la atención que esta página presentara varios captchas, posiblemente para impedir el acceso de rastreadores automatizados. Después de pasarlos, el usuario llegaba a otra página, en la que se le ofrecía copiar el código de un solo uso. Este código es user_code, que la aplicación en el servidor o lado de los atacantes obtuvo al solicitar https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode que describimos más arriba.

Código de un solo uso

Al hacer clic en el código mostrado, se lo copiaba al portapapeles y el sistema remitía al usuario a la página de autorización legítima de Microsoft (verification_uri), donde se le pedía introducir el código obtenido.

Página oficial de Microsoft

Si el usuario introducía el código, se iniciaba el proceso de Device Authorization Grant descrito. La víctima, sin sospechar nada, pasaba la autenticación multifactor (MFA) completa en la página oficial de Microsoft. Al finalizar este proceso, el atacante obtenía el access_token, el refresh_token y el id_token, lo que le permitía, por ejemplo, leer y enviar correos desde la cuenta de la víctima, además de acceder a sus archivos de OneDrive y a sus mensajes de Teams.

Adaptación del método de ataque

La campaña de phishing descrita no tuvo gran alcance y duró poco más de un mes. Sin embargo, los atacantes siguen utilizando este método hasta el día de hoy, adaptándolo a regiones específicas. Detectamos ataques de Device Code Phishing con pequeñas modificaciones, dirigidos, por ejemplo, a usuarios de Brasil.

Phishing al estilo brasileño

 
Este correo no incluía un PDF adjunto. En su lugar, contenía un enlace al recurso legítimo cacoo.com (plataforma de diagramación de la empresa Nulab), que, como se describió en el esquema anterior, remitía al usuario a un sitio de phishing.

El enlace proxy conduce al recurso legítimo Cacoo.com con redirección al sitio de phishing

 
Al hacer clic en el enlace, el usuario llegaba a la página, ya conocida, que solicitaba un código de un solo uso.

Página del código

Luego, la víctima veía de nuevo la página oficial de Microsoft y pasaba por el proceso de autorización mediante Device Authorization Grant.

Página de Microsoft para introducir el código

Cómo protegerse del ataque de Device Code Phishing

Como demuestra nuestra investigación, para acceder a datos confidenciales los atacantes no siempre dependen del robo de credenciales mediante malware: también pueden abusar de herramientas legítimas. Por eso, los usuarios deben estar atentos no solo a sitios sospechosos, sino también a páginas oficiales como las de Microsoft o Cacoo.com.

Recomendaciones para los usuarios

• Si usted no inició una sesión en un dispositivo mediante Microsoft Device Authorization Grant, no confirme la autorización.
• Nunca introduzca códigos de autorización recibidos en correos o mensajes inesperados, aunque el enlace conduzca al sitio oficial de Microsoft.
• Los atacantes utilizan enlaces a dominios legítimos, e insertan la dirección del recurso malicioso en los parámetros de redirección de la URL (redirect_uri, return_url, next, tras el signo “?”). Antes de hacer clic, pase el cursor sobre el enlace y revise tanto el dominio principal como los parámetros de redirección sospechosos. Después de seguir el enlace, verifique que la URL final coincida con el recurso esperado. Este es el mínimo indispensable antes de ingresar sus credenciales.

A las organizaciones, les recomendamos evaluar si es necesario habilitar Device Code Flow en el entorno corporativo. Conviene deshabilitar este escenario mediante políticas de Conditional Access en Microsoft Entra ID si el negocio no lo utiliza. También conviene monitorear los eventos DeviceCodeSignIn, el estado de cumplimiento de dispositivos (device compliance) y los inicios de sesión anómalos desde ubicaciones inusuales.

Las soluciones avanzadas de correo electrónico aportan protección adicional contra los ataques Device Code Phishing y garantizan la seguridad de la correspondencia corporativa y personal.