Phishing mediante códigos de dispositivo: la nueva cara del BEC en Microsoft 365

El phishing mediante códigos de dispositivo se ha convertido en una de las técnicas más peligrosas para comprometer cuentas corporativas en Microsoft 365 y otros servicios en la nube. No estamos ante el típico correo cutre con una web falsa que pide la contraseña, sino ante campañas muy refinadas que abusan de flujos de autenticación legítimos, tokens OAuth válidos y de la confianza que los usuarios depositan en portales como el de Microsoft.

En las últimas semanas, diferentes investigaciones de fabricantes como Barracuda Networks y el propio Microsoft han sacado a la luz campañas masivas que explotan el flujo de autenticación por código de dispositivo (device code flow) para saltarse MFA, mantener sesiones persistentes y operar durante largo tiempo dentro del correo, los archivos y la identidad de las empresas sin levantar sospechas claras. Vamos a desmenuzar cómo funciona este ataque, por qué está creciendo tan rápido y qué puede hacer una organización realista para defenderse.

Qué es el phishing mediante códigos de dispositivo y por qué es tan peligroso

El llamado device code phishing se apoya en un flujo OAuth 2.0 totalmente legítimo, diseñado originalmente para dispositivos con poca capacidad de interacción, como televisores, impresoras, terminales IoT o equipos sin navegador completo. En este modelo, el dispositivo muestra un código que el usuario debe introducir en otra pantalla o navegador (normalmente en una página de Microsoft) para autorizar el acceso.

La idea original es cómoda: separar el lugar donde se inicia la sesión del lugar donde el usuario la autoriza. El problema llega cuando un atacante inicia por su cuenta ese flujo, genera un código de dispositivo real y convence a la víctima para que lo escriba en el portal legítimo de Microsoft, pensando que está verificando su identidad o accediendo a un recurso confiable.

Investigaciones recientes de Barracuda Networks han detectado más de 7 millones de intentos de ataque con esta técnica en apenas cuatro semanas, lo que muestra que ya no estamos ante algo marginal. Se trata de campañas industriales, altamente automatizadas, que muchas veces se ofrecen bajo el modelo PhaaS (phishing-as-a-service), bajando la barrera de entrada para atacantes con poca experiencia técnica.

Microsoft, por su parte, ha documentado una campaña de gran escala que combinaba IA y automatización del flujo de device code y explotación de tokens para exfiltrar correo, mantener persistencia en los buzones y realizar reconocimiento en el entorno Microsoft 365 a través de Microsoft Graph. En la práctica, se trata de una evolución clara de los ataques BEC (Business Email Compromise), pero apoyada en flujos OAuth reales en lugar de simples robos de contraseña.

Cómo funciona el ataque de device code phishing paso a paso

El mecanismo del ataque es directo, pero extremadamente efectivo porque aprovecha componentes legítimos del ecosistema Microsoft y enlaces que no son, en sí mismos, maliciosos. A grandes rasgos, la secuencia es la siguiente.

Primero, el atacante realiza selección y validación del objetivo. Se centra en usuarios con valor financiero u operativo: personal de finanzas, directivos, compras, responsables de proyectos críticos, etc. Microsoft ha descrito que, antes del phishing real, los delincuentes suelen hacer reconocimiento previo para validar cuentas activas y entender la estructura de la organización.

Después llega el envío del señuelo. La víctima recibe un correo, un PDF, un HTML o una URL con una excusa creíble: un documento supuestamente compartido, una firma pendiente, una factura, una solicitud urgente o un aviso administrativo. Se está viendo cada vez más el uso de IA generativa para pulir el lenguaje, adaptar el tono al sector y evitar los clásicos errores que delatan un phishing mediocre.

En muchos casos el usuario no aterriza directamente en una web obviamente falsa. Los atacantes utilizan páginas de transición, redirecciones encadenadas e incluso servicios cloud legítimos (almacenamiento, formularios, sitios temporales) para mezclarse con el tráfico normal. Esa infraestructura efímera complica mucho los bloqueos basados solo en reputación o listas negras tradicionales.

Cuando la víctima hace clic en el señuelo, el atacante pone en marcha la generación dinámica del código de dispositivo. En lugar de enviar un código ya creado (que se podría quedar obsoleto o caducar), el sistema automático lanza el flujo OAuth en tiempo real y pide a Microsoft un nuevo device code justo en ese momento, reduciendo la ventana de caducidad y aumentando la tasa de éxito.

