Google Workspace: el ataque puede comenzar con OAuth y no con el correo

La nueva cadena: primero el token, después Gmail

Un análisis publicado el 14 de agosto de 2026 sostiene que las brechas asociadas con Vercel y Composio podrían responder a un mismo patrón: el acceso a Google Workspace no comienza necesariamente en el buzón de correo, sino a través de un token OAuth comprometido o de una integración autorizada.

Esta distinción modifica el modelo tradicional de toma de control de cuentas. En el pasado, la secuencia más habitual incluía un mensaje de phishing, el robo de credenciales, el acceso a Gmail y Drive y, finalmente, el movimiento lateral hacia otros servicios. En este escenario, en cambio, el atacante puede entrar en el entorno mediante una aplicación conectada y llegar al correo solo después.

El correo electrónico sigue siendo un elemento central, aunque no siempre como punto de entrada. Una vez alcanzado, puede convertirse en un multiplicador del incidente: suele contener enlaces para restablecer contraseñas, magic links, credenciales almacenadas en conversaciones y referencias a aplicaciones internas.

El análisis está firmado por Rajan Kapoor, VP de Security de Material Security, empresa promotora de la publicación. No se han divulgado detalles técnicos sobre los incidentes de Vercel y Composio: no constan identificadores CVE, campañas atribuidas ni grupos de amenazas asociados.

Por qué OAuth puede sobrevivir al restablecimiento de la contraseña

Un token OAuth permite que una aplicación opere en nombre del usuario según los permisos definidos en sus scopes. Si el token es robado, el atacante puede utilizarlo para acceder a los recursos autorizados sin necesidad de conocer la contraseña.

Esto plantea un problema operativo para los equipos de seguridad. Restablecer la contraseña puede no bastar para interrumpir el acceso, ya que el token podría seguir siendo válido. Según el análisis, algunos tokens tampoco tendrían una caducidad evidente y serían difíciles de detectar si la organización solo supervisa los inicios de sesión, las contraseñas y la actividad del usuario.

El riesgo aumenta cuando el token pertenece a una aplicación de terceros. La vulneración del proveedor o de la integración puede convertirse en un ataque a la cadena de suministro, con un acceso aparentemente legítimo al entorno corporativo.

La secuencia planteada sería la siguiente:

1. se compromete un token OAuth;
2. el atacante utiliza los scopes concedidos a la aplicación;
3. Gmail y Drive quedan accesibles;
4. la cuenta es atacada sin que inicialmente se robe la contraseña;
5. el contenido del correo y de los documentos se aprovecha para alcanzar otros sistemas;
6. los datos se recopilan o se transfieren a terceros.

El aspecto más difícil de detectar es la legitimidad formal del acceso. La aplicación puede estar autorizada, el token puede ser válido y el usuario quizá no observe ninguna señal evidente en su cuenta.

Los agentes de IA convierten los privilegios en acciones automatizadas

La misma dinámica también puede producirse sin un token robado. Cada vez más usuarios conectan agentes de IA a Google Workspace mediante OAuth, concediéndoles la capacidad de leer correos, buscar documentos en Drive y actuar en nombre de personas reales.

Por tanto, un agente puede acceder a datos y servicios según los scopes asignados. El problema no se limita a un comportamiento malicioso o a una prompt injection. Un sistema puede funcionar según lo previsto y, aun así, disponer de privilegios desproporcionados respecto de la actividad solicitada.

Por ejemplo, un agente encargado de recuperar información de un buzón podría tener también la capacidad de consultar conversaciones con credenciales o documentos almacenados en unidades compartidas. Si encuentra instrucciones ambiguas, contenido manipulado o una cadena de decisiones no contemplada por los desarrolladores, podría utilizar esa información para ejecutar acciones posteriores.

La cadena puede incluir:

