En febrero de 2026 apareció EvilTokens, una plataforma de phishing como servicio, o PhaaS, diseñada para explotar una zona que muchas empresas todavía observan con demasiada confianza: el consentimiento OAuth.
En apenas cinco semanas, esta operación habría comprometido a más de 340 organizaciones de Microsoft 365 en cinco países, sin depender del robo tradicional de contraseñas ni de los métodos clásicos que suelen activar las alarmas de seguridad.
La mecánica era inquietantemente sencilla. La víctima recibía un mensaje que le pedía introducir un código breve en microsoft.com/devicelogin y completar su desafío habitual de autenticación multifactor.
Para el usuario, todo parecía formar parte de una verificación rutinaria. Entraba en un dominio legítimo, pasaba el MFA y salía convencido de que había confirmado un inicio de sesión normal.
Pero, en realidad, acababa de entregar algo mucho más peligroso que una contraseña: un token de actualización válido, con permisos sobre su correo, archivos, calendario y contactos.
Ese token no vivía como una sesión corriente, sino bajo la duración definida por la política del tenant. En otras palabras, el atacante no necesitaba volver a engañar al usuario cada pocas horas. Ya tenía una llave persistente.
El operador nunca pidió una contraseña, no provocó un nuevo aviso de MFA y tampoco generó un evento de inicio de sesión con apariencia clara de intrusión. El ataque funcionó porque la pantalla de consentimiento OAuth se ha convertido en un gesto automático.
El usuario ve una solicitud de permisos, reconoce una interfaz familiar y pulsa aceptar. Mientras tanto, muchos controles diseñados para frenar el phishing de credenciales siguen mirando hacia otro lado: revisan el inicio de sesión, pero no inspeccionan con suficiente rigor la capa de consentimiento.
Los investigadores suelen describir esta técnica como phishing de consentimiento OAuth o abuso de concesiones OAuth. El clic peligroso de la década pasada era el que entregaba una contraseña.
El clic peligroso de ahora puede entregar un token renovable, firmado por el proveedor de identidad y ubicado por debajo de los controles que muchas organizaciones aún tratan como su perímetro principal.
Tabla de Contenidos
- 1 Por qué el phishing de consentimiento OAuth evade el MFA
- 2 Cómo se normalizó el consentimiento OAuth
- 3 Cuando los permisos crean combinaciones tóxicas
- 4 Qué debes revisar frente al phishing de consentimiento OAuth
- 5 Dónde encajan las plataformas de seguridad con IA
- 6 Cuando el consentimiento también debe ser vigilado
- 7 About Post Author
Por qué el phishing de consentimiento OAuth evade el MFA
Un ataque tradicional de phishing de credenciales captura un usuario y una contraseña que luego deben reutilizarse en algún punto. Ese intento de reutilización deja señales.
La mayoría de los entornos modernos exige un segundo factor cuando detecta el inicio de sesión, y hasta los kits de adversario en el medio, conocidos como AiTM, generan cookies de sesión asociadas a eventos que un SIEM puede correlacionar con ubicación, dispositivo, horario o patrones de viaje imposibles.
El phishing de consentimiento OAuth opera de otra manera. No hay credenciales robadas que el atacante deba reproducir. El usuario se autentica ante el proveedor legítimo, completa el MFA en el dominio correcto y acepta una solicitud de permisos.
Desde el punto de vista del sistema, no ha ocurrido una ruptura del flujo normal. El token que recibe el atacante es el resultado de un proceso permitido, firmado y autorizado.
Por eso el MFA no puede bloquearlo en ese momento: el MFA ya se completó. El problema aparece después, cuando el token queda activo y puede seguir utilizándose para acceder a recursos conforme a los permisos aceptados.
Si el usuario concedió acceso al correo, el atacante puede leer mensajes o autorizó archivos, puede recorrer documentos. Si el permiso incluye acceso sin presencia del usuario, el riesgo se extiende mucho más allá de una sesión puntual.
La situación se agrava con los tokens de actualización. En el caso descrito de EvilTokens, algunos tokens podían sobrevivir a cambios de contraseña y mantenerse válidos durante semanas o meses, según la configuración del tenant.
Restablecer la contraseña, una respuesta clásica ante el compromiso de credenciales, no bastaba para cortar la concesión. Solo una revocación explícita del token o una política de acceso condicional capaz de exigir nuevo consentimiento podía cerrar realmente la puerta.
Cómo se normalizó el consentimiento OAuth
El vector no es nuevo. Existe desde que OAuth se convirtió en un estándar de autorización ampliamente utilizado. Lo que cambió fue el entorno. Hoy los usuarios aceptan pantallas de consentimiento con la misma velocidad con la que antes cerraban banners de cookies.
Cada agente de IA, integración de productividad, extensión del navegador o herramienta conectada a una cuenta SaaS puede presentar una solicitud de permisos.
Para un trabajador del conocimiento, el volumen mensual de consentimientos legítimos es muy superior al que existía cuando se diseñaron muchos modelos originales de amenaza.
Esa saturación crea una costumbre peligrosa: aceptar primero y pensar después. El atacante no necesita romper la confianza; le basta con camuflarse dentro de un hábito ya instalado.
Además, el lenguaje de los permisos suele ser demasiado amable para el riesgo real que representa. Una frase como “leer tu correo” puede sonar limitada, pero en la práctica puede abarcar mensajes, adjuntos, conversaciones compartidas y datos sensibles vinculados al negocio.
Una solicitud como “acceder a tus archivos cuando no estés presente” puede traducirse en un token persistente capaz de operar sin que el usuario esté frente a la pantalla para detectar, frenar o revocar el abuso.
Esa distancia entre el texto visible para el usuario y el alcance operativo del permiso es precisamente el espacio donde prospera el phishing de consentimiento OAuth. La víctima cree que autoriza una función puntual. El atacante obtiene una capacidad sostenida.
Cuando los permisos crean combinaciones tóxicas
Una única concesión OAuth puede abrir una puerta limitada dentro de una aplicación. El verdadero problema surge cuando varias concesiones empiezan a cruzarse entre sistemas.
Imagina a un usuario del área financiera que autoriza a un resumidor de reuniones con IA para acceder a su calendario y buzón. Más tarde, ese mismo usuario concede permisos a un asistente de productividad sobre una unidad compartida de la empresa.
Después, una tercera herramienta de enriquecimiento CRM se conecta a la base de datos de clientes. Cada aprobación parece razonable de forma aislada. Ningún propietario de aplicación autorizó el conjunto completo. Sin embargo, el riesgo ya existe.
La superficie resultante combina correo, calendario, documentos internos y datos de clientes a través de una sola identidad humana. Si una de esas herramientas queda comprometida, puede convertirse en puente hacia información que nunca debería haber quedado conectada bajo una misma cadena de permisos.
A esto se le conoce como combinación tóxica. No se trata solo de un permiso excesivo, sino de una acumulación de autorizaciones entre aplicaciones, integraciones o agentes de IA que ningún responsable evalúa como un riesgo único.
El registro de auditoría de una aplicación puede mostrar su parte del evento, pero no necesariamente revela el puente completo. La relación peligrosa vive entre sistemas, no dentro de uno solo.
El mismo patrón se extiende a instalaciones MCP, consentimientos OAuth y extensiones de navegador. Cada uno puede crear un puente con un clic.
Los servidores basados en Model Context Protocol empiezan a perfilarse como una nueva superficie de ataque similar a OAuth, porque permiten que agentes adquieran alcance sobre recursos mediante mecanismos de confianza inicial que, una vez aprobados, pueden persistir.
El incidente de Salesloft-Drift en 2025 mostró cómo este tipo de dependencia puede escalar. Un conector descendente comprometido se propagó por más de 700 tenants de Salesforce mediante tokens OAuth que los clientes habían aprobado legítimamente.
Cada empresa había autorizado la integración. Ninguna había autorizado el efecto dominó.
Qué debes revisar frente al phishing de consentimiento OAuth
Cerrar esta brecha exige tratar el consentimiento OAuth con la misma seriedad con la que ya tratamos la autenticación. No basta con preguntar quién inició sesión.
También hay que saber qué aplicación recibió permisos, qué alcance obtuvo, quién los aprobó, cuánto tiempo llevan activos y qué sistemas conecta esa autorización.
El primer punto es mantener un inventario vivo de aplicaciones OAuth. No una revisión anual ni una hoja estática, sino una vista continua de cada aplicación de terceros que conserva tokens de actualización dentro del tenant.
Luego conviene revisar la antigüedad de las concesiones y exigir nuevo consentimiento cuando los permisos superan cierto umbral, por ejemplo, treinta días sin validación.
También debes observar identidades que mantienen permisos en tres o más aplicaciones SaaS, porque allí suelen aparecer los cruces más delicados.
Los agentes de IA y las integraciones merecen una categoría propia, especialmente cuando conectan sistemas que ningún dueño de aplicación ha aprobado en conjunto.
A eso se suma una regla clave: las políticas de acceso condicional no deberían activarse únicamente ante eventos de inicio de sesión, sino también ante eventos de consentimiento.
Por último, la respuesta debe ser quirúrgica. Ante una concesión sospechosa, suspender al usuario puede resultar excesivo o insuficiente. Lo que necesitas es capacidad de revocar un token OAuth específico, cortar el puente afectado y preservar la operación legítima cuando sea posible.
Dónde encajan las plataformas de seguridad con IA
Una nueva generación de plataformas está intentando resolver este problema desde el lugar correcto: el grafo de identidad y permisos. Su valor está en mapear concesiones OAuth, agentes de IA e integraciones de terceros en el momento en que aparecen, en lugar de esperar a una auditoría tardía.
Reco es uno de los ejemplos más visibles de este enfoque. Su propuesta combina seguridad para agentes de IA, gobierno de identidades y detección de amenazas en un mismo plano de control.
Mediante un grafo de conocimiento de identidad, conecta usuarios humanos, identidades no humanas, aplicaciones, concesiones OAuth e integraciones dentro del ecosistema SaaS.
Este tipo de visibilidad permite descubrir permisos a medida que se crean, asociar cada alcance con la identidad que lo aprobó, detectar desviaciones de comportamiento y revocar acceso a nivel de token, no solo a nivel de cuenta.
Para los equipos de seguridad, esa diferencia importa. El riesgo ya no vive únicamente en el inicio de sesión, sino en las relaciones persistentes que se forman después.
Cuando el consentimiento también debe ser vigilado
El phishing de consentimiento OAuth difícilmente seguirá siendo un problema marginal. La autenticación resistente al phishing ha recibido años de inversión, controles y atención ejecutiva.
La capa de consentimiento, en cambio, todavía funciona en demasiadas organizaciones como una zona de confianza implícita.
Ese desequilibrio ya no es sostenible. Si los atacantes pueden obtener tokens legítimos mediante clics aparentemente normales, entonces el consentimiento debe entrar en el mismo nivel de monitoreo, gobierno y revocación que la autenticación.
Proteger el perímetro ya no significa únicamente verificar quién eres. También significa entender qué autorizas, durante cuánto tiempo, con qué alcance y entre qué sistemas estás creando nuevos puentes de riesgo.
1
0
Average Rating