La cadena de ataque moderna: repensando la seguridad de Google Workspace en la era de la IA

En los últimos dos meses, he escrito por separado sobre las brechas de Vercel y Composio. Cada una ofrece lecciones por sí sola. Pero al leerlas juntas, no dejo de llegar a la misma observación: no son incidentes aislados, sino el mismo ataque ejecutado dos veces contra objetivos diferentes, donde el correo electrónico no fue el punto de entrada al espacio de trabajo. Y una vez que ves el patrón con claridad, cambia lo que crees que necesitas defender. También plantea una pregunta incómoda que me ha estado rondando. El patrón que describo, donde un permiso OAuth se usa para acceder a una cuenta, leer datos confidenciales del correo y Drive, y utilizar ese acceso para moverse más allá del espacio de trabajo, no solo describe lo que hacen los atacantes. Cada vez más, describe lo que los agentes de IA hacen por diseño todos los días. Antes de profundizar, tracemos la cadena de ataque del espacio de trabajo.

El viejo modelo mental: el correo electrónico es el peligro

Durante la mayor parte de la última década, el modelo mental dominante para la seguridad del espacio de trabajo era algo así: el correo es el canal peligroso, y todo lo demás en Google Workspace es relativamente seguro. Ese modelo tenía sentido cuando los atacantes principalmente intentaban robar credenciales mediante phishing. Ya no se sostiene, porque los atacantes han aprendido a encadenar su camino a través del espacio de trabajo, no solo a entrar por la bandeja de entrada.

El correo es el punto de entrada: un correo malicioso (un enlace de phishing, un adjunto armado, un pretexto convincente, un prompt para desviar a un agente de IA) es como comienzan la mayoría de los ataques.
Se roba una credencial: el ataque resulta en el robo de una credencial válida y la toma de control de la cuenta.
Se accede a datos confidenciales en Gmail y Drive: una vez que se toma el control, el atacante salta fácilmente a aplicaciones conectadas dentro de Google Workspace.
Pivotes laterales: un atacante dentro de la bandeja de entrada puede restablecer contraseñas y acceder a aplicaciones adicionales mediante enlaces mágicos.
Establecer persistencia: los atacantes pueden permanecer sin ser detectados dentro de las cuentas durante días, semanas o meses, exfiltrando datos silenciosamente.

Tomado en conjunto, este es el escenario de pesadilla ampliamente reconocido como toma de control de cuenta (ATO). La cadena de ataque del espacio de trabajo comienza con un compromiso de identidad a través del correo y se expande desde allí.

La cadena de ataque en evolución: OAuth como punto de entrada

Los elementos de la cadena de ataque del espacio de trabajo no han cambiado, pero el orden en que se desarrollan ha evolucionado. La secuencia que he observado en Vercel, Composio y un número creciente de incidentes que rastreamos no comienza con el correo en absoluto. En cambio, el guion se invierte: un token OAuth se convierte en la puerta de entrada al correo, no al revés.

OAuth es el punto de entrada: estos ataques comienzan estableciendo persistencia a través de un token OAuth robado. Estos tokens sobreviven a los restablecimientos de contraseña, no expiran y son difíciles de observar. Son invisibles para los usuarios y en gran medida invisibles para los equipos de seguridad que no monitorean el comportamiento de las aplicaciones. Peor aún, el token robado es un ataque a la cadena de suministro: un proveedor se ve comprometido y el resultado es acceso a tu entorno.
Acceso a datos confidenciales: con el token robado, el atacante accede a los datos en Gmail y Drive.
Toma de control de cuentas de correo: el ATO se ejecuta inicialmente usando OAuth, no correo. El acceso al correo convierte una bandeja de entrada comprometida en un incidente mucho más amplio.
Pivotes laterales: usando una combinación de credenciales almacenadas en Drive y restablecimientos de contraseña o enlaces mágicos por correo, el atacante puede moverse lateralmente entre sistemas conectados.

Podemos anticipar que los componentes básicos de la cadena de ataque del espacio de trabajo seguirán siendo consistentes, pero los atacantes, equipados con herramientas de IA para detectar vulnerabilidades y escalar sus esfuerzos, continuarán encontrando formas de recombinarlos. Estos ataques centrados en OAuth son solo un ejemplo de esta evolución.

Las mismas cadenas, un actor diferente

Ahora cambiemos nuestro pensamiento, manteniendo en mente las secuencias de cuatro pasos que acabo de describir. Tus empleados están conectando agentes de IA a Google Workspace en este momento. Esos agentes están autorizados, usan permisos OAuth legítimos, leen correos, buscan en Drive y operan en nombre de usuarios reales para hacer trabajo real. En la mayoría de las organizaciones, esto ocurre más rápido de lo que los equipos de seguridad pueden rastrearlo.

Cuando un agente de IA se comporta inesperadamente, porque sus instrucciones eran ambiguas, porque siguió una cadena de razonamiento que sus desarrolladores no anticiparon, o porque recibió un prompt a través del contenido encontrado en el entorno, puede recorrer el mismo camino que un atacante: accede a una bandeja de entrada o carpeta de Drive que no estaba destinado a alcanzar, lee contenido confidencial como credenciales en hilos de correo o documentos confidenciales en unidades compartidas y hace uso de esa información; toma una acción posterior, como enviar un mensaje, seguir un enlace o hacer una solicitud a otro servicio; y se mueve lateralmente entre aplicaciones, con información confidencial que termina siendo exfiltrada a un tercero.

