Connexion suspecte Google Workspace et changements 2SV
Enquêter sur une connexion suspecte Google Workspace : is_suspicious, ASN d'hébergeurs, nouveaux pays, voyage impossible, rafales d'échecs, 2SV et récupération.
En bref. Dans le journal des connexions (User log), vérifiez quatre signaux pour le compte suspect : le signalement de Google lui-même (suspicious_login, is_suspicious=true, avertissements de compte désactivé), une connexion réussie depuis un ASN d'hébergeur, un nouveau pays ou un voyage impossible, et des rafales d'échecs. Puis regardez ce que la session a changé sur le compte : 2sv_disable, recovery_email_edit, recovery_phone_edit. Une connexion réussie depuis un VPS juste après un clic sur un lien est la signature de l'hameçonnage adversary-in-the-middle.
La connexion est le point de départ de la chronologie d'une compromission Workspace, et souvent le seul endroit où figurent des indicateurs réseau clairs. Cet article décrit ce qu'enregistre le journal des connexions, comment le lire et où sont les pièges.
Ce qu'enregistre le journal des connexions
Les événements de connexion (et de compte utilisateur) sont documentés dans l'annexe Login audit activity events de Google. Ceux qui comptent pour une prise de contrôle :
| Événement | Signification |
|---|---|
login_success, login_failure | Résultat de la connexion, avec login_type, login_challenge_method, is_suspicious |
login_challenge, login_verification | Challenge 2SV ou de risque présenté / réussi |
suspicious_login, suspicious_login_less_secure_app, suspicious_programmatic_login | Le moteur de risque de Google a bloqué ou signalé la tentative |
user_signed_out_due_to_suspicious_session_cookie | Google a détecté un cookie de session suspect et déconnecté l'utilisateur |
account_disabled_password_leak, account_disabled_hijacked, gov_attack_warning | Avertissements de compte |
risky_sensitive_action_allowed / _blocked | Action sensible après une connexion à risque |
2sv_disable, 2sv_enroll, titanium_unenroll, passkey_removed | Changements de 2SV et de Protection Avancée |
recovery_email_edit, recovery_phone_edit, password_edit | Changements de récupération et de mot de passe |
Chaque enregistrement porte aussi l'adresse IP. Dans l'API Reports, il porte en plus networkInfo, avec l'ASN de l'IP et un code de région. Ce sont ces données réseau qui rendent possibles les trois contrôles suivants.
Signal 1 : Google l'a déjà signalé
Commencez par la preuve la moins coûteuse. Le moteur de risque de Google décide quand une connexion sort du « comportement habituel » (à propos des alertes de connexion suspecte). Un login_success avec is_suspicious = true signifie que la tentative est passée malgré tout. user_signed_out_due_to_suspicious_session_cookie est particulièrement intéressant dans les cas AiTM : la session a été volée, et Google s'en est aperçu.
Ces signalements ne sont pas exhaustifs. Beaucoup de connexions AiTM ne sont pas signalées, parce que la victime a réellement réussi le challenge.
Signal 2 : un réseau d'hébergeur
Les kits AiTM (des proxys inverses à la Evilginx) s'intercalent entre la victime et Google. La victime saisit son mot de passe et valide l'invite sur la page relayée. Google voit la connexion arriver depuis le serveur du proxy, typiquement un VPS chez DigitalOcean, OVH, Hetzner, Vultr, AWS ou équivalent. MITRE décrit la technique sous T1557 Adversary-in-the-Middle, qui mène à T1078.004 Cloud Accounts.
L'analyseur compare l'ASN de chaque connexion réussie (y compris SAML) à une liste vérifiée d'hébergeurs et signale les correspondances en gravité élevée. Avant d'escalader, écartez votre propre infrastructure : concentrateurs VPN d'entreprise, postes virtuels hébergés dans le cloud et proxys de sécurité sortent tous par ces réseaux.
Signal 3 : la géographie
- Nouveau pays. Après un historique d'au moins trois connexions depuis des pays connus, une réussite depuis un pays jamais vu pour cet utilisateur. Gravité moyenne à elle seule : les gens voyagent.
- Voyage impossible. Deux connexions réussies depuis des pays distants de plus de 500 km, à une vitesse implicite supérieure à 900 km/h. L'une des deux sessions n'est pas l'utilisateur, ou un VPN est en jeu.
Les deux contrôles dépendent d'un code de région par événement. L'API Reports le fournit. Beaucoup d'exports CSV de la console, non. Sans lui, ces contrôles ne peuvent pas tourner. Voir limites des journaux d'audit.
Signal 4 : les rafales d'échecs
Dix événements login_failure ou plus en dix minutes sur un même compte indiquent une devinette ou une pulvérisation de mots de passe (T1110). Seul, c'est un constat de gravité moyenne. Il devient important quand une réussite suit depuis la même IP.
Ensuite : qu'a changé la session ?
Après la connexion, l'attaquant rend son accès durable :
2sv_disable(outitanium_unenrollpour la Protection Avancée) facilite la connexion suivante. MITRE : T1556.006 Multi-Factor Authentication. Un administrateur peut faire de même depuis le journal Admin (TURN_OFF_2_STEP_VERIFICATION,UNENROLL_USER_FROM_STRONG_AUTH).recovery_email_edit/recovery_phone_editpermettent à l'attaquant de reprendre le compte après votre réinitialisation. Vérifiez toujours les nouvelles valeurs avec l'utilisateur.
L'analyseur signale ces deux familles et, si elles suivent une connexion à risque sur le même compte, fait monter la chaîne « connexion à risque → changement de sécurité » en critique.
Pourquoi la 2SV n'a pas suffi, et ce qui marche
Les codes SMS, les codes d'application d'authentification et les invites sur téléphone sont tous relayables : la victime les valide sur le proxy de l'attaquant. Les méthodes résistantes au phishing (clés de sécurité et clés d'accès FIDO2/WebAuthn) sont liées à l'origine réelle et ne fonctionnent pas à travers un proxy. La fiche de la CISA sur la MFA résistante au phishing explique la différence. Google permet aux administrateurs d'imposer les clés de sécurité par unité organisationnelle ou par groupe. Commencez par la comptabilité et les administrateurs. Voir aussi validation en deux étapes.
Réponse
- Réinitialisez les cookies de connexion de l'utilisateur pour tuer la session volée.
- Regardez ce qui a suivi : autorisations OAuth, transfert, filtres. Voir le guide d'investigation.
- Réinitialisez le mot de passe après avoir supprimé la persistance, et rétablissez la 2SV et les options de récupération.
- Pivotez sur les IP de l'attaquant dans l'onglet Entités de l'analyseur pour trouver les autres comptes atteints.
Suite de la série : les règles de transfert Gmail posées par les attaquants. Si votre Workspace s'authentifie via Okta, le côté fournisseur d'identité de la même connexion est traité sur oktaforensics.com.
FAQ
Pourquoi l'attaquant est-il entré malgré la validation en deux étapes ?
Les kits d'hameçonnage adversary-in-the-middle servent la vraie page de connexion Google via un proxy. La victime saisit son mot de passe et valide l'invite ou tape le code, et le kit conserve la session obtenue. Seules les méthodes résistantes au phishing, comme les clés de sécurité et les clés d'accès, sont liées au vrai site et y résistent.
Une connexion depuis un VPS ou un fournisseur cloud est-elle toujours malveillante ?
Non. Les VPN d'entreprise, passerelles web sécurisées et certains services de bureau à distance sortent par des réseaux cloud. Vérifiez d'abord l'IP par rapport à votre propre infrastructure. Pour un utilisateur ordinaire sans ce type de configuration, une connexion réussie depuis un hébergeur est un signal fort de prise de contrôle.