¿Se puede hackear la MFA? Explicación de 8 técnicas comunes de bypass de MFA

La MFA puede ser hackeada. Conozca 8 técnicas de bypass de MFA que usan los atacantes hoy, qué métodos son más vulnerables y cómo reforzar su implementación frente a ellas.

¿Se puede vulnerar el MFA?

La autenticación multifactor (MFA) es el control en el que más equipos confían para evitar que una contraseña robada se convierta en una brecha. Y los atacantes han pasado años aprendiendo a sortearla. Entonces, ¿se puede vulnerar el MFA? Sí. El MFA eleva el costo de un ataque, pero no lo elimina. 

El problema no está en el concepto de MFA. La mayoría de las implementaciones dependen de factores que los atacantes han aprendido a interceptar, redirigir o eludir mediante ingeniería social. Los códigos SMS pueden redirigirse. Las notificaciones push pueden saturarse con spam. Los tokens de sesión pueden robarse después de que se complete una autenticación legítima. Incluso se puede engañar al personal de la mesa de ayuda para restablecer por completo el MFA. El Data Breach Investigations Report (DBIR) 2025 de Verizon concluyó que los patrones de inicio de sesión sospechosos son una señal recurrente de robo de credenciales y actividad de omisión de MFA.

En diciembre de 2024, el FBI y la Cybersecurity and Infrastructure Security Agency (CISA) dieron el paso inusual de aconsejar a organizaciones y usuarios que dejaran de usar MFA basado en SMS, citando explotación activa vinculada a la campaña de espionaje Salt Typhoon dirigida a la infraestructura de telecomunicaciones de EE. UU. La guía móvil de CISA recomienda la autenticación basada en Fast Identity Online (FIDO) como la forma más sólida de MFA eficaz frente a técnicas de omisión.

Comprender cómo funciona cada técnica de omisión es el primer paso para construir defensas que resistan.

8 técnicas comunes de omisión de MFA

Cada técnica a continuación apunta a una debilidad distinta en las implementaciones de MFA, desde errores humanos hasta fallas a nivel de protocolo. Algunas requieren ingeniería social. Otras funcionan sin intervención humana alguna.

1. Bombardeo de solicitudes MFA (fatiga por push)

El atacante obtiene credenciales válidas mediante phishing o brechas de datos, y luego activa repetidas notificaciones push de MFA hasta que el usuario aprueba una por frustración. Según CISA AA23-320A, Scattered Spider "envía continuamente solicitudes de notificación MFA para llevar a los empleados a aceptar la solicitud y obtener acceso a la red objetivo". APT29 también ha utilizado esta técnica.

Qué buscar en su SOC: solicitudes MFA repetidas a una sola cuenta en un período corto, intentos de inicio de sesión desde ubicaciones inusuales y secuencias de autenticación fallida seguidas de una aprobación repentina.

2. Secuestro de sesión y robo de tokens

Esta técnica apunta a lo que ocurre después de la autenticación. Los atacantes explotan vulnerabilidades en la infraestructura de acceso remoto, VPN, puertas de enlace web o servidores de aplicaciones para extraer tokens de sesión válidos. Reproducen esos tokens para establecer sesiones autenticadas sin activar nunca un desafío MFA. Los afiliados de LockBit demostraron esto mediante la falla CitrixBleed (CVE-2023-4966), recolectando tokens de sesión de dispositivos Citrix NetScaler para omitir por completo el MFA.

Para ver cómo se conectan el secuestro de cuentas y el abuso de tokens de sesión, nuestra guía cubre la mecánica y los controles de detección que lo identifican.

Qué buscar en su SOC: sesiones originadas desde ubicaciones geográficamente imposibles, múltiples sesiones concurrentes para un solo usuario y flujos de autenticación que omiten las solicitudes MFA esperadas.

3. SIM swapping

El atacante recopila información de identificación personal (PII) mediante ingeniería social o inteligencia de fuentes abiertas (OSINT), y luego contacta al operador móvil para transferir el número de teléfono de la víctima a una SIM controlada por el atacante. Todos los códigos MFA basados en SMS ahora se enrutan al atacante. Según CISA AA23-320A, Scattered Spider emplea sistemáticamente el SIM swapping como parte de operaciones de extorsión de datos.

Qué buscar en su SOC: pérdida repentina del servicio móvil o mensajes inesperados del operador sobre desactivación de la SIM, uso de códigos MFA por SMS desde dispositivos distintos de los registrados previamente y acceso a cuentas inmediatamente después de actividad de SIM swap.

