Del Workspace a GCP: cómo escala un atacante en el ecosistema Google

Por Kike Gandia · Co-Fundador y CEO, OSCP

Google Workspace rara vez está aislado: comparte identidades con Google Cloud (GCP) y con decenas de apps SaaS a través de SSO. Esa integración es cómoda, pero crea caminos de escalada que un atacante aprovecha para pasar del correo a la infraestructura. Esta guía explica esa frontera y cómo auditarla.

Identidad compartida: el punto de unión

Las cuentas de Google Workspace son también identidades en Google Cloud. Si un usuario tiene permisos en GCP, comprometer su cuenta de Workspace puede abrir la puerta a recursos cloud: máquinas, bases de datos, buckets o secretos. La identidad es el pegamento que une ambos mundos y, por tanto, el objetivo del atacante.

Delegación de dominio y cuentas de servicio

La delegación de dominio (Domain-Wide Delegation) permite que una cuenta de servicio de GCP impersone a cualquier usuario de Workspace. El estudio DeleFriend demostró cómo abusar de esto desde GCP con permisos limitados. Es el puente más peligroso entre ambos entornos y uno de los menos auditados.

SSO y apps federadas

Cuando Workspace actúa como proveedor de identidad (SSO) de otras aplicaciones, comprometerlo propaga el acceso a todo lo federado. El radio de impacto de un solo compromiso deja de ser una cuenta de correo y pasa a ser todo el ecosistema de aplicaciones de la empresa.

Cómo auditar la frontera Workspace-GCP

Hay que mirar los dos lados: revisar el IAM de GCP y las cuentas de servicio, inventariar las delegaciones de dominio, restringir quién puede crear claves de cuentas de servicio y correlacionar los registros de Workspace y de GCP. Auditar uno sin el otro deja un hueco crítico que el atacante conoce bien.

Un camino de escalada concreto, paso a paso

El recorrido que vemos en auditorías suele ser este. Primero, el atacante compromete la cuenta de Workspace de un perfil técnico —un desarrollador, alguien de plataforma— mediante phishing en tiempo real. Esa cuenta no es administradora de Workspace, así que a primera vista el daño parece limitado.

Segundo, enumera el IAM de los proyectos de Google Cloud a los que esa identidad tiene acceso y busca cuentas de servicio sobre las que pueda actuar: los roles de creador de tokens de cuenta de servicio y de usuario de cuenta de servicio permiten obtener credenciales de esa cuenta sin necesidad de robar ninguna clave. Tercero, comprueba si alguna de esas cuentas de servicio tiene configurada la delegación de dominio. Si la tiene, puede pedir un token en nombre de cualquier usuario del dominio con los ámbitos delegados, incluido el súper administrador.

Lo importante de esta cadena es lo que no aparece en ella: en ningún momento hace falta la contraseña ni el segundo factor de la víctima final. La 2SV del súper administrador no interviene, porque el acceso llega por la vía de la API, no por la del inicio de sesión.

Qué mirar a cada lado de la frontera

Las preguntas que hay que responder no viven todas en la misma consola, y esa es exactamente la razón por la que este vector se queda sin auditar.

Pregunta	Dónde se responde en Workspace	Dónde se responde en Google Cloud
¿Qué cuentas de servicio pueden suplantar usuarios?	Controles de acceso a las APIs, delegación de dominio	IAM y cuentas de servicio de cada proyecto
¿Con qué ámbitos pueden hacerlo?	Lista de IDs de cliente y ámbitos autorizados	—
¿Quién puede crear claves de cuenta de servicio?	—	Políticas de la organización y roles IAM
¿Quién puede obtener tokens de una cuenta de servicio?	—	Roles de creador de tokens y de usuario de cuenta de servicio
¿Queda rastro del uso de la delegación?	Registros de auditoría de administrador y de tokens	Cloud Audit Logs

Auditar solo una columna deja el hueco intacto, y es un hueco que el atacante conoce bien.

FAQ

¿Auditar solo el Workspace es suficiente?

No, si también usas Google Cloud. La escalada aprovecha precisamente la integración entre ambos: hay que auditar el IAM de GCP, las cuentas de servicio y las delegaciones de dominio además de la configuración del Workspace.

¿Quién debería preocuparse por esto?

Cualquier empresa que use Google Workspace y Google Cloud de forma conjunta, especialmente si tiene cuentas de servicio con delegación de dominio o integraciones automatizadas entre ambos entornos.

¿Qué alcance tiene una auditoría que cubra los dos entornos?

Como mínimo: el inventario de delegaciones de dominio con sus ámbitos, el IAM de los proyectos de Google Cloud, quién puede obtener credenciales de cada cuenta de servicio, las políticas de organización que restringen la creación de claves y la correlación de registros entre ambos lados. El tamaño real del trabajo lo marcan el número de proyectos y de cuentas de servicio, no el número de usuarios.

¿Se puede hacer en producción?

La parte de revisión sí: enumerar delegaciones, roles y políticas se hace con permisos de solo lectura y no altera nada. La demostración de un camino concreto de escalada se acuerda por escrito y se ejecuta en ventana pactada, o se reproduce sobre una cuenta de prueba creada para eso, para no tocar datos reales.

¿Qué entregables salen de este trabajo?

El mapa de caminos de escalada que existen hoy entre Workspace y Google Cloud, la lista de delegaciones de dominio con sus ámbitos y quién puede usarlas, las políticas de organización recomendadas para cerrar la creación de claves y la suplantación innecesaria, y los eventos concretos que hay que vigilar para detectar el uso de la delegación.

Si no usamos Google Cloud, ¿esto me afecta igualmente?

Probablemente sí. La delegación de dominio se configura sobre una cuenta de servicio de Google Cloud, aunque vosotros no uséis Google Cloud para nada: si alguna integración de terceros la pidió en su día, existe un proyecto con una cuenta de servicio capaz de suplantar a vuestros usuarios. Es justamente el caso donde nadie lo revisa, porque la organización cree que no tiene nada en Google Cloud.