Fatiga de MFA y bombardeo de notificaciones: cómo detener las aprobaciones por cansancio

La fatiga de MFA, también llamada push bombing o bombardeo de notificaciones, es un ataque en el que alguien que ya tiene la contraseña de un empleado genera solicitudes de aprobación de inicio de sesión una y otra vez, hasta que el empleado toca "Aprobar" por error o solo para que las notificaciones paren. Si su empresa usa notificaciones push para la autenticación multifactor (MFA), la solución es directa: asegúrese de que el number matching (coincidencia de números) esté activo, muestre el nombre de la aplicación y la ubicación en cada solicitud, permita que el personal reporte solicitudes sospechosas con un toque, refuerce el Acceso Condicional y enseñe a todos una sola regla: si usted no acaba de intentar iniciar sesión, rechácela y avise a TI. Para las cuentas con más privilegios, pase a MFA resistente al phishing.

Si todavía está decidiendo qué métodos de MFA usar, comience con nuestra guía de MFA para empresas. Este artículo se enfoca en una debilidad específica de la MFA basada en notificaciones push y en cómo cerrarla.

Cómo funciona un ataque de push bombing

El push bombing no rompe la MFA. La rodea aprovechándose de la persona que tiene el teléfono.

1. El atacante obtiene una contraseña. Normalmente mediante phishing, una contraseña reutilizada de una filtración antigua o adivinándola.
2. Inicia sesión y genera una notificación. Cada intento envía un aviso de "¿Está intentando iniciar sesión?" al teléfono del empleado.
3. Lo repite. A veces de madrugada, a veces decenas de veces seguidas, a veces acompañado de una llamada o un texto que finge ser la mesa de ayuda de TI ("Estamos arreglando su cuenta, solo apruebe la solicitud").
4. Basta un toque. Si el empleado aprueba una sola vez, el atacante entra.

Esto no es teórico. El aviso conjunto de CISA sobre el grupo Scattered Spider menciona el "push bombing" y el envío repetido de solicitudes de MFA que llevan a los empleados a presionar "Aceptar" entre las técnicas que el grupo usó para burlar la MFA. La hoja informativa de CISA sobre number matching describe el mismo patrón como fatiga de MFA.

Number matching: qué es y si ya lo tiene

Con number matching, la pantalla de inicio de sesión muestra un número y el usuario debe escribir ese número en la aplicación de autenticación para aprobar. Un atacante que está en otro lugar puede generar la solicitud, pero el empleado nunca ve el número en su propia pantalla, así que un toque por reflejo no completa el inicio de sesión.

CISA recomienda la MFA resistente al phishing como meta y describe el number matching como un paso intermedio sólido para las organizaciones que no pueden llegar allí de inmediato.

Microsoft 365 y Microsoft Entra ID

Microsoft hizo obligatorio el number matching para todas las notificaciones push de Microsoft Authenticator a partir de mayo de 2023, y su documentación indica que el number matching "está habilitado para todas las notificaciones push de Authenticator" y que los usuarios no pueden desactivarlo. En la mayoría de los tenants de Microsoft 365 no hay nada que activar, pero revise estas excepciones:

• Extensión NPS (inicios de sesión de VPN y RD Gateway mediante RADIUS): NPS no admite number matching. Las versiones recientes de la extensión NPS piden un código de un solo uso (TOTP) en lugar de Aprobar/Rechazar cuando el usuario tiene uno registrado; las versiones antiguas pueden seguir mostrando Aprobar/Rechazar. Mantenga la extensión actualizada.
• Adaptador de AD FS: el number matching requiere las actualizaciones de Windows Server indicadas en la documentación de Microsoft; los servidores sin parches siguen mostrando Aprobar/Rechazar.
• Versiones antiguas de Authenticator: los usuarios con versiones desactualizadas no pueden iniciar sesión con push hasta que actualicen. Aprovéchelo para mantener los teléfonos de la empresa administrados y al día (vea nuestro servicio de Microsoft Intune).