4. Phishing Adversary-in-the-Middle (AiTM)

El atacante coloca un servidor proxy inverso entre usted y un portal de autenticación legítimo. Usted introduce sus credenciales y completa su desafío MFA. El proxy captura ambos. El atacante usa el token de sesión robado para entrar directamente. 

Las plataformas Phishing-as-a-Service han ayudado a convertir esta técnica en un producto básico. Los kits de phishing con proxy inverso ahora se especializan en ataques AiTM contra flujos comunes de identidad en la nube. Kits como Mamba 2FA apuntan a las principales plataformas de identidad en la nube e implementan identificación anti-bot para evadir el escaneo de seguridad.

Nuestra guía sobre ataques adversary-in-the-middle explica en qué se diferencia AiTM de las técnicas clásicas man-in-the-middle y cómo encontrar indicadores en su entorno.

Qué buscar en su SOC: solicitudes de autenticación originadas desde infraestructura de servidor privado virtual (VPS) o proxy, registros de dominios sospechosos que imitan sus portales de inicio de sesión y breves intervalos entre la introducción de credenciales y el acceso desde una IP diferente.

5. Ingeniería social a mesas de ayuda

Según CISA AA23-320A, Scattered Spider ejecuta un ataque multifase contra el soporte de TI: primero realiza llamadas de reconocimiento para conocer los procedimientos de restablecimiento de contraseñas y luego suplanta a empleados para convencer al personal de la mesa de ayuda de restablecer tokens MFA. Desde principios de 2023, esta técnica ha otorgado acceso a "cuentas de inicio de sesión único (SSO) y suites de aplicaciones basadas en la nube". Las mesas de ayuda contratadas o externalizadas son particularmente vulnerables debido a verificaciones menos estrictas.

Qué buscar en su SOC: volúmenes inusuales de solicitudes de restablecimiento de MFA para cuentas privilegiadas, especialmente fuera del horario laboral, e instalación de herramientas de acceso remoto (TeamViewer, AnyDesk) después de interacciones con la mesa de ayuda.

6. Explotación del protocolo SS7

Signaling System 7, diseñado en la década de 1970, sigue siendo la columna vertebral de las comunicaciones móviles globales. Los atacantes que obtienen acceso a redes SS7 pueden redirigir tráfico SMS e interceptar códigos MFA en tiempo real. El abuso de SS7 puede interceptar códigos y facilitar fraude sin desplegar malware, lo que lo convierte en un riesgo práctico para cualquier organización que dependa de MFA basado en SMS.

Tras la campaña Salt Typhoon, la guía del SANS Institute confirmó que CISA "declaró sin rodeos: 'No use SMS como segundo factor para la autenticación'".

7. Toolkits de phishing en tiempo real

Toolkits como EvilProxy, Evilginx, Sneaky2FA y WikiKit operan como plataformas en tiempo real de captura de credenciales y reproducción de sesiones. Capturan credenciales y tokens de sesión, y luego los reproducen antes de que los usuarios o los equipos de seguridad detecten anomalías. La rápida ventana de reproducción crea una carrera que las herramientas basadas en firmas tienen dificultades para seguir.

El phishing se ha convertido en una amenaza operativa mayor construida en torno al abuso de MFA, herramientas modulares e infraestructura reutilizable. Los investigadores de amenazas siguen documentando cómo los atacantes empaquetan estos flujos de trabajo para su reutilización y distribución.

8. Phishing de OAuth y consentimiento

El atacante registra una aplicación maliciosa con un proveedor OAuth y luego engaña a un usuario para que le otorgue permisos. La aplicación recibe tokens OAuth legítimos con acceso concedido por el usuario, omitiendo por completo el MFA. Los mecanismos de refresh token permiten una persistencia a largo plazo que a menudo sobrevive a los restablecimientos de contraseña.

A partir de ahí, los atacantes manipulan service principals, crean aplicaciones OAuth maliciosas y exfiltran datos sensibles a través de API en la nube y plataformas de colaboración. El grupo patrocinado por el Estado chino Silk Typhoon ha utilizado esta técnica para moverse entre entornos de clientes sin ser detectado.

Qué buscar en su SOC: nuevos registros de aplicaciones OAuth que solicitan permisos de alto privilegio, tokens SAML emitidos sin MFA en los registros de identidad y patrones inusuales de llamadas API a API en la nube o plataformas de colaboración.

