MFA adaptativa bajo ataque: Por qué los motores de riesgo no detectan la ola de 7 millones de códigos de dispositivo

9 Min. de lectura

El 23 de abril de 2026, Barracuda informó haber detectado 7 millones de ataques de phishing de código de dispositivo en las últimas cuatro semanas. Microsoft Security publicó el 6 de abril un análisis detallado sobre una campaña de phishing de código de dispositivo impulsada por IA. Ambos informes muestran la misma incómoda verdad: la MFA adaptativa en Entra, Okta y Duo ya no es la zona de confort que hace doce meses aún se vendía en cada hoja de ruta de seguridad. Los motores de riesgo que confían en la huella del dispositivo, la clasificación de IP y los patrones de comportamiento son eludidos por atacantes con IA en producción, sin necesidad de que se abra una sola CVE.

Por qué los motores de riesgo fallan sistemáticamente

¿Qué es la MFA adaptativa? La MFA adaptativa es un modelo de autenticación que ajusta dinámicamente el requisito de MFA (autenticación multifactor) en función de señales de riesgo como la reputación de IP, geolocalización, cumplimiento del dispositivo, comportamiento del usuario y contexto de sesión. La idea: los usuarios con dispositivo y red conocidos experimentan menos solicitudes de MFA, mientras que las sesiones de riesgo se aseguran con factores adicionales o restricciones de sesión. Su implementación se lleva a cabo en Microsoft Entra ID (Identity Protection), Okta (Adaptive MFA) y Duo (Risk-Based Authentication) con componentes de telemetría similares.

El funcionamiento de la actual campaña de ataque explota precisamente esta lógica. El atacante ya no construye páginas de robo de credenciales, sino que inicia un flujo legítimo de código de dispositivo OAuth en Microsoft o otro proveedor de identidad. El código generado se envía a la víctima en el momento oportuno mediante correos de phishing basados en IA. Una vez que la víctima introduce el código, autoriza involuntariamente la sesión del atacante. La MFA se ha superado con éxito, solo que por la persona equivocada para la cuenta correcta.

Las tres características que hacen que este ataque sea invisible para los motores de riesgo están diseñadas arquitectónicamente. Primero: la autenticación y el origen de la sesión están desacoplados por diseño en el flujo de código de dispositivo. Segundo: el token está vinculado a un proceso real de MFA, no robado. Tercero: la IP de la víctima parece normal para el motor de riesgo, ya que es el dispositivo real que autoriza. El token llega posteriormente al servidor del atacante, pero ya no es la fase de autenticación, sino el uso de la sesión.

Blog de seguridad de Microsoft del 6 de abril de 2026 en términos sencillos

La entrada del blog de Microsoft del 6 de abril de 2026 documenta una campaña con dos innovaciones técnicas. En primer lugar, Generación dinámica de código de dispositivo: el servidor de phishing genera el código OAuth en el momento exacto en que la víctima hace clic en el enlace. Esto resuelve el problema de que los códigos de dispositivo caducan después de 15 minutos, lo que hace que las oleadas tradicionales de phishing por correo electrónico a menudo fallen. En segundo lugar, Personalización basada en IA: el correo de phishing se adapta en tiempo real al rol, contexto y estilo de comunicación de la víctima. Ambos componentes juntos aumentan la tasa de clic en las campañas observadas según Barracuda a un 4,2 por ciento, frente al 0,4 por ciento en los ataques clásicos de fatiga de MFA.

Las cifras del panorama de amenazas actual

La diferencia entre «seguridad por diseño» y «seguridad por incidente» es aproximadamente una semana de sueño. La MFA adaptativa no proporciona somníferos cuando el ataque evita el motor de riesgo.

Tres contramedidas que realmente funcionan

Los equipos de seguridad que han respondido bien en los últimos dos trimestres siguen todos la misma secuencia. Ninguna bala de plata, sino tres claramente delimitadas medidas que en una empresa típica del espacio DACH son implementables en ocho semanas.

Medida 1: Configurar restrictivamente el flujo de código de dispositivo

En Microsoft Entra ID, el flujo de código de dispositivo se puede restringir mediante una política de acceso condicional. La política bloquea la autenticación de código de dispositivo para todos los grupos de usuarios que no lo necesitan productivamente (normalmente: todos excepto administradores de IoT y cuentas de servicio especiales fuera de línea). En la práctica, son necesarias dos políticas: «Bloquear flujo de código de dispositivo para todos los usuarios» con grupo de excepción para casos de uso documentados. En Okta, esta característica se llama «Políticas de autenticación con restricción de código de dispositivo». Quienes utilizan Duo resuelven esto mediante el motor de políticas a nivel de aplicación. Esta medida por sí sola elimina alrededor del 60% de los ataques observados, ya que el vector simplemente ya no está disponible.

Medida 2: FIDO2 y Passkeys como factor principal