Llega la parte crítica: la víctima introduce el código en el portal legítimo de Microsoft. El correo o el documento le indican que debe ir a una dirección oficial de Microsoft, introducir el código y, en muchos casos, completar MFA como si se tratase de un proceso habitual de verificación. El dominio es real, el candado del navegador está ahí y el aspecto de la página es totalmente legítimo, así que el usuario baja la guardia.

Cuando el usuario completa el proceso, Microsoft emite tokens OAuth válidos (access tokens y, en muchos casos, refresh tokens). Esos tokens se asocian a la sesión iniciada por el atacante, no a un dispositivo de la víctima. A partir de aquí, el delincuente puede acceder a correo, archivos y otras aplicaciones vinculadas a Azure AD / Entra ID como si fuera el usuario, sin necesidad de conocer la contraseña.

Una de las claves de este ataque es que el atacante obtiene un refresh token que le permite mantener la sesión a largo plazo, incluso si la contraseña del usuario cambia más tarde. Eso posibilita un acceso continuado a buzones de correo en la nube, identidades corporativas y aplicaciones SaaS, eludiendo muchas de las señales típicas de compromiso que dependen de cambios de credencial.

Impacto en Microsoft 365, Entra ID y ataques BEC

La gravedad para una empresa que se apoya en Microsoft 365 es evidente: el atacante obtiene acceso aparentemente legítimo a servicios críticos como Exchange Online, OneDrive, Teams, SharePoint, aplicaciones internas federadas y otros servicios SaaS integrados con Entra ID.

En las campañas analizadas, Microsoft ha observado que, tras obtener los tokens, los atacantes realizan reconocimiento a través de Microsoft Graph, analizan buzones, listas de distribución, estructura organizativa y permisos, y después pasan a crear reglas maliciosas en los buzones (inbox rules) para reenviar, ocultar o clasificar correos de forma que el usuario afectado no vea ciertas comunicaciones.

Este patrón encaja perfectamente con ataques BEC avanzados, donde el objetivo final suele ser el fraude económico, el cambio de cuentas bancarias para pagos, el robo de información sensible de clientes o la manipulación de cadenas de aprobación. Como el acceso se realiza con tokens válidos emitidos por Microsoft, las actividades se mezclan con el tráfico normal y no siempre saltan las alarmas más básicas.

Además, el abuso de device code flow permite al atacante evitar algunos requisitos de registro de dispositivos, como el alta formal en Entra ID o Entra Hybrid joined, y saltarse ciertos controles que exigen equipos gestionados o unidos al dominio. Desde el punto de vista de la empresa, puede llegar a parecer que el usuario está accediendo «desde un dispositivo autorizado», cuando en realidad quien opera es la infraestructura del atacante.

Aquí entra en juego otro factor clave: no todas las formas de MFA son iguales. CISA lleva tiempo insistiendo en que, aunque cualquier MFA es mejor que nada, existen diferencias importantes entre factores débiles (OTP por SMS, códigos de apps sin vinculación de origen, notificaciones push sin contexto) y mecanismos realmente resistentes al phishing como FIDO/WebAuthn y passkeys. El device code phishing demuestra que basta con convencer al usuario para que apruebe una sesión iniciada por el atacante, aunque esa aprobación implique MFA.

Industrialización del ataque y modelo phishing-as-a-service (PhaaS)

Una de las razones por las que este tipo de ataques se está disparando es que ya no hace falta que cada delincuente monte toda la infraestructura desde cero. Plataformas de phishing-as-a-service (PhaaS) ofrecen kits y paneles listos para usar que automatizan el proceso y lo ponen al alcance de actores con relativamente poca experiencia técnica.

Barracuda Networks señala, por ejemplo, el kit Evil Tokens, orientado precisamente a explotar flujos de device code y gestionar de forma centralizada la generación de códigos, la recogida de tokens y su explotación posterior. Estas plataformas integran también plantillas de correos, manejo de listas de víctimas, automatización de redirecciones y paneles de seguimiento para monitorizar qué cuentas se han comprometido.

