Introduction

Avec l'augmentation de l'adoption des environnement cloud, la sécurité ne peut plus reposer uniquement sur la protection du périmètre externe des entreprises. De nombreux services en ligne (SaaS) échappent à ce modèle classique, rendant la gestion des identités et des accès centrale pour protéger l’organisation.

Dans ce contexte, le cryptojacking apparaît comme une menace croissante pour les environnements cloud. Des infrastructures hébergées chez des fournisseurs tels qu’AWS, Azure ou GCP sont régulièrement visées. Notre équipe de réponse à incident est récemment intervenue sur l’une de ces plateformes après la détection d’une hausse soudaine et anormale des coûts liés à la consommation de ressources cloud, un indicateur fréquent d’activités malveillantes comme le déploiement non autorisé de mineurs de cryptomonnaies.

Qu’est-ce que le cryptojacking ?

Le minage de cryptomonnaies requiert une puissance de calcul considérable, ce qui implique non seulement des coûts énergétiques élevés, mais également des investissements importants en infrastructure. Ces dépenses doivent normalement être déduites des gains générés par l’activité de minage, ce qui réduit fortement la rentabilité.

Les attaques de type cryptojacking sont donc particulièrement attractives pour les cybercriminels, puisqu’elles leur permettent de s’affranchir de ces coûts : l’infrastructure, les ressources de calcul et la consommation énergétique sont intégralement supportées par la victime. L’attaquant, quant à lui, conserve la totalité des bénéfices issus du minage illicite.

Retour terrain d’un cas de cryptojacking

Accès Initial

Lors de notre intervention en réponse à incident, nous avons analysé une infrastructure reposant sur un environnement GCP (Google Cloud Platform). Bien que le vecteur d’accès initial de l’attaquant n’ait pas pu être déterminé avec précision, le compte utilisé pour mener les actions malveillantes a, quant à lui, été identifié.

Plusieurs pistes ont été explorées afin de comprendre comment l’attaquant a pu compromettre les identifiants de ce compte. L’hypothèse principale met en évidence des faiblesses dans l’hygiène de gestion des mots de passe ainsi qu’un manque de cloisonnement entre les comptes professionnels et personnels, augmentant ainsi la surface d’exposition.

Premier élément constaté, le compte compromis appartenait à un développeur disposant de privilèges étendus sur l’infrastructure GCP, ce qui a facilité l’escalade des actions malveillantes et amplifié l’impact de l’attaque.

Mise en place de l’infrastructure et persistance sur l’environnement

Après avoir compromis un compte valide au sein de l’organisation, l’attaquant a déployé son infrastructure de cryptomining de la manière suivante : une permission au niveau organisationnel lui a permis de créer de nouveaux projets GCP, qu’il a ensuite rattachés au compte de facturation associé à un projet légitime de cette même organisation.

Ce mécanisme a permis à l’attaquant de provisionner des projets sous son contrôle exclusif et d’y déployer les ressources nécessaires à ses activités malveillantes (machines virtuelles, stockage, etc.), tout en transférant l’intégralité des coûts d’infrastructure et de consommation à la victime.

L’analyse forensic de l’environnement a permis d’identifier plusieurs appels aux API GCP utilisés pour mettre en place les ressources nécessaires à l’infrastructure malveillante. Les principales actions observées sont :

• CreateProject : Création de nouveaux projets GCP
• google.api.serviceusage.v1.ServiceUsage.EnableService : permet l'activation répétée des services GCP nécessaires (Compute Engine, Cloud Storage, etc.) pour la mise en place de l'infrastructure
• google.longrunning.Operations.GetOperation : Suivi des opérations en cours afin de valider le déploiement des ressources.
• AssignResourceToBillingAccount : Association des projets nouvellement créés au compte de facturation de l’organisation.

La séquence complète en partant de la création du projet à son rattachement à la facturation, avec l’activation des services requis s’est déroulée en moins de 30 secondes, ce qui suggère l’utilisation de scripts ou d’outils automatisés pour orchestrer le déploiement.

Analyse des logs

Pour identifier ces activités, GCP met à disposition l’outil Logs Explorer, permettant d’analyser les différents journaux associés à l’organisation. Via cette interface, un analyste peut consulter les appels aux API effectués au sein de l’infrastructure, facilitant ainsi la détection d’actions suspectes ou non conformes.

Pour accéder à cette fonctionnalité, rendez-vous sur la console de votre instance GCP : https://console.cloud.google.com.

Une fois connecté, ouvrez le menu qui se trouve sur la gauche pour accéder aux fonctionnalités de monitoring. Dans les fonctionnalités disponibles, sous la section Explorer, sélectionnez Explorateur de journaux.

Une fois l’explorateur ouvert, vous pourrez commencer votre analyse des différents logs qui concernent votre infrastructure GCP.

Mise en garde sur le niveau d’information

Toutefois, il est important de noter que tous les appels d’API ne sont pas journalisés. Cela crée ainsi une zone d'ombre exploitable par un attaquant, notamment lors de la phase de reconnaissance suite à l'obtention d'un compte valide ou la récupération d'un jeton d'authentification d'un compte de service.

Concernant l'obtention d'un compte de service

Un scénario concret serait de se mettre dans la position d'une application web exposée sur internet via une ressource gérée par GCP comme une Compute Instance. Ensuite via différents mécanismes, un attaquant parvient à trouver une vulnérabilité qui lui permet d'exécuter du code distant via une injection de commande.
Ainsi il parvient à exécuter la commande suivante pour obtenir le jeton de connexion du compte de service associé à cette ressource :

$ curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token  

Avec ce jeton, il peut maintenant faire l’appel à la fonction testIamPermissions, qui permet de découvrir les permissions du compte compromis qui n’est pas monitoré par les solutions natives de Google. Ainsi, un attaquant peut énumérer les privilèges associés à un compte sans générer d’alertes ni être détecté par les équipes défensives.

