En septiembre de 2022, un atacante de 18 años comprometió la red interna de Uber. No explotó una vulnerabilidad de software. No usó malware sofisticado. Compró credenciales de un empleado en la dark web, intentó hacer login y cuando el sistema de MFA envió una notificación push al teléfono del empleado, el atacante le escribió por WhatsApp haciéndose pasar por soporte técnico de Uber: "Vamos a enviarte varias solicitudes de autenticación, necesitas aprobar una para continuar." El empleado confundido por las notificaciones, aprobó. El atacante estaba dentro.

La organización tenía MFA. Eso no fue suficiente.

La autenticación multifactor (MFA) es el control con la mejor relación costo-efectividad disponible en ciberseguridad hoy en día. Microsoft documenta que habilitarla bloquea más del 99,9% de los ataques automatizados a cuentas. Sin embargo, ese número asume que el método MFA implementado es resistente al tipo de ataque específico que enfrenta la organización. A pesar de su eficacia, existe una brecha de adopción preocupante: mientras que el 87% de las grandes empresas tecnológicas ya usan MFA, solo el 34% de las medianas y el 27% de las pequeñas empresas lo han implementado, según datos de JumpCloud.

El hackeo a Uber en 2022 ilustra con precisión el problema, no todos los métodos de MFA son equivalentes y los atacantes ya tienen playbooks específicos para los más débiles.

Qué hace el MFA y por qué las contraseñas solas no alcanzan

El MFA requiere que un usuario demuestre su identidad mediante al menos dos factores independientes de categorías distintas antes de otorgar acceso. La independencia entre categorías es el principio que hace al sistema robusto, comprometer un factor no debería implicar comprometer el otro.

Los factores se clasifican en cuatro categorías.

1. Algo que sabes: contraseñas, PINs, respuestas a preguntas de seguridad.
2. Algo que tienes: un teléfono que recibe un código, una llave de hardware física, una tarjeta inteligente.
3. Algo que eres: biometría: huella dactilar, reconocimiento facial, voz.
4. Algo que haces o dónde estás: patrones de comportamiento, ubicación geográfica, si el dispositivo cumple las políticas de la organización.

El problema con depender solo de contraseñas es estructural, no de disciplina del usuario. Las contraseñas se filtran en brechas de terceros, se reutilizan entre plataformas, se capturan en ataques de phishing y se compran en marketplaces de la dark web por unos pocos dólares.

El informe de adversarios activos de Sophos documenta que más del 67% de los compromisos en 2025 comenzaron con credenciales de identidad. Una contraseña robada en una brecha de hace dos años puede ser el acceso a un sistema corporativo hoy, si el empleado la reutilizó. El MFA cierra esa brecha añadiendo un factor que el atacante no puede obtener solo con la contraseña.

Los métodos de MFA ordenados por resistencia real

La diferencia de seguridad entre los distintos métodos de MFA es más grande de lo que la mayoría de las organizaciones asume al momento de implementar. Hay cuatro niveles que importa distinguir.

SMS y correo electrónico
son el punto de entrada más común porque son los más fáciles de implementar. Son mejor que nada, eliminan los ataques de credential stuffing masivo. Pero son vulnerables a SIM swapping, donde un atacante convence al operador de telefonía de transferir el número de teléfono de la víctima a una SIM bajo su control y a ataques de interceptación en tiempo real donde un proxy de phishing captura el código en el momento en que el usuario lo introduce. El ataque a la brecha de Twilio en 2022 comprometió cuentas protegidas con SMS MFA a escala.

Las aplicaciones de autenticación
(Google Authenticator, Microsoft Authenticator, Authy) generan códigos TOTP, contraseñas de un solo uso basadas en tiempo localmente en el dispositivo. Son significativamente más seguras que SMS porque no dependen del operador de telefonía y los códigos expiran en 30 segundos.

Sin embargo, siguen siendo vulnerables a ataques MITM en tiempo real donde un proxy de phishing captura el código y lo usa antes de que expire, y a los ataques de MFA fatigue que ilustra el caso Uber, notificaciones push que el usuario puede aprobar accidentalmente o por agotamiento.

Las llaves de hardware físicas
(YubiKey, Google Titan) implementan el estándar FIDO2/WebAuthn con criptografía de clave pública vinculada al dominio. La llave solo responde a desafíos de autenticación del dominio legítimo, un sitio de phishing en un dominio look-alike no puede activarla. Son físicamente no exportables y requieren presencia física del dispositivo. Son el único método de MFA verdaderamente resistente al phishing disponible hoy.

Las passkeys
(llaves de acceso) son la evolución hacia passwordless que FIDO Alliance, Apple, Google y Microsoft están impulsando activamente. Reemplazan la contraseña con un par de claves criptográficas, la clave privada nunca sale del dispositivo del usuario, la clave pública se registra en el servicio. La autenticación combina la posesión del dispositivo con biometría local. Como las llaves de hardware, están vinculadas al dominio y son resistentes al phishing por diseño.

Cómo los atacantes clasifican qué MFA vale la pena eludir

Los grupos de amenaza avanzados ya no atacan el MFA de forma genérica. Tienen técnicas específicas para cada método y las seleccionan según qué tipo de MFA tiene el objetivo.

El MFA fatigue o push bombing, la técnica usada contra Uber funciona específicamente contra notificaciones push de aplicaciones de autenticación. El atacante envía decenas o cientos de solicitudes de aprobación hasta que el usuario las aprueba por agotamiento, confusión o suponiendo que es un error del sistema.

La solución es configurar las apps de autenticación para requerir confirmación de número (number matching) o contexto adicional en lugar de un simple botón de aprobar/rechazar.

Los ataques AiTM (adversary-in-the-middle) como el kit FlowerStorm, documentado en el reporte Sophos 2026 interceptan tanto las credenciales como el token de sesión en tiempo real mediante un proxy entre el usuario y el servicio legítimo. El usuario se autentica exitosamente con su MFA de TOTP o push, el proxy captura el token de sesión resultante y el atacante lo reutiliza para acceder al servicio como si fuera el usuario.

Este ataque específicamente evade el MFA de segundo factor basado en códigos. Las llaves FIDO2 son inmunes porque el challenge de autenticación incluye el origen del dominio, un proxy no puede presentar el challenge correcto.

El SIM swapping apunta al SMS MFA con ingeniería social contra el operador de telefonía. Los actores más sofisticados tienen redes de insiders en operadoras que facilitan las transferencias. La solución no es mejorar el SMS MFA, es reemplazarlo.

El caso especial de las identidades no humanas

Un ángulo que la mayoría de las implementaciones de MFA ignoran es el de las identidades no humanas, cuentas de servicio, APIs, AI agents, procesos automatizados. En organizaciones con automatización avanzada, estas identidades superan en número a las humanas.

Aplicar MFA a los usuarios humanos mientras las cuentas de servicio operan con credenciales estáticas o tokens de larga duración crea un punto ciego estructural que los atacantes explotan activamente. Comprometer una cuenta de servicio con permisos excesivos puede dar acceso a más recursos que comprometer la cuenta del CEO.

El MFA para identidades no humanas se resuelve con certificados de corta duración, tokens con tiempo de vida limitado y políticas de acceso condicional que validen el contexto de cada solicitud, desde qué sistema viene, hacia qué recurso va y en qué horario opera. Es más complejo que activar una app de autenticación, pero el riesgo de omitirlo es equivalent al de no tener MFA en las cuentas humanas.

Marco de implementación por nivel de riesgo

La realidad de la mayoría de las organizaciones es que no pueden migrar todo a FIDO2 en un trimestre. El enfoque correcto es priorizar por superficie de riesgo y avanzar incrementalmente.

Las cuentas de administrador con acceso privilegiado, los sistemas financieros y los accesos remotos son el punto de partida obligatorio y el candidato más directo para llaves de hardware o passkeys, el costo de un compromiso en esas cuentas justifica ampliamente la inversión.

Las cuentas de usuarios estándar con acceso a datos sensibles deberían migrar de SMS a apps de autenticación como mínimo, con number matching habilitado para eliminar la vulnerabilidad de MFA fatigue. Las cuentas de servicio y las identidades no humanas requieren un inventario completo antes de cualquier control, no se puede proteger lo que no se sabe que existe.

El plan de recuperación es tan importante como la implementación. Si un usuario pierde su dispositivo de autenticación, el proceso de recuperación debe ser seguro sin ser tan restrictivo que los usuarios lo eviten. Los métodos de recuperación que eluden el MFA (preguntas de seguridad, SMS de respaldo) anulant la protección del método principal, cada canal de recuperación es tan fuerte como su eslabón más débil.

Conclusión: el MFA correcto para la amenaza correcta

El MFA no es binario, no es simplemente tenerlo o no tenerlo. Es un espectro de resistencia donde el extremo más débil (SMS) todavía bloquea los ataques masivos de credential stuffing y el extremo más fuerte (FIDO2) es prácticamente inmune al phishing y al AiTM. Lo que importa es que el método implementado sea resistente al tipo de ataque que enfrenta cada rol y cada sistema en la organización.

La pregunta operativa no es "¿tienes MFA?" Es "¿tu MFA resiste los vectores que los atacantes usan contra organizaciones con tu perfil?" Para responderla, hay que conocer qué métodos están desplegados, en qué cuentas, con qué configuración de recovery, y qué técnicas de evasión son relevantes para ese método específico. Ese inventario es el punto de partida para cualquier mejora real.