Estas ocho técnicas abarcan ingeniería social, explotación de protocolos y abuso posterior a la autenticación. El método MFA que implemente determina a cuántas de ellas está expuesta su organización.

¿Qué métodos MFA son más vulnerables a la omisión?

No todos los métodos MFA están igualmente expuestos a las ocho técnicas anteriores. La siguiente tabla relaciona cinco implementaciones comunes de MFA con las categorías de omisión que pueden derrotarlas, según la guía de CISA sobre resistencia al phishing y las clasificaciones de FIDO Alliance.

Método MFA	Vulnerable a	¿Resistente al phishing?
Códigos SMS / voz	SIM swapping, explotación de SS7, phishing AiTM, toolkits de phishing en tiempo real	No
Aplicaciones TOTP (Google Authenticator, Authy)	Phishing AiTM, toolkits de phishing en tiempo real	No
Notificaciones push	Bombardeo de solicitudes, phishing AiTM	No
Push con coincidencia numérica	Phishing AiTM (el proxy retransmite el número en tiempo real)	No
Llaves de seguridad FIDO2 / WebAuthn	Ninguna de las ocho técnicas anteriores	Sí

El patrón es claro: todo método basado en secretos compartidos o solicitudes aprobadas por el usuario cae ante al menos una técnica de omisión. Solo la autenticación criptográfica resiste toda la lista.

Por qué falla el MFA de secreto compartido

Los primeros cuatro métodos se apoyan en secretos compartidos o solicitudes aprobadas por el usuario, exactamente lo que un atacante puede interceptar o retransmitir. Las llaves FIDO2 funcionan con un principio completamente distinto. La clave privada nunca sale de su dispositivo y cada desafío de autenticación queda vinculado criptográficamente al dominio real. Un proxy de phishing no puede falsificar una firma válida, porque el dominio nunca coincide. Según NIST 800-63-4, solo los autenticadores que usan "procesos criptográficos de clave asimétrica" califican para el nivel más alto de garantía.

Si hoy utiliza MFA basado en SMS o push, puede reducir su riesgo de inmediato. Mueva primero las cuentas privilegiadas a llaves FIDO2 y luego proporcione a los usuarios estándar autenticadores de plataforma como Windows Hello y Apple Touch ID. Es una implementación por etapas, no una sustitución total, y la vía más práctica hacia la resistencia al phishing sin interrumpir ni una sola jornada laboral.

Ejemplos reales de ataques de omisión de MFA

Las técnicas anteriores no son teóricas. Las brechas del mundo real muestran cómo los atacantes encadenan técnicas de omisión de MFA en ataques de múltiples etapas, a menudo en cuestión de horas tras obtener el acceso inicial.

1. MGM Resorts (2023). Scattered Spider comprometió el entorno de MGM llamando a la mesa de ayuda, suplantando a un empleado y persuadiendo al personal para restablecer credenciales MFA. El ataque utilizó LinkedIn para identificar al personal de TI y recopilar los detalles necesarios para superar las verificaciones. La interrupción se extendió a operaciones hoteleras, sistemas de casino y datos de clientes, con daños reportados superiores a 100 millones de dólares según la presentación 8-K de MGM ante la SEC.
2. Uber (2022). Un atacante compró credenciales robadas en un mercado de la dark web y luego lanzó una campaña sostenida de bombardeo de solicitudes MFA contra un contratista de Uber. Después de que el contratista aprobara una notificación push para detener las alertas, el atacante se movió lateralmente por los sistemas internos de Uber, incluidos Slack, AWS y Google Workspace, en cuestión de horas. La actualización oficial de seguridad de Uber confirmó que las credenciales del contratista probablemente se compraron en la dark web tras una infección de malware en su dispositivo personal.
3. Salt Typhoon (2024). El grupo patrocinado por el Estado chino explotó debilidades del protocolo SS7 para interceptar códigos MFA basados en SMS dirigidos a la infraestructura de telecomunicaciones de EE. UU. El FBI y CISA emitieron guía conjunta aconsejando a las organizaciones dejar de usar MFA basado en SMS en respuesta directa a la explotación activa vinculada a esta campaña.
4. Storm-0558 (2023). Microsoft reveló que el actor de amenazas afiliado a China Storm-0558 falsificó tokens de autenticación utilizando una clave de firma de Microsoft obtenida para acceder a cuentas de correo electrónico en la nube de múltiples organizaciones clientes. El ataque omitió los controles MFA estándar al operar en la capa de tokens en lugar de la capa de credenciales, haciendo irrelevante el desafío MFA inicial.