Lors de nos missions de pentest en mode assumed breach sur des environnements GCP, nous exploitons régulièrement cette technique d’énumération silencieuse en nous appuyant sur des outils open source tels que :

• https://github.com/egre55/gcp-permissions-checker
• https://github.com/carlospolop/CloudPEASS

Ce type de lacune dans la visibilité des appels d’API démontre la nécessité d’implémenter des mécanismes complémentaires de détection, afin de surveiller les activités suspectes qui échappent aux journaux natifs de GCP.

Exemples de requêtes LQL

Dans Logs Explorer, il est possible de construire des requêtes en LQL (Logging Query Language) afin d’extraire les événements pertinents liés à une compromission. Ces requêtes permettent de filtrer les appels API spécifiques et de restreindre la recherche à une période donnée.

Exemple 1: Détection de la création de projets

La requête suivante permet d’identifier les appels à l’API de création de projets (CreateProject), sur une période limitée ici au mois de juin 2025 :

timestamp >= "2025-06-01T00:00:00Z"  
timestamp <= "2025-06-30T24:00:00Z"  
(protoPayload.methodName="google.cloudresourcemanager.v1.Projects.CreateProject"  
 OR protoPayload.methodName="google.cloudresourcemanager.v3.Projects.CreateProject")  

Exemple 2: Détection de l’association d’un projet à un compte de facturation

La requête suivante permet de repérer les appels à l’API AssignResourceToBillingAccount, utilisés pour rattacher un projet à un compte de facturation :

timestamp >= "2025-06-01T00:00:00Z"  
timestamp <= "2025-06-30T24:00:00Z"  
protoPayload.serviceName="cloudbilling.googleapis.com"  
protoPayload.methodName="google.cloud.billing.v1.CloudBilling.AssignResourceToBillingAccount"  

Exemple 3: recherche d'un utilisateur en particulier

Ici, la requête est un peu plus simple que les deux précédentes. Il suffit de mettre le nom de l’utilisateur que vous recherchez pour l’identifier les journaux. Cela peut être juste le nom de l’utilisateur ou le mail qui est utilisé pour accéder aux différentes ressources disponibles dans l’organisation GCP.

timestamp >= "2025-06-01T00:00:00Z"  
timestamp <= "2025-06-30T24:00:00Z"  
"<Nom de l'utilisateur>"  

Si vous souhaitez construire vos propres requêtes, la documentation de google offre quelques exemples.

Chronologie des événements

Ces recherches permettent de reconstituer la timeline des actions malveillantes (création du projet, activation des services, rattachement au billing), et constituent des IoCs (Indicators of Compromise) exploitables pour d’autres investigations sur des environnements GCP similaires.

Certaines étapes ont été associées au framework MITRE ATT&CK, un référentiel international décrivant les techniques utilisées par les cybercriminels. Cette approche permet de mieux comprendre le déroulement de l’attaque et d’identifier les priorités en matière de détection et de renforcement de la sécurité:

• Accès Initial: T1078 - Compte valide
• Exploitation de privilège: T1098 - Abus de permissions
• Setup : T1648 - Exécution Serverless
• Impact Financier : T1657
• Compute Hijacking : T1496.001

Remédiation

Suite aux différents éléments mentionnés dans cet article, voici des pistes de remédiation à mettre en place sur un environnement GCP.

Pour la gestion des identités et des accès (IAM), il est recommandé d’appliquer le principe du moindre privilège, en limitant les permissions attribuées aux différents utilisateurs. Lorsque certains utilisateurs doivent accéder à des services spécifiques, l’impersonation de comptes de service peut être mise en œuvre, tout en veillant à une configuration stricte de cette méthode d’authentification. De plus, la MFA doit être activée sur l’ensemble des comptes, qu’ils soient gérés via Google Workspace ou directement sur GCP.

Afin d’améliorer la détection, un audit régulier des permissions attribuées aux comptes et services de l’organisation permettra d’identifier les identités disposant de privilèges excessifs. Ensuite, la mise en place d’alertes spécifiques permettra de surveiller les appels aux API sensibles telles que : Projects.CreateProject, AssignResourceToBillingAccount et ServiceUsage.EnableService.

Enfin, pour accroître la visibilité et la corrélation des logs, il est conseillé d’intégrer GCP à des solutions telles que Chronicle (le SIEM de Google) ou le Security Command Center. Ce dernier dispose de mécanismes de détection intégrés, notamment pour les activités liées au cryptomining.

Conclusion

Cet article a illustré un exemple concret de compromission d’un environnement cloud, en l’occurrence sur une infrastructure GCP. Toutefois, il est important de souligner que tous les fournisseurs cloud (AWS, Azure, GCP, etc.) sont exposés à ce type d’attaques. Comme mentionné précédemment, leur détection reste particulièrement complexe dans des environnements toujours plus distribués et dynamiques.

Pour s’en prémunir, la mise en place d’audits de sécurité réguliers est essentielle. Un audit de configuration permet dans un premier temps d’identifier les erreurs classiques ainsi que les comportements par défaut susceptibles de mettre en péril une organisation.

Cependant, il est tout aussi crucial d’adopter une vision offensive. La réalisation de tests d’intrusion en mode assumed breach offre une approche complémentaire, en simulant un attaquant ayant déjà obtenu un premier accès dans l’environnement cloud. Ce type d’évaluation permet de révéler des vulnérabilités qui resteraient invisibles lors d’un simple pentest externe ou qui resteraient au niveau applicatif. Par exemple, l’exploitation de permissions excessives sur des comptes de service peut ouvrir de nouveaux chemins de compromission et amplifier l’impact d’une attaque.