Phishing de dispositivos: El auge del robo de tokens OAuth 2.0

En el panorama de la ciberseguridad actual, donde las defensas tradicionales han alcanzado un nivel de madurez considerable, los atacantes han desplazado su foco hacia los puntos más vulnerables: las capas de autorización y la confianza intrínseca del usuario. Al 12 de abril de 2026, la comunidad de seguridad ha reportado una alarmante escalada en los ataques de phishing de dispositivos, una táctica sofisticada que está burlando incluso las implementaciones más robustas de autenticación multifactor (MFA).

Los datos son contundentes: se ha registrado un aumento masivo de 37.5 veces en la detección de páginas diseñadas para explotar el flujo de “Device Authorization Grant” de OAuth 2.0. Esta técnica, que permite el secuestro de sesiones sin necesidad de robar contraseñas ni interceptar códigos MFA en tiempo real, representa una amenaza existencial para las organizaciones que dependen de servicios basados en la nube como Microsoft 365 y Google Workspace.

La anatomía del engaño: ¿Cómo funciona el phishing de dispositivos?

El phishing de dispositivos no intenta comprometer el proceso de inicio de sesión estándar; en su lugar, abusa de una funcionalidad legítima de OAuth 2.0 diseñada para dispositivos con capacidades de entrada limitadas, como televisores inteligentes, impresoras o dispositivos IoT. El protocolo, definido técnicamente en el RFC 8628, permite a estos dispositivos obtener acceso a recursos sin necesidad de un teclado completo o una pantalla de navegador para la autenticación.

En un ataque típico, el flujo sigue una lógica perversa pero efectiva:

1. Iniciación del ataque: El atacante inicia una solicitud de autorización de dispositivo utilizando una aplicación maliciosa controlada por él mismo. El servidor de autorización devuelve un código de dispositivo y una URL de verificación (por ejemplo, microsoft.com/devicelogin).
2. Ingeniería social: El atacante envía al usuario una comunicación (email, mensaje, documento señuelo) instándolo a completar una “verificación de seguridad” o un acceso urgente a un archivo. El mensaje incluye el código del dispositivo proporcionado por el servidor legítimo.
3. La trampa final: La víctima accede a la URL oficial, ingresa el código y completa su autenticación y MFA como lo haría normalmente. Al hacerlo, el usuario está, sin saberlo, autorizando el dispositivo del atacante.
4. Secuestro de sesión: Una vez completada la autenticación por parte del usuario, el atacante, que ha estado sondeando el endpoint del token en segundo plano, recibe inmediatamente el acceso y los tokens de actualización. Con esto, obtiene acceso persistente y programático a la cuenta de la víctima.

Democratización del cibercrimen mediante kits de Phishing-as-a-Service (PhaaS)

La proliferación de esta técnica no es un accidente, sino el resultado de la industrialización de los ataques a través de plataformas de phishing de dispositivos. El surgimiento de kits especializados como “EvilTokens”, “VENOM” y “SHAREFILE” ha reducido drásticamente la barrera de entrada para los ciberdelincuentes.

Estos kits operan bajo el modelo de “Phishing-as-a-Service”, proporcionando a delincuentes con habilidades técnicas mínimas una infraestructura completa que incluye:

• Lures automatizados: Generación de plantillas de correo electrónico convincentes utilizando modelos de lenguaje (LLM) para temas como solicitudes de documentos, facturas, avisos de correo de voz o invitaciones a reuniones.
• Bypassing de seguridad: Integración de técnicas de evasión de bots, uso de servicios de red (PaaS) legítimos para ocultar la infraestructura de mando y control (C2) y el uso de técnicas como “browser-in-the-browser” para maximizar la legitimidad visual.
• Gestión post-compromiso: Funcionalidades integradas para filtrar correos electrónicos, buscar palabras clave financieras o realizar movimientos laterales dentro de la organización, todo gestionado a menudo desde bots de Telegram.

Por qué el MFA ya no es suficiente

Uno de los aspectos más críticos y frustrantes para los defensores es que el phishing de dispositivos ocurre completamente fuera del alcance de las protecciones MFA estándar. Debido a que la víctima, un usuario legítimo, completa el desafío de autenticación en la URL oficial del proveedor de identidad, el sistema de seguridad percibe la interacción como una solicitud autorizada y legítima.

Más grave aún, una vez que el atacante obtiene los tokens de acceso y actualización, estos permanecen válidos incluso si la víctima cambia su contraseña inmediatamente después del incidente. La persistencia del ataque reside en la sesión autorizada, no en las credenciales estáticas. Esto otorga al atacante un acceso duradero, permitiéndole exfiltrar datos, realizar fraudes de tipo Business Email Compromise (BEC) y mantener un punto de apoyo persistente en el entorno de la nube de la víctima.

Estrategias de defensa: Cómo blindar su infraestructura

Dado que este tipo de ataque no explota una vulnerabilidad de software, sino que abusa de una configuración legítima del protocolo OAuth, la defensa requiere un enfoque proactivo basado en políticas y visibilidad:

1. Restricción del flujo de autorización de dispositivos

La medida más efectiva es deshabilitar el flujo de “Device Authorization Grant” a través de las políticas de Acceso Condicional (Conditional Access) en plataformas como Microsoft Entra ID. Muchas organizaciones no tienen una necesidad legítima de este flujo para la mayoría de sus usuarios. Si el flujo es necesario por requerimientos técnicos, debe limitarse mediante una lista de permitidos (allow-list) que restrinja el uso a usuarios, ubicaciones, dispositivos o rangos de IP específicos.

2. Monitoreo de anomalías en logs de autenticación

Las organizaciones deben implementar una monitorización estricta de sus registros de inicio de sesión. Aunque la autenticación en sí parezca normal, a menudo hay anomalías sutiles en los registros (como inicios de sesión inusuales desde IPs que no coinciden con la ubicación conocida del usuario o patrones de dispositivos no estándar) que, al ser correlacionadas, pueden indicar un compromiso de tokens.

3. Educación y concienciación orientada a tokens

Es vital actualizar los programas de concienciación de seguridad. Los usuarios deben aprender que no solo las contraseñas son valiosas; los códigos de dispositivos y las pantallas de consentimiento de aplicaciones son igualmente críticos. Se debe instruir al personal a desconfiar de cualquier solicitud que pida ingresar códigos fuera de un flujo de trabajo que ellos mismos hayan iniciado intencionalmente.

4. Gestión del ciclo de vida de tokens

Implementar políticas de revocación de sesiones cuando se detecten comportamientos sospechosos es esencial. Además, el uso de herramientas de visibilidad de SaaS (CASB) puede ayudar a identificar aplicaciones OAuth instaladas por usuarios finales que pueden representar una amenaza, permitiendo la revocación inmediata de permisos excesivos.

Conclusión: Un nuevo paradigma de identidad

La explosión de los ataques de phishing de dispositivos este año marca un punto de inflexión en la ciberseguridad. Estamos viendo la transición definitiva de un modelo centrado en la protección del “acceso” (contraseñas y MFA) a un modelo centrado en la protección de la “autorización” (tokens y consentimientos). Mientras los atacantes sigan democratizando el uso de kits automatizados, la única salida para las organizaciones es asumir un nivel de desconfianza zero-trust sobre cualquier flujo de autorización, por muy legítimo que parezca el origen del mismo. El año 2026 nos ha dejado claro que el perímetro de seguridad ya no reside en el firewall, sino en cada token de sesión activo dentro de nuestras nubes corporativas.