Google Workspace

Las solicitudes de Google muestran el dispositivo, la ubicación y la hora del intento de inicio de sesión, y Google indica que, cuando detecta algo inusual, como una ubicación diferente, puede pedirle al usuario que haga coincidir un número que aparece en la computadora con uno en el teléfono. Los administradores pueden ir más allá y exigir llaves de seguridad para la verificación en dos pasos, lo que elimina las aprobaciones push para esos usuarios.

Agregue contexto a cada solicitud

Un número por sí solo le dice al empleado "este es un inicio de sesión real", no "este es mi inicio de sesión". Microsoft Authenticator también puede mostrar el nombre de la aplicación y la ubicación geográfica (según la dirección IP) del inicio de sesión. Un empleado en Doral que ve una solicitud para una aplicación que no está usando, desde una ciudad que nunca ha visitado, tiene un motivo claro para rechazarla.

Este es el detalle que muchas pequeñas empresas pasan por alto: Microsoft clasifica ambos ajustes como Microsoft managed (administrados por Microsoft), y hoy el valor administrado por Microsoft para cada uno es Disabled (deshabilitado). Si los quiere, cámbielos usted mismo a Enabled:

1. Inicie sesión en el centro de administración de Microsoft Entra como, al menos, Administrador de directivas de autenticación.
2. Vaya a Entra ID > Authentication methods > Microsoft Authenticator.
3. En la pestaña Configure, cambie Show application name in push and passwordless notifications y Show geographic location in push and passwordless notifications a Enabled para todos los usuarios (o primero para un grupo piloto).
4. Guarde y pruebe con algunos usuarios antes de anunciarlo.

Tenga en cuenta que la ubicación es aproximada y puede ser incorrecta para quienes usan VPN, así que pida al personal que la use como pista, no como prueba.

Permita que el personal reporte una solicitud sospechosa con un toque

Rechazar una solicitud detiene ese intento, pero el atacante sigue teniendo la contraseña. Usted quiere enterarse en ese mismo minuto.

La función Report suspicious activity (Reportar actividad sospechosa) de Microsoft permite que el usuario marque una solicitud de MFA inesperada desde Microsoft Authenticator o por teléfono. Los usuarios que reportan quedan marcados como High User Risk (riesgo de usuario alto), y el evento aparece en los registros de inicio de sesión, los registros de auditoría y el informe de detecciones de riesgo. Igual que los ajustes de contexto, su valor administrado por Microsoft es Disabled, así que habilítela en Entra ID > Authentication methods > Settings.

Lo que pasa después depende de su licencia:

• Con Microsoft Entra ID P2, una política de Acceso Condicional basada en riesgo puede bloquear a los usuarios de alto riesgo o exigir automáticamente un cambio seguro de contraseña.
• Con P1 o inferior, alguien debe vigilar estos eventos y actuar: restablecer la contraseña, revocar sesiones y revisar los inicios de sesión recientes. Un proveedor de TI administrada puede encargarse de este monitoreo.

Reduzca las oportunidades de abusar de las solicitudes

Refuerce el Acceso Condicional

Las políticas de Acceso Condicional (Microsoft Entra ID P1 o superior) deciden cuándo se exige MFA y qué más debe cumplirse. Políticas útiles contra el push bombing:

• Bloquear la autenticación heredada, que no admite MFA moderna.
• Exigir un dispositivo conforme o administrado por la empresa para el correo, los archivos y los portales de administración, de modo que una contraseña robada más una solicitud aprobada siga fallando desde la laptop del atacante.
• Restringir o agregar fricción a los inicios de sesión desde países donde no tiene personal.
• Exigir MFA resistente al phishing (una "authentication strength" o fortaleza de autenticación) para los administradores.

Responda a la primera señal de ataque

