La filtración de Figure demuestra que la MFA tradicional ya no basta

En febrero de 2026 saltó la alarma: una filtración vinculada a Figure —una entidad del sector financiero— dejó al descubierto casi un millón de direcciones de correo electrónico. Ese recuento, impresiona por su magnitud, pero entenderlo solo como una cifra es quedarse en la superficie. Una colección de correos electrónicos expuestos no es el fin del incidente, es el inventario inicial que los atacantes transforman en vectores de acceso.

Cuando un conjunto masivo de direcciones entra en manos hostiles, esas direcciones pasan inmediatamente a alimentar procesos automatizados. Primero, se combinan con bases de datos de siniestros previos para lanzar campañas de credential stuffing: pares de correo y contraseñas reutilizadas se prueban a escala contra portales corporativos, pasarelas VPN y proveedores de identidad de uso masivo. Informes y guías de seguridad sobre credential stuffing y su impacto muestran que, con listas recientes y bien segmentadas, las tasas de éxito pueden producir miles de combinaciones válidas en cuestión de horas; la industria lo documenta y explica con detalle en recursos como los de Imperva.

En paralelo, la misma lista permite campañas de phishing dirigidas y altamente personalizadas. La inteligencia artificial acelera la generación de correos con señuelos creíbles: mensajes que parecen comunicaciones internas, que mencionan nombres de proyectos o departamentos, y que replican la estética de servicios legítimos. Con una dirección de correo y datos públicos como cargos o perfiles en redes profesionales, un atacante puede producir en minutos un envío muy convincente. Para quienes quieren profundizar en cómo las herramientas y los kits de explotación facilitan estas operaciones, los repositorios y análisis técnicos sobre proxies de phishing en tiempo real son una referencia, por ejemplo en los proyectos de código abierto Evilginx2 y Modlishka.

Tercero, la exposición de correos alimenta intentos de ingeniería social dirigidos al servicio de soporte: llamadas o interacciones donde el atacante, con datos básicos de OSINT, finge ser un empleado para solicitar reinicios de contraseña, reseteos de MFA o desbloqueos de cuenta. Esa técnica ataca directamente el proceso humano que existe para corregir fallos de autenticación, y no necesita vulnerabilidades técnicas en los sistemas.

En todos estos flujos no hay que imaginar un “exploit” sofisticado; la finalidad del atacante no es explotar un agujero del software, sino iniciar sesión como un usuario legítimo. Y ahí está el matiz que muchas veces se pierde en las noticias: el riesgo real es la cadena de ataque que sigue a la filtración, y la pregunta crítica es si los controles de autenticación de una organización pueden interrumpir esa cadena en algún punto.

La respuesta, por desgracia, suele ser negativa. Gran parte de la industria ha confiado en formas de MFA —notificaciones push, códigos SMS, TOTP— que protegen la transmisión de un código o la posesión de un dispositivo, pero colocan a una persona como el último eslabón decisorio. Esa dependencia humana es precisamente lo que atacan los métodos de relay en tiempo real (también llamados AiTM, adversary-in-the-middle). En un ataque de este tipo, un proxy malicioso retransmite las acciones entre la víctima y el servicio legítimo: las credenciales se ingieren en una página clonada, el proxy las reenvía al sitio real, el servicio genera un reto de MFA, y la víctima, que cree estar interactuando con el sitio legítimo, completa la segunda factor. El atacante recibe así una sesión autenticada pese a no haber “explotado” el software del servicio.

Es importante entender por qué las formas de MFA más comunes no interrumpen ese ataque. Los mecanismos que verifican un código o confirman una notificación no distinguen si el intercambio se produjo directamente entre usuario y servicio, o a través de un intermediario que retransmite la transacción en tiempo real. Además, existe el fenómeno conocido como “MFA fatigue”: repetidas solicitudes de aprobación pueden llevar a usuarios cansados o confundidos a aceptar notificaciones sospechosas. Microsoft y otros equipos de seguridad han documentado y advertido sobre estos patrones y su explotación por actores criminales; para quienes quieran revisar análisis institucionales sobre estas tácticas, los blogs de seguridad de grandes proveedores y los centros de respuesta a incidentes son fuentes útiles, como Microsoft Security y los reportes de divulgadores independientes como KrebsOnSecurity.

El enfoque habitual de la industria —formación a usuarios para detectar phishing y recordatorios sobre no aceptar solicitudes inesperadas— no es erróneo, pero se queda corto. La insuficiencia es de arquitectura, no únicamente de comportamiento. Un ataque de relay no depende de la habilidad del usuario para reconocer una página clonada: la notificación MFA que recibe es legítima, emitida por el servicio, dentro de la aplicación habitual. No hay pistas evidentes para que el humano detecte la maniobra.