Los motores de riesgo necesitan señales contra las cuales ni siquiera los correos de phishing con IA puedan prevalecer. Las claves de hardware FIDO2 y los Passkeys de plataforma en 2026 son la única clase ampliamente implementable de factores de autenticación que son robustos simultáneamente contra ataques de tipo Adversary-in-the-Middle y phishing de código de dispositivo. El orden de implementación en nuestros clientes: comenzando con roles privilegiados (administradores de dominio, administradores de IdP, finanzas), luego roles empresariales con acceso a datos sensibles, y finalmente implementación general. Calcule de 12 a 18 meses para una implementación completa de FIDO2 en una organización con más de 5.000 empleados, incluyendo adquisición, logística, formación del helpdesk y configuración de Entra/Okta.

Medida 3: Vinculación de sesión y validación continua

Las plataformas modernas de MFA adaptativo ofrecen vinculación de token y evaluación de acceso continua (CAE). En Entra ID, esta característica se llama «Evaluación de acceso continua» y verifica constantemente los tokens de sesión contra señales de riesgo. Okta lo proporciona como «Señales de riesgo de sesión». La configuración requiere tres componentes: duración de validez de token estricta (una hora en lugar de ocho horas), activación de CAE en políticas de acceso condicional y una automatización de revocación de sesión que proactivamente termina la sesión ante nuevos IOC (IP sospechosa, cambio geográfico nuevo, viaje imposible). En combinación con las medidas 1 y 2, esta política cierra aproximadamente el 80% de los ataques reales.

Qué deben evaluar internamente de manera diferente los motores de riesgo

Las tres medidas anteriores son operativas. Pero detrás de ellas hay una pregunta más profunda que se decidirá en las arquitecturas de seguridad de los próximos 18 meses: ¿Qué señales de riesgo siguen siendo útiles cuando la autenticación y el origen de la sesión están desconectados? Nuestra observación en los clientes: los motores de riesgo están desplazando su lógica de «de dónde viene la sesión» hacia «cómo se comporta el token después de la autenticación». Así, señales como la frecuencia de actualización de token, el comportamiento de consentimiento de aplicación OAuth, los cambios en reglas de buzón y llamadas inusuales a la API de Graph se convierten en indicadores primarios, mientras que IP y Geolocalización decaen a indicadores secundarios.

Un efecto secundario práctico: las reglas de SIEM que hoy alertan ante «MFA exitoso» e «IP desconocida» simultáneamente generarán más falsas alarmas, ya que la señal IP pierde poder predictivo. Las reglas más caras pero efectivas son aquellas que correlacionan eventos de ciclo de vida de token con patrones de actividad del usuario. Quienes inviertan aquí ahora reducirán en seis meses sus volúmenes de alertas de manera demostrable.

La dimensión de la IA en el ataque: lo que ha cambiado desde 2024

Un segundo punto que a menudo se simplifica en el debate actual: el componente de IA del ataque no solo está en la personalización del correo de phishing, sino también en la coordinación en tiempo real del flujo de código de dispositivo. En 2024, las campañas de phishing lo eran estáticas como para que un rol del equipo azul pudiera seguir manualmente el proceso. En 2026, la generación de código, la personalización del correo y la extracción de token ocurren en una cadena de milisegundos. Esto cambia el tiempo de respuesta que las operaciones de seguridad deben proporcionar de manera realista. Quienes aún tienen un bucle de aprobación manual entre alerta y revocación de sesión perderán en caso real de dos a cuatro horas, durante las cuales el token ya ha ejecuto exportaciones de buzón.

La consecuencia para las arquitecturas de seguridad: la revocación de sesión debe pasar de ser una decisión manual a una impulsada por políticas. En Entra ID, esto significa específicamente la activación de CAE con revocación ante detección de riesgo, en Okta la integración de señales de riesgo con suscripción de registros del sistema y playbooks de respuesta automáticos. Las organizaciones que hemos considerado bien preparadas han invertido entre seis y doce semanas precisamente en esta automatización y después han reducido el tiempo de permanencia (dwell-time) a menos de 45 minutos.

Qué cuenta en la primera semana de respuesta a incidentes

Si un ataque de código de dispositivo aparece en la propia telemetría, tres acciones son cruciales en las primeras 24 horas. Primero, revocación de sesión para la cuenta de usuario afectada mediante PowerShell de Entra ID o API de Okta; la invalidación de token es más importante que el restablecimiento de contraseña, ya que el token ya está activo. Segundo, revisión de registros de auditoría de los últimos 30 días en busca de accesos a buzón, consentimiento de aplicación OAuth y exfiltración de datos, que a menudo comienzan pocas horas después de la toma del control del token. Tercero, threat hunting para campañas paralelas: los ataques de código de dispositivo suelen venir en oleadas, una sola víctima rara vez es la única afectada en la organización. Quien espera una semana para aclarar el alcance completo, ha perdido la ventana para contener el incidente.

Comunicación hacia el consejo de administración y el consejo supervisor

Una dimensión subestimada de una evasión exitosa de MFA adaptativo es la comunicación ascendente. Los consejos de administración esperan una declaración clara sobre por qué la inversión existente en MFA no ha detenido a los atacantes. La explicación es técnicamente simple pero políticamente delicada: el motor de riesgo no ha fallado, fue eludido. Para la comunicación, se recomienda un enfoque sobrio en tres pasos: ¿cuál fue el camino de ataque concreto?, ¿qué brecha de control se explotó?, ¿qué tres medidas cierran esta brecha hasta fin de trimestre. Quien en este momento se desvía hacia jerga técnica pierde confianza. Quien cuenta la historia clara obtiene la aprobación presupuestaria para implementación de FIDO2 y activación de CAE más rápido de lo que sería posible en un ciclo presupuestario normal.