Sin actor malicioso, sin credencial comprometida; solo un agente que hace algo que su operador no pretendía, en un entorno que no tenía los controles para detenerlo.

Por qué esto importa para cómo piensas la defensa

La mayoría de las conversaciones sobre la seguridad de los agentes de IA se centran en prevenir la inyección de prompts, el red teaming del comportamiento del agente o revisar qué aplicaciones conectan tus empleados. Esos son problemas reales y vale la pena resolverlos. Pero la amenaza que describo no se trata de un agente armado, sino de un agente que opera exactamente como fue construido, en un entorno donde las barreras de seguridad no fueron diseñadas para ese tipo de actor.

Un operador humano en un entorno con sobre permisos generalmente sabrá cómo navegar la situación usando sentido común y conocimiento de las normas y políticas de la empresa. Los tokens OAuth otorgados a un agente de IA llevan el mismo acceso que los tokens otorgados a una persona, pero el agente no entenderá que tiene permisos excesivos antes de actuar; simplemente hará lo necesario para ejecutar la tarea. Los controles que importan aquí no son controles sobre el agente, sino controles sobre el entorno en el que opera.

Si sabes dónde están los datos confidenciales en el correo y Drive, puedes aplicar políticas para restringir el acceso antes de que un agente (o atacante) llegue allí. Si estás investigando permisos OAuth, puedes comprender y limitar la exposición a los ojos indiscretos de un atacante o un agente errante. Si puedes redactar enlaces de restablecimiento de contraseña y requerir verificación adicional antes de que el contenido sensible de la bandeja de entrada sea legible, no importa si la entidad que intenta acceder es un atacante o un agente fuera de su alcance previsto.

La misma cobertura que defiende contra la cadena de ataque moderna también defiende contra el riesgo moderno de los agentes. Son el mismo problema, con diferentes sombreros.

Cómo se ve la defensa a lo largo de toda la cadena

No creo que la respuesta sea agregar más soluciones puntuales en cada etapa de esta cadena. La respuesta es una cobertura que entienda la cadena como una cadena, que pueda ver lo que sucede en correo, OAuth, Drive y comportamiento de cuentas, y conecte los puntos antes de que las cosas salgan mal en el paso tres o cuatro. Eso es lo que hemos construido en Material. Aquí hay un mapa de cómo nuestra cobertura se alinea con cada paso:

Bloqueo del payload inicial de correo: nuestra seguridad de correo está diseñada para detectar lo que los controles nativos pasan por alto: phishing sofisticado, payloads que evaden filtros basados en reputación, técnicas de atacante en el medio. Detener el método de ataque más común antes de que comience sigue siendo la intervención de mayor apalancamiento contra la amenaza maliciosa.
Detección de comportamiento OAuth sospechoso: Material va más allá de catalogar qué aplicaciones existen y qué alcances tienen. La plataforma observa lo que las aplicaciones realmente hacen: qué leen, cuándo lo leen, cómo cambia ese comportamiento con el tiempo. Ya sea que un token OAuth sea usado por un atacante o por un agente de IA fuera de sus parámetros previstos, el comportamiento anómalo en la capa de actividad saca a la luz el peligro.
Detección y protección de datos confidenciales en reposo: no puedes proteger lo que no puedes ver, y no puedes diseñar una política en torno a un acceso que no sabes que existe. La seguridad de archivos de Material da a los equipos visibilidad sobre dónde viven los datos confidenciales en correo y Drive: qué unidades compartidas tienen acceso amplio, qué hilos de correo contienen credenciales o PII, qué carpetas de Drive están expuestas más allá de su audiencia prevista. Esta es la base para aplicar el principio de mínimo privilegio contra cualquier actor, humano o automatizado.
Bloqueo del movimiento lateral mediante restablecimiento de contraseña: Material puede redactar contenido de mensajes confidenciales, incluidos enlaces de restablecimiento de contraseña, y requerir verificación adicional antes de que ese contenido sea accesible. Un atacante con acceso a la bandeja de entrada no puede usarlo como punto de pivote si los enlaces de restablecimiento no están disponibles en texto plano. Un agente de IA que llegue a la bandeja de entrada buscando algo para actuar se encontrará con la misma restricción.

El patrón se repetirá

Vercel. Composio. Espero que esta lista siga creciendo, y espero que los próximos nombres no siempre encajen perfectamente en la categoría de 'atacante externo'. Algunos involucrarán agentes de IA que hacen algo inesperado. Otros involucrarán integraciones con sobre permisos que alcanzan datos que nunca debieron ver. El mecanismo resultará familiar incluso cuando la historia que lo rodea no lo sea.

La respuesta correcta no es alarmarse por los agentes de IA ni frenar su adopción. Los agentes son genuinamente útiles y el caso de productividad es real. La respuesta correcta es reconocer que el espacio de trabajo donde operan esos agentes necesita controles apropiados para un mundo donde el software autenticado con OAuth (autorizado o no) es un actor de primera clase en tu entorno.

Si tu estrategia de seguridad de Google Workspace termina en la bandeja de entrada, tienes una brecha. Esa brecha es exactamente donde corre la cadena de ataque moderna, y es exactamente donde un agente de IA que opera fuera de su alcance previsto también correrá. Si quieres hablar sobre cómo se ve la cobertura de espacio de trabajo de cadena completa para tu entorno, contáctanos en Material Security.

Patrocinado y escrito por Material Security.