A widely repeated claim says that 86% of compromised Google Cloud instances were being used to mine cryptocurrency. The number is real, but it is often repeated without the context needed to interpret it correctly.
An expert take by Ethan Cross, HakTechs.com Lead Analyst
Google published the finding in November 2021 after examining 50 recently compromised Google Cloud Platform instances. Cryptocurrency mining appeared on 86% of that specific sample. It did not mean that 86% of all Google Cloud instances, customers, or servers had been compromised.
The incidents also did not point to a platform-wide breach of Google Cloud infrastructure. Google reported that attackers commonly entered customer-controlled workloads through weak authentication, vulnerable third-party software, configuration errors, or exposed credentials.
The broader lesson is straightforward: an internet-facing workload with weak controls can be discovered and abused very quickly.
Quick Answer: What Did Google Actually Report?
Google’s first Threat Horizons report examined 50 Google Cloud instances that were already known to have been compromised. Of those instances, 86% had been used for cryptocurrency mining, allowing attackers to consume computing resources for their own financial benefit.
This was a small, incident-focused sample. It was not a measurement of the entire Google Cloud customer base. The figure showed how common cryptomining was among the examined compromises, not how often GCP instances overall were being breached.
Google also observed other malicious activity on some affected systems. An administrator who discovers a miner should therefore treat it as evidence of unauthorized access and investigate for additional payloads, persistence, stolen credentials, lateral movement, or data access.
Where the 86% Statistic Came From
The 50-instance sample
The statistic appeared in the November 2021 edition of Google’s Threat Horizons report. Researchers reviewed 50 recently compromised GCP instances and found cryptocurrency-mining activity on 86% of them.
The report described mining as a resource-intensive, for-profit activity that could consume CPU or GPU capacity and, in some cases, storage.
The sample consisted entirely of known compromises. It was not randomly selected from all active Google Cloud workloads, so it cannot be used to calculate a general compromise rate for the platform.
What “compromised instance” means
In this context, a compromised instance was a customer-controlled cloud workload that an unauthorized actor had managed to access. Once inside, the attacker could run software, consume resources, change settings, create more infrastructure, or use the system as a starting point for other activity.
That distinction is important. A customer workload may be compromised because of exposed credentials, weak access controls, vulnerable software, or unsafe configuration without the cloud provider’s underlying infrastructure being breached.
Why the statistic should not be generalized to all GCP workloads
The correct interpretation is:
Cryptocurrency mining appeared on 86% of 50 already-compromised GCP instances examined for Google’s November 2021 report.
The incorrect interpretation is that 86% of all Google Cloud instances were compromised or mining cryptocurrency. The cited dataset does not support that conclusion.
What Attackers Did With the Compromised Instances
Cryptocurrency mining
Unauthorized mining lets an attacker collect computational output while shifting the infrastructure cost to the victim. A miner can consume substantial CPU or GPU capacity, disrupt legitimate workloads, trigger scaling, and create unexpected cloud charges.
Google later described cryptomining as a common way attackers abuse computing resources after gaining access and warned that related costs can build quickly.
Scanning and attacks against other systems
The 2021 report also found that compromised instances were used to scan publicly reachable systems for more vulnerable targets. Some were used to launch attacks against other systems.
This creates risk beyond the affected project. A hijacked workload may generate suspicious outbound traffic, damage an organization’s reputation, violate service policies, or attract abuse complaints before the owner realizes that the system has been compromised.
Malware hosting and other forms of abuse
Google observed other activity, including malware hosting, unauthorized content, distributed denial-of-service activity, and spam. Some instances were used for more than one malicious purpose.
A visible mining process may therefore be only the easiest part of an intrusion to detect. Its presence does not mean the attacker limited their activity to mining.
How the Google Cloud Instances Were Compromised
Weak passwords and exposed APIs
Google attributed 48% of the analyzed initial-access cases to weak or missing passwords for user accounts or missing authentication for APIs. Internet-facing services with poor authentication could be found through scanning and then accessed or brute-forced.
The report also showed how quickly attackers could act after discovering an exposed system. In some cases, mining software was downloaded within 22 seconds of compromise. Once a vulnerable service is publicly reachable, administrators may have almost no time to react.
Vulnerable third-party software
Another 26% of the examined compromises involved vulnerabilities in third-party software installed by the workload owner. An unpatched application exposed to the internet can provide an entry point even when the underlying virtual machine and Google account have stronger controls.
Administrators need to assess the full software stack, including web applications, management panels, container images, plugins, libraries, and remotely accessible services.
Misconfiguration and leaked credentials
Google’s analysis identified configuration problems and leaked credentials among the other access paths. Credentials at risk may include service-account keys, API keys, OAuth secrets, command-line credentials, application default credentials, SSH access, tokens, and browser sessions.
A miner deployed with a valid stolen credential may initially resemble authorized administrative activity. Logging, identity monitoring, and resource-change alerts are needed to separate legitimate changes from misuse.
Why Cloud Cryptomining Appeals to Attackers
The victim pays the compute cost
Mining requires processing power and electricity. By hijacking cloud infrastructure, an attacker transfers those operating costs to the project owner while keeping the potential mining proceeds.
CPU, GPU, storage, and scalable cloud resources
Cloud environments can provide processors, GPUs, storage, containers, and automated scaling. Those capabilities are useful for legitimate workloads, but they can also increase the financial impact when an attacker gains permission to create or resize resources.
The damage may extend beyond one overloaded virtual machine. Unauthorized instance creation, GPU provisioning, container deployment, or autoscaling changes can raise consumption across an entire project.
Why mining can be an early sign of a larger breach
Mining is noisier than many other forms of intrusion because it often creates visible resource consumption. That can make it the first symptom administrators notice, even if the attacker has already changed IAM permissions, installed persistence, accessed data, or deployed other tools.
Cryptomining should therefore be investigated as an account or workload compromise, not treated only as a performance issue.
Warning Signs of Cryptomining in Google Cloud
Unexpected resource utilization
Sustained CPU or GPU use that does not match a known workload deserves investigation. Unexpected storage activity, slower application performance, or unfamiliar processes consuming large amounts of compute may also be relevant.
High utilization alone does not prove that mining is taking place. Legitimate builds, analytics jobs, machine-learning workloads, and traffic spikes can create similar patterns.
New instances, containers, or scaling activity
Review unexpected virtual machines, GPU-enabled resources, GKE workloads, container images, snapshots, instance templates, startup scripts, scheduled tasks, and autoscaling changes. Compare each resource with approved deployments and recent change records.
Unexplained billing or quota changes
Cryptomining can increase a cloud bill through unauthorized compute, GPU, storage, or network use. Investigate spending anomalies, quota consumption, new projects, activity in unexpected regions, and resources created outside normal deployment processes.
Suspicious processes and mining-pool communications
Security Command Center can produce VM or container threat findings related to cryptocurrency mining when the applicable detection services are available and enabled. Current Google documentation describes detections based on known memory hashes, YARA patterns, process information, and suspicious Stratum-protocol communications.
Useful investigation details may include the process name, binary path, command-line arguments, affected resource, associated logs, memory signature, container namespace, image, pod, and related findings. These indicators require analysis and should not be treated as universal proof that every flagged process is malicious.
What to Do if a Google Cloud Instance Is Mining Crypto
Contain the affected workload
Stop the confirmed mining activity and isolate or shut down the affected workload when doing so will not create a greater operational or safety risk. Preserve the logs and forensic information needed to understand the intrusion before destroying evidence.
Review logs and identify initial access
Use Cloud Logging, audit logs, Security Command Center findings, application logs, operating-system records, and network telemetry to build a timeline.
Look for unusual logins, API calls, software exploitation, instance creation, startup-script changes, container activity, and access from unfamiliar identities or locations.
Revoke credentials and inspect IAM changes
Review IAM users, groups, service accounts, roles, service-account keys, API keys, OAuth credentials, SSH access, tokens, and recently changed permissions. Revoke or rotate exposed credentials and remove unauthorized principals or access grants.
Google’s current compromised-credential guidance recommends revoking and reissuing affected credentials, then searching Logging and Security Command Center for unauthorized access and resources.
Remove persistence and rebuild when necessary
Inspect scheduled tasks, startup scripts, system services, cron jobs, container definitions, images, SSH keys, modified packages, new accounts, and altered administrative tools. Terminating one mining process is not enough if the attacker can restart it or regain access.
Replace a compromised instance from a trusted image when its integrity cannot be established confidently. Restore only verified data and configuration, then apply the security fixes needed to close the original access path.
Review billing and additional attacker activity
Examine billing, quotas, resource creation, outbound connections, data access, snapshots, storage activity, and related projects. Determine whether the attacker attempted lateral movement, credential theft, malware delivery, scanning, spam, or other abuse.
Google’s abuse-response documentation similarly advises project owners to review project activity, stop unauthorized mining, secure affected accounts and projects, and inspect usage and logs for signs of compromise.
How to Reduce the Risk
Enforce multifactor authentication
Require multifactor authentication for human administrators and protect privileged accounts against phishing and credential reuse. Passwords should not be the only defense protecting remotely accessible administrative functions.
Apply least privilege
Give each user and service account only the permissions required for its function. Restrict who can create instances, provision GPUs, change IAM policies, generate service-account keys, modify billing, or deploy workloads.
Patch internet-facing software
Maintain an inventory of exposed services and address vulnerabilities in operating systems, applications, plugins, container images, and management software. Remove services that do not need to be reachable from the public internet.
Protect service-account credentials and API keys
Do not place secrets in public repositories, downloadable files, container images, or unprotected configuration files. Prefer short-lived credentials and managed identity mechanisms where suitable. Restrict API keys by service, application, or network context when supported.
Enable logging, threat detection, billing alerts, and quota controls
Retain the logs needed to investigate identity, resource, and network activity. Review the Security Command Center capabilities available to your organization, configure budget notifications and cost monitoring, and use quotas or organizational controls to limit unauthorized resource expansion.
Feature availability, service tiers, finding names, and console navigation can change. Administrators should consult current Google Cloud documentation when configuring these controls.
Does This Mean Google Cloud Is Unsafe?
The 2021 findings do not show that Google Cloud’s underlying platform was broadly compromised or that the service is inherently unsafe. They show that customer-controlled workloads can be abused when attackers exploit weak authentication, vulnerable applications, leaked credentials, or unsafe configuration.
Cloud security follows a shared-responsibility model. Google secures the underlying cloud infrastructure, while customers remain responsible for areas such as identities, permissions, workload configuration, deployed software, credential handling, and monitoring.
The more useful conclusion is that cloud resources are attractive targets and exposed weaknesses may be exploited rapidly. Strong identity controls, patching, restricted access, logging, cost monitoring, and a rehearsed incident-response process remain necessary.
Frequently Asked Questions
Did hackers breach Google Cloud itself?
No platform-wide Google Cloud breach was described by the 86% finding. It concerned 50 customer-controlled GCP instances that had already been compromised through routes such as weak authentication, vulnerable software, misconfiguration, or exposed credentials.
What does Google’s 86% cryptomining statistic actually mean?
Cryptocurrency mining was observed on 86% of a sample of 50 recently compromised GCP instances examined for Google’s November 2021 Threat Horizons report. It does not mean that 86% of all Google Cloud instances were affected.
Why do attackers use cloud instances to mine cryptocurrency?
Unauthorized cloud mining lets attackers consume computing resources while the victim pays the infrastructure cost. Cloud CPUs, GPUs, storage, and scaling capabilities can make a compromised account financially useful to an attacker.
How are Google Cloud instances commonly compromised?
In the 2021 sample, the leading identified access paths included weak or absent authentication and exploited vulnerabilities in third-party software. Misconfiguration and leaked credentials were also identified.
What are the warning signs of cloud cryptojacking?
Possible indicators include unexplained CPU or GPU use, unfamiliar processes, new instances or containers, unexpected scaling, suspicious outbound connections, quota consumption, and abnormal billing. Each indicator requires investigation because legitimate activity may produce similar symptoms.
Can cryptomining malware increase a Google Cloud bill?
Yes. Unauthorized mining can consume paid compute, GPU, storage, and network resources. It may also create more instances or trigger scaling when the attacker has sufficient permissions.
What should an administrator do after detecting a miner?
Contain the affected workload, preserve relevant evidence, review logs, identify the initial-access route, revoke exposed credentials, inspect IAM changes, remove persistence, patch the exploited weakness, and investigate billing and other attacker activity.
Is deleting the mining process enough to secure the instance?
No. The process may restart through a persistence mechanism, and the attacker may still have valid credentials or elevated permissions. Treat the system as compromised until the access path, persistence, unauthorized changes, and wider impact have been investigated.
Final Takeaway
The widely quoted 86% figure came from a clearly defined historical dataset: 50 compromised Google Cloud instances examined in 2021. It showed that cryptocurrency mining was the most common observed use of those already-compromised workloads. It did not show that most Google Cloud systems had been breached.
The practical lesson still applies. Unexpected resource consumption or billing may reveal unauthorized mining, but the miner could be only one part of the intrusion. Administrators should contain the workload, determine how access was obtained, revoke compromised credentials, inspect IAM and persistence, patch exposed services, and rebuild systems whose integrity cannot be trusted.
Cloud cryptomining creates a financial problem, but it is also evidence of a security failure. Someone gained access to resources they did not control, and the investigation needs to account for every action that access made possible.