Para la comunicación con el consejo supervisor, un componente adicional es importante: las lecciones aprendidas deben incorporarse como prueba formal de mitigación de riesgo en la documentación NIS2. El artículo 21 no solo exige el análisis inicial de riesgo, sino también el ajuste continuo tras incidentes. Un incidente de evasión de MFA adaptativo sin corrección documentada será un hallazgo en la próxima auditoría con impacto en la evaluación general.

Verificación final del pragmatismo

La MFA adaptativa fue para muchas organizaciones una mejora de comodidad alejándose de la MFA estática. En 2026 está claro: comodidad y seguridad no son equivalentes. Una buena configuración de MFA adaptativa en 2026 es más restrictiva, no más tolerante, y combina factores resistentes al phishing con validación agresiva de sesión. Quien aborde esto en los próximos dos trimestres sacará a su propia organización de la estadística de los 7 millones. Quien espera, confía en que las campañas con IA no afectarán a su empresa. Esto no es una estrategia de seguridad, es casualidad. Y la casualidad en la situación de amenaza actual es el componente arquitectónico más caro que una organización puede permitirse, si se calculan realistamente los costes de un incidente y la posterior adaptación a NIS2.

Preguntas frecuentes

¿Es el flujo de código de dispositivo fundamentalmente inseguro?

No. El flujo ha sido desarrollado para escenarios específicos (autenticación de dispositivo compartido, IoT, herramientas de línea de comandos sin navegador) y es útil en esos casos. El riesgo surge cuando está activado de manera generalizada y sin restricciones, y puede ser abusado como vector de phishing. La solución no es desactivar el flujo, sino restringirlo conscientemente a los casos de uso documentados.

¿Cómo detecto un ataque en curso de código de dispositivo en los registros?

En los registros de inicio de sesión de Entra ID, los eventos de código de dispositivo están marcados explícitamente (AuthenticationProtocol = DeviceCode). Una regla de anomalía KQL que alerte sobre poblaciones de usuarios inusuales con eventos de código de dispositivo detecta la mayoría de las campañas en las primeras horas. En Okta, la misma información se encuentra en el registro del sistema bajo «login.device_code». Importante: La regla debe activarse para nuevas cohortes de usuarios, no solo por volumen.

¿Ayuda el bloqueo geográfico a mejorar la situación?

Parcialmente. El bloqueo geográfico en países no utilizados reduce el nivel de ruido, pero los atacantes utilizan cada vez más redes de proxy residenciales en el mismo país que la víctima. El bloqueo geográfico no reemplaza las contramedidas mencionadas anteriormente, solo alivia el análisis de alertas.

¿Cómo se posiciona NIS2 frente a la evasión de MFA adaptativa?

NIS2 exige en el artículo 21 medidas adecuadas contra el acceso no autorizado, análisis de riesgo documentado y notificación de incidentes. Una campaña exitosa de código de dispositivo con exfiltración de datos cae así en la obligación de notificación. Para prepararse para tal caso, es obligatorio documentar las medidas de MFA implementadas y sus limitaciones. Quien no documente una política de restricción de código de dispositivo, no tendrá una buena posición en la auditoría NIS2.

¿Cuál es el coste realista de una implementación de FIDO2?

Para una empresa de 5.000 empleados, calculamos entre 150.000 y 280.000 euros en el año 1 (hardware, licencias de IdP, integración de soporte, formación). El ahorro proviene de incidentes de phishing reducidos, menos llamadas al servicio de ayuda para restablecimientos de MFA y, en el mejor de los casos, de brechas evitadas. Un caso de ROI realista se basa en dos o tres incidentes evitados al año, que se encuentran en el rango de coste de 150.000 euros hacia arriba.

¿Deberíamos desactivar completamente el flujo de código de dispositivo?

Para la mayoría de las organizaciones, la respuesta es: sí, con excepciones para grupos de usuarios documentados. Una matriz de excepciones limpia suele incluir tres a cinco casos de uso (herramientas de línea de comandos para administradores, implementaciones específicas de IoT, cuentas de servicio con propósito de uso documentado). Todo lo demás debería bloquearse mediante una política de acceso condicional, siempre que no exista una justificación de negocio clara.

Red: Siga leyendo en Security Today

• Fondo sobre DORA 2.0 y la política de la FCA del Reino Unido del 16 de abril de 2026
• Clasificación del incidente sobre el escape de la sandbox Terrarium CVE-2026-5752 y la actualización de 72h de Cohere AI
• Guía de cumplimiento sobre el CVE de Microsoft ASP.NET y el plan de 72h fuera de banda de abril de 2026

Fuente de la imagen de portada: Pexels / Tima Miroshnichenko (px:5380610)

Sobre el autor: Alec Chizhik

Más artículos de Alec Chizhik