Phishing de consentimiento: el nuevo vector que roba tokens OAuth y expande el acceso

En febrero de 2026 emergió un servicio que resume la evolución del phishing: EvilTokens. En menos de cinco semanas esta plataforma de phishing-as-a-service comprometió más de 340 organizaciones que usan Microsoft 365 en cinco países, no robando contraseñas sino solicitando un consentimiento OAuth aparentemente inocuo en microsoft.com/devicelogin. El usuario completaba su MFA legítimo, hacía clic en Aceptar y volvía a su tarea con la sensación de haber verificado un inicio de sesión rutinario; el atacante, en cambio, se llevaba un refresh token válido y renovable con acceso a correo, calendario, unidad y contactos, que perduraba mientras la política del tenant lo permitiera.

La mecánica del ataque revela una rotura conceptual: la capa de consentimiento OAuth se mantiene fuera del perímetro que muchas organizaciones protegen con rigor. Mientras que el robo de credenciales provoca señales reconocibles —reintentos, correlaciones de sesión, solicitudes desde ubicaciones anómalas— un grant OAuth legítimo es indistinguible de la operación normal del proveedor de identidad; está firmado, lleva scopes que el usuario aceptó y no genera el tipo de evento que las SIEMs tradicionales consideran sospechoso. El resultado es lo que la comunidad llama consent phishing u OAuth grant abuse, un vector que explota la confianza del usuario y el diseño del protocolo. Para entender su base técnica conviene repasar el estándar: OAuth 2.0 (RFC 6749).

Dos propiedades hacen especialmente potente este abuso: la primera, que la autenticación y el MFA ocurren en el dominio legítimo, por lo que los controles anti-phishing centrados en credenciales fallan; la segunda, que los refresh tokens extienden la ventana de exposición y muchas veces sobreviven a cambios de contraseña. La consecuencia práctica: un atacante no necesita reproducir una sesión humana ni sortear MFA, porque ha obtenido un artefacto de acceso con la misma validez que el resto del ecosistema confía en utilizar de manera automática.

El ecosistema actual amplifica el problema. Los trabajadores reciben una avalancha mensual de solicitudes de consentimiento: agentes de IA que se integran con calendarios, extensiones de navegador que reclaman acceso a cuentas SaaS, conectores que unen aplicaciones de terceros. El lenguaje de los scopes —“Leer tu correo”, “Acceder a archivos cuando no estás presente”— oculta un alcance operacional amplio: cada scope suele traducirse en acceso a todos los mensajes, adjuntos, archivos compartidos y recursos a los que el usuario puede llegar. Esa brecha entre etiqueta y capacidad es el hueco donde atacantes como los operadores de EvilTokens se mueven.

El riesgo verdadero no es solo el acceso aislado a una cuenta, sino las combinaciones tóxicas que emergen cuando permisos aparentemente benignos se interconectan a través de una identidad humana. Un usuario concede a un asistente de reuniones acceso al calendario y al correo, luego autoriza a otro agente al drive compartido y un tercer servicio al CRM; ninguna de estas aprobaciones fue diseñada para interoperar, pero juntas crean un puente que permite a un atacante pivotar entre información confidencial, contratos y datos de clientes. Estas «combinaciones tóxicas» no aparecen en los logs de una única aplicación porque la conexión ocurre fuera del dominio de cualquier dueño de aplicación.

Un nuevo frente emergente son los Model Context Protocol (MCP) y servidores equivalentes que facilitan a agentes de IA adquirir alcance mediante el mismo mecanismo de confianza única que los consent screens explotan. Ya vimos eventos a escala por mecanismos similares: en 2025 una cadena de concesiones legítimas permitió que un conector comprometido se propagara entre cientos de tenants de Salesforce, mostrando que la cascada de OAuth puede convertir una concesión aislada en una infección masiva.

Cerrar esta brecha exige cambiar la forma en que se gobierna el consentimiento: hay que tratar los grants OAuth y las conexiones de agentes de IA con la misma disciplina que se aplica a la autenticación. Eso significa políticas que limiten la delegación automática, revocación ágil de tokens a nivel de aplicación, monitorización continua del grafo de identidades y concesiones, y medidas técnicas que reduzcan la longevidad de los refresh tokens. Microsoft y otros proveedores publican directrices sobre flujos como el Device Code y cómo deben manejarse correctamente los tokens; consultarlas ayuda a entender las opciones de configuración: Azure AD — OAuth 2.0 Device Code.

Además de ajustar configuraciones, las organizaciones deben incorporar detección y visibilidad en tiempo real sobre el runtime del consentimiento. Herramientas que mapean un grafo de identidades y concesiones al momento de su creación facilitan ver puentes inesperados, tokens sin uso o desviaciones de política antes de que se conviertan en un incidente. La integración entre gobernanza de identidad, detección de amenazas y control de agentes de IA se vuelve prioritaria para reducir la ventana de exposición y automatizar la remediación: desde revocar un grant comprometido hasta disparar re-consentimiento forzado o aplicar políticas condicionadas por riesgo.

En lo operativo, los equipos de seguridad deben exigir aprobación administrativa para aplicaciones con scopes elevados, aplicar principios de menor privilegio en las aprobaciones por defecto, limitar la duración de refresh tokens cuando el proveedor lo permita y habilitar la supervisión de actividades inusuales de las aplicaciones (por ejemplo, exportaciones masivas o accesos fuera de horario). La formación sigue siendo necesaria, pero ya no bastará con instruir a los usuarios a no clicar: hace falta que el entorno tecnológico haga difícil autorizar permisos amplios por error.

Por último, el fenómeno obliga a repensar la responsabilidad: la superficie de riesgo es un grafo que ninguna aplicación individual controla por completo. Por eso la mitigación efectiva combina controles de plataforma (configuraciones de tenant, políticas de acceso condicional), herramientas que observan el grafo de consentimiento en tiempo real y procesos organizativos que reduzcan la velocidad a la que se pueden crear puentes (provisión de agentes, procesos de aprobación, verificación de proveedores). El tiempo de reacción debe acortarse desde semanas y auditorías periódicas a minutos y colas operativas contiguas a la emisión del grant.

El modelo de amenazas ha evolucionado: ya no solo defendemos credenciales, defendemos el acto de conceder permisos. Tratar el consentimiento como un recurso crítico y aplicar visibilidad, limitación y revocación con la misma prioridad que al control de accesos y MFA es la línea de defensa que impide que servicios como EvilTokens dejen de ser la excepción y se conviertan en rutina.