Une compromission GCP commentée (cas fictif)

En bref. Cet incident est fictif : l'entreprise, les personnes, le projet, les clés et les adresses IP sont inventés (les IP proviennent des plages de documentation de la RFC 5737). C'est le jeu de données derrière Essayer un exemple sur la page de l'outil. Une clé de compte de service de CI, créée pour un test local, fuit ; six jours plus tard, elle est utilisée depuis un VPS qui énumère, accorde roles/owner à un compte Gmail, implante un script de démarrage, télécharge 140 objets, rend le bucket public et supprime le sink qui alimente le SIEM, le tout en 55 minutes. Chaque étape ci-dessous est un constat réel que l'analyseur produit sur cet exemple.

Un cas commenté sert à montrer le raisonnement, pas l'outil. Chaque étape nomme le champ de journal qui porte la preuve, pour que vous puissiez la reproduire sur vos propres données avec Logs Explorer si vous préférez.

Le décor

« Northwind Analytics » (fictive) exploite un projet nw-analytics-prod avec :

un compte de service de CI, ci-deployer@…, utilisé par Terraform ;
une VM d'ETL, etl-worker-1 dans us-central1-a, qui tourne sous etl-runner@… et lit des exports quotidiens ;
un bucket nw-analytics-exports contenant des extractions clients ;
un sink nw-audit-to-siem qui exporte les journaux d'audit vers Pub/Sub pour le SIEM ;
des journaux Data Access activés, et des VPC Flow Logs sur le sous-réseau par défaut.

L'export correspond à ce qu'on obtient en copiant le bucket d'un sink : 26 fragments horaires JSON lines sous cloudaudit.googleapis.com/… et compute.googleapis.com/vpc_flows/…, plus un téléchargement Logs Explorer. L'analyseur lit 215 entrées d'audit et 65 enregistrements de flux, et met de côté 3 entrées GKE pour Kubernetes Forensics.

Le verdict

Compromis, avec 16 constats : 3 critiques, 8 hauts, 5 moyens. La première raison est la corrélation « chaîne d'attaque : accès volé, puis prise de contrôle », qui couvre la période de 02:03 à 02:57 UTC le 14 septembre.

Un verdict est une affirmation ; le reste de l'article la vérifie.

8 septembre : naissance de la clé

09:14:22  alex.martin@…  google.iam.admin.v1.CreateServiceAccountKey  from 198.51.100.24 (gcloud, macOS)

sa_key_created (moyenne). Alex crée une clé JSON pour ci-deployer afin de tester Terraform en local. Quelques minutes plus tard, la clé est utilisée depuis la même IP de bureau avec un user agent Terraform/1.9.5 : serviceAccountKeyName se termine par …/keys/6f1c2d9e…. Cela déclenche sa_key_used_external (moyenne) : la clé est utilisée hors de Google Cloud. En soi, c'est banal. Cela devient important parce que l'IP du bureau est désormais la première IP connue de la clé.

Les jours suivants sont routiniers et ne produisent aucun constat : le compte de service d'ETL lit quatre objets chaque matin depuis l'IP interne de la VM, Priya liste des instances, restreint une règle de pare-feu à la plage IAP, accorde roles/viewer à un collègue ; Google migre la VM à chaud (une entrée System Event de system@google.com). C'est cette référence qui fait ressortir le jour suivant. Exportez une période de référence chaque fois que possible.

14 septembre, 02:03 : la clé est utilisée depuis ailleurs

02:03:11  ci-deployer@…  GetIamPolicy  from 203.0.113.66 (gcloud, Linux)  key 6f1c2d9e…

sa_key_new_ip (haute, accès initial, T1078.004). Même clé, nouvelle IP publique, nouveau client : gcloud sous Linux au lieu de Terraform sous macOS, à 2 heures du matin. La clé a été copiée. L'article sur la clé divulguée explique comment distinguer ce cas du bruit de la CI.

De 02:04 à 02:08 : l'énumération

24 appels en quatre minutes, tous en status.code: 7 (PERMISSION_DENIED) : accès au secret prod-db-password, lecture de la stratégie IAM et des règles d'administration de l'organisation, du compte de facturation, des configurations de notification de Security Command Center, des comptes de service d'un autre projet. permission_denied_burst (moyenne, découverte). L'attaquant découvre ce que la clé permet : pas grand-chose au niveau de l'organisation, mais setIamPolicy sur le projet.

02:11 : Owner pour un compte Gmail

02:11:07  ci-deployer@…  SetIamPolicy  ADD roles/owner user:nw.ops.backup@gmail.com

