El nuevo phishing: cómo OAuth está logrando evadir la MFA

Durante años, las organizaciones centraron sus esfuerzos de ciberseguridad en proteger credenciales: contraseñas, sesiones y autenticaciones multifactor (MFA). Sin embargo, el panorama cambió silenciosamente. Hoy, muchos ataques ya no buscan robar contraseñas; buscan obtener consentimiento.

En febrero de 2026, una plataforma de phishing como servicio (PhaaS) denominada EvilTokens comenzó a operar a gran escala. En apenas cinco semanas logró comprometer más de 340 organizaciones de Microsoft 365 distribuidas en cinco países. El dato más preocupante no fue únicamente el alcance del ataque, sino la forma en que consiguió el acceso: sin robar contraseñas, sin evadir MFA y sin generar alertas evidentes de intrusión.

Cuando el usuario autoriza al atacante sin darse cuenta

Los usuarios afectados recibían un mensaje aparentemente legítimo solicitando ingresar un código en microsoft.com/devicelogin y completar su proceso habitual de autenticación multifactor. Desde la perspectiva del usuario, todo parecía normal: iniciaban sesión en el dominio oficial de Microsoft y validaban su identidad como cualquier otro día.

Pero detrás de esa aparente legitimidad ocurría algo distinto.

Al aprobar el acceso, el usuario estaba otorgando al atacante un refresh token OAuth con permisos sobre correo electrónico, almacenamiento, calendario y contactos. Ese token podía mantenerse activo durante semanas o incluso meses, dependiendo de la configuración del tenant. El atacante no necesitaba contraseñas ni debía volver a autenticarse: el propio sistema le entregaba acceso autorizado.

¿El phishing moderno ya no roba contraseñas

La evolución del phishing marca un cambio profundo en la seguridad digital.

Hace una década, el objetivo era obtener credenciales para reutilizarlas posteriormente. Hoy, el objetivo es persuadir al usuario para que conceda permisos legítimos a aplicaciones maliciosas o comprometidas.

Los investigadores de seguridad llaman a esta técnica:

• Consent Phishing
• OAuth Grant Abuse
• Abuso de consentimiento OAuth

La diferencia es crítica. En un phishing tradicional, el atacante roba credenciales que luego debe reutilizar.

Ese intento suele generar señales detectables:

• nuevos inicios de sesión,
• cambios geográficos,
• dispositivos desconocidos,
• sesiones anómalas,
• alertas del SIEM,
• solicitudes MFA inesperadas.

En cambio, un ataque basado en OAuth no requiere reutilizar credenciales robadas. El usuario inicia sesión directamente con el proveedor legítimo de identidad, supera la MFA correctamente y finalmente hace clic en “Aceptar”.

Desde la perspectiva técnica, el sistema está funcionando exactamente como fue diseñado.

Por qué la MFA no puede detener este tipo de ataque

La MFA protege el proceso de autenticación, pero no necesariamente el proceso de autorización.

Ese es el punto ciego.

Cuando un usuario concede permisos OAuth:

• la autenticación ya ocurrió,
• la MFA ya fue validada,
• el proveedor de identidad considera legítima la operación,
• y el token emitido es completamente válido.

El atacante simplemente aprovecha esa confianza implícita.

A diferencia de una cookie de sesión tradicional, el refresh token puede renovarse automáticamente y mantener acceso persistente incluso después de:

• cerrar sesión,
• reiniciar dispositivos,
• cambiar la contraseña,
• o invalidar sesiones activas.

En muchos entornos, la única forma efectiva de detener el acceso consiste en:

• revocar explícitamente el token OAuth,
• eliminar el consentimiento otorgado,
• o aplicar políticas de acceso condicional que obliguen a revalidar permisos.

Esto convierte a los tokens OAuth en uno de los mecanismos de persistencia más silenciosos y peligrosos dentro de entornos SaaS modernos.

Cómo normalizamos el clic en “Aceptar”

El problema no es únicamente tecnológico. También es conductual. Los usuarios han sido entrenados durante años para aceptar solicitudes de consentimiento sin analizarlas detenidamente. Lo que antes ocurría con banners de cookies ahora sucede con permisos OAuth.

