Super-admin Google Workspace compromis : le journal Admin
Super-admin Google Workspace compromis : événements du journal Admin pour nouveaux admins, rôles, SSO, délégation, routage du courrier et règles de conformité.
En bref. Un compte administrateur compromis transforme un incident de boîte mail en incident de tenant. Dans le journal Admin, passez en revue tout ce que ce compte a fait sur la fenêtre. Les priorités : nouveaux super-administrateurs et attributions de rôles (GRANT_ADMIN_PRIVILEGE, ASSIGN_ROLE), changements SSO / SAML (CHANGE_SSO_SETTINGS, TOGGLE_SSO_ENABLED), délégation au niveau du domaine (AUTHORIZE_API_CLIENT_ACCESS), routage du courrier, surveillance d'e-mails et règles de conformité du contenu, 2SV désactivée pour des utilisateurs, réinitialisations de mots de passe et nouveaux comptes. Chacun est un mécanisme de persistance que le nettoyage au niveau utilisateur ne touchera pas.
La plupart des compromissions Workspace restent au niveau de la boîte mail. Quand ce n'est pas le cas, c'est en général parce qu'un administrateur s'est fait hameçonner comme tout le monde, ou à cause d'un identifiant réutilisé. Le rapport de Google Threat Intelligence de juin 2026 sur UNC6508 décrit un acteur qui a réutilisé des identifiants récoltés ailleurs pour atteindre un compte administrateur Workspace, puis a créé une règle de conformité du contenu qui mettait en copie cachée les messages correspondants vers une adresse Gmail externe. Les paramètres de boîte des utilisateurs ne montraient rien.
Le journal Admin, en bref
Chaque changement fait via la console d'administration ou le SDK Admin est enregistré dans le journal Admin (Admin log events ; noms d'API dans l'annexe des événements admin). Chaque enregistrement comporte l'administrateur auteur, l'IP, le nom de l'événement et ses paramètres (utilisateur cible, nom du paramètre, anciennes et nouvelles valeurs). Google le documente comme quasi temps réel, avec la conservation de six mois habituelle.
Quoi chercher, et pourquoi
| Changement | Événements du journal Admin | Pourquoi l'attaquant le fait | Gravité dans l'analyseur |
|---|---|---|---|
| Nouveau super-admin | GRANT_ADMIN_PRIVILEGE | Un admin de secours qui survit à la réinitialisation du compte d'origine | Élevée |
| Rôle admin / admin délégué | ASSIGN_ROLE, GRANT_DELEGATED_ADMIN_PRIVILEGES, ADD_PRIVILEGE | Plus discret qu'un super-admin, toujours puissant | Moyenne |
| SSO | CHANGE_SSO_SETTINGS, TOGGLE_SSO_ENABLED, UPLOAD_OAUTH_CERTIFICATE | Envoyer les connexions vers un IdP qu'il contrôle, ou faire accepter son certificat | Élevée |
| Délégation au niveau du domaine | AUTHORIZE_API_CLIENT_ACCESS | Usurpation de chaque utilisateur via l'API | Élevée |
| Contrôles d'applications | ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS, … | Laisser passer son application OAuth | Moyenne |
| Routage / surveillance du courrier | MAIL_ROUTING_DESTINATION_ADDED, CREATE_EMAIL_MONITOR, changements de paramètres Gmail liés au routage, au transfert ou à la conformité | Copier le courrier d'utilisateurs ou de tout le domaine | Élevée |
| 2SV désactivée pour un utilisateur | TURN_OFF_2_STEP_VERIFICATION, UNENROLL_USER_FROM_STRONG_AUTH | Affaiblir un compte cible | Élevée |
| Réinitialisation de mot de passe | CHANGE_PASSWORD | Prendre le contrôle d'un autre utilisateur | Faible |
| Utilisateur nouveau ou restauré | CREATE_USER, UNSUSPEND_USER, UNDELETE_USER | Compte dérobé (porte dérobée) | Faible |
Correspondances MITRE : T1098.003 Additional Cloud Roles, T1484.002 Trust Modification, T1556 Modify Authentication Process, T1136.003 Create Cloud Account.
Les lignes de faible gravité relèvent du quotidien du support. Elles ne comptent qu'en contexte : même admin, même jour, après une connexion à risque. C'est exactement ce que capte la règle de chaîne de l'analyseur. Une connexion à risque suivie dans les 14 jours d'un changement admin, SSO, délégation, routage ou 2SV sur le même compte est critique.
Le SSO : la porte dérobée discrète
Workspace peut confier l'authentification à un fournisseur d'identité tiers au moyen de profils SSO (Security → Authentication → SSO with third-party IdP, libellés de la console en anglais ; voir le guide de configuration SSO de Google). Un attaquant qui change l'URL de connexion ou téléverse son propre certificat de vérification peut fabriquer des connexions pour des utilisateurs sans connaître aucun mot de passe. Ni la réinitialisation du mot de passe ni la 2SV n'y changent rien.
Vérifications :
- Comparez l'URL de la page de connexion, l'ID d'entité et les certificats de chaque profil avec les vraies valeurs de votre IdP.
- Vérifiez à quelles unités organisationnelles ou quels groupes chaque profil est attribué.
- Recoupez avec le journal SAML : des connexions via un profil que personne n'attendait.
Une limite à signaler : l'analyseur reconnaît les noms d'événements SSO ci-dessus. Les opérations plus récentes sur les profils SSO peuvent être journalisées sous d'autres noms. Pendant un incident, cherchez « SSO » manuellement dans le journal Admin. Si votre IdP est Okta, regardez aussi côté IdP. oktaforensics.com traite le System Log d'Okta.
Routage du courrier et règles de conformité
Les règles de messagerie au niveau admin s'appliquent à de nombreuses boîtes à la fois et sont invisibles dans les paramètres Gmail de chaque utilisateur :
- Le routage peut ajouter des destinataires ou changer le serveur de destination.
- La conformité du contenu peut repérer des expressions et ajouter des destinataires. C'est la technique d'UNC6508.
- Les surveillances d'e-mails (email monitors, ancienne fonction d'API) copient le courrier d'un utilisateur vers une autre adresse.
L'analyseur signale MAIL_ROUTING_DESTINATION_ADDED, CREATE_EMAIL_MONITOR, ainsi que les créations ou modifications de paramètres Gmail dont le nom évoque le routage, le transfert, la conformité ou un contournement. Examinez aussi les règles elles-mêmes dans Apps → Google Workspace → Gmail → Compliance et Routing. Le journal vous dit quand, la console vous dit ce qui est actif aujourd'hui.
Réponse à la compromission d'un admin
- Contenez le compte admin : réinitialisez ses cookies de connexion, révoquez les jetons, réinitialisez le mot de passe, imposez les clés de sécurité. La page de Google sur l'application de la 2SV aux administrateurs est utile ici.
- Recensez les changements : filtrez le journal Admin sur cet acteur pour toute la fenêtre et exportez-le.
- Annulez chaque changement inexpliqué : retirez admins et rôles, rétablissez les profils SSO, supprimez les délégations, effacez les règles de routage et de conformité, rétablissez la 2SV.
- Traquez les comptes de second rang : les utilisateurs créés ou dont le mot de passe a été réinitialisé par l'attaquant sont sous son contrôle. Refaites l'enquête pour chacun.
- Durcissez : peu de super-admins, pas utilisés au quotidien, clés de sécurité uniquement, et approbation multipartite quand elle est disponible. Les références SCuBA de la CISA pour Google Workspace fournissent une configuration de référence éprouvée.
Cet article clôt la série sur les techniques d'attaque. Pour le pendant au niveau utilisateur, voir les règles de transfert Gmail. Pour la méthode complète, le guide d'investigation. Pour trier rapidement un export du journal Admin, utilisez l'analyseur.
FAQ
Comment voir ce qu'un administrateur Google Workspace a modifié ?
Ouvrez Reporting → Audit and investigation → Admin log events dans la console d'administration, filtrez sur l'adresse de l'admin comme acteur et sur la période de l'incident, ou interrogez l'API Reports avec applicationName=admin. Chaque changement de paramètre, attribution de rôle et modification d'utilisateur y est enregistré.
Pourquoi un attaquant modifierait-il les paramètres SSO de Google Workspace ?
Rediriger le SSO vers un fournisseur d'identité qu'il contrôle, ou ajouter son propre certificat de signature, lui permet de se connecter en tant qu'utilisateurs sans mot de passe ni 2SV, et survit aux réinitialisations de mot de passe. Traitez tout changement SSO non planifié comme un incident.