9 Min. de lectura<\/p>\n
El 23 de abril de 2026, Barracuda inform\u00f3 haber detectado 7 millones de ataques de phishing de c\u00f3digo de dispositivo en las \u00faltimas cuatro semanas. Microsoft Security public\u00f3 el 6 de abril un an\u00e1lisis detallado sobre una campa\u00f1a de phishing de c\u00f3digo de dispositivo impulsada por IA. Ambos informes muestran la misma inc\u00f3moda verdad: la MFA adaptativa en Entra, Okta y Duo ya no es la zona de confort que hace doce meses a\u00fan se vend\u00eda en cada hoja de ruta de seguridad. Los motores de riesgo que conf\u00edan en la huella del dispositivo, la clasificaci\u00f3n de IP y los patrones de comportamiento son eludidos por atacantes con IA en producci\u00f3n, sin necesidad de que se abra una sola CVE.<\/strong><\/p>\n \u00bfQu\u00e9 es la MFA adaptativa?<\/strong> La MFA adaptativa es un modelo de autenticaci\u00f3n que ajusta din\u00e1micamente el requisito de MFA (autenticaci\u00f3n multifactor) en funci\u00f3n de se\u00f1ales de riesgo como la reputaci\u00f3n de IP, geolocalizaci\u00f3n, cumplimiento del dispositivo, comportamiento del usuario y contexto de sesi\u00f3n. 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\u00f3n. Su implementaci\u00f3n se lleva a cabo en Microsoft Entra ID (Identity Protection), Okta (Adaptive MFA) y Duo (Risk-Based Authentication) con componentes de telemetr\u00eda similares.<\/p>\n El funcionamiento de la actual campa\u00f1a de ataque explota precisamente esta l\u00f3gica. El atacante ya no construye p\u00e1ginas de robo de credenciales, sino que inicia un flujo leg\u00edtimo de c\u00f3digo de dispositivo OAuth en Microsoft o otro proveedor de identidad. El c\u00f3digo generado se env\u00eda a la v\u00edctima en el momento oportuno mediante correos de phishing basados en IA. Una vez que la v\u00edctima introduce el c\u00f3digo, autoriza involuntariamente la sesi\u00f3n del atacante. La MFA se ha superado con \u00e9xito, solo que por la persona equivocada para la cuenta correcta.<\/p>\n Las tres caracter\u00edsticas que hacen que este ataque sea invisible para los motores de riesgo est\u00e1n dise\u00f1adas arquitect\u00f3nicamente. Primero: la autenticaci\u00f3n y el origen de la sesi\u00f3n est\u00e1n desacoplados por dise\u00f1o en el flujo de c\u00f3digo de dispositivo. Segundo: el token est\u00e1 vinculado a un proceso real de MFA, no robado. Tercero: la IP de la v\u00edctima 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\u00f3n, sino el uso de la sesi\u00f3n.<\/p>\n La entrada del blog de Microsoft del 6 de abril de 2026 documenta una campa\u00f1a con dos innovaciones t\u00e9cnicas. En primer lugar, Generaci\u00f3n din\u00e1mica de c\u00f3digo de dispositivo: el servidor de phishing genera el c\u00f3digo OAuth en el momento exacto en que la v\u00edctima hace clic en el enlace. Esto resuelve el problema de que los c\u00f3digos de dispositivo caducan despu\u00e9s de 15 minutos, lo que hace que las oleadas tradicionales de phishing por correo electr\u00f3nico a menudo fallen. En segundo lugar, Personalizaci\u00f3n basada en IA: el correo de phishing se adapta en tiempo real al rol, contexto y estilo de comunicaci\u00f3n de la v\u00edctima. Ambos componentes juntos aumentan la tasa de clic en las campa\u00f1as observadas seg\u00fan Barracuda a un 4,2 por ciento, frente al 0,4 por ciento en los ataques cl\u00e1sicos de fatiga de MFA.<\/p>\n La diferencia entre \u00abseguridad por dise\u00f1o\u00bb y \u00abseguridad por incidente\u00bb es aproximadamente una semana de sue\u00f1o. La MFA adaptativa no proporciona somn\u00edferos cuando el ataque evita el motor de riesgo.<\/p><\/blockquote>\n Los equipos de seguridad que han respondido bien en los \u00faltimos dos trimestres siguen todos la misma secuencia. Ninguna bala de plata, sino tres claramente delimitadas medidas que en una empresa t\u00edpica del espacio DACH son implementables en ocho semanas.<\/p>\n En Microsoft Entra ID, el flujo de c\u00f3digo de dispositivo se puede restringir mediante una pol\u00edtica de acceso condicional. La pol\u00edtica bloquea la autenticaci\u00f3n de c\u00f3digo 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\u00ednea). En la pr\u00e1ctica, son necesarias dos pol\u00edticas: \u00abBloquear flujo de c\u00f3digo de dispositivo para todos los usuarios\u00bb con grupo de excepci\u00f3n para casos de uso documentados. En Okta, esta caracter\u00edstica se llama \u00abPol\u00edticas de autenticaci\u00f3n con restricci\u00f3n de c\u00f3digo de dispositivo\u00bb. Quienes utilizan Duo resuelven esto mediante el motor de pol\u00edticas a nivel de aplicaci\u00f3n. Esta medida por s\u00ed sola elimina alrededor del 60% de los ataques observados, ya que el vector simplemente ya no est\u00e1 disponible.<\/p>\n Los motores de riesgo necesitan se\u00f1ales 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 \u00fanica clase ampliamente implementable de factores de autenticaci\u00f3n que son robustos simult\u00e1neamente contra ataques de tipo Adversary-in-the-Middle y phishing de c\u00f3digo de dispositivo. El orden de implementaci\u00f3n 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\u00f3n general. Calcule de 12 a 18 meses para una implementaci\u00f3n completa de FIDO2 en una organizaci\u00f3n con m\u00e1s de 5.000 empleados, incluyendo adquisici\u00f3n, log\u00edstica, formaci\u00f3n del helpdesk y configuraci\u00f3n de Entra\/Okta.<\/p>\n Las plataformas modernas de MFA adaptativo ofrecen vinculaci\u00f3n de token y evaluaci\u00f3n de acceso continua (CAE). En Entra ID, esta caracter\u00edstica se llama \u00abEvaluaci\u00f3n de acceso continua\u00bb y verifica constantemente los tokens de sesi\u00f3n contra se\u00f1ales de riesgo. Okta lo proporciona como \u00abSe\u00f1ales de riesgo de sesi\u00f3n\u00bb. La configuraci\u00f3n requiere tres componentes: duraci\u00f3n de validez de token estricta (una hora en lugar de ocho horas), activaci\u00f3n de CAE en pol\u00edticas de acceso condicional y una automatizaci\u00f3n de revocaci\u00f3n de sesi\u00f3n que proactivamente termina la sesi\u00f3n ante nuevos IOC (IP sospechosa, cambio geogr\u00e1fico nuevo, viaje imposible). En combinaci\u00f3n con las medidas 1 y 2, esta pol\u00edtica cierra aproximadamente el 80% de los ataques reales.<\/p>\n Las tres medidas anteriores son operativas. Pero detr\u00e1s de ellas hay una pregunta m\u00e1s profunda que se decidir\u00e1 en las arquitecturas de seguridad de los pr\u00f3ximos 18 meses: \u00bfQu\u00e9 se\u00f1ales de riesgo siguen siendo \u00fatiles cuando la autenticaci\u00f3n y el origen de la sesi\u00f3n est\u00e1n desconectados? Nuestra observaci\u00f3n en los clientes: los motores de riesgo est\u00e1n desplazando su l\u00f3gica de \u00abde d\u00f3nde viene la sesi\u00f3n\u00bb hacia \u00abc\u00f3mo se comporta el token despu\u00e9s de la autenticaci\u00f3n\u00bb. As\u00ed, se\u00f1ales como la frecuencia de actualizaci\u00f3n de token, el comportamiento de consentimiento de aplicaci\u00f3n OAuth, los cambios en reglas de buz\u00f3n y llamadas inusuales a la API de Graph se convierten en indicadores primarios, mientras que IP y Geolocalizaci\u00f3n decaen a indicadores secundarios.<\/p>\n Un efecto secundario pr\u00e1ctico: las reglas de SIEM que hoy alertan ante \u00abMFA exitoso\u00bb e \u00abIP desconocida\u00bb simult\u00e1neamente generar\u00e1n m\u00e1s falsas alarmas, ya que la se\u00f1al IP pierde poder predictivo. Las reglas m\u00e1s caras pero efectivas son aquellas que correlacionan eventos de ciclo de vida de token con patrones de actividad del usuario. Quienes inviertan aqu\u00ed ahora reducir\u00e1n en seis meses sus vol\u00famenes de alertas de manera demostrable.<\/p>\n Un segundo punto que a menudo se simplifica en el debate actual: el componente de IA del ataque no solo est\u00e1 en la personalizaci\u00f3n del correo de phishing, sino tambi\u00e9n en la coordinaci\u00f3n en tiempo real del flujo de c\u00f3digo de dispositivo. En 2024, las campa\u00f1as de phishing lo eran est\u00e1ticas como para que un rol del equipo azul pudiera seguir manualmente el proceso. En 2026, la generaci\u00f3n de c\u00f3digo, la personalizaci\u00f3n del correo y la extracci\u00f3n 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\u00fan tienen un bucle de aprobaci\u00f3n manual entre alerta y revocaci\u00f3n de sesi\u00f3n perder\u00e1n en caso real de dos a cuatro horas, durante las cuales el token ya ha ejecuto exportaciones de buz\u00f3n.<\/p>\n La consecuencia para las arquitecturas de seguridad: la revocaci\u00f3n de sesi\u00f3n debe pasar de ser una decisi\u00f3n manual a una impulsada por pol\u00edticas. En Entra ID, esto significa espec\u00edficamente la activaci\u00f3n de CAE con revocaci\u00f3n ante detecci\u00f3n de riesgo, en Okta la integraci\u00f3n de se\u00f1ales de riesgo con suscripci\u00f3n de registros del sistema y playbooks de respuesta autom\u00e1ticos. Las organizaciones que hemos considerado bien preparadas han invertido entre seis y doce semanas precisamente en esta automatizaci\u00f3n y despu\u00e9s han reducido el tiempo de permanencia (dwell-time) a menos de 45 minutos.<\/p>\n Si un ataque de c\u00f3digo de dispositivo aparece en la propia telemetr\u00eda, tres acciones son cruciales en las primeras 24 horas. Primero, revocaci\u00f3n de sesi\u00f3n para la cuenta de usuario afectada mediante PowerShell de Entra ID o API de Okta; la invalidaci\u00f3n de token es m\u00e1s importante que el restablecimiento de contrase\u00f1a, ya que el token ya est\u00e1 activo. Segundo, revisi\u00f3n de registros de auditor\u00eda de los \u00faltimos 30 d\u00edas en busca de accesos a buz\u00f3n, consentimiento de aplicaci\u00f3n OAuth y exfiltraci\u00f3n de datos, que a menudo comienzan pocas horas despu\u00e9s de la toma del control del token. Tercero, threat hunting para campa\u00f1as paralelas: los ataques de c\u00f3digo de dispositivo suelen venir en oleadas, una sola v\u00edctima rara vez es la \u00fanica afectada en la organizaci\u00f3n. Quien espera una semana para aclarar el alcance completo, ha perdido la ventana para contener el incidente.<\/p>\n Una dimensi\u00f3n subestimada de una evasi\u00f3n exitosa de MFA adaptativo es la comunicaci\u00f3n ascendente. Los consejos de administraci\u00f3n esperan una declaraci\u00f3n clara sobre por qu\u00e9 la inversi\u00f3n existente en MFA no ha detenido a los atacantes. La explicaci\u00f3n es t\u00e9cnicamente simple pero pol\u00edticamente delicada: el motor de riesgo no ha fallado, fue eludido. Para la comunicaci\u00f3n, se recomienda un enfoque sobrio en tres pasos: \u00bfcu\u00e1l fue el camino de ataque concreto?, \u00bfqu\u00e9 brecha de control se explot\u00f3?, \u00bfqu\u00e9 tres medidas cierran esta brecha hasta fin de trimestre. Quien en este momento se desv\u00eda hacia jerga t\u00e9cnica pierde confianza. Quien cuenta la historia clara obtiene la aprobaci\u00f3n presupuestaria para implementaci\u00f3n de FIDO2 y activaci\u00f3n de CAE m\u00e1s r\u00e1pido de lo que ser\u00eda posible en un ciclo presupuestario normal.<\/p>\n Para la comunicaci\u00f3n con el consejo supervisor, un componente adicional es importante: las lecciones aprendidas deben incorporarse como prueba formal de mitigaci\u00f3n de riesgo en la documentaci\u00f3n NIS2. El art\u00edculo 21 no solo exige el an\u00e1lisis inicial de riesgo, sino tambi\u00e9n el ajuste continuo tras incidentes. Un incidente de evasi\u00f3n de MFA adaptativo sin correcci\u00f3n documentada ser\u00e1 un hallazgo en la pr\u00f3xima auditor\u00eda con impacto en la evaluaci\u00f3n general.<\/p>\n La MFA adaptativa fue para muchas organizaciones una mejora de comodidad alej\u00e1ndose de la MFA est\u00e1tica. En 2026 est\u00e1 claro: comodidad y seguridad no son equivalentes. Una buena configuraci\u00f3n de MFA adaptativa en 2026 es m\u00e1s restrictiva, no m\u00e1s tolerante, y combina factores resistentes al phishing con validaci\u00f3n agresiva de sesi\u00f3n. Quien aborde esto en los pr\u00f3ximos dos trimestres sacar\u00e1 a su propia organizaci\u00f3n de la estad\u00edstica de los 7 millones. Quien espera, conf\u00eda en que las campa\u00f1as con IA no afectar\u00e1n a su empresa. Esto no es una estrategia de seguridad, es casualidad. Y la casualidad en la situaci\u00f3n de amenaza actual es el componente arquitect\u00f3nico m\u00e1s caro que una organizaci\u00f3n puede permitirse, si se calculan realistamente los costes de un incidente y la posterior adaptaci\u00f3n a NIS2.<\/p>\n Cada pregunta est\u00e1 bloqueada. Un toque desbloquea la respuesta.<\/p>\n No. El flujo ha sido desarrollado para escenarios espec\u00edficos (autenticaci\u00f3n de dispositivo compartido, IoT, herramientas de l\u00ednea de comandos sin navegador) y es \u00fatil en esos casos. El riesgo surge cuando est\u00e1 activado de manera generalizada y sin restricciones, y puede ser abusado como vector de phishing. La soluci\u00f3n no es desactivar el flujo, sino restringirlo conscientemente a los casos de uso documentados.<\/p>\n<\/details>\n En los registros de inicio de sesi\u00f3n de Entra ID, los eventos de c\u00f3digo de dispositivo est\u00e1n marcados expl\u00edcitamente (AuthenticationProtocol = DeviceCode). Una regla de anomal\u00eda KQL que alerte sobre poblaciones de usuarios inusuales con eventos de c\u00f3digo de dispositivo detecta la mayor\u00eda de las campa\u00f1as en las primeras horas. En Okta, la misma informaci\u00f3n se encuentra en el registro del sistema bajo \u00ablogin.device_code\u00bb. Importante: La regla debe activarse para nuevas cohortes de usuarios, no solo por volumen.<\/p>\n<\/details>\n Parcialmente. El bloqueo geogr\u00e1fico en pa\u00edses no utilizados reduce el nivel de ruido, pero los atacantes utilizan cada vez m\u00e1s redes de proxy residenciales en el mismo pa\u00eds que la v\u00edctima. El bloqueo geogr\u00e1fico no reemplaza las contramedidas mencionadas anteriormente, solo alivia el an\u00e1lisis de alertas.<\/p>\n<\/details>\n NIS2 exige en el art\u00edculo 21 medidas adecuadas contra el acceso no autorizado, an\u00e1lisis de riesgo documentado y notificaci\u00f3n de incidentes. Una campa\u00f1a exitosa de c\u00f3digo de dispositivo con exfiltraci\u00f3n de datos cae as\u00ed en la obligaci\u00f3n de notificaci\u00f3n. Para prepararse para tal caso, es obligatorio documentar las medidas de MFA implementadas y sus limitaciones. Quien no documente una pol\u00edtica de restricci\u00f3n de c\u00f3digo de dispositivo, no tendr\u00e1 una buena posici\u00f3n en la auditor\u00eda NIS2.<\/p>\n<\/details>\n Para una empresa de 5.000 empleados, calculamos entre 150.000 y 280.000 euros en el a\u00f1o 1 (hardware, licencias de IdP, integraci\u00f3n de soporte, formaci\u00f3n). 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\u00f1o, que se encuentran en el rango de coste de 150.000 euros hacia arriba.<\/p>\n<\/details>\n Para la mayor\u00eda de las organizaciones, la respuesta es: s\u00ed, con excepciones para grupos de usuarios documentados. Una matriz de excepciones limpia suele incluir tres a cinco casos de uso (herramientas de l\u00ednea de comandos para administradores, implementaciones espec\u00edficas de IoT, cuentas de servicio con prop\u00f3sito de uso documentado). Todo lo dem\u00e1s deber\u00eda bloquearse mediante una pol\u00edtica de acceso condicional, siempre que no exista una justificaci\u00f3n de negocio clara.<\/p>\n<\/details>\n Fuente de la imagen de portada: Pexels \/ Tima Miroshnichenko (px:5380610)<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"Barracuda informa de 7 millones de ataques de phishing con c\u00f3digo de dispositivo en 4 semanas. Por qu\u00e9 la MFA adaptativa en Entra\/Okta\/Duo es eludida y qu\u00e9 medidas est\u00e1n funcionando ahora.","protected":false},"author":10,"featured_media":13001,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_focuskw":"mfa adaptativa c\u00f3digo de dispositivo ataque","_yoast_wpseo_title":"MFA adaptativa bajo ataque: Por qu\u00e9 los motores de riesgo no detectan la ola de","_yoast_wpseo_metadesc":"Barracuda 23.04.2026: 7 millones de phishing con c\u00f3digo de dispositivo. Por qu\u00e9 los motores de riesgo de MFA adaptativa fallan y qu\u00e9 3 contramedidas est\u00e1n funcionando ahora.","_yoast_wpseo_meta-robots-noindex":"","_yoast_wpseo_meta-robots-nofollow":"","_yoast_wpseo_meta-robots-adv":"","_yoast_wpseo_canonical":"","_yoast_wpseo_opengraph-title":"","_yoast_wpseo_opengraph-description":"","_yoast_wpseo_opengraph-image":"","_yoast_wpseo_opengraph-image-id":0,"_yoast_wpseo_twitter-title":"","_yoast_wpseo_twitter-description":"","_yoast_wpseo_twitter-image":"","_yoast_wpseo_twitter-image-id":0,"_evm_slot_owner":"","evm_cvss":0,"evm_risk":0,"evm_casefile":"","evm_primary_cve":"","evm_pin_until":0,"evm_external_preview_token":"","evm_external_preview_expires":"","_evm_translation_lang":"","featured_post":0,"featured_post_sortierung":0,"_wp_old_slug":[],"footnotes":""},"categories":[257],"tags":[],"class_list":["post-13025","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-praxis-umsetzung-es"],"evm_reading_time_minutes":16,"wpml_language":"es","wpml_translation_of":13022,"_links":{"self":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts\/13025","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/comments?post=13025"}],"version-history":[{"count":3,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts\/13025\/revisions"}],"predecessor-version":[{"id":19238,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/posts\/13025\/revisions\/19238"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/media\/13001"}],"wp:attachment":[{"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/media?parent=13025"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/categories?post=13025"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.securitytoday.de\/es\/wp-json\/wp\/v2\/tags?post=13025"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Por qu\u00e9 los motores de riesgo fallan sistem\u00e1ticamente<\/h2>\n
Blog de seguridad de Microsoft del 6 de abril de 2026 en t\u00e9rminos sencillos<\/h3>\n
Las cifras del panorama de amenazas actual<\/h2>\n
Tres contramedidas que realmente funcionan<\/h2>\n
Medida 1: Configurar restrictivamente el flujo de c\u00f3digo de dispositivo<\/h3>\n
Medida 2: FIDO2 y Passkeys como factor principal<\/h3>\n
Medida 3: Vinculaci\u00f3n de sesi\u00f3n y validaci\u00f3n continua<\/h3>\n
Qu\u00e9 deben evaluar internamente de manera diferente los motores de riesgo<\/h3>\n
La dimensi\u00f3n de la IA en el ataque: lo que ha cambiado desde 2024<\/h3>\n
Qu\u00e9 cuenta en la primera semana de respuesta a incidentes<\/h3>\n
Comunicaci\u00f3n hacia el consejo de administraci\u00f3n y el consejo supervisor<\/h3>\n
Verificaci\u00f3n final del pragmatismo<\/h3>\n
Preguntas frecuentes<\/h2>\n
\u00bfEs el flujo de c\u00f3digo de dispositivo fundamentalmente inseguro?<\/strong><\/summary>\n
\u00bfC\u00f3mo detecto un ataque en curso de c\u00f3digo de dispositivo en los registros?<\/strong><\/summary>\n
\u00bfAyuda el bloqueo geogr\u00e1fico a mejorar la situaci\u00f3n?<\/strong><\/summary>\n
\u00bfC\u00f3mo se posiciona NIS2 frente a la evasi\u00f3n de MFA adaptativa?<\/strong><\/summary>\n
\u00bfCu\u00e1l es el coste realista de una implementaci\u00f3n de FIDO2?<\/strong><\/summary>\n
\u00bfDeber\u00edamos desactivar completamente el flujo de c\u00f3digo de dispositivo?<\/strong><\/summary>\n
Red: Siga leyendo en Security Today<\/h3>\n
\n