MFA fatigue y push bombing: cuando el aviso de aprobación se convierte en el ataque
La autenticación multifactor funciona mejor cuando el segundo factor exige algo deliberado. Un aviso de aprobación push exige mucho menos: un solo toque. Los ataques de MFA fatigue, también llamados push bombing, explotan esa brecha. Un atacante que ya tiene una contraseña válida provoca intentos de inicio de sesión una y otra vez, saturando el teléfono de la víctima con solicitudes de aprobación hasta que una se acepta: por reflejo, por molestia o en la creencia de que aprobar hará que los avisos por fin se detengan.
Cómo funciona un ataque de push bombing
El patrón es consistente en los casos que los equipos de seguridad han documentado. El atacante parte de credenciales robadas en otro lugar —los registros de infostealers vendidos a granel son un origen común— y comprueba que la contraseña sigue funcionando. Luego intenta iniciar sesión repetidamente, generando notificaciones push en el dispositivo registrado de la víctima. Cada aviso se ve idéntico a uno legítimo, y años de aprobaciones diarias inofensivas han entrenado a muchos usuarios a aprobar casi sin pensar. Las campañas suelen añadir una segunda capa: una llamada o mensaje de alguien que se hace pasar por soporte de TI, indicando al objetivo que acepte los avisos para que se detengan. Desde el lado del usuario esto es desconcertante por diseño. El aviso se presenta como si el usuario hubiera iniciado la sesión, pero nada en la notificación demuestra quién lo hizo. En teoría el aviso es un control de seguridad; en la práctica es un mensaje en su pantalla que cualquiera con su contraseña puede generar, y regenerar, hasta que la fatiga haga el resto. Tratar ese aviso como entrada no confiable es exactamente el cambio mental que estos ataques evitan.Uber, septiembre de 2022: el caso de manual
El ejemplo más citado sigue siendo la brecha de Uber de septiembre de 2022. Como informó TechCrunch, Uber atribuyó la intrusión a un hacker vinculado a Lapsus$ y dijo que la contraseña corporativa de un contratista externo pudo haberse comprado en un mercado de la dark web, según los reportes procedente de registros del malware infostealer RedLine. La contraseña por sí sola no bastaba, porque la cuenta exigía un segundo factor. El atacante generó avisos push durante más de una hora y luego contactó al contratista por WhatsApp haciéndose pasar por IT de Uber, diciéndole que las notificaciones cesarían si las aceptaba. El atacante describió después el resultado a TechCrunch en una sola frase:And well, he accepted and I added my device.Con esa aprobación, el atacante registró su propio dispositivo para la MFA y entró a la red interna de Uber por la VPN. Como documentó BleepingComputer, el acceso se expandió rápido: en el Slack de Uber apareció un mensaje anunciando la brecha, y el atacante alcanzó consolas en la nube, el dominio de Windows y los tickets de HackerOne de la empresa, de donde según los reportes descargó informes privados de vulnerabilidades antes de que se cortara el acceso. En un recurso compartido de red, un script de PowerShell exponía credenciales de administrador de la plataforma de acceso privilegiado de Uber. La cobertura de TechCrunch señaló que el number matching, según los reportes, no estaba activo donde importaba.
Cisco: la misma palanca, usada de otra forma
El equipo de respuesta a incidentes de Cisco, Talos, documentó un caso paralelo el mismo año. El 24 de mayo de 2022, Cisco detectó un compromiso que comenzó con la cuenta personal de Google de un empleado, donde se sincronizaban credenciales corporativas guardadas en Chrome. El atacante combinó llamadas de vishing haciendo pasar por una organización de soporte confiable con solicitudes push de MFA repetidas hasta que una se aceptó, obteniendo acceso por VPN. Talos evaluó con confianza moderada a alta que el actor era un broker de acceso inicial vinculado a UNC2447, Lapsus$ y los operadores del ransomware Yanluowang, y describió la actividad como pre-ransomware: primero el acceso, después la monetización. Dos brechas, la misma puerta: el aviso push, aprobado bajo presión.Number matching y la escalera de mitigaciones
Las mitigaciones son bien conocidas. La guía de CISA afirma que "la MFA resistente al phishing es el estándar al que deberían aspirar todos los líderes de la industria, pero cualquier MFA es mejor que ninguna", señala FIDO/WebAuthn como la única opción resistente al phishing ampliamente disponible y, donde no es viable, recomienda "MFA con coincidencia de números para bloquear el bombardeo push móvil". Microsoft convirtió el number matching en el estándar para sus notificaciones push de Authenticator: la pantalla de inicio de sesión muestra un número y aprobar exige teclear ese número en la app. Un aviso fuera de contexto no tiene número que teclear, y por eso la técnica derrota la aprobación a ciegas.- Trate cada aviso inesperado como entrada no confiable: deníguelo, repórtelo y cambie la contraseña que estaba probando.
- Prefiera factores que exijan una acción deliberada —códigos del autenticador o claves de hardware— antes que el push de aprobar con un toque.
- Nunca sincronice credenciales de trabajo o de alto valor en un perfil de navegador personal; el atacante de Cisco entró justo por ahí.
- Reserve las claves de seguridad de hardware para las cuentas más importantes; según TechCrunch, fueron lo que sostuvo en Cloudflare durante un ataque similar.