Superadministrador de Workspace comprometido: registro Admin
Superadministrador de Google Workspace comprometido: eventos del registro de Admin sobre nuevos admins, roles, SSO, delegación, enrutamiento y cumplimiento.
En resumen. Una cuenta de administrador comprometida convierte un incidente de buzón en un incidente del tenant. En el registro de Admin, revise todo lo que hizo esa cuenta durante la ventana. Las prioridades: nuevos superadministradores y asignaciones de roles (GRANT_ADMIN_PRIVILEGE, ASSIGN_ROLE), cambios de SSO / SAML (CHANGE_SSO_SETTINGS, TOGGLE_SSO_ENABLED), delegación de todo el dominio (AUTHORIZE_API_CLIENT_ACCESS), enrutamiento de correo, supervisión de correo y reglas de cumplimiento de contenido, 2SV desactivada para usuarios, restablecimientos de contraseña y cuentas nuevas. Cada uno es un mecanismo de persistencia que la limpieza a nivel de usuario no tocará.
La mayoría de los compromisos de Workspace se quedan en el buzón. Cuando no es así, suele deberse a un administrador que cayó en el phishing como cualquiera, o a una credencial reutilizada. El informe de Google Threat Intelligence de junio de 2026 sobre UNC6508 describe a un actor que reutilizó credenciales robadas en otro sistema para llegar a una cuenta de administrador de Workspace, y después creó una regla de cumplimiento de contenido que enviaba en copia oculta los mensajes coincidentes a una dirección de Gmail externa. La configuración de los buzones de los usuarios no mostraba nada.
El registro de Admin, en breve
Cada cambio hecho en la consola de administración o con el SDK de administración queda en el registro de Admin (Admin log events; nombres de API en el apéndice de eventos de administración). Cada registro tiene el administrador que actuó, la IP, el nombre del evento y sus parámetros (usuario afectado, nombre del ajuste, valores anterior y nuevo). Google lo documenta como casi en tiempo real, con la retención de seis meses habitual.
Qué buscar y por qué
| Cambio | Eventos del registro de Admin | Por qué lo hace el atacante | Gravedad en el analizador |
|---|---|---|---|
| Nuevo superadministrador | GRANT_ADMIN_PRIVILEGE | Un administrador de reserva que sobrevive al restablecimiento de la cuenta original | Alta |
| Rol de administración / administrador delegado | ASSIGN_ROLE, GRANT_DELEGATED_ADMIN_PRIVILEGES, ADD_PRIVILEGE | Más discreto que un superadministrador, igual de útil | Media |
| SSO | CHANGE_SSO_SETTINGS, TOGGLE_SSO_ENABLED, UPLOAD_OAUTH_CERTIFICATE | Enviar los inicios de sesión a un IdP que controla, o hacer aceptar su certificado | Alta |
| Delegación de todo el dominio | AUTHORIZE_API_CLIENT_ACCESS | Suplantar por API a todos los usuarios | Alta |
| Controles de aplicaciones | ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS, … | Dejar pasar su aplicación OAuth | Media |
| Enrutamiento / supervisión de correo | MAIL_ROUTING_DESTINATION_ADDED, CREATE_EMAIL_MONITOR, cambios de ajustes de Gmail sobre enrutamiento, reenvío o cumplimiento | Copiar el correo de usuarios o de todo el dominio | Alta |
| 2SV desactivada para un usuario | TURN_OFF_2_STEP_VERIFICATION, UNENROLL_USER_FROM_STRONG_AUTH | Debilitar una cuenta objetivo | Alta |
| Restablecimiento de contraseña | CHANGE_PASSWORD | Tomar el control de otro usuario | Baja |
| Usuario nuevo o restaurado | CREATE_USER, UNSUSPEND_USER, UNDELETE_USER | Cuenta puerta trasera | Baja |
Correspondencias MITRE: T1098.003 Additional Cloud Roles, T1484.002 Trust Modification, T1556 Modify Authentication Process, T1136.003 Create Cloud Account.
Las filas de gravedad baja son el trabajo normal del soporte. Solo importan en contexto: el mismo administrador, el mismo día, tras un inicio de sesión de riesgo. La regla de cadena del analizador capta exactamente eso. Un inicio de sesión de riesgo seguido, en 14 días, de un cambio de administración, SSO, delegación, enrutamiento o 2SV en la misma cuenta es crítico.
SSO: la puerta trasera silenciosa
Workspace puede delegar la autenticación en un proveedor de identidad externo mediante perfiles de SSO (Security → Authentication → SSO with third-party IdP, etiquetas de la consola en inglés; véase la guía de configuración de SSO de Google). Un atacante que cambie la URL de inicio de sesión o suba su propio certificado de verificación puede fabricar inicios de sesión de usuarios sin conocer ninguna contraseña. Ni el restablecimiento de contraseñas ni la 2SV ayudan.
Comprobaciones:
- Compare la URL de la página de inicio de sesión, el ID de entidad y los certificados de cada perfil con los valores reales de su IdP.
- Compruebe a qué unidades organizativas o grupos está asignado cada perfil.
- Correlacione con el registro de SAML: inicios de sesión a través de un perfil que nadie esperaba.
Un límite que conviene indicar: el analizador reconoce los nombres de eventos de SSO de arriba. Las operaciones más recientes sobre perfiles de SSO pueden registrarse con otros nombres. Durante un incidente, busque «SSO» manualmente en el registro de Admin. Si su IdP es Okta, mire también ese lado. oktaforensics.com trata el System Log de Okta.
Enrutamiento de correo y reglas de cumplimiento
Las reglas de correo a nivel de administración se aplican a muchos buzones a la vez y son invisibles en la configuración de Gmail de cada usuario:
- El enrutamiento puede añadir destinatarios o cambiar el servidor de destino.
- El cumplimiento de contenido puede detectar expresiones y añadir destinatarios. Es la técnica de UNC6508.
- Las supervisiones de correo (email monitors, una función de API antigua) copian el correo de un usuario a otra dirección.
El analizador marca MAIL_ROUTING_DESTINATION_ADDED, CREATE_EMAIL_MONITOR y las creaciones o cambios de ajustes de Gmail cuyo nombre menciona enrutamiento, reenvío, cumplimiento o excepciones. Revise también las propias reglas en Apps → Google Workspace → Gmail → Compliance y Routing. El registro le dice cuándo, la consola le dice qué está activo hoy.
Respuesta ante el compromiso de un administrador
- Contenga la cuenta de administrador: restablezca sus cookies de inicio de sesión, revoque tokens, restablezca la contraseña y exija llaves de seguridad. La página de Google sobre la aplicación obligatoria de la 2SV a administradores es pertinente aquí.
- Enumere los cambios: filtre el registro de Admin por ese actor en toda la ventana y expórtelo.
- Revierta cada cambio no explicado: quite administradores y roles, restaure los perfiles de SSO, elimine delegaciones, borre reglas de enrutamiento y cumplimiento, restaure la 2SV.
- Busque cuentas de segundo orden: los usuarios creados o con contraseña restablecida por el atacante están bajo su control. Repita la investigación con cada uno.
- Refuerce: pocos superadministradores, no usados en el día a día, solo llaves de seguridad y aprobación multiparte donde esté disponible. Las líneas base SCuBA de CISA para Google Workspace ofrecen una configuración de referencia revisada.
Con esto se cierra la serie de técnicas de ataque. Para la contraparte a nivel de usuario, véase reglas de reenvío de Gmail. Para el método completo, la guía de investigación. Para revisar rápido una exportación del registro de Admin, use el analizador.
FAQ
¿Cómo veo qué cambió un administrador de Google Workspace?
Abra Reporting → Audit and investigation → Admin log events en la consola de administración y filtre por el correo del administrador como actor y por el periodo del incidente, o consulte la API Reports con applicationName=admin. Cada cambio de configuración, asignación de rol y cambio de usuario queda registrado ahí.
¿Por qué un atacante cambiaría la configuración de SSO de Google Workspace?
Apuntar el SSO a un proveedor de identidad que controla, o añadir su propio certificado de firma, le permite iniciar sesión como los usuarios sin contraseñas ni 2SV, y sobrevive a los restablecimientos de contraseña. Trate cualquier cambio de SSO no planificado como un incidente.