Public GCP keys on GitHub enabled large-scale Chia mining

At a glance

What this is: This investigation shows how a public GitHub repository containing more than 5,000 live GCP service account keys supported a Chia mining setup built around cloud storage abuse and automated plotting.

Why it matters: It matters because leaked NHI credentials can be turned into an immediate abuse path for cloud resources, and IAM teams need to govern exposure, scope, and revocation together rather than as separate problems.

👉 Read Truffle Security's analysis of leaked GCP keys and Chia mining abuse

Context

Cloud credential leakage is not only an exposure problem, it is often an access problem that survives long enough to be monetised. In this case, the credentials were service account keys, which are non-human identities bound to cloud access scope and storage permissions rather than human login behaviour. The article points to a public GitHub repository as the exposure point and to Chia mining as the abuse pattern, with API key management as the closest governance analogue for how exposed secrets should be treated.

The operational pattern matters because the repository did not just contain secrets, it contained scripts that turned those secrets into repeatable workload access. That shifts the risk from one-off leakage to reusable machine identity abuse, which is exactly where conventional perimeter thinking fails.

The starting position here is typical of many cloud abuse cases: exposed keys, broad access, and automation designed to monetise whatever the credential can reach.

Key questions

Q: What should teams do first when a cloud service account key is found in a public repository?

A: Revoke the exposed key immediately, confirm which workload and storage paths used it, and then replace any dependent automation with a fresh credential under clear ownership. The first priority is to stop reuse, because the exposure itself can become an active access path before broader cleanup is finished.

Q: Why do leaked cloud keys create such a large abuse risk?

A: Because the secret is usually bound to a real cloud principal with permissions that extend beyond a single app. If the key can authenticate to storage, compute, or deployment services, an attacker can turn one leaked credential into repeated access and monetised workload abuse.

Q: How can security teams tell whether exposed NHI credentials are still operationally dangerous?

A: Look at what the credential can still reach, whether any automation still depends on it, and how long it remained valid after exposure. A key that is already revoked may still reveal a governance failure if it was live long enough to support data movement or cloud abuse.

Q: What is the difference between secret leakage and service account misuse?

A: Secret leakage is the exposure event, while service account misuse is the operational abuse that follows when the leaked credential is still valid. In practice, the first is a discovery problem and the second is an identity governance problem, because the real risk comes from what the credential can do.

Technical breakdown

Why exposed service account keys become reusable cloud access

A GCP service account key is a long-lived credential that can authenticate a non-human identity directly to Google Cloud services. Once the private key is copied into a public repository, anyone who finds it can impersonate that service account until the key is revoked or invalidated. In this case, the keys were used only for Google Drive access, which shows that the attacker did not need a complex exploit chain. The problem is not just disclosure, but durable impersonation of a cloud principal that can still act exactly as issued. See the Google Cloud IAM and Service Accounts Guide.

Practical implication: Treat service account keys as revocable access credentials, not passive configuration files.

How crypto-mining turns cloud identities into infrastructure abuse

The repo’s setup scripts did more than authenticate. They installed plotting tools, prepared storage, and automated uploads in a loop, which is a classic abuse pattern when attackers or opportunistic operators want to convert cloud resources into mining capacity. Chia is storage-heavy, so the value of the credential was not just API access, but access to storage, compute, and orchestration at a cost that could be externalised to the cloud tenant. That makes the identity itself part of the mining supply chain.

Practical implication: Classify cloud identity abuse as workload theft when credentials are used to instantiate compute and storage workflows.

Why public secret exposure creates a governance gap even after revocation

The article notes that the keys were no longer live when scanned, but that does not remove the governance issue. Secret revocation after exposure narrows the window of abuse, yet it does not undo the time during which the credential was valid or the infrastructure changes created from it. The deeper control gap is that secret discovery, offboarding, and activity review are often not joined up. Once a service account is exposed publicly, the identity lifecycle has already failed at multiple points. Read Guide to the Secret Sprawl Challenge.

Practical implication: Connect secret scanning to credential revocation and post-exposure access review as one workflow, not three separate tickets.

Threat narrative

Attacker objective: The objective was to use exposed cloud identities to run a high-capacity Chia mining operation while distributing storage use across multiple credentials.

1. Entry occurred through a public GitHub repository that exposed previously live GCP service account private keys.
2. Credential abuse followed when the leaked keys were used to authenticate to Google Cloud storage and related services.
3. Escalation took the form of automated resource use, with scripts building Chia plots at scale and uploading them in rotation across credentials.
4. Impact was cloud-resource abuse for cryptocurrency mining, with legitimate cloud access converted into sustained monetisation activity.