Si la pregunta que deben responder auditores, reguladores y aseguradoras hoy es “¿pueden probar ustedes que la persona autorizada estuvo físicamente presente y fue biométricamente verificada en el momento de la autenticación?”, muchas implementaciones tradicionales quedan sin respuesta. Los estándares y orientaciones sobre identidad ya diferencian entre la prueba de presencia de un dispositivo y la verificación del individuo; el primer caso no garantiza que la persona haya sido la que operó el acceso. El documento de NIST sobre pautas de autenticación digital y las recomendaciones de la FIDO Alliance explican las limitaciones y las direcciones hacia mecanismos de autenticación resistentes al phishing; ver, por ejemplo, la guía del NIST en SP 800-63B y los materiales de la FIDO Alliance.

¿Qué propiedades debe tener una autenticación para cerrar de verdad la puerta a estos ataques? Pueden resumirse en tres exigencias técnicas que deben coexistir: en primer lugar, un enlace criptográfico al origen que haga imposible que un sitio falso firme una transacción destinada a otro dominio; en segundo lugar, claves privadas atadas a hardware seguro que nunca abandonen ese enclave, para que no puedan ser copiadas o retransmitidas; y en tercer lugar, una verificación biométrica en tiempo real que confirme la presencia del individuo autorizado en el acto de autenticación. Combinadas, estas garantías impiden que un proxy produzca firmas válidas desde un origen distinto, que una sesión sea reproducida con material criptográfico exfiltrado, o que un atacante complete el proceso sin la presencia física del titular.

FIDO2/WebAuthn aporta un avance importante en términos de origin binding y uso de claves en hardware, y por eso suele citarse en estas discusiones. No obstante, las implementaciones estándar pueden quedar cortas si confían en la sincronización en la nube de credenciales o en flujos de recuperación que heredan otras vulnerabilidades. Por eso los expertos reclaman no solo claves vinculadas al dispositivo, sino también la incorporación de autenticación biométrica “en vivo” y controles de proximidad y hardware que cierren las rutas de recuperación inseguras. La especificación WebAuthn del W3C y la documentación de FIDO dan el marco técnico para comprender estas diferencias: W3C WebAuthn y los recursos explicativos de FIDO Alliance.

En el mercado ya aparecen productos que reivindican este enfoque integral: hardware con claves no exportables, biometría local obligatoria y verificación de proximidad. Estos dispositivos intentan eliminar el “juicio humano” como punto final de decisión: si no hay coincidencia biométrica en el momento y lugar de la autenticación, no se firma nada y no se concede acceso. Es una respuesta arquitectónica a la fragilidad que han explotado las campañas de relay y las campañas de MFA fatigue. Como en cualquier medida de seguridad, estas soluciones deben evaluarse por su capacidad de integración, su impacto en la privacidad y sus procedimientos de recuperación ante pérdida de dispositivo; son una pieza de la mitigación, pero orientan la arquitectura hacia un modelo de identidad centrado en la verificación del individuo y no solo del token.

La lección clave que deja la filtración de Figure —y la próxima que inevitablemente vendrá— es que las organizaciones deben evaluar su autenticación desde el punto de vista del atacante que ya dispone de datos iniciales: ¿el modelo de autenticación que usan exige que el usuario, bajo presión y a veces sin señales de alerta, haga la decisión correcta, o bien impide técnicamente que una entidad ajena obtenga acceso sin la presencia y verificación del titular?

Si la respuesta actual es la primera, conviene rediseñar la base. La protección real frente a los ataques que siguen a una filtración masiva pasa por cambiar la arquitectura de autenticación, no solo por entrenar mejor a las personas. Las guías de NIST y las iniciativas de FIDO son puntos de partida para entender el camino técnico; los análisis sobre credential stuffing, AiTM y MFA fatigue muestran por qué el cambio es urgente. Consultar fuentes técnicas y casos documentados ayuda a tomar decisiones informadas: revisen los materiales del NIST SP 800-63B, los recursos de la FIDO Alliance, artículos de investigación y análisis en KrebsOnSecurity o reportes de proveedores como Imperva, y consideren pruebas de concepto que incorporen hardware seguro y biometría en vivo para los accesos de alto riesgo.

La filtración de correos es solo el primer paso de una cadena. La defensa efectiva exige pensar más allá del número de registros expuestos y arquitectar controles que hagan imposible que esos registros se conviertan en accesos válidos.