En febrero de 2026, se puso en marcha una plataforma de phishing como servicio (PhaaS) llamada EvilTokens. En cinco semanas, había comprometido a más de 340 organizaciones de Microsoft 365 en cinco países.

Los objetivos de la plataforma recibieron un mensaje pidiéndoles que introdujeran un código corto en microsoft.com/devicelogin y completaran su desafío MFA habitual; luego se marcharon creyendo que habían verificado un inicio de sesión rutinario. En realidad, habían entregado al operador un token de actualización (refresh token) válido con alcance limitado a su buzón, unidad, calendario y contactos, con una vida útil basada en la política del inquilino en lugar de una sesión.

El operador nunca necesitó una contraseña, nunca activó un aviso de MFA y nunca generó un evento de inicio de sesión que pareciera una intrusión. El ataque tuvo éxito porque la pantalla de consentimiento de OAuth se ha convertido en un clic instintivo, y los controles diseñados para detener el phishing de credenciales no analizan la capa de consentimiento.

Los investigadores de seguridad llaman a esta condición phishing de consentimiento o abuso de concesión de OAuth. El clic de phishing que importaba la década pasada entregaba una contraseña. El clic de phishing que importa ahora entrega un token de actualización, y se sitúa estructuralmente por debajo de los controles de identidad que la mayoría de las organizaciones siguen tratando como el perímetro.

¿Por qué mfa no puede ver una autorización OAuth?

Un phishing de credenciales entrega un nombre de usuario y una contraseña que deben ser replicados en algún lugar, y la mayoría de los entornos de identidad exigen ahora un segundo factor en esa replicación. Incluso los kits de adversario en el medio (AiTM) producen una cookie de sesión vinculada a un evento de inicio de sesión que el SIEM correlaciona con la geografía, el dispositivo y los patrones de viaje.


Figura 1: El phishing de credenciales deja un rastro de inicio de sesión que el SIEM puede correlacionar.

Una concesión de OAuth no produce credenciales replicadas. El usuario se autentica en el proveedor de identidad legítimo, termina el desafío MFA en el dominio legítimo y hace clic en Aceptar. El token que el atacante obtiene es el sistema funcionando según lo diseñado. Está firmado por el proveedor de identidad, limitado a lo que el usuario aceptó y es actualizable. El MFA no puede bloquearlo porque el MFA ya ocurrió.


Figura 2: Una concesión de OAuth no deja replicación, solo un token actualizable.

El otro problema es que los tokens de actualización amplían la ventana de tiempo. Los tokens emitidos por EvilTokens sobrevivieron a los restablecimientos de contraseña y permanecieron válidos durante semanas o meses, dependiendo de la configuración del inquilino. Rotar la contraseña no invalidó la concesión. Solo la revocación explícita, o una política de acceso condicional que exigiera un nuevo consentimiento, la cerró.

Cómo se normalizó el consentimiento

Este vector de ataque existe desde que OAuth se convirtió en estándar. Lo que ha cambiado es el entorno en el que opera. Los usuarios han sido entrenados para hacer clic en las pantallas de consentimiento al mismo ritmo que antes hacían clic en los banners de cookies. Cada agente de IA instala Surface One. Cada integración de productividad muestra una. Cada extensión de navegador que toca una cuenta SaaS muestra una. El volumen de consentimiento legítimo que un trabajador del conocimiento ve en un mes supera cualquier cosa que existiera cuando se escribieron los modelos originales de amenazas de OAuth.

Los propios alcances utilizan un lenguaje que no se traduce claramente al riesgo. Un alcance llamado "Leer su correo" suena limitado, pero en la práctica cubre cada mensaje, adjunto e hilo compartido al que el usuario puede acceder. Un alcance llamado "Acceder a archivos cuando no esté presente" significa un token de larga duración emitido sin que el usuario esté frente a una pantalla para revocarlo. La brecha entre el lenguaje de consentimiento y el alcance operativo es exactamente donde operan los atacantes.

Un único consentimiento de OAuth otorga al atacante un punto de apoyo limitado dentro de una aplicación. El riesgo más profundo surge cuando esos puntos de apoyo se conectan.

Un usuario de finanzas concede a un resumidor de reuniones de IA acceso a su calendario y buzón. El mismo usuario concede más tarde a un asistente de productividad acceso a la unidad compartida de la empresa. Una tercera concesión conecta una herramienta de enriquecimiento de CRM con la base de datos de clientes. Cada una fue aprobada individualmente. Ningún propietario de aplicación sancionó la combinación. La superficie de riesgo son ahora tres alcances que se intersectan a través de una sola identidad humana, donde el compromiso del resumidor de reuniones puede llegar a borradores de contratos y registros de clientes a través de la misma persona.