Breaches seen in the wild

• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Publicly exposed service account keys create an identity reuse economy: once a GCP key lands in a public repository, the credential can be copied, replayed, and operationalised before any governance process catches up. That is not just leakage, it is durable machine identity reuse. The relevant control question is whether the organisation can detect exposure fast enough to make the key non-usable before abuse begins. Practitioners should treat public secret exposure as an identity lifecycle failure, not a storage mistake.

Chia mining in cloud environments exposes the real cost of over-broad non-human access: the value of the leaked credential is determined by what the service account can touch, not by where the secret was stored. When cloud identities can reach storage, deployment surfaces, and automation paths, mining operators can convert access into infrastructure at scale. That is why least privilege for NHIs is not abstract policy language, it is an economic control on abuse potential.

Secret scanning without lifecycle enforcement leaves a governance gap open: this article shows the difference between finding a leaked credential and governing the identity behind it. A scan can tell you a key is exposed, but it cannot by itself tell you whether the service account still has effective rights, whether related automation still exists, or whether the compromise window has already been exploited. The implication is that secret discovery has to be tied to ownership, revocation, and offboarding, not treated as a standalone hygiene check.

Cloud abuse cases should be read through the lens of identity blast radius: the repo’s scripts reveal how a single exposed key can unlock plotting, storage access, and repeated uploads in one operational chain. That is the blast radius practitioners need to model when they approve service account scope, especially for keys that can reach high-value storage or billing-sensitive workloads. The practical conclusion is to govern every exposed key as a potential infrastructure control plane, not a single compromised secret.

Named concept, identity reuse economy: exposed machine credentials become reusable operational assets whenever revocation is delayed or ownership is unclear. The article illustrates how a leaked service account can persist as a monetisable control point even after discovery, which is why organisations need to measure exposure, not just count secrets. For practitioners, the priority is to collapse the time between discovery and identity invalidation.

What this signals

Identity blast radius is the right lens for exposed cloud keys: the issue is not the repository alone, it is the set of cloud capabilities the leaked service account can still activate. When a single credential can touch storage, compute, and automation, the organisation has already given the attacker a reusable control point. Practitioners should model leaked keys by reachable privilege, not by file count.

A public secret is a governance event, not just a detection event. Once a cloud credential is exposed, the real question becomes how quickly ownership, revocation, and workflow removal converge, because any lag extends the window for abuse. That is the operational signal teams should monitor in their own programme.

Cloud mining abuse shows that the boundary between credential management and workload governance is thinner than many programmes assume. A leaked key can become an on-ramp to storage-heavy, cost-bearing activity even when the original exposure looks trivial. Identity teams need to treat that as a programme design issue, not an edge case.

For practitioners

• Inventory exposed service account keys continuously Scan repositories, issue trackers, and shared storage for cloud service account keys, then map each secret back to a named owner and workload.
• Revoke and rotate keys as a single response When a key is exposed publicly, revoke the credential first and rotate any dependent automation immediately so the identity cannot be reused.
• Limit service account reach to the minimum storage path Scope machine identities so they cannot create or move data across large storage areas unless that access is explicitly required for the workload. See the Google Cloud Security Guide.
• Review automation tied to leaked identities Check whether scripts, cron jobs, or deployment routines still reference the exposed identity and remove any workflow that can continue mining or exfiltration.

Key takeaways

• A public GitHub repository with live GCP keys can function as an identity control plane for cloud abuse when service account scope is too broad.
• The evidence in this case points to automated Chia mining built on exposed non-human credentials, not a one-off accidental leak.
• The control that changes the outcome is fast revocation joined to ownership, scope review, and automation cleanup after exposure.

Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · API Key Management Guide · Google Cloud IAM and Service Accounts Guide · Top 10 Cloud Security Risks

Key terms

• Service-account key: A service-account key is a non-human credential used by a workload, integration, or automation process to authenticate without a person present. When keys are stale, duplicated, or stored outside a managed vault, they become difficult to govern and easy to overlook during lifecycle reviews.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Cloud Abuse: Cloud abuse is the misuse of legitimate cloud credentials or resources for unauthorized activity such as mining, data exfiltration, or covert automation. Unlike a direct exploit, it often relies on valid access and blends into normal operations. That makes detection harder and containment more urgent.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Truffle Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The raw repository structure and file layout that revealed the scale of key exposure
• The exact setup and upload scripts used to automate plotting and Google Drive transfer
• The TruffleHog validation process that showed the keys were no longer live
• The reasoning used to connect the key inventory to likely mining behaviour

👉 The full Truffle Security post covers the repository evidence, script behaviour, and key validation details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.