Minage de crypto et scripts de démarrage GCP : détection
Détecter l'abus de Compute Engine dans l'audit : scripts de démarrage piégés, clés SSH, OS Login retiré, VM à GPU, rafales de VM, régions inutilisées.
En bref. L'abus de Compute Engine laisse des traces nettes dans Admin Activity. Persistance : des entrées setMetadata / setCommonInstanceMetadata dont le delta ajoute startup-script, startup-script-url, ssh-keys, ou retire enable-oslogin / block-project-ssh-keys. Minage : compute.instances.insert avec guestAccelerators ou des types de machine a2-/a3-/g2-, des rafales de créations, des VM dans des régions que vous n'utilisez jamais. L'entrée d'audit indique quelles clés de métadonnées ont changé ; le contenu se récupère sur la VM ou son disque.
Compute Engine est l'endroit où un projet Google Cloud compromis se transforme le plus souvent en facture. Le rapport Threat Horizons de novembre 2021 de Google indique que 86 % d'un échantillon de 50 instances Google Cloud récemment compromises servaient à miner de la cryptomonnaie et que, lorsque la chronologie était disponible, le logiciel de minage avait été téléchargé dans 58 % des cas moins de 22 secondes après la compromission. C'est le volet « impact » (T1496, Resource Hijacking). Le volet persistance, les portes dérobées dans les métadonnées des VM, est plus discret et plus dangereux.
Scripts de démarrage : root à chaque démarrage
Un script de démarrage est une valeur de métadonnées que l'environnement invité exécute en root, à chaque démarrage sous Linux (scripts de démarrage sur les VM Linux). Toute personne disposant de compute.instances.setMetadata sur une VM, ou de compute.projects.setCommonInstanceMetadata sur le projet, peut donc exécuter du code en root sur ces VM au prochain redémarrage, et provoquer ce redémarrage avec reset. Charges utiles typiques : un reverse shell, un mineur, ou un script qui lit le jeton du compte de service sur le serveur de métadonnées.
Les clés qui exécutent du code :
| OS | Clés de métadonnées |
|---|---|
| Linux | startup-script, startup-script-url, shutdown-script, shutdown-script-url |
| Windows | windows-startup-script-ps1, -cmd, -bat, -url, sysprep-specialize-script-ps1, -cmd |
Dans le journal d'audit, cherchez :
protoPayload.methodName=("v1.compute.instances.setMetadata" OR "v1.compute.projects.setCommonInstanceMetadata")
et lisez protoPayload.metadata.instanceMetadataDelta (ou projectMetadataDelta), qui liste addedMetadataKeys, modifiedMetadataKeys et deletedMetadataKeys. Les opérations Compute sont de longue durée : un même changement peut produire deux entrées (operation.first et operation.last) ; comptez-le une seule fois.
N'attendez pas le script lui-même dans le journal. Récupérez-le avec gcloud compute instances describe VM --format=json (ou project-info describe pour les métadonnées du projet), et prenez un instantané du disque de démarrage avant toute autre chose pour examiner ce qui s'est exécuté. Security Command Center propose une détection comparable, Persistence: GCE Admin Added Startup Script. MITRE rattache cela à T1037 et, pour l'exécution de commandes via le plan de contrôle cloud, à T1651.
Clés SSH et OS Login
Deux manières d'obtenir un shell sans toucher à IAM :
- Clés SSH dans les métadonnées : ajouter une ligne à
ssh-keysdans les métadonnées de l'instance ou du projet donne accès SSH aux VM (ajouter des clés SSH aux VM). Les clés au niveau du projet s'appliquent à toutes les VM qui ne les bloquent pas. MITRE T1098.004. - Désactiver OS Login : avec
enable-oslogin=TRUE, l'accès SSH est contrôlé par IAM et les clés des métadonnées sont ignorées. Supprimer ou modifierenable-oslogin(oublock-project-ssh-keys) remet les clés des métadonnées en jeu. C'est l'étape qui rend la clé SSH utile, et elle est rare en exploitation normale.
La combinaison « ssh-keys ajoutée et enable-oslogin supprimée dans le même appel setCommonInstanceMetadata » est à peu près aussi claire que peut l'être une preuve dans le cloud. La correction consiste à réactiver OS Login et à imposer la règle d'administration compute.requireOsLogin (OS Login).
Minage : VM à GPU, rafales et régions inutilisées
Les entrées de création sont v1.compute.instances.insert, bulkInsert et instanceTemplates.insert. La requête montre ce qui a été demandé :
guestAccelerators(GPU attachés), ou des types de machine optimisés pour les accélérateurs (famillesa2-,a3-,a4-,g2-) dansmachineType;- un volume : de nombreuses instances créées par le même principal en peu de temps ;
- une zone dans une région où le projet n'a aucune autre activité. Les attaquants choisissent les régions que personne ne surveille (T1535, Unused/Unsupported Cloud Regions).
Les erreurs de quota sont aussi un indice : un attaquant qui bute sur les quotas de GPU laisse des appels insert en échec. Et regardez la facturation : des mineurs qui tournent depuis des heures s'y voient avant que quiconque lise un journal.
Pare-feu ouverts à Internet
v1.compute.firewalls.insert, patch ou update avec sourceRanges contenant 0.0.0.0/0 (ou ::/0) ouvre un port à tout le monde : SSH pour l'attaquant, ou un port pour un web shell. Rattaché à T1562.007.
Confirmer avec les preuves réseau
Les changements de métadonnées disent ce qui a été configuré. Les VPC Flow Logs, s'ils sont activés sur le sous-réseau, disent ce qui s'est passé : une session SSH entrante depuis l'IP de l'attaquant après le reset, des connexions sortantes de la VM vers cette IP ou vers des pools de minage, le volume sortant.
Ce que l'analyseur signale
| Règle | Sévérité | Condition |
|---|---|---|
startup_script_changed | Haute | Clé de script de démarrage / d'arrêt / sysprep ajoutée ou modifiée dans les métadonnées d'instance ou de projet |
oslogin_changed | Haute | enable-oslogin, enable-oslogin-2fa ou block-project-ssh-keys modifiée ou supprimée |
ssh_key_added | Moyenne | ssh-keys / sshKeys ajoutée ou modifiée |
gpu_instance_created | Moyenne | Instance ou modèle créé avec des accélérateurs ou un type de machine optimisé pour les accélérateurs |
instance_burst | Haute | Au moins 5 créations d'instance par le même principal en 30 minutes |
new_zone_instance (analyse) | Moyenne | Instance créée dans une région sans activité antérieure dans les journaux |
firewall_opened | Moyenne | Règle de pare-feu créée ou modifiée avec la source 0.0.0.0/0 ou ::/0 |
Les clés de métadonnées sont affichées sur chaque événement sous la forme +startup-script, ~enable-oslogin, -block-project-ssh-keys. La checklist de remédiation demande de prendre un instantané et d'examiner, puis de reconstruire plutôt que de nettoyer, et de renouveler les identifiants que détenait la VM.
Remédiation
Prenez des instantanés des disques des VM concernées pour l'analyse, puis reconstruisez-les à partir d'une image de confiance ; retirez les clés SSH et scripts de démarrage inconnus des métadonnées d'instance et de projet ; réactivez OS Login et imposez-le ; arrêtez les instances que personne n'a approuvées ; plafonnez les quotas de GPU ; restreignez les emplacements avec gcp.resourceLocations. Le jeton du compte de service de la VM doit être considéré comme volé : passez en revue ce que ce compte pouvait faire.
Questions fréquentes
Comment trouver une porte dérobée dans un script de démarrage Google Cloud ?
Cherchez dans les journaux Admin Activity les entrées v1.compute.instances.setMetadata et v1.compute.projects.setCommonInstanceMetadata dont le delta de métadonnées ajoute ou modifie startup-script, startup-script-url ou leurs équivalents Windows. Lisez ensuite la valeur actuelle de la clé sur la VM ou le projet, et prenez un instantané du disque.
Le minage de cryptomonnaie est-il fréquent après une compromission Google Cloud ?
Le rapport Threat Horizons de novembre 2021 de Google indique que 86 % d'un échantillon de 50 instances Google Cloud récemment compromises servaient à miner de la cryptomonnaie.
Pour aller plus loin
- Journaux d'audit de Compute Engine — documentation Google Cloud.
- À propos d'OS Login — documentation Google Cloud.
- Réponse à incident Google Cloud : projet compromis.