Cómo atacan los hackers un Google Workspace
Por el equipo de QuantumSec
Entender cómo se ataca un Google Workspace es el primer paso para defenderlo. La mayoría de los compromisos no explotan un fallo de Google, sino la configuración y el comportamiento de la organización. Estos son los vectores que vemos una y otra vez en auditorías y respuestas a incidentes, explicados desde el punto de vista del atacante.
Phishing y robo de credenciales
Sigue siendo el punto de entrada número uno. El atacante envía un correo de phishing que imita a Google o a un servicio conocido para robar las credenciales. Las campañas modernas de tipo "adversary-in-the-middle" (AitM) son capaces incluso de capturar el código de verificación en dos pasos y la cookie de sesión, saltándose el MFA basado en SMS o en códigos. Una vez dentro, el siguiente paso suele ser el fraude del CEO (BEC) o la exfiltración de datos.
Consent phishing: apps OAuth maliciosas
En lugar de robar la contraseña, el atacante engaña al usuario para que autorice una aplicación OAuth maliciosa con permisos sobre Gmail y Drive. El usuario hace clic en "Permitir" y la app obtiene un token de acceso persistente. Lo peligroso es que ese acceso sobrevive al cambio de contraseña e incluso al MFA: mientras el token sea válido, el atacante sigue leyendo el correo y los archivos. Por eso el control de apps OAuth es una de las defensas más importantes y más ignoradas.
Persistencia en Gmail: reglas de reenvío y filtros
Tras conseguir acceso a una cuenta, una de las primeras acciones del atacante es crear reglas de reenvío automático o filtros que envían copias del correo a una dirección externa y, a la vez, ocultan o eliminan las alertas de seguridad. Estas reglas son discretas y persisten aunque la víctima cambie la contraseña, por lo que se usan para mantener el acceso al correo durante semanas sin ser detectado.
Abuso de delegación de dominio (DeleFriend / DWD)
La delegación de dominio (Domain-Wide Delegation) permite que una cuenta de servicio actúe en nombre de cualquier usuario del dominio. Investigadores de seguridad demostraron con "DeleFriend" que, con acceso a un proyecto de Google Cloud, un atacante puede abusar de una cuenta de servicio con delegación para impersonar a cualquier usuario —incluidos los súper administradores— sin su contraseña y sin disparar el MFA. Es uno de los vectores más graves y peor auditados de los entornos Google.
Del Workspace a GCP y a las apps SaaS
Google Workspace rara vez está aislado. Suele actuar como proveedor de identidad (SSO) de decenas de aplicaciones SaaS y está estrechamente integrado con Google Cloud (GCP). Comprometer el Workspace puede significar comprometer todo lo que está federado a través de él, y un atacante con acceso puede pivotar hacia GCP para alcanzar infraestructura, bases de datos o secretos. El radio de impacto de un solo compromiso es enorme.
Cómo se detiene esto
La defensa combina varias capas: MFA resistente al phishing (llaves de seguridad o passkeys), control estricto de las apps OAuth con lista de permitidos, monitorización de las reglas de reenvío de Gmail, inventario y mínimo privilegio de las delegaciones de dominio, y registros con alertas para detectar la actividad sospechosa a tiempo. Una auditoría periódica con enfoque ofensivo verifica que estas defensas funcionan de verdad, no solo sobre el papel.
FAQ
Si cambio la contraseña, ¿echo al atacante?
No necesariamente. Los tokens OAuth, las reglas de reenvío de Gmail, las contraseñas de aplicación y las delegaciones de dominio pueden mantener el acceso aunque cambies la contraseña. Tras un incidente hay que revocar sesiones y tokens, revisar reglas y filtros, y auditar las apps conectadas.
¿El MFA me protege de todos estos ataques?
El MFA resistente al phishing es esencial, pero no cubre todo: no detiene el consent phishing (donde el usuario autoriza una app maliciosa) ni el abuso de delegación de dominio, que no requiere las credenciales del usuario. Por eso hace falta endurecer la configuración y auditar el entorno.