Trois constats sur une seule entrée : owner_to_consumer (critique), owner_editor_granted (haute), consumer_account_granted (haute). Le nom a été choisi pour ressembler à un compte de sauvegarde interne ; le domaine le trahit. Sept minutes plus tard, ce compte Gmail liste les instances depuis la même IP de VPS, dans un navigateur : l'attaquant est passé à une identité qui survit à la désactivation de la clé. Voir l'abus de SetIamPolicy.

De 02:24 à 02:26 : porte dérobée sur la VM

02:24:40  nw.ops.backup@gmail.com  v1.compute.instances.setMetadata  +startup-script  etl-worker-1
02:25:10  nw.ops.backup@gmail.com  v1.compute.projects.setCommonInstanceMetadata  +ssh-keys  -enable-oslogin
02:26:02  nw.ops.backup@gmail.com  v1.compute.instances.reset  etl-worker-1

startup_script_changed (haute), ssh_key_added (moyenne), oslogin_changed (haute). Un script de démarrage s'exécute en root au démarrage ; le reset le fait s'exécuter tout de suite. Une clé SSH au niveau du projet et OS Login retiré donnent un accès shell à toutes les VM. Le journal d'audit nomme les clés, pas le script : une vraie investigation prendrait un instantané du disque et lirait les métadonnées. Voir l'abus de Compute Engine.

À partir de 02:27 : le réseau confirme

Les VPC Flow Logs montrent une session SSH entrante de 203.0.113.66 vers la VM sur le port 22 à 02:27, puis 36 flux HTTPS sortants d'etl-worker-1 vers la même IP jusqu'à 02:54, environ 1,9 Gio au total, destination géolocalisée aux Pays-Bas.

flow_large_egress (moyenne) et flow_ioc_match (haute) : l'IP qui a utilisé la clé divulguée est aussi le pair de la VM piégée. C'est le lien entre le plan de contrôle et ce que la VM a réellement fait. Voir l'analyse des VPC Flow Logs.

De 02:33 à 02:40 : le bucket

140 storage.objects.get sur nw-analytics-exports, des objets nommés à partir de customers/2026/q3/customer-extract-0000.csv.gz, en six minutes et demie, par le compte Gmail : bulk_object_reads (haute). Puis :

02:40:15  nw.ops.backup@gmail.com  storage.setIamPermissions  ADD roles/storage.objectViewer allUsers

public_access_granted (critique). À partir de 02:40, le bucket est public ; les lectures anonymes n'apparaîtraient pas dans les journaux d'audit. Le rapport doit énoncer une fenêtre d'exposition, pas seulement les 140 lectures prouvées. Voir l'exfiltration GCS et BigQuery.

02:57 : effacer les traces

02:57:42  nw.ops.backup@gmail.com  google.logging.v2.ConfigServiceV2.DeleteSink  nw-audit-to-siem

sink_deleted (haute). À partir de là, le SIEM ne reçoit plus rien. La suppression elle-même se trouve dans le bucket _Required, comme toutes les entrées Admin Activity avant et après. Voir l'évasion des défenses.

Les pivots qui relient le tout

IP 203.0.113.66 : 173 entrées d'audit sous deux principaux (le compte de service de CI, puis le compte Gmail), plus les enregistrements de flux. Un clic dans l'onglet Entités filtre le tableau des événements sur elle.
Clé 6f1c2d9e… : créée par Alex, utilisée depuis deux IP, la seconde hostile.
Principal nw.ops.backup@gmail.com : 147 entrées, toutes depuis le VPS, première apparition à 02:18.

La checklist générée par l'outil

Dans l'ordre : déclarer un incident et préserver les journaux ; bloquer l'IP ; retirer la liaison IAM et restreindre les domaines des membres ; rendre le bucket privé et évaluer l'exposition des données ; désactiver la clé et renouveler ce que le compte de service de CI pouvait lire ; prendre un instantané, examiner et reconstruire la VM ; réimposer OS Login ; restaurer le sink ; interdire la création de clés ; examiner l'énumération ; retirer les clés SSH. Les actions de confinement viennent en premier parce que l'attaquant détient encore deux identités.

Ce que ce cas enseigne

La fuite n'était pas l'attaque ; l'attaque a commencé six jours plus tard. Les créations de clés méritent d'être examinées pour elles-mêmes.
L'attaquant a changé d'identité en huit minutes. Pivotez sur les IP, pas seulement sur les principaux.
Les journaux Data Access et les journaux de flux ont transformé « peut-être » en « 140 fichiers et 1,9 Gio ». Sans eux, c'est l'article sur les limites qui s'applique.

Pour reproduire, ouvrez l'analyseur, cliquez sur Essayer un exemple, et suivez le guide pas à pas.

Pour aller plus loin

Réponse à incident Google Cloud : projet compromis.
Répondre à des identifiants Google Cloud compromis — documentation Google Cloud.
Matrice MITRE ATT&CK IaaS.