Compte Google Workspace compromis ? Guide d'investigation

En bref. Une prise de contrôle de compte Google Workspace laisse presque toujours la même trace. D'abord une connexion à risque dans le journal des connexions. Puis une persistance qui survit à la réinitialisation du mot de passe : une autorisation OAuth dans le journal des jetons, un transfert externe dans le journal des comptes utilisateur, un filtre Gmail que seuls les paramètres Gmail révèlent. Ensuite viennent la collecte et la fraude dans les journaux Gmail et Drive. Extrayez ces sources sur les 30 jours qui précèdent l'e-mail suspect et corrélez-les par compte. Traitez l'enchaînement « connexion à risque → persistance » comme une compromission tant que personne n'a prouvé le contraire. L'analyseur gratuit dans le navigateur fait exactement cette corrélation sur vos exports, sans les envoyer nulle part.

La plupart des enquêtes Workspace commencent de la même façon. Un fournisseur appelle au sujet d'une facture réglée sur un « nouveau » compte bancaire. Ou un utilisateur raconte qu'il s'est connecté sur une page de partage de document un peu étrange. Ou Google envoie une alerte de connexion suspecte. La question de la direction est binaire : le compte a-t-il été compromis, et qu'ont-ils obtenu ? Les journaux répondent aux deux, à condition d'extraire les bons avant qu'ils n'expirent.

Les cinq questions de l'enquête

Les noms d'événements proviennent de l'annexe de l'API Reports sur les événements de connexion. Les mêmes événements apparaissent sous des libellés d'affichage dans la console d'administration (Reporting → Audit and investigation, libellés de la console en anglais).

Étape 1 : reconstituer l'histoire des connexions

Commencez par le compte suspect et les 30 jours qui précèdent le premier signe d'anomalie. Dans le journal des connexions, listez chaque connexion réussie avec son adresse IP, son ASN et son pays. Vous cherchez trois choses :

• Le signalement de Google lui-même. Les événements suspicious_login, suspicious_programmatic_login et user_signed_out_due_to_suspicious_session_cookie, ou un login_success avec is_suspicious = true. Google les décrit comme des connexions hors du comportement habituel de l'utilisateur. Notez aussi les avertissements de compte comme account_disabled_password_leak ou gov_attack_warning.
• Un réseau qui n'appartient pas à une personne. Les salariés se connectent depuis un bureau, leur domicile ou un opérateur mobile. Une connexion réussie depuis un hébergeur cloud ou VPS (DigitalOcean, OVH, AWS…) est la signature typique d'un kit d'hameçonnage adversary-in-the-middle. Le kit relaie le mot de passe et l'invite de validation en deux étapes, puis réutilise la session depuis son propre serveur. Voir ASN d'hébergeur.
• Une géographie incohérente. Un pays jamais vu pour cet utilisateur, ou un voyage impossible entre deux connexions.

Le détail, y compris les champs qui n'existent que dans l'API Reports, est dans connexions suspectes et changements 2SV.

Étape 2 : chercher la persistance qui survit au changement de mot de passe

C'est là que la plupart des enquêtes menées en interne s'arrêtent trop tôt. Une réinitialisation du mot de passe ne supprime pas :

1. Les autorisations OAuth. Un utilisateur qui a cliqué sur « Autoriser » pour une application leurre (« PDF viewer », un faux service de signature) lui a donné un jeton d'actualisation. Le journal des jetons OAuth enregistre l'événement authorize avec le nom de l'application, son ID client et ses scopes. Tout ce qui porte https://mail.google.com/ ou un scope gmail.* peut lire la boîte via l'API tant que le jeton vit. Voir applications OAuth suspectes et consentement illicite.
2. Le transfert externe. Le journal des comptes utilisateur enregistre email_forwarding_out_of_domain avec l'adresse de destination. Voir transfert automatique externe.
3. Les filtres Gmail, délégués et adresses « envoyer en tant que ». Ils ne figurent pas du tout dans les journaux d'audit. Il faut lire les paramètres de la boîte (API Gmail ou pages de paramètres Gmail de l'utilisateur). Un filtre sur « invoice OR payment » qui évite la boîte de réception et transfère vers l'extérieur est la signature d'une compromission de messagerie professionnelle (BEC). La méthode complète est dans trouver la règle de transfert Gmail d'un pirate.
4. L'authentification affaiblie. 2sv_disable, une nouvelle adresse ou un nouveau téléphone de récupération, une clé de sécurité retirée.

MITRE ATT&CK nomme ces techniques T1114.003 Email Forwarding Rule, T1564.008 Email Hiding Rules et T1528 Steal Application Access Token.

Étape 3 : mesurer ce qui a été consulté

