Cuando la mayoría de la gente piensa en "phishing", suele pensar en usuarios engañados para que revelen sus credenciales o descarguen malware.
Uno de los métodos de ataque de más rápido crecimiento no hace ninguna de las dos cosas. En cambio, se engaña al usuario objetivo para que autorice un cliente controlado por el atacante. Estos ataques abusan de la confianza del usuario en los flujos de autorización basados en OAuth que se utilizan para otorgar a una aplicación acceso a los datos de otra aplicación.
A principios de 2026, el phishing mediante códigos de dispositivos está aumentando drásticamente. Este ataque explota vulnerabilidades conocidas en la concesión de autenticación mediante código de dispositivo, un método en el que los usuarios autorizan a un cliente en un dispositivo iniciando sesión en otro dispositivo. Esta concesión tenía como objetivo facilitar el inicio de sesión en dispositivos con "limitaciones de entrada", donde resulta complicado introducir una contraseña. Pero también vemos que se utiliza para muchos otros casos de uso, incluidos casos de uso relacionados con la fuerza laboral. Los ciberdelincuentes se han apropiado de este flujo con un éxito sorprendente para engañar a los usuarios y conseguir que autoricen sus aplicaciones maliciosas.
Los investigadores de amenazas de Push Security han observado un aumento de 15 veces en los ataques de phishing mediante código de dispositivo dirigidos a usuarios de Microsoft 365 desde principios de año. Investigadores de Okta Threat Intelligence y Proofpoint han observado indicios de que algunos ciberdelincuentes han pasado de realizar ataques de phishing dirigidos a AitM a llevar a cabo ataques de phishing dirigidos al código de los dispositivos.
El phishing mediante códigos de dispositivos ha cobrado gran protagonismo debido a que los ataques se han industrializado a través de operaciones de "phishing como servicio", como EvilTokens.
EvilTokens proporciona a los ciberdelincuentes con poca experiencia la infraestructura, los señuelos, las herramientas para evadir las defensas y los sistemas de alerta y mensajería necesarios para lanzar ataques de phishing mediante código de dispositivo contra clientes de Microsoft a gran escala y con un mínimo esfuerzo por parte del usuario.
En este artículo, explicaremos para qué se utiliza el flujo de código del dispositivo, cómo se explota y las condiciones que hacen que esta forma de ataque sea «phishing con dinamita».
La concesión de autorización del código del dispositivo
El phishing mediante código de dispositivo abusa de un flujo de autorización OAuth 2.0 específico diseñado para dispositivos con limitaciones de entrada: la concesión de autorización de código de dispositivo OAuth 2.0 (RFC8628).
Un dispositivo con limitaciones de entrada podría ser una aplicación de streaming en tu televisor, aplicaciones que controlan tus electrodomésticos o incluso los sistemas de entretenimiento de tu coche. En cualquier sistema donde resulte engorroso escribir una contraseña larga y segura, el flujo de código del dispositivo permite al usuario iniciar sesión fuera de banda en un dispositivo móvil o portátil y autorizar (consentir) al cliente para acceder a los datos de su cuenta.
Si utilizamos la idea de una aplicación de vídeo en streaming para ilustrarlo:
Un usuario quiere iniciar sesión en una aplicación de streaming en su televisor.
El navegador del teléfono inteligente del usuario es el dispositivo de autorización fuera de banda.
Un servidor de autorización gestiona el acceso a los servidores back-end del servicio de streaming.
En un flujo de autorización de código de dispositivo legítimo:
- Un usuario intenta iniciar sesión en su cuenta de servicio de streaming desde un televisor.
- Una aplicación en el televisor solicita acceso a un servidor de autorización enviando un ID de cliente en una solicitud a un punto final específico. El servidor de autorización devuelve un código de dispositivo, un código de usuario y una URI de verificación.
- La aplicación indica al usuario que visite la URI de verificación, ya sea presentándola como una dirección web o un código QR en la pantalla del televisor, y también le proporciona un código de usuario de ocho caracteres para que lo introduzca en su teléfono inteligente para autorizar la aplicación.
- Al acceder a la dirección web proporcionada, se le solicita al usuario que introduzca el código de usuario y que verifique su identidad. Opcionalmente, se le puede solicitar al usuario que dé su consentimiento para otorgar a la aplicación acceso a los recursos alojados en el servidor (datos de la cuenta en el servicio de streaming).
- En segundo plano, la aplicación consulta continuamente al servidor de autorización mediante solicitudes que incluyen el ID del cliente y el código del dispositivo. En esencia, la aplicación cliente le pregunta al servidor de autorización si el usuario la ha autorizado. Una vez que el usuario da su consentimiento, el servidor de autorización responde a una solicitud de sondeo con un token de acceso. Posteriormente, ese token de acceso se puede utilizar para realizar llamadas a la API del servicio de streaming.
Figura 1: flujo de autorización del código del dispositivo OAuth 2.0
Todas estas interacciones ocurren en cuestión de segundos. El flujo resulta práctico y fomenta el uso de métodos de autenticación más robustos (especialmente en comparación con las contraseñas cortas y los códigos OTP que se introducen en dispositivos con limitaciones de entrada).
Desafortunadamente, el flujo del código del dispositivo también es vulnerable a abusos en ataques de ingeniería social.
Suplantación de identidad mediante código de dispositivo
En un ataque de phishing mediante código de dispositivo, por el contrario, el atacante controla la aplicación cliente:
- El atacante registra una nueva aplicación en un tenant controlado por el atacante, o bien utiliza un ID de cliente que el servidor de autorización del usuario objetivo reconoce como confiable. Las solicitudes al servidor de autorización se consideran válidas porque el flujo de autorización del código del dispositivo no requiere que la aplicación cliente esté autenticada ni siquiera registrada en el servidor de autorización. No hay nada que impida que un atacante abuse de un id. de cliente conocido, y los id. de cliente no suelen estar protegidos como secretos.
- El atacante proporciona el código de usuario y la URI de verificación a un usuario objetivo a través de un sitio de phishing o por teléfono mediante una llamada de ingeniería social. Si el usuario autenticado visita esta dirección web e introduce el código de usuario, le estará otorgando efectivamente a la aplicación del atacante acceso a sus recursos. El atacante simplemente necesita consultar el servidor de autorización y recibirá un token de acceso como respuesta.
Figura 2. Suplantación de identidad mediante código de dispositivo
Suplantación de identidad con dinamita
En los ataques que hemos observado hasta la fecha, los atacantes han mostrado interés en suplantar la identidad de clientes que:
Están autorizados por un servidor de autorización común,
Se asignan a todos los usuarios por defecto en los nuevos arrendatarios (incluidos los arrendatarios gratuitos/de prueba).
Disponer de un ID de cliente conocido o común que sea el mismo en todos los inquilinos
Lamentablemente, las aplicaciones de Microsoft cumplen con este criterio en varios aspectos:
Un usuario de EvilTokens puede iniciar un flujo de código de dispositivo enviando una solicitud POST al mismo punto final común que es aplicable a todos los clientes de Microsoft (common/oauth2/devicecode).
Esta solicitud POST debe incluir un ID de cliente válido. Los ID de cliente de las aplicaciones propias que están disponibles de forma predeterminada en los inquilinos de Microsoft se listan y tabulan de forma rutinaria, y las relaciones inusuales entre ellas se discuten abiertamente. Los investigadores de amenazas señalaron que, por defecto, EvilTokens abusa del ID de cliente conocido de Microsoft Office, pero otros investigadores han observado el abuso de otras aplicaciones de Microsoft.
Esto significa que una sola herramienta puede servir para atacar a prácticamente cualquier cliente de Microsoft en el planeta, independientemente de si se trata de un adolescente que autoriza una aplicación en su Xbox o de un gerente de TI que autoriza una aplicación para una empresa de la lista Fortune 500.
La ventaja para un atacante de que todos los usuarios se autentiquen a través de un único dominio (login.microsoft.com) es que resulta muy fácil atacar a gran escala. En un ataque de phishing mediante código de dispositivo dirigido a clientes de Microsoft, los atacantes dirigen a todos los usuarios objetivo a un punto final común (login.microsoft.com/common/oauth2/v2.0/devicecode). En ese punto final, cualquier usuario de los servicios de Microsoft es un usuario válido, especialmente cuando se utilizan ID de cliente que probablemente se asignen a muchos o a todos los usuarios.
Por el contrario, la plataforma Okta se diseñó en torno al principio de que cada organización tiene su propio servidor o servidores de autorización independientes y descentralizados. No existe el concepto de un punto final “común” donde usuarios de diferentes organizaciones verifiquen su identidad en una misma ubicación.
Esto significa que, si bien los clientes creados en Okta no son inmunes a los ataques de phishing mediante código de dispositivo, la arquitectura de Okta obliga a los atacantes a realizar una investigación mucho más exhaustiva sobre cualquier objetivo potencial.
Recursos
Obtener la historia completa
Para obtener más información sobre el enfoque de Okta para protegerse contra el abuso del flujo de código del dispositivo, los contactos de seguridad de los clientes de Okta pueden iniciar sesión para acceder a una versión extendida de este artículo en security.okta.com.
Recomendaciones
- Permitir el uso del flujo de código del dispositivo únicamente por excepción. Los clientes de Microsoft deberían implementar una política de acceso condicional que bloquee todo acceso mediante el flujo de código del dispositivo.
En los casos en que el flujo de código del dispositivo se considere el más apropiado para una aplicación cliente creada en Okta:
incluya en la lista permitida el rango de IP desde el cual se puede emitir un token para un cliente determinado. Esto se puede configurar para cualquier cliente en Aplicaciones > General > IP de red. Cuando está configurado, las solicitudes de un token de acceso provenientes de un cliente controlado por un atacante que se encuentre fuera del rango de direcciones IP permitidas serán denegadas.
Supervisar las solicitudes anómalas de tokens y las concesiones anómalas de usuarios.
