Nos han enseñado desde hace tiempo a mirar la dirección del sitio: si el dominio es legítimo y la página pertenece a Microsoft, entonces todo está bien. El nuevo esquema rompe justamente ese hábito. El estafador no necesita un sitio falso, y a veces ni siquiera necesita la contraseña. Envía un código y pide ingresarlo en la página oficial de Microsoft, supuestamente para conectarse a una reunión, abrir un documento o configurar un dispositivo de servicio.
Tras la confirmación, el acceso lo obtiene no el ordenador del empleado, sino un cliente iniciado antes por el atacante. El usuario inicia sesión en su cuenta laboral, pasa la verificación multifactor si es necesario y autoriza así un inicio de sesión iniciado por el atacante. En 2026 el esquema se hizo especialmente visible por una campaña masiva con generación automática de códigos y preparación de correos.
A este tipo de ataque se le llama phishing con código de dispositivo, o device code phishing. Primero la víctima autoriza a una aplicación de terceros a obtener tokens en nombre de su cuenta. Después el delincuente puede registrar un nuevo dispositivo, crear reglas en Outlook o consolidarse de otra manera.
Cómo funciona el flujo de código de dispositivo
El esquema se basa en el mecanismo estándar OAuth 2.0 Device Authorization Grant. Microsoft lo denomina flujo de código de dispositivo. Sirve para equipos donde es incómodo escribir una contraseña: paneles de salas de reunión, terminales, impresoras, Microsoft Teams Rooms y algunos programas de consola.
Por ejemplo, un panel en una sala de reuniones muestra un código corto. El empleado abre en el teléfono o en el ordenador la página de Microsoft, introduce el valor y realiza la verificación habitual. Después de eso, el panel recibe permiso para operar con la cuenta correspondiente. El mecanismo es seguro mientras el código se muestre en el dispositivo que la persona realmente está conectando.
El cliente recibe un device code operativo y un user code corto para la persona. Tras la confirmación, Microsoft emite a la aplicación un token de acceso y, a veces, un token de actualización.
- La aplicación solicita un código a Microsoft.
- La persona abre la página de inicio de sesión en otro dispositivo.
- Introduce el código y confirma su identidad.
- El cliente recibe tokens y acceso a los recursos permitidos.
La vulnerabilidad aparece por la separación de dispositivos. La persona confirma el inicio en una pantalla, y el permiso lo recibe un cliente que opera en otro lugar. La descripción del mecanismo está en la documentación oficial de Microsoft.
Cómo se desarrolla el ataque
Todo comienza con un mensaje adaptado al puesto del destinatario. Al contable le envían una factura, al responsable le ofrecen firmar un documento, y al personal de ventas le envían una invitación a una reunión. En la campaña de 2026 los textos y cebos se adaptaron automáticamente con datos públicos.
El enlace lleva a una página del atacante que simula un servicio de firma electrónica, un documento compartido, un buzón de voz o un formulario de conexión a una conferencia. Habitualmente no se solicita la contraseña. Tras pulsar el botón, un script oculto crea un nuevo código de dispositivo a través de la infraestructura de Microsoft.
El código es válido durante un tiempo limitado: alrededor de 15 minutos en la campaña descrita. Por eso los estafadores lo generan solo tras el clic en el enlace. Luego envían a la persona al portal oficial de Microsoft. Esta introduce el código, selecciona la cuenta laboral y completa la verificación multifactor (MFA).
Al completarse el inicio de sesión, los tokens los recibe el cliente que pidió primero el código. Después los delincuentes buscan correos de pago, contratos y correspondencia con contrapartes, registran dispositivos o crean reglas en la carpeta Bandeja de entrada.
- La víctima recibe un mensaje con un motivo empresarial.
- Abre la página con el documento o la reunión.
- Un script crea un código de dispositivo nuevo.
- El usuario lo introduce en el sitio de Microsoft.
- Los tokens se transfieren al cliente del atacante.
- El delincuente revisa el correo y los recursos corporativos.
En qué se diferencia este esquema del phishing habitual
El phishing clásico obtiene la contraseña en una página falsa. El ataque por código de dispositivo funciona de otra manera: el delincuente convence a la persona para que autorice de forma legítima a un cliente preparado de antemano.
| Característica | Phishing habitual | Código de dispositivo |
|---|---|---|
| Página de inicio de sesión | Normalmente falsa | Puede ser oficial |
| Acción de la víctima | Introducir usuario y contraseña | Introducir el código de otra persona |
| Lo que obtiene el delincuente | Contraseña o datos del formulario | Tokens del cliente |
| Comprobación del dominio | A menudo ayuda | Casi no ayuda |
| Papel de la verificación multifactor | Puede detener el acceso | La víctima confirma la sesión por sí misma |
| Principal indicador | Dirección de un sitio ajeno | El código lo envió otra persona |
El código de dispositivo no es una contraseña de un solo uso. Es una solicitud para conceder acceso a un cliente que ya está funcionando en otro equipo. Por eso es importante entender quién inició el acceso y dónde apareció el código.
Si el código llegó por correo, mensajería, en un archivo PDF o se comunicó por teléfono, no debe introducirse ni siquiera en el sitio oficial de Microsoft.
Por qué el sitio oficial y la verificación multifactor no bastan
El sitio oficial solo confirma que los datos se envían a Microsoft. No demuestra que la aplicación que solicita la autorización sea segura. El servidor ejecuta el comando: el usuario introdujo un código válido, inició sesión y confirmó la solicitud.
En la página de autorización hay que leer el nombre de la aplicación y la descripción de la acción. Si la persona pensaba abrir un documento y Microsoft propone conectar una aplicación o dispositivo desconocido, debe pulsar Cancelar.
La verificación multifactor sigue siendo importante, pero confirma la identidad del usuario, no la corrección de su decisión. El delincuente no hackea Microsoft Authenticator; consigue que el propietario de la cuenta complete por sí mismo un inicio de sesión ajeno.
Una invitación habitual de Microsoft Teams no requiere un código de dispositivo por parte del organizador. En una configuración legítima, el código se muestra en el propio equipo.
- El código debe mostrarse en el dispositivo que se conecta.
- No debe introducirse un código recibido por correo o mensajería.
- Hay que verificar el nombre de la aplicación de antemano.
- Una petición inesperada debe cancelarse.
Cómo proteger Microsoft 365
Para el empleado la regla es sencilla: no introducir un código de dispositivo que envió otra persona. Un técnico de soporte legítimo puede explicar dónde se muestra el código, pero no enviará un valor preparado con antelación para una sesión ajena.
Las organizaciones deberían bloquear el flujo de código de dispositivo donde no se necesite. Primero es necesario revisar los registros y determinar si se usa el mecanismo para Teams Rooms, terminales o escenarios de servicio. Microsoft recomienda empezar en modo Solo informe.
- Abrir el centro de administración de Microsoft Entra.
- Ir a Entra ID, Acceso condicional, Políticas.
- Crear una nueva política y seleccionar usuarios.
- Abrir Condiciones, Flujos de autenticación.
- Seleccionar Flujo de código de dispositivo.
- En la sección Concesión indicar Bloquear acceso.
- Activar primero el modo Solo informe.
- Tras la comprobación, poner la política en Activado.
En Entra ID abra Monitorización y rendimiento, Registros de inicio de sesión, y en el filtro Protocolo de autenticación seleccione Código de dispositivo. Para sistemas de salas de reunión es mejor crear un grupo de exclusión separado.
Qué hacer si ya se introdujo el código
Si el inicio de sesión aún no se ha completado, hay que cerrar la página, pulsar Cancelar y avisar al departamento de TI. Si la contraseña y la verificación multifactor ya se confirmaron, la situación debe considerarse un secuestro completo de la cuenta.
Cambiar solo la contraseña no basta. Es posible que ya se hayan emitido tokens, por lo que el administrador debe bloquear temporalmente el inicio de sesión, revocar las sesiones activas, cambiar la contraseña, revisar los métodos de autenticación y eliminar dispositivos desconocidos.
- Bloquear el inicio de sesión durante la investigación.
- Ejecutar "Revocar sesiones".
- Restablecer la contraseña.
- Revisar los inicios con el protocolo Código de dispositivo.
- Buscar nuevos registros de dispositivos.
- Revisar aplicaciones y permisos.
- Analizar reglas de Outlook y reenvíos.
- Determinar qué datos pudieron haberse abierto.
En Outlook hay que revisar Configuración, Correo, Reglas. También es importante comprobar lecturas masivas de correos, llamadas a Microsoft Graph, direcciones IP inusuales y sesiones nuevas.
Preguntas y respuestas
¿El estafador obtiene la contraseña?
No necesariamente. La contraseña se transmite a Microsoft, y el atacante obtiene tokens de la autorización exitosa. Eso es suficiente para acceder a los recursos corporativos permitidos.
¿Se vincula de inmediato un ordenador ajeno a la cuenta?
No siempre. Primero se autoriza la aplicación o el cliente que solicitó el código. El registro de un dispositivo nuevo puede ocurrir después.
¿Por qué Microsoft permite ese tipo de acceso?
El flujo es necesario para equipos sin teclado ni navegador cómodos. Microsoft no puede determinar si la persona está conectando su propio dispositivo o introduciendo un código de un correo fraudulento.
¿Ayuda la verificación multifactor?
Protege contra muchos ataques, pero aquí el usuario realiza la verificación multifactor para una solicitud ajena. El problema está en la interpretación equivocada de la sesión que se está confirmando.
¿Cuál es el indicador más fiable?
El código debe mostrarse en el equipo que el empleado conecta personalmente. No hay que introducir un código enviado por correo, chat o teléfono.
Resumen breve
- El esquema utiliza el mecanismo estándar OAuth 2.0.
- La página de Microsoft puede ser auténtica.
- La contraseña puede no llegar al delincuente.
- El usuario confirma por sí mismo una sesión ajena.
- Debería bloquearse el flujo de código de dispositivo cuando no sea necesario.
- Tras un incidente hay que revocar las sesiones.
La regla principal es más sencilla que cualquier guía técnica: solo hay que confirmar el inicio de sesión que la persona inició por sí misma. Un código ajeno no se vuelve seguro porque se proponga introducirlo en el sitio oficial de Microsoft.