Une fois que vous savez quand l'attaquant avait accès et d'où, filtrez tous les autres journaux sur cette fenêtre et sur ses adresses IP :

• Journal Gmail. Messages transférés automatiquement, archivés ou supprimés juste après réception, en particulier les factures fournisseurs. Et les messages sortants vers des destinataires externes.
• Journal des jetons OAuth, événements activity. Les appels à l'API Gmail (gmail.users.messages.get, …settings.filters.create) passés via l'application leurre montrent une collecte de la boîte à grande échelle.
• Journal Drive. Rafales d'événements download, fichiers partagés vers des adresses externes, liens ouverts à « tous les utilisateurs disposant du lien ». Détails dans téléchargement massif Drive et exfiltration Takeout.
• Journal Takeout. Un export Google Takeout du compte entier est le moyen le plus rapide de tout emporter.

Étape 4 : vérifier si l'attaque a dépassé une seule boîte

Si le compte compromis est administrateur, ou si l'attaquant en a atteint un, le journal Admin devient la priorité : nouveaux super-administrateurs, attributions de rôles, changements SSO, délégation au niveau du domaine accordée à un client API, règles de routage ou de conformité du courrier. En juin 2026, Google Threat Intelligence a décrit un acteur lié à la RPC (UNC6508) qui a utilisé un identifiant administrateur volé pour créer une règle de conformité du contenu. La règle mettait silencieusement en copie cachée les messages correspondants vers une adresse Gmail externe. Ce type de changement n'apparaît jamais dans les paramètres de la boîte d'un utilisateur. Voir abus de rôles admin et changements SSO.

Étape 5 : corréler, puis décider

Pris isolément, les événements sont bruyants. Les gens voyagent, utilisent des VPN, installent des applications légitimes. Le signal, c'est la séquence sur un même compte :

• connexion à risque → transfert / filtre masquant / application avec scope Gmail / e-mail de changement de RIB → fraude BEC ;
• connexion à risque → changement admin, SSO, délégation ou 2SV → prise de contrôle possible du tenant.

L'analyseur de la page d'accueil encode ces deux chaînes sous forme de règles avec une fenêtre de 14 jours. Il rend le verdict « Compromission probable » quand une chaîne se déclenche, ou quand des constats de gravité élevée de deux catégories différentes touchent le même compte. Ses règles sont du JSON lisible, donc vous voyez exactement ce qui a déclenché.

Ce que « sain » veut dire, et ne veut pas dire

Un résultat sain sur le seul journal des connexions ne dit rien des autorisations OAuth ni des filtres. Avant de clore le dossier, confirmez que vous aviez :

• chaque source pertinente sur toute la fenêtre (l'outil liste les sources manquantes) ;
• les paramètres Gmail de chaque boîte concernée ;
• les informations réseau (ASN et pays), que seuls certains exports contiennent.

Les données d'audit sont aussi limitées dans le temps. Google conserve la plupart des événements six mois, et les exports ont des plafonds de lignes. Détails dans limites des journaux d'audit.

Pour aller plus loin

• L'heure qui suit, côté actions : checklist de réponse à incident pour la première heure.
• Extraire les données : comment exporter les journaux d'audit Google Workspace.
• Lancer l'analyse : analyser les journaux d'audit Google Workspace pas à pas.
• Un cas fictif complet : exemple d'enquête BEC.

Le même schéma se retrouve chez d'autres fournisseurs cloud. Pour un tenant Microsoft 365, l'analyse équivalente des règles de boîte de réception est sur m365forensics.com.

FAQ

Comment savoir si un compte Google Workspace a été compromis ?

Cherchez une connexion qui ne ressemble pas à l'utilisateur (réseau d'hébergeur, nouveau pays, signalement de Google) suivie d'une persistance sur le même compte : transfert externe, filtre qui masque les factures, nouvelle application tierce avec accès Gmail, validation en deux étapes désactivée. Un seul de ces éléments peut être légitime. C'est l'enchaînement qui fait le dossier.

Réinitialiser le mot de passe suffit-il à mettre fin à la compromission ?

Non. Les sessions ouvertes, les jetons OAuth accordés à des applications tierces, les adresses de transfert et les filtres Gmail survivent à une réinitialisation. Révoquez sessions et jetons, supprimez la persistance de la boîte mail, puis réinitialisez le mot de passe. La procédure de Google pour les comptes compromis suit le même ordre.

Quels journaux Google Workspace faut-il pour enquêter sur un compte compromis ?

Au minimum le journal des connexions (User log), le journal des jetons OAuth et le journal Gmail du compte, plus ses paramètres Gmail (filtres, transfert, délégués, envoi en tant que). Ajoutez Drive, Admin, SAML, Takeout et Groups pour mesurer l'accès aux données et les changements d'administration.