Un inicio de sesión legítimo: una intención maliciosa

La autenticación mediante código de dispositivo tiene una finalidad completamente legítima. Se utiliza cuando una aplicación necesita que el usuario complete el inicio de sesión desde otro equipo, por ejemplo, cuando un dispositivo muestra un código que debe introducirse en el navegador de una computadora o un teléfono.

El problema aparece cuando un atacante manipula este procedimiento.

El proceso suele comenzar con un correo electrónico que parece habitual: una invitación para consultar un documento compartido, revisar una factura, escuchar un mensaje de voz o responder a una solicitud de propuesta.

El empleado sigue las instrucciones y recibe un código de verificación. Después, es dirigido a una página auténtica de inicio de sesión, donde introduce el código y completa la autenticación multifactor.

Todo parece correcto. Sin embargo, hay un detalle que cambia por completo la situación: la solicitud de autenticación no fue iniciada por el empleado, sino por el atacante.

Al introducir el código y aprobar el proceso, el usuario termina autorizando la sesión del ciberdelincuente.

De esta manera, el atacante puede obtener tokens de acceso y actualización que le permiten utilizar los servicios disponibles para la cuenta comprometida, como el correo electrónico, el almacenamiento en la nube y otras aplicaciones empresariales, mientras los tokens continúen siendo válidos.

¿Por qué la autenticación multifactor no siempre es suficiente?

La autenticación multifactor (MFA) representa una capa importante de protección, pero este ataque demuestra que no todos los procesos de autenticación son igualmente resistentes al phishing.

En un ataque tradicional, el usuario suele ser redirigido a una página falsa que intenta imitar un servicio legítimo. La dirección web, el diseño o ciertos detalles del sitio pueden revelar el engaño.

El phishing mediante código de dispositivo elimina buena parte de esas señales de alerta.

La víctima puede:

• Acceder a un dominio legítimo.
• Introducir el código de verificación siguiendo las instrucciones.
• Completar correctamente la autenticación multifactor.
• No proporcionar su contraseña a una página controlada por el atacante.
• Recibir una aprobación normal del sistema de autenticación.

El engaño no está necesariamente en la página que el usuario visita, sino en la solicitud que está autorizando.

Por eso, revisar la URL y completar la MFA no garantizan, por sí solos, que el inicio de sesión sea legítimo. También es necesario comprobar qué aplicación o dispositivo solicita la autorización y por qué se está realizando ese proceso.

De una técnica específica a campañas cada vez más sofisticadas

El phishing mediante código de dispositivo dejó de ser únicamente una técnica experimental.

En febrero de 2025, Microsoft reveló una campaña que utilizaba este mecanismo para capturar tokens de autenticación y obtener acceso a cuentas comprometidas.

A principios de 2026, los atacantes comenzaron a combinar esta técnica con automatización, señuelos generados mediante inteligencia artificial y códigos de dispositivo generados dinámicamente.

Este último elemento representa un avance importante.

Los códigos de dispositivo tienen un periodo de validez limitado. Anteriormente, esto obligaba a los atacantes a convencer a sus víctimas de actuar dentro de una ventana de tiempo relativamente corta.

Con la generación dinámica de códigos, los ciberdelincuentes pueden crear uno nuevo cuando la víctima llega a la etapa final del engaño. Así reducen los obstáculos operativos y facilitan la ejecución de campañas a mayor escala.

La automatización también permite coordinar mejor los diferentes pasos del ataque, desde el primer mensaje hasta la obtención de acceso.

El correo electrónico es el punto de partida, pero no el final del ataque

Para que esta técnica funcione, el atacante necesita una razón convincente para que el empleado complete el proceso de autenticación.

Ahí es donde entra el correo electrónico.

Un mensaje sobre un archivo compartido, una factura pendiente, una solicitud de propuesta o un mensaje de voz puede generar suficiente confianza para que el usuario siga las instrucciones sin cuestionar su origen.

Algunas campañas utilizan enlaces directos. Otras recurren a archivos PDF o HTML y a múltiples redirecciones mediante servicios en la nube legítimos o de buena reputación.

Esto dificulta la detección, porque analizar únicamente el dominio de destino puede dejar fuera información importante sobre el recorrido que llevó al usuario hasta la página de inicio de sesión.

Pero el riesgo no termina cuando el atacante consigue autenticarse.

Una cuenta comprometida puede convertirse en un punto de entrada para explorar aplicaciones conectadas, consultar información confidencial, suplantar la identidad del empleado o intentar avanzar hacia otros recursos de la organización.

Por eso, los equipos de seguridad necesitan observar lo que ocurre antes, durante y después de la autenticación.

Entre las señales que conviene investigar se encuentran:

• ¿Quién envió el mensaje original y qué contexto utilizó para generar confianza?
• ¿Qué enlaces, archivos adjuntos y redirecciones llevaron al empleado hasta la página de inicio de sesión?
• ¿Qué aplicación o dispositivo se estaba solicitando autorizar?
• ¿La actividad posterior corresponde al comportamiento habitual del usuario?
• ¿A qué aplicaciones, recursos o información accedió la cuenta?
• ¿Aparecieron nuevas reglas en el correo, permisos de aplicaciones o registros de dispositivos inesperados?

Conectar las señales del correo electrónico, la identidad, las aplicaciones en la nube y los dispositivos permite comprender mejor el alcance de una posible vulneración y responder antes de que una cuenta comprometida se convierta en un incidente de mayor impacto.

¿Cómo puede una organización reducir este riesgo?

La protección frente al phishing mediante código de dispositivo requiere una estrategia que vaya más allá del filtrado de correos o de la implementación de MFA.

Las organizaciones deben considerar medidas específicas en sus sistemas de identidad, políticas de acceso y herramientas de detección.

• Bloquear la autenticación mediante código de dispositivo cuando no sea necesaria.

Si la organización no tiene una necesidad empresarial legítima para utilizar este mecanismo, deshabilitarlo ayuda a reducir la superficie de ataque.

• Restringir su utilización cuando sea indispensable.

Las políticas de acceso condicional permiten establecer controles sobre cuándo y bajo qué circunstancias puede utilizarse este flujo de autenticación.

• Implementar autenticación resistente al phishing.

Las claves de seguridad y las credenciales FIDO2 ofrecen una protección más sólida frente a técnicas de phishing y robo de credenciales.

• Capacitar a los empleados para verificar lo que autorizan.

No basta con revisar la dirección del sitio web. Los usuarios deben aprender a identificar qué aplicación y dispositivo están solicitando la autorización, y cuestionar cualquier proceso que no hayan iniciado.

• Supervisar los eventos de autenticación y la actividad posterior.

Es importante detectar inicios de sesión inusuales mediante códigos de dispositivo, actividad sospechosa de tokens, registros inesperados de dispositivos, accesos anómalos a Microsoft Graph y nuevas reglas de bandeja de entrada.

• Actuar rápidamente ante una posible intrusión.

Cuando se identifica actividad maliciosa, los equipos de seguridad deben revocar los tokens de actualización y aplicar las medidas de contención correspondientes para impedir que el atacante conserve el acceso.

• Analizar el recorrido completo del correo electrónico.

Evaluar al remitente, el contexto del mensaje, los archivos adjuntos, las redirecciones y la solicitud de autenticación permite identificar señales que podrían pasar desapercibidas al revisar únicamente la página de destino.

Una página legítima no garantiza un acceso seguro