Según Saravanan Mohankumar, responsable del equipo de análisis de amenazas de Barracuda, el phishing mediante códigos de dispositivo se ha industrializado dentro del modelo PhaaS, lo que lo convierte en una amenaza altamente escalable. En otras palabras, no se trata de un experimento de laboratorio, sino de un modelo de negocio criminal consolidado y en crecimiento.

La automatización va más allá del envío de correos: algunos actores utilizan IA generativa para personalizar mensajes, traducirlos a múltiples idiomas, ajustar el tono a la cultura de cada país e incluso para crear variaciones continuas de los señuelos que dificulten la detección basada en firmas. A esto se suma el uso de infraestructuras en la nube de vida muy corta, lo que complica la tarea de los equipos de seguridad que dependen solo de listas de bloqueo estáticas.

En paralelo, se ve un aumento general de otros vectores de phishing sofisticados, como el quishing (phishing mediante códigos QR) y el smishing (phishing por SMS y mensajería). Todos ellos comparten el mismo objetivo: esquivar las defensas tradicionales centradas en URL claras dentro del cuerpo del correo y explotar nuevos canales de entrega más difíciles de analizar.

Por qué este ataque evita tantos controles tradicionales

El éxito del device code phishing se explica, en gran parte, porque aprovecha enlaces totalmente legítimos y no necesita páginas falsas. La víctima acaba en una URL oficial de Microsoft, introduce un código auténtico y, en muchos casos, completa correctamente su MFA. Desde su punto de vista, no ha hecho nada raro.

Esto dificulta mucho la labor de los filtros de correo electrónico clásicos, que suelen basarse en analizar reputación de dominios, contenidos sospechosos o detección de URLs maliciosas. En este caso, el enlace final es de confianza y el peligro está en el contexto del código de dispositivo, no en la página en sí.

Otro elemento crítico es que el ataque puede eludir MFA y determinadas políticas de acceso condicional, porque es el propio usuario quien autoriza la sesión del atacante. Las defensas basadas solo en “tengo MFA activo” o “uso Microsoft 365, así que estoy más seguro por defecto” no bastan frente a este modelo.

Conviene también remarcar qué cosas, por sí solas, no bloquean este ataque de forma fiable: no es suficiente con tener antivirus actualizado, revisar únicamente contraseñas, fiarse ciegamente del dominio final porque sea legítimo o pensar que por usar Microsoft 365 el problema desaparece. El dispositivo del atacante puede mantenerse autorizado a través de un refresh token incluso si se fuerza un cambio de contraseña posterior.

En muchos incidentes reales, las empresas acaban detectando el problema por síntomas secundarios: accesos anómalos en logs de OAuth, actividad poco habitual en Microsoft Graph, reglas extrañas en buzones de Exchange Online, uso de tokens desde ubicaciones no habituales o usuarios que comentan haber “verificado algo de Microsoft” sin recordar haber introducido sus credenciales completas.

Señales de alerta y exposición en una empresa

Muchas organizaciones no van a ver un aviso literal de “device code phishing” en sus paneles de seguridad. Lo que suele aparecer es un conjunto de indicios, que conviene saber interpretar para adelantarse a un compromiso grave.

Entre las señales a vigilar están los accesos inusuales asociados a OAuth o a flujos de autenticación menos habituales, especialmente si provienen de ubicaciones geográficas o rangos de IP que no encajan con el patrón normal de la empresa. En entornos monitorizados, estos eventos pueden correlacionarse con detecciones de riesgo de inicio de sesión en Entra ID.

Otro síntoma típico es la actividad anómala en Exchange Online: reglas de bandeja de entrada recién creadas o modificadas sin justificación, reenvíos externos no autorizados, filtros que mueven a carpetas ocultas los correos relacionados con facturación, bancos o proveedores clave, y cambios silenciosos en parámetros del buzón.

También hay que estar atentos a usos de tokens desde infraestructuras poco habituales, uso reiterado de sesiones desde ubicaciones que no encajan con el teletrabajo declarado, exportaciones masivas de correo o datos desde la nube, y comportamientos incoherentes con el historial del usuario (por ejemplo, accesos nocturnos desde otra región).