Cada incidente explotó una técnica distinta de la lista anterior. El hilo conductor es constante: los atacantes adaptan su método al eslabón más débil de la implementación MFA de cada organización.

Indicadores de intentos de omisión de MFA

La omisión de MFA deja rastros en los registros de identidad, la telemetría de endpoints y la actividad de red. Detecte esas señales a tiempo y podrá responder antes de que un atacante se afiance.

Anomalías de autenticación:

• Inicios de sesión desde ubicaciones imposibles a los pocos minutos de una autenticación exitosa en otra región
• Múltiples sesiones activas concurrentes para una sola cuenta de usuario
• Flujos de autenticación que se completan sin un desafío MFA correspondiente en los registros de identidad
• Desafíos MFA aprobados fuera del horario laboral o desde dispositivos que no figuran en la lista de dispositivos registrados

Patrones de identidad y acceso:

• Aumento repentino de solicitudes de restablecimiento de MFA para cuentas privilegiadas
• Nuevos registros de aplicaciones OAuth que solicitan permisos de alto privilegio
• Tokens SAML emitidos sin contexto MFA en los registros del proveedor de identidad
• Tickets de mesa de ayuda que solicitan omisión de MFA o restablecimientos de credenciales seguidos inmediatamente de acceso a la cuenta desde un nuevo dispositivo

Señales de red y endpoint:

• Actividad de sesión originada desde infraestructura VPS, proxies de anonimización o nodos de salida Tor
• Breves intervalos entre el envío de credenciales y el acceso posterior desde una IP diferente
• Movimiento lateral que comienza a los pocos minutos de un evento de autenticación exitoso
• Nuevas herramientas de acceso remoto instaladas poco después del contacto con la mesa de ayuda

Estos indicadores rara vez aparecen de forma aislada durante un intento de omisión. Correlacionar eventos de autenticación con señales de endpoint y red es lo que separa una detección real de omisión de un falso positivo.

Cómo prevenir ataques de omisión de MFA

Conocer las técnicas es la mitad de la ecuación. Aquí viene la parte alentadora: cada brecha sobre la que acaba de leer puede cerrarse, y las medidas para hacerlo son bien conocidas.

• Implemente MFA resistente al phishing como control principal. Según la guía de CISA, solo FIDO2/WebAuthn y la autenticación basada en PKI califican como resistentes al phishing. Los códigos SMS, las aplicaciones de contraseña de un solo uso basada en tiempo (TOTP), los enlaces por correo electrónico y las notificaciones push, incluso con coincidencia numérica, quedan explícitamente excluidos. CISA afirma que los métodos MFA heredados están sujetos a phishing, SIM swap, problemas de SS7 y bombardeo de solicitudes. Comience la implementación con sus cuentas de mayor privilegio: administradores de dominio, administradores de nube y equipos de seguridad.
• Aplique vinculación de tokens y controles del ciclo de vida de la sesión. NIST IR 8587 proporciona orientación sobre el ciclo de vida de los tokens: aísle las claves de firma del proveedor de identidad, rote las claves según el nivel de riesgo y aplique tiempos de espera de sesión alineados con los niveles de garantía de NIST. Para acceso privilegiado, limite las sesiones y las ventanas de inactividad conforme a los requisitos más altos de garantía de NIST.
• Implemente políticas de acceso condicional. Exija una postura de dispositivo conforme y MFA resistente al phishing para todo acceso a aplicaciones en la nube. Según la guía de Cloud Security Alliance (CSA), incorpore ubicación, cumplimiento del dispositivo, contexto del rol y nivel de garantía MFA en cada decisión de acceso.
• Bloquee los protocolos de autenticación heredados. La Binding Operational Directive (BOD) 25-01 de CISA exige bloquear protocolos heredados porque no pueden admitir MFA. Cualquier flujo de autenticación heredado representa una vía persistente de omisión, incluso cuando los flujos modernos aplican MFA sólido.
• Refuerce los procesos de la mesa de ayuda. Los controles técnicos fallan cuando un ingeniero social convence a su mesa de ayuda de restablecerlos. Exija verificación de identidad por múltiples canales para todos los restablecimientos de MFA en cuentas privilegiadas. Implemente procedimientos de devolución de llamada fuera de banda. Capacite al personal de la mesa de ayuda para reconocer los patrones de reconocimiento que utiliza Scattered Spider.