• lectura de mensajes o carpetas fuera del perímetro necesario;
• identificación de credenciales, datos personales o información confidencial;
• apertura de enlaces y envío de solicitudes a otros servicios;
• transición de una aplicación a otra;
• transferencia de datos a terceros.

En este caso, no es imprescindible que un atacante controle directamente el agente. El riesgo surge de la interacción entre permisos excesivos, el contenido presente en el entorno y la capacidad del sistema para ejecutar acciones automáticamente.

Un operador humano con los mismos privilegios puede aplicar las políticas internas y el sentido común antes de utilizar una información. Un agente, en cambio, tiende a ejecutar la tarea basándose en las instrucciones y los accesos disponibles. Por tanto, el token OAuth asignado a una persona y el concedido a un sistema automatizado pueden exponer privilegios similares, pero con modalidades operativas muy distintas.

Gmail y Drive se convierten en puntos de expansión

En este modelo, Gmail y Drive no son únicamente repositorios de información. También se convierten en infraestructuras para el movimiento lateral.

Un mensaje puede contener el enlace para restablecer una contraseña. Un documento puede incluir una clave de acceso, un procedimiento operativo o una referencia a un servicio interno. Una unidad compartida puede exponer datos a más usuarios y aplicaciones de los previstos.

La consecuencia es que una vulneración aparentemente limitada puede expandirse con rapidez. El acceso a una aplicación autorizada permite leer su contenido; ese contenido puede proporcionar después los medios para alcanzar otras cuentas y sistemas.

El impacto potencial incluye correos electrónicos, documentos corporativos, credenciales, información personal identificable y datos almacenados por aplicaciones conectadas. La automatización puede aumentar la velocidad y la escala de las operaciones, especialmente cuando las herramientas de IA ayudan a localizar información útil y combinarla entre varios servicios.

La fuente no asigna una clasificación formal de gravedad ni proporciona indicadores de compromiso que deban buscarse. Tampoco especifica versiones de software afectadas, productos vulnerables ni plazos de remediación. El caso se refiere al modelo de acceso y control, no a una vulnerabilidad identificada mediante un CVE.

Cómo reducir el riesgo en un entorno de Workspace

La defensa no debería centrarse únicamente en el filtro antiphishing o en la protección de las cuentas de usuario. El primer paso consiste en inventariar las aplicaciones, los tokens OAuth y los scopes realmente concedidos, además de revisar el comportamiento de las integraciones a lo largo del tiempo.

No basta con saber que una aplicación está autorizada. Es necesario observar qué datos lee, con qué frecuencia, de qué usuarios y si su actividad cambia respecto del comportamiento esperado. Un acceso anómalo puede indicar tanto el uso de un token robado como que un agente legítimo está operando fuera de su función.

También son necesarios controles sobre los datos:

• localizar correos que contengan credenciales, PII y enlaces de recuperación;
• verificar la accesibilidad de las unidades compartidas;
• reducir los scopes OAuth que no sean imprescindibles;
• aplicar el principio de mínimo privilegio a usuarios, aplicaciones y agentes automatizados;
• controlar cambios repentinos en la actividad de las integraciones.

El correo requiere una protección específica. Además de bloquear el phishing, los payloads evasivos y los ataques attacker-in-the-middle, conviene impedir que un buzón comprometido se convierta automáticamente en un repositorio operativo para el atacante. El contenido más sensible puede ocultarse o someterse a una verificación step-up antes de permitir el acceso.

La misma regla debe aplicarse a los agentes de IA. Un sistema autorizado a buscar información en el correo no debería poder recuperar sin controles adicionales credenciales, enlaces de restablecimiento ni datos que no necesite para realizar su tarea.

Por último, la visibilidad debe integrar los eventos de correo electrónico, OAuth, Drive y las cuentas. Supervisar estos elementos por separado deja sin cubrir los saltos entre aplicaciones, precisamente los que permiten que un token legítimo o comprometido transforme un acceso inicial en exfiltración y movimiento lateral.