Introduction

With the increasing adoption of cloud environments, security can no longer rely solely on protecting the external perimeter of companies. Many online services (SaaS) fall outside this classic model, making identity and access management central to protecting the organization.

Against this backdrop, the encryptojacking is emerging as a growing threat to cloud environments. Infrastructures hosted by providers such as AWS, Azure or GCP are regularly targeted. Our incident response team recently intervened on one of these platforms after detecting a sudden and abnormal rise in costs linked to cloud resource consumption, a frequent indicator of malicious activity such as the unauthorized deployment of cryptocurrency miners.

What is cryptojacking?

Cryptocurrency mining requires considerable computing power, which implies not only high energy costs, but also major investments in infrastructure. These expenses normally have to be deducted from the profits generated by the mining activity, which greatly reduces profitability.

Cryptojacking attacks are therefore particularly attractive to cybercriminals, as they enable them to avoid these costs: infrastructure, computing resources and energy consumption are entirely borne by the victim. The attacker, on the other hand, retains all the profits from illegal mining.

Cryptojacking case report

Initial access

During our incident response, we analyzed an infrastructure based on a GCP (Google Cloud Platform) environment. Although the attacker's initial access vector could not be precisely determined, the account used to carry out the malicious actions was identified.

Several avenues have been explored to understand how the attacker was able to compromise this account's credentials. The main hypothesis points to weaknesses in password management hygiene, as well as a lack of compartmentalization between business and personal accounts, thus increasing the surface area of exposure.

Firstly, the compromised account belonged to a developer with extended privileges on the GCP infrastructure, which facilitated the escalation of malicious actions and amplified the impact of the attack.

Setting up the infrastructure and persistence on the environment

After compromising a valid account within the organization, the attacker deployed his cryptomining infrastructure as follows: a organizational-level permission allowed him to create new GCP projects, which he then attached to the billing account associated with a legitimate project within the same organization.

This mechanism enabled the attacker to provision projects under his exclusive control and deploy the resources necessary for his malicious activities (virtual machines, storage, etc.), while transferring all infrastructure and consumption costs to the victim.

The forensic analysis of the environment identified several calls to the API GCP used to set up the resources required by the malicious infrastructure. The main actions observed are :

• CreateProject: Create new GCP projects
• google.api.serviceusage.v1.ServiceUsage.EnableService: enables repeated activation of the GCP services required (Compute Engine, Cloud Storage, etc.) to set up the infrastructure.
• google.longrunning.Operations.GetOperation: Monitor current operations to validate resource deployment.
• AssignResourceToBillingAccount: Assign newly created projects to the organization's billing account.

The complete sequence from creation of the project to its attachment to billing, with activation of the required services took place in less than 30 seconds, suggesting the use of scripts or automated tools to orchestrate the deployment.

Log analysis

To identify these activities, GCP provides Logs Explorer, a tool for analyzing the various logs associated with the organization. Via this interface, an analyst can view API calls made within the infrastructure, facilitating the detection of suspicious or non-compliant actions.

To access this feature, go to the console of your GCP instance: https://console.cloud.google.com.

Once logged in, open the menu on the left to access monitoring features. In the available functions, under the Explorer section, select Log Explorer.

Once you've opened the explorer, you can start analyzing the various logs concerning your GCP infrastructure.

Information level warning

However, it is important to note that not all API calls are logged. This creates a grey area that can be exploited by an attacker, particularly during the recognition phase following the acquisition of a valid account or the recovery of an authentication token from a service account.

About obtaining a service account

A concrete scenario would be to put oneself in the position of a web application exposed to the Internet via a GCP-managed resource such as a Compute Instance. Then, via various mechanisms, an attacker manages to find a vulnerability that enables him to execute remote code via command injection.
It then executes the following command to obtain the connection token for the service account associated with this resource:

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

With this token, he can now make a call to the testIamPermissions function, which discovers the permissions of the compromised account that is not monitored by Google's native solutions. Thus, an attacker can enumerate the privileges associated with an account without generating alerts or being detected by defensive teams.

During our pentest in assumed breach mode on GCP environments, we regularly exploit this silent enumeration technique using open source tools such as :

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

This type of gap in the visibility of API calls demonstrates the need to implement complementary detection mechanisms, in order to monitor suspicious activities that escape GCP's native logs.

LQL query examples

In Logs Explorer, it is possible to build LQL (Logging Query Language) queries to extract relevant events linked to a compromise. These queries can filter out specific API calls and restrict the search to a given period.

Example 1: Detection of project creation

The following query identifies calls to the project creation API (CreateProject), over a period limited here to June 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")  

Example 2: Detecting the association of a project with a billing account

The following query identifies calls to the AssignResourceToBillingAccount API, used to attach a project to a billing account:

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"  

Example 3: search for a specific user

Here, the query is a little simpler than the previous two. Simply enter the name of the user you're looking for to identify the logs. This may be just the user's name, or the e-mail address used to access the various resources available in the GCP organization.

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

If you'd like to build your own queries, the Google documentation offers some useful tips.

Chronology of events

These searches make it possible to reconstruct the timeline of malicious actions (project creation, service activation, billing attachment), and constitute IoCs (Indicators of Compromise) that can be exploited for further investigations on similar GCP environments.

Certain stages are associated with framework MITRE ATT&CK, an international standard describing the techniques used by cybercriminals. This approach provides a better understanding of how attacks are carried out, and helps identify priorities for detection and security reinforcement:

• Initial access: T1078 - Valid account
• Privilege exploitation: T1098 - Permission abuse
• Setup : T1648 - Serverless execution
• Financial impact : T1657
• Compute Hijacking: T1496.001

Remediation

Following on from the various elements mentioned in this article, here are some remedial measures to be implemented in a GCP environment.

For identity and access management (IAM), we recommend applying the principle of least privilege, limiting the permissions assigned to individual users. When certain users need access to specific services, impersonation of service accounts can be implemented, while ensuring strict configuration of this authentication method. In addition, MFA must be enabled on all accounts, whether managed via Google Workspace or directly on GCP.

To improve detection, a regular audit of the permissions assigned to the organization's accounts and services will help identify identities with excessive privileges. Next, the implementation of specific alerts will enable monitoring of calls to sensitive APIs such as : Projects.CreateProject, AssignResourceToBillingAccount and ServiceUsage.EnableService.

Finally, to increase the visibility and correlation of logs, we recommend integrating GCP with solutions such as Chronicle (Google's SIEM) or the Security Command Center. The latter features built-in detection mechanisms, particularly for activities linked to cryptomining.

Conclusion

This article has illustrated a concrete example of compromise of a cloud environment, in this case on a GCP infrastructure. However, it is important to stress that all cloud providers (AWS, Azure, GCP, etc.) are exposed to this type of attack. As already mentioned, detecting them remains particularly complex in increasingly distributed and dynamic environments.

To guard against this, regular security audits are essential. A configuration audit allows us to identify classic errors and default behaviors that can jeopardize an organization.

However, it is just as crucial to adopt an offensive vision. Performing intrusion tests in assumed breach mode offers a complementary approach, by simulating an attacker who has already gained initial access to the cloud environment. This type of assessment can reveal vulnerabilities that would remain invisible during a simple external pentest, or that would remain at the application level. For example, the exploitation of excessive permissions on service accounts can open up new compromise paths and amplify the impact of an attack.