Que un empleado reciba solicitudes que no pidió significa que otra persona ya conoce su contraseña. Trátelo como un incidente, no como una molestia:

1. Restablezca la contraseña y revoque las sesiones activas.
2. Revise los registros de inicio de sesión para ver de dónde vinieron los intentos y si alguno tuvo éxito.
3. Busque reglas nuevas en la bandeja de entrada, reenvíos o métodos de MFA registrados recientemente en la cuenta.
4. Pregunte si el empleado reutilizó esa contraseña en otro lugar.

Nuestra guía de señales de phishing explica cómo se suelen robar las contraseñas, y la implementación de un administrador de contraseñas hace mucho menos probable su reutilización.

Capacite a su equipo con una regla sencilla

La tecnología cierra la mayor parte de la brecha, pero la decisión final es un toque humano. Mantenga la capacitación breve y repítala:

• Solo verá una solicitud justo después de iniciar sesión usted mismo. Cualquier otra solicitud es un ataque.
• Rechácela y luego repórtela (con la opción de reporte de la aplicación o llamando a TI).
• TI nunca le llamará ni le enviará un texto pidiéndole que apruebe una solicitud o que le lea un código. Quien lo haga es el atacante.
• Muchas solicitudes seguidas no son una falla técnica. Es alguien que tiene su contraseña.

Los equipos bilingües deben recibir estas reglas en inglés y en español; una tarjeta de una página en ambos idiomas funciona muy bien.

La solución a largo plazo: MFA resistente al phishing

El number matching detiene las aprobaciones por reflejo, pero aún puede burlarse con una página de inicio de sesión falsa y convincente que retransmite el número. La guía de CISA es clara: los métodos resistentes al phishing, como las llaves de seguridad FIDO2 y las passkeys, son la opción más sólida y no son vulnerables al push bombing. Un camino práctico para una pequeña empresa:

1. Comience con los administradores y con quienes aprueban pagos.
2. Use las fortalezas de autenticación del Acceso Condicional para exigir métodos resistentes al phishing a esos grupos.
3. Extiéndalo al resto del personal a medida que se reemplacen los equipos.

Combínelo con la base de nuestra lista de ajustes de seguridad de Microsoft 365.

Lista rápida

Paso	Microsoft 365	Google Workspace
Number matching	Obligatorio para push de Authenticator; revise NPS y AD FS	Se muestra cuando Google detecta inicios de sesión inusuales
Contexto de app y ubicación	Habilítelo (Microsoft managed = Disabled)	Las solicitudes muestran dispositivo, ubicación y hora
Reporte con un toque	Habilite Report suspicious activity	Rechace la solicitud y avise a TI
MFA resistente al phishing	Fortalezas de autenticación para administradores	Exija llaves de seguridad a los administradores
Regla para el personal	Rechace y reporte toda solicitud que usted no inició	Igual

Si quiere ayuda para revisar estos ajustes, monitorear inicios de sesión riesgosos o implementar llaves de seguridad, nuestro equipo de ciberseguridad trabaja con empresas de Miami-Dade y todo el sur de Florida, en inglés y en español. Solicite una evaluación de TI gratuita y revisaremos con usted su configuración de MFA.

Fuentes

• How number matching works in MFA push notifications for Authenticator (Microsoft Learn)
• Use additional context in Authenticator notifications (Microsoft Learn)
• Protecting authentication methods in Microsoft Entra ID (Microsoft Learn)
• Configure Microsoft Entra multifactor authentication: Report suspicious activity (Microsoft Learn)
• Microsoft enforces number matching to fight MFA fatigue attacks (BleepingComputer, en inglés)
• Implementing Number Matching in MFA Applications (CISA, en inglés)
• Implementing Phishing-Resistant MFA (CISA, en inglés)
• Scattered Spider, aviso AA23-320A (CISA, en inglés)
• Iniciar sesión con las solicitudes de Google (Ayuda de la Cuenta de Google)