Si la organización no cuenta con buena visibilidad sobre tokens, sesiones, actividad de Graph y reglas de Exchange, resulta fácil que el atacante permanezca activo durante semanas. De ahí que muchas empresas opten por apoyarse en servicios especializados de seguridad Microsoft 365, auditoría de Microsoft 365 o evaluación de IAM y postura cloud para revisar esta exposición con más profundidad.

Medidas de defensa: identidad, correo y usuario

La respuesta a este problema pasa por reforzar varios frentes al mismo tiempo: seguridad de correo electrónico, protección de identidad, monitorización continua de actividad sospechosa y una concienciación de usuario mucho más específica que la clásica charla de “no hagas clic en enlaces raros”.

En el plano de correo, fabricantes como Barracuda recomiendan filtrado avanzado capaz de detectar campañas masivas, incluso cuando los enlaces finales sean legítimos. Esto implica modelos que entienden el contexto del mensaje, patrones de envío, reputación del remitente y técnicas como adjuntos HTML o PDFs con enlaces ocultos que sirven de trampolín hacia el flujo de device code.

Desde la perspectiva de identidad, es crucial reforzar Entra ID con políticas de riesgo de inicio de sesión, acceso condicional basado en contexto, respuesta automática a inicios de sesión sospechosos y mecanismos para revocar sesiones o tokens cuando se detecte posible abuso de flujos OAuth. Esto incluye revisar quién puede usar device code flow y en qué aplicaciones está realmente justificado.

La monitorización continua tiene que ir más allá del simple “inicio de sesión correcto/incorrecto”. Es necesario vigilar actividad en Microsoft Graph, cambios en reglas de Exchange Online, creación de reenvíos externos y uso anómalo de tokens. Microsoft Defender XDR, Defender for Office 365 y Entra ID Protection ofrecen capacidades de detección específicas y opciones de hunting para este tipo de patrones.

Por último, hay un componente humano ineludible: la formación de usuarios debe incluir este patrón concreto de engaño. No basta con decir “no pongas tu contraseña en sitios raros”; hay que explicar que tampoco deben introducir códigos de Microsoft ni aprobar sesiones si la petición viene de un correo, documento o mensaje que no haya sido validado por vías corporativas.

El papel del MFA resistente al phishing y las passkeys

En este escenario, la recomendación de CISA y de múltiples expertos es clara: avanzar hacia métodos de autenticación resistentes al phishing, en particular aquellos basados en FIDO/WebAuthn, passkeys y llaves de seguridad físicas o integradas en dispositivos.

Las passkeys no son solo una forma más cómoda de iniciar sesión; representan un cambio de modelo frente a credenciales reutilizables y códigos fácilmente manipulables. Cuando la autenticación está ligada criptográficamente al origen (dominio) y al dispositivo del usuario, el margen para que un atacante convenza a la víctima de “autorizar una sesión ajena” se reduce drásticamente.

Eso no significa que una empresa pueda activar passkeys en dos tardes y olvidarse del problema. Requiere planificación, compatibilidad con aplicaciones heredadas, cambios en procesos internos y comunicación clara con los usuarios. Pero sí marca una dirección estratégica: depender menos de contraseñas, OTP genéricos y aprobaciones de MFA sin contexto.

Un proyecto serio de modernización de identidad debería evaluar qué porcentaje del MFA actual es realmente resistente al phishing, dónde se siguen utilizando factores débiles (SMS, correo, apps sin binding de origen) y cómo migrar progresivamente a mecanismos más robustos. El device code phishing es un ejemplo perfecto de por qué este salto ya no es opcional para muchas organizaciones.

Checklist práctico para reducir el riesgo de device code phishing

Para aterrizar todo lo anterior en acciones concretas, una empresa de tamaño medio puede apoyarse en un checklist operativo que le permita evaluar su exposición y priorizar cambios de forma ordenada.

Como punto de partida, conviene identificar si la organización usa realmente el Device Code Flow y en qué casos de uso. No todas las compañías necesitan que este flujo esté abierto de forma generalizada; en algunos entornos puede limitarse a determinadas apps o colectivos muy concretos.

Después hay que revisar las aplicaciones y servicios que permiten device code, evaluar si el valor operativo justifica el riesgo y, si no es así, plantearse limitar o deshabilitar su uso mediante políticas de Entra ID y controles de acceso condicional.

