19 de Mayo de 2026
El phishing moderno ya no necesita contraseñas
Las víctimas recibían mensajes aparentemente legítimos solicitando ingresar un código corto en microsoft.com/devicelogin y completar su autenticación MFA habitual.
Desde la perspectiva del usuario, todo parecía un proceso normal de verificación de identidad. Sin embargo, al aceptar los permisos OAuth solicitados, estaban autorizando silenciosamente la entrega de un refresh token válido para los operadores maliciosos.
La diferencia clave es que:
- No se roba la contraseña.
- No se intercepta el MFA.
- No existe un inicio de sesión sospechoso que genere alertas tradicionales.
El atacante obtiene un token emitido directamente por Microsoft, firmado legítimamente y con permisos otorgados por el propio usuario.
Por qué MFA no puede detener este ataque
Los sistemas MFA fueron diseñados para proteger autenticaciones y reutilización de credenciales robadas. Sin embargo, en un escenario OAuth legítimo, la autenticación ya ocurrió correctamente.
El usuario:
- Ingresa al dominio legítimo.
- Completa MFA legítimamente.
- Acepta permisos OAuth.
Desde el punto de vista técnico, no existe comportamiento anómalo para el proveedor de identidad.
Esto convierte al consentimiento OAuth en un punto ciego para muchas plataformas SIEM, EDR e incluso políticas modernas de Zero Trust.
Además, los refresh tokens pueden mantenerse activos durante semanas o meses dependiendo de la configuración del tenant. Incluso un cambio de contraseña puede no invalidar el acceso ya concedido.
En muchos casos, solo una revocación explícita del token o políticas avanzadas de re-consentimiento logran cortar el acceso malicioso.
El problema silencioso: usuarios entrenados para aceptar permisos
Los investigadores destacan que el ecosistema SaaS actual ha normalizado peligrosamente las pantallas de consentimiento.
Hoy los usuarios autorizan constantemente:
- Extensiones de navegador.
- Herramientas de productividad.
- Integraciones SaaS.
- Plugins colaborativos.
- Agentes de inteligencia artificial.
- MCP Servers y asistentes automatizados.
Como resultado, los cuadros de consentimiento OAuth se han convertido en un clic casi automático, similar a lo ocurrido durante años con los banners de cookies.
El problema aumenta porque los permisos OAuth suelen expresarse con lenguaje ambiguo o poco comprensible.
Por ejemplo:
- “Leer tu correo” puede implicar acceso total a mensajes y adjuntos.
- “Acceder a archivos cuando no estés presente” implica tokens persistentes de larga duración.
La diferencia entre lo que el usuario cree autorizar y el alcance real del permiso es precisamente donde operan los atacantes.
Las “toxic combinations”: el nuevo riesgo oculto en SaaS
Uno de los conceptos más preocupantes mencionados por investigadores es el de toxic combinations.
Esto ocurre cuando múltiples aplicaciones OAuth, aprobadas individualmente y aparentemente inofensivas, terminan creando una superficie de riesgo combinada.
Por ejemplo:
- Un asistente IA accede al correo y calendario.
- Otra aplicación accede a archivos compartidos.
- Un conector CRM obtiene acceso a bases de clientes.
Cada permiso fue autorizado legítimamente, pero la combinación de todos ellos genera una cadena de exposición que ningún propietario de aplicación evaluó como un único riesgo integrado.
El problema es aún más complejo porque estas relaciones no suelen verse en los logs individuales de cada aplicación, sino en la intersección entre identidades, permisos y conexiones SaaS.
AI Agents y MCP: la próxima superficie crítica
El informe también advierte que los Model Context Protocol (MCP) y agentes de IA están ampliando rápidamente esta superficie de ataque.
Cada instalación de un agente IA, extensión o integración crea nuevos puentes OAuth entre servicios empresariales.
El antecedente más citado es el incidente de Salesloft-Drift en 2025, donde un conector comprometido terminó propagando acceso OAuth a más de 700 tenants Salesforce mediante permisos legítimamente aprobados por los clientes.
Esto demuestra que un único proveedor o integración comprometida puede convertirse en un vector masivo de expansión lateral dentro del ecosistema SaaS.
Qué deberían revisar las organizaciones
Especialistas recomiendan comenzar a tratar los permisos OAuth con el mismo nivel de criticidad que las autenticaciones tradicionales.
Entre los controles prioritarios destacan:
- Inventariar todas las aplicaciones OAuth activas.
- Detectar tokens persistentes antiguos.
- Supervisar identidades conectadas a múltiples SaaS.
- Auditar integraciones IA y MCP.
- Aplicar políticas de Conditional Access sobre eventos de consentimiento.
- Implementar revocación granular de tokens OAuth.
También se recomienda identificar aplicaciones que mantengan refresh tokens de larga duración y revisar permisos que ya no sean necesarios.
Plataformas de seguridad orientadas a OAuth y AI
El crecimiento de este tipo de amenazas ha impulsado nuevas plataformas enfocadas en seguridad SaaS y control de identidad en tiempo real.
Soluciones como Reco permiten mapear:
- OAuth grants.
- Integraciones SaaS.
- AI Agents.
- Identidades humanas y no humanas.
- Tokens persistentes.
Estas plataformas buscan detectar desviaciones de comportamiento, relaciones de riesgo entre aplicaciones y accesos excesivos antes de que sean utilizados por atacantes.
El phishing está cambiando de objetivo
Durante años, la industria enfocó enormes inversiones en autenticación resistente al phishing y protección MFA. Sin embargo, el consentimiento OAuth continúa funcionando principalmente bajo un modelo de confianza implícita.
La realidad actual es que el “clic peligroso” ya no siempre entrega una contraseña: ahora puede entregar un token persistente completamente legítimo.
Y eso cambia radicalmente la forma en que las organizaciones deberán abordar la seguridad de identidad en la era SaaS y de inteligencia artificial.