Esto se denomina combinación tóxica. Consiste en una ruptura de permisos a través de aplicaciones, conectadas por una concesión de OAuth, una integración o un agente de IA, que ningún propietario de aplicación autorizó individualmente como su propia superficie de riesgo. No puede ser visto por el registro de auditoría de ninguna aplicación porque el puente existe fuera de todas ellas.


Figura 3: Una combinación tóxica entre dos aplicaciones SaaS que ningún propietario sancionó conjuntamente.

La instalación de MCP, el clic de consentimiento de OAuth y la concesión de la extensión del navegador: cada uno es un puente emitido a la velocidad de un solo clic. Los servidores de Protocolo de Contexto de Modelo (MCP) están emergiendo como la siguiente superficie de ataque estilo OAuth, permitiendo que los agentes adquieran un alcance limitado a través del mismo mecanismo de confianza única que ya usan las pantallas de consentimiento.

El incidente de Salesloft-Drift de 2025 mostró cómo se ve esto a escala. Un conector comprometido se propagó a través de más de 700 inquilinos de Salesforce mediante tokens de OAuth que los clientes habían aprobado legítimamente. Cada cliente autorizó la integración. Ninguno autorizó la cascada.

¿Qué revisar para evitarlo?

Cerrar esta brecha requiere tratar el consentimiento de OAuth de la misma manera que el programa de seguridad ya trata la autenticación. Un pequeño conjunto de preguntas expone dónde reside la brecha real.

Área a revisar | Qué significa en la práctica
Inventario de aplicaciones OAuth | Cada aplicación de terceros que posee tokens de actualización en el inquilino, actualizados continuamente en lugar de en el momento de la auditoría.
Antigüedad de la concesión y nuevo consentimiento | Tokens emitidos hace más de 30 días sin un nuevo consentimiento, presentados como una cola.
Identidades entre aplicaciones | Identidades que poseen concesiones en tres o más aplicaciones SaaS, marcadas para revisión.
Puentes de agentes e integraciones | Agentes de IA e integraciones que conectan dos sistemas que ningún propietario de aplicación sancionó conjuntamente.
Acceso condicional en el consentimiento | Políticas que se activan nuevamente en eventos de consentimiento, no solo en eventos de inicio de sesión.
Revocación a nivel de token | Un libro de jugadas que revoca un único token de OAuth en lugar de suspender al usuario.

La disciplina procedimental solo escala hasta cierto punto. Los puentes viven en un grafo que ninguna aplicación individual posee, y se crean a la velocidad de una instalación de MCP o un clic de consentimiento de OAuth. Ver ese grafo continuamente requiere una plataforma construida para vigilar la capa de tiempo de ejecución donde realmente se forman los puentes.

El papel de las plataformas de seguridad basadas en IA

Una nueva clase de plataformas gestiona gran parte de esto automáticamente. Mapean cada concesión de OAuth, agente de IA e integración de terceros en el grafo de identidad en el momento en que se emite, en lugar de esperar a la siguiente auditoría, y luego presentan los puentes, los tokens no utilizados y las desviaciones de política como una cola operativa continua.

Un ejemplo destacado es Reco. Combina la seguridad de agentes de IA, la gobernanza de la identidad y la detección de amenazas en un único plano de control. Su Grafo de Conocimiento de Identidad conecta identidades humanas y no humanas con las aplicaciones, concesiones de OAuth e integraciones a las que pueden acceder en todo el entorno SaaS.


Figura 4: Vista de Reco de las concesiones de OAuth de un agente de IA y las cuentas conectadas.

La plataforma descubre continuamente agentes de IA y concesiones de OAuth a medida que aparecen, mapea cada alcance con la identidad que lo aprobó, monitorea el comportamiento en busca de desviaciones de la política y revoca el acceso a nivel de token en lugar de en la cuenta de usuario. Esto brinda a los equipos de seguridad visibilidad en la capa de tiempo de ejecución donde realmente se forman estas relaciones de confianza.

El phishing de consentimiento probablemente no permanecerá en los márgenes por mucho más tiempo. La autenticación resistente al phishing ha recibido años de inversión y escrutinio, mientras que la capa de consentimiento todavía opera mayoritariamente basándose en la confianza. Cerrar esa brecha significa tratar las concesiones de OAuth y las conexiones de agentes de IA con la misma visibilidad, monitoreo y disciplina de revocación que ya se aplica a la propia autenticación.


Fuente:
THN