En paralelo, es imprescindible auditar el despliegue actual de MFA y medir qué parte de la plantilla está usando métodos resistentes al phishing. A partir de ahí, se puede diseñar un plan de despliegue progresivo de FIDO2, passkeys u opciones equivalentes allí donde encajen mejor (accesos privilegiados, cuentas críticas, personal de finanzas, etc.).

También resulta clave reforzar la monitorización de Exchange Online: reglas de bandeja, reenvíos, cambios silenciosos y actividades inusuales deben entrar en el radar del SOC o del proveedor de seguridad. Esto se complementa con una validación de la visibilidad real en Defender XDR, Defender for Office y Entra ID Protection, asegurando que los logs necesarios se recojan y analicen de forma continua.

Finalmente, conviene definir un procedimiento claro de respuesta ante sospecha de abuso de flujos OAuth: revocación de sesiones, invalidación de refresh tokens, revisión exhaustiva del buzón afectado, análisis de actividad en Graph, comprobación de consentimientos otorgados y evaluación de accesos privilegiados relacionados.

Otros vectores emergentes: quishing y smishing como parte del mismo problema

El auge del device code phishing encaja en un contexto más amplio donde los atacantes diversifican los canales de entrada para esquivar controles clásicos de correo. Dos ejemplos relevantes son el quishing (phishing con códigos QR) y el smishing (phishing por SMS o apps de mensajería).

En el caso del quishing, la amenaza se basa en códigos QR incrustados en correos, documentos o soportes físicos. Muchas soluciones de seguridad tradicionales tienen dificultades para analizar imágenes, por lo que no detectan enlaces maliciosos ocultos en esos códigos. Proveedores avanzados ya utilizan visión artificial para extraer y decodificar los QR, escanear las URLs en sandbox y aplicar modelos de ML entrenados con años de datos de phishing.

Plataformas como Proofpoint o Microsoft Defender para Office 365 extraen códigos QR de adjuntos (por ejemplo, PDFs) y simulan su apertura en entornos aislados para detectar malware o recolectores de credenciales antes de que lleguen al usuario final. Según datos recientes, este tipo de análisis previo a la entrega ha llegado a bloquear más de un millón de intentos diarios de phishing con QR.

En paralelo, muchas organizaciones refuerzan su postura con medidas organizativas adicionales: uso de generadores de códigos QR corporativos con listas de dominios permitidos, segmentación de redes para aislar dispositivos IoT, protección de APIs implicadas en flujos con QR y, en escenarios avanzados, uso de firmas digitales sobre códigos para verificar su autenticidad.

En cuanto al smishing por SMS, los delincuentes aprovechan que las tasas de clic en SMS son claramente superiores a las del correo electrónico, y que resulta más complicado para el usuario inspeccionar enlaces antes de abrirlos. Tácticas como la suplantación de números, el uso de teléfonos desechables o el envío masivo desde pasarelas de correo a SMS facilitan enormemente este tipo de campañas.

Mientras que medidas regulatorias como STIR/SHAKEN ayudan a identificar llamadas fraudulentas, su efecto en los mensajes de texto ha sido mucho más limitado, empujando a muchos atacantes a centrarse precisamente en SMS y aplicaciones de mensajería. De nuevo, la educación al usuario y la integración de estos canales en los modelos de detección corporativos resulta fundamental.

En todos estos vectores (device code, quishing, smishing), la combinación de tecnología de detección avanzada, segmentación adecuada y formación continua es lo que marca la diferencia entre una organización que reacciona a golpes y otra que se adelanta a las campañas modernas de phishing.

La evolución del phishing hacia el abuso de flujos legítimos de autenticación, tokens válidos, códigos de dispositivo, códigos QR y mensajes móviles deja claro que ya no basta con bloquear un par de URLs sospechosas o activar un MFA básico. Las empresas que dependen de Microsoft 365 y otros servicios cloud tienen que revisar con lupa cómo se gestionan las sesiones, qué flujos OAuth están permitidos, qué visibilidad real tienen sobre tokens y actividades anómalas y hasta qué punto su autenticación es resistente al engaño. Quien logre combinar controles técnicos sólidos con una cultura de seguridad bien trabajada estará mucho mejor preparado para afrontar esta nueva generación de ataques.

Related article:

¿Cómo evitar el phishing y evitar sufrir un ataque de suplantación de identidad? Guía paso a paso