Actualmente, un trabajador promedio interactúa constantemente con solicitudes de acceso provenientes de:

• asistentes de IA,
• extensiones de navegador,
• herramientas colaborativas,
• plataformas de productividad,
• integraciones SaaS,
• conectores empresariales,
• aplicaciones móviles,
• y agentes basados en IA generativa.

El consentimiento se volvió rutinario.

Y ahí es donde los atacantes encuentran ventaja.

Además, el lenguaje utilizado por muchos permisos OAuth minimiza la percepción de riesgo:

La distancia entre cómo se describen los permisos y lo que realmente permiten es uno de los mayores problemas de seguridad actuales.

El verdadero peligro: las combinaciones tóxicas

Un único consentimiento OAuth ya representa un riesgo importante. Pero el escenario se vuelve mucho más grave cuando múltiples integraciones se combinan entre sí.

Imaginemos este caso:

1. Un usuario autoriza una IA para resumir reuniones y acceder a su calendario y correo.
2. Posteriormente concede acceso a una herramienta de productividad conectada al almacenamiento corporativo.
3. Luego habilita una integración CRM con acceso a datos comerciales.

Cada autorización parece razonable por separado.

Sin embargo, juntas crean un ecosistema de acceso interconectado que ningún propietario individual aprobó completamente.

Ese fenómeno se conoce como:

Toxic Combination (Combinación Tóxica)

Se trata de permisos distribuidos entre múltiples aplicaciones que, combinados mediante OAuth, agentes de IA o integraciones, generan superficies de ataque invisibles para los controles tradicionales.

Ningún sistema individual detecta el riesgo completo porque la amenaza existe en la relación entre aplicaciones, no dentro de una sola.

IA, MCP y la próxima generación de riesgos OAuth

La aparición de agentes autónomos y servidores MCP (Model Context Protocol) amplifica aún más el problema.

Los MCP permiten que agentes de IA adquieran permisos sobre múltiples sistemas mediante mecanismos similares a OAuth:

• una autorización rápida,
• un clic de confianza,
• y acceso persistente automatizado.

Esto acelera la creación de “puentes invisibles” entre aplicaciones empresariales.

Cada instalación de un agente de IA puede convertirse en:

• un nuevo vector de acceso,
• una expansión del perímetro,
• o una nueva superficie de persistencia para atacantes.

El incidente Salesloft-Drift de 2025 demostró el alcance potencial de este modelo. Un conector comprometido logró propagarse a más de 700 tenants de Salesforce mediante tokens OAuth previamente autorizados por clientes legítimos. Ninguna organización aprobó el efecto cascada completo.
Solo aprobaron integraciones individuales.

Qué deberían revisar las organizaciones

Las empresas ya no pueden tratar OAuth como un componente secundario de autenticación. Debe ser gestionado como parte central de la seguridad de identidad.

Algunos controles fundamentales incluyen:

Inventario continuo de aplicaciones OAuth

Identificar todas las aplicaciones de terceros con tokens activos y permisos persistentes.

Supervisión de antigüedad de tokens

Detectar consentimientos otorgados hace semanas o meses sin revalidación.

Monitoreo de identidades interconectadas

Usuarios con múltiples integraciones SaaS representan puntos críticos de riesgo.

Detección de combinaciones tóxicas

Identificar conexiones entre aplicaciones que nunca fueron evaluadas conjuntamente.

Políticas de acceso condicional basadas en consentimiento

No limitar las políticas únicamente al inicio de sesión.

Revocación granular de tokens

Eliminar accesos específicos sin deshabilitar cuentas completas.

El futuro de la seguridad de identidad

La autenticación resistente al phishing recibió enormes inversiones durante la última década. Sin embargo, la capa de consentimiento OAuth todavía opera bajo un modelo de confianza excesiva.

Ese desequilibrio está convirtiéndose en uno de los mayores desafíos de la seguridad moderna. El nuevo perímetro ya no son las contraseñas. Ahora el verdadero objetivo es el consentimiento.

Y mientras las organizaciones continúen enfocándose únicamente en autenticación y MFA, los atacantes seguirán explotando la capa menos vigilada del ecosistema de identidad: los permisos legítimos otorgados por los propios usuarios.

Conclusión