Incluso con un refuerzo sólido, los intentos de omisión de MFA seguirán ocurriendo. La pregunta pasa a ser con qué rapidez los detecta y detiene cuando suceden.

Omisión de MFA en entornos de nube e identidad

La nube cambia la forma del problema. Introduce riesgos de omisión de MFA que las configuraciones on-premises nunca tuvieron que afrontar.

• Encadenamiento de inicio de sesión único (SSO). Cuando una sesión SSO comprometida concede acceso a decenas de aplicaciones posteriores, una sola omisión exitosa de MFA escala de inmediato. Un atacante que robe un token de sesión de Okta o Microsoft Entra puede moverse por toda la cartera de aplicaciones conectadas sin activar desafíos MFA adicionales en ninguna plataforma integrada.
• Brechas de acceso condicional. Muchas organizaciones aplican MFA resistente al phishing para aplicaciones principales en la nube, pero dejan brechas en conectores de aplicaciones heredadas, endpoints de API o configuraciones de service principal. Los atacantes identifican y explotan estas brechas. CISA BOD 25-01 exige bloquear protocolos de autenticación heredados específicamente porque omiten las políticas de acceso condicional.
• Abuso de service principal y OAuth. Los entornos de identidad en la nube dependen de cuentas de servicio y tokens OAuth para automatización e integraciones. Estas identidades de máquina suelen operar sin controles MFA. Los atacantes comprometen service principals, les conceden permisos elevados mediante phishing de consentimiento OAuth y usan esos permisos para persistir en el entorno mucho después de que se roten las credenciales de acceso inicial.
• Identidad federada y manipulación de SAML. La autenticación federada entre proveedores de identidad y plataformas en la nube crea superficies de ataque adicionales. Un atacante que comprometa una clave de firma, como demostró Storm-0558 en 2023, puede falsificar aserciones SAML y acceder a recursos en la nube sin ninguna interacción MFA.

Asegurar la identidad en la nube requiere aplicar los mismos controles MFA resistentes al phishing a cuentas de servicio y flujos OAuth que aplica a usuarios humanos. La identidad de máquina es la superficie de ataque de más rápido crecimiento en entornos de nube, y la que con mayor frecuencia queda fuera de su perímetro MFA.

Cómo ayuda SentinelOne a detectar ataques de omisión de MFA

Los ataques de omisión de MFA viven en el espacio entre autenticación y acceso. La supervisión exclusiva del proveedor de identidad deja brechas que los atacantes explotan. La SingularityTM Platform de SentinelOne cierra esas brechas al correlacionar eventos de autenticación con comportamiento de endpoints, actividad de red y acciones de usuario en todo su entorno.

Singularity Identity amplía la protección a su infraestructura de identidad. Detecta en tiempo real ataques en curso contra Active Directory y proveedores de identidad en la nube como Entra ID, Ping, Okta, Duo y SecureAuth, tanto on-premises como en la nube. La IA conductual marca patrones de viaje imposibles, uso indebido de credenciales y escalada de privilegios vinculados a manipulación de tokens. Cuando la actividad de identidad coincide con abuso de sesión, la plataforma actúa. Finaliza procesos maliciosos, cierra sesiones comprometidas y aísla endpoints afectados.

Singularity Identity también analiza continuamente credenciales débiles, expuestas y comprometidas, ofreciendo respuestas autónomas para detener ataques basados en credenciales antes de que lleguen a su entorno.

Solicite una demo con SentinelOne para ver cómo puede encontrar y detener ataques de omisión de MFA en todo su entorno.

Conclusiones clave

El MFA sigue siendo esencial, pero no es invulnerable. Ocho técnicas distintas de omisión, desde el bombardeo de solicitudes hasta el phishing de consentimiento OAuth, explotan debilidades del MFA heredado. El camino a seguir es claro: actualizar a una estrategia diseñada para esta amenaza. 

El MFA resistente al phishing (FIDO2/WebAuthn), combinado con supervisión conductual que detecta anomalías posteriores a la autenticación en tiempo real, puede convertir el MFA de una responsabilidad nuevamente en una ventaja real.

Preguntas frecuentes

¿Qué es la autenticación multifactor (MFA)?

La autenticación multifactor (MFA) es un método de seguridad que requiere que los usuarios verifiquen su identidad con dos o más tipos distintos de evidencia antes de acceder a un sistema o una aplicación. 

Estos factores se dividen en categorías: algo que sabes (contraseñas, PIN), algo que tienes (llaves de seguridad, teléfonos) y algo que eres (huellas dactilares, reconocimiento facial). NIST 800-63-4 especifica que los factores deben provenir de diferentes categorías para calificar como MFA verdadero.

¿Por qué se puede eludir la MFA?

La MFA puede eludirse porque la mayoría de las implementaciones dependen de secretos compartidos o solicitudes aprobadas por el usuario, no de vinculación criptográfica. Los códigos SMS, las aplicaciones TOTP y las notificaciones push requieren transmitir o confirmar un valor que un atacante puede interceptar, retransmitir o manipular mediante ingeniería social. 

El propio evento de autenticación también puede eludirse robando tokens de sesión después de que se complete un inicio de sesión legítimo, lo que hace irrelevante el desafío de MFA. Solo FIDO2/WebAuthn elimina esta clase de evasión al vincular criptográficamente la autenticación al dominio legítimo, haciendo que la retransmisión y la interceptación sean técnicamente imposibles

¿Cuál es la diferencia entre la MFA resistente al phishing y la MFA estándar?

La MFA estándar (códigos SMS, notificaciones push, aplicaciones TOTP) se basa en secretos compartidos que los atacantes pueden interceptar, redirigir o reproducir. La MFA resistente al phishing utiliza vinculación criptográfica entre el autenticador y el dominio legítimo. 

Los métodos basados en FIDO2/WebAuthn y PKI (PIV/CAC) verifican la identidad del servidor antes de liberar credenciales, lo que hace que los ataques de retransmisión y AiTM sean técnicamente imposibles. CISA, NIST y la FIDO Alliance clasifican únicamente estos dos métodos como resistentes al phishing.

¿Cómo eluden los atacantes la MFA incluso cuando la coincidencia de números está habilitada?

La coincidencia de números detiene la fatiga básica de notificaciones push al requerir que los usuarios introduzcan un número mostrado. Sin embargo, no detiene el phishing AiTM, donde el proxy del atacante retransmite el flujo de autenticación real en tiempo real. 

El atacante ve la misma solicitud de número y puede retransmitírsela a la víctima. CISA describe la coincidencia de números como una medida temporal mientras las organizaciones hacen la transición a MFA resistente al phishing, no como una defensa permanente.

¿Qué técnica de bypass de MFA es la más común hoy en día?

El robo de tokens y el secuestro de sesiones se presentan en el Verizon 2025 DBIR como las principales preocupaciones de omisión de MFA. Se dirigen a las sesiones posteriores a la autenticación en lugar del evento de autenticación en sí, lo que hace que el desafío inicial de MFA sea irrelevante una vez que se captura un token de sesión válido. 

Detener el robo de tokens requiere monitoreo del comportamiento de la actividad de la sesión, patrones de viaje imposible y anomalías de sesiones concurrentes.

¿Deben las empresas dejar de usar por completo la MFA basada en SMS?

Las organizaciones deben dejar de depender de la MFA basada en SMS. Tras la campaña Salt Typhoon, la guía del FBI y CISA advirtió contra confiar en SMS como segundo factor. Múltiples técnicas de ataque, incluidas la explotación de SS7, el SIM swapping y el phishing AiTM, pueden derrotar la MFA basada en SMS. 

Haga la transición a claves de seguridad FIDO2 para cuentas privilegiadas y autenticadores de plataforma vinculados al hardware para usuarios estándar.

¿Qué técnicas de MITRE ATT&CK se corresponden con los ataques de bypass de MFA?

Las ocho técnicas principales se corresponden con varios ID de ATT&CK: T1621 (MFA Request Generation) cubre el bombardeo de solicitudes y los flujos de phishing en tiempo real. T1550 (Use Alternate Authentication Material) cubre el secuestro de sesión. T1589 (Gather Victim Identity Information) respalda el SIM swapping. 

T1111 (MFA Interception) cubre la explotación de SS7. T1566.004 (Spearphishing Voice) cubre la ingeniería social al service desk. T1606 (Forge Web Credentials) cubre el phishing de consentimiento de OAuth.