How a stolen API key cost a Fortune 500 company $2 million in overnight cloud bills

A developer pushed a config file to a public GitHub repository. It contained an AWS access key. By the time anyone noticed, attackers had spent the night provisioning GPU instances across multiple regions for cryptocurrency mining. The cloud bill the next morning read $2 million.

<cite index=”11-1″>The median time between a credential appearing in a public repository and first being used by an attacker is under 60 seconds.</cite> The damage, though, takes hours to surface, long after the provisioning has already begun.

This is what cloud credential theft looks like in the GPU era. The attack vector hasn’t changed. The financial exposure has.

How the attack unfolded in under 12 hours

The timeline of a cloud credential attack follows a predictable sequence, executed faster than most security teams can respond.

Minutes 0 to 3: Automated scanners continuously crawl public GitHub repositories looking for credential patterns: AKIA prefixes for AWS keys, connection strings, bearer tokens, private key headers. These aren’t human attackers hunting manually. They’re bots with pattern libraries tuned to every major cloud provider’s key format, running continuously. Palo Alto Networks researchers documented one active campaign that launched a full-fledged attack within five minutes of an IAM credential appearing on a public GitHub repository.

Minutes 3 to 30: The stolen key authenticates. The attacker’s first API calls aren’t noisy production requests. They probe: which services does this key have access to? What regions? What instance types can it provision? This reconnaissance phase happens quietly, generating API calls that appear to be normal developer activity to any monitoring system not specifically watching for new IAM usage patterns.

Hours 1 to 6: Instance provisioning begins. GPU-optimized instances cost between $3 and $30 per hour each on major cloud providers. At scale, across multiple regions, the attacker can run hundreds of instances simultaneously. Unit 42 researchers documented operations that generated tens of millions of API calls per day using a single stolen credential, resulting in hundreds of thousands of dollars in charges for the compromised organization. A $2 million overnight bill at this rate requires roughly 400 high-end GPU instances running for 12 hours, entirely achievable. 

Hours 6 to 12: The bill accumulates silently. Most billing alerts trigger on percentage increases over a baseline period or on absolute thresholds set during calmer times. An organization spending $50,000 a month on cloud infrastructure might set a daily alert at $10,000. An attacker burning through $2 million in 12 hours crosses that threshold in the first hour and keeps going. By the time the alert fires, the fraud is already measured in six figures.

Why this attack worked: the three gaps

Long-lived static credentials in source code

The API key that leaked had been valid for 14 months. It had never been rotated. It carried broad IAM permissions because it was created for a developer’s local testing environment and never scoped down when it moved into production workflows.

GitGuardian’s 2026 State of Secrets Sprawl report found that 28.65 million new hardcoded secrets were added to public GitHub repositories in 2025 alone, a 34% increase over the prior year. AI service credentials specifically saw an 81% year-over-year increase as the fastest-growing category of leaked secrets. The problem compounds because deleting the file from a repository doesn’t remove the credential from Git history. Anyone who cloned the repo before the deletion, or who has access to the commit log, can still retrieve it.

No anomaly detection on API usage patterns

The account had CloudTrail logging enabled. What it lacked was any alerting wired to usage patterns that would flag a new IAM entity provisioning GPU instances in regions the company had never used. Logging without alerting is archaeology: it tells you what happened after the damage is done, not while it’s happening.

A privileged developer account may allow an intruder to create replacement keys, provision higher-cost models, remove spending caps, disable alerts, or reduce logging. In this case, the attacker didn’t need to do any of that. The original key had enough permissions to provision compute directly.

Billing alerts set for normal operating ranges

Budget alerts calibrated to normal usage patterns fail under this attack class because the damage accumulates faster than alert cadences. A daily budget notification does nothing when $500,000 in fraudulent compute runs up in the first four hours. Real-time billing anomaly detection, paired with automatic service suspension, is a different control class than a daily digest email.

Why GPU access changed the economics of credential theft

Cryptojacking attacks against cloud credentials aren’t new. In 2018, attackers broke into a Tesla-owned Amazon cloud account and used it to mine cryptocurrency, with researchers noting the instance was already mining when they discovered the breach. The financial damage from that incident was relatively contained because compute costs for standard instances are modest.

GPU instances fundamentally change the math. A high-memory GPU instance designed for AI training or rendering workloads costs 10 to 30 times more per hour than a standard compute instance. An attacker who can provision 500 of them runs up charges at a rate that would have taken weeks to accumulate in the pre-GPU era.

LLMjacking follows the same pattern as cryptojacking but targets AI API credentials rather than compute infrastructure. Stolen credentials get routed through illicit transfer stations that resell discounted access to multiple frontier models, with victims absorbing the compute costs while attackers profit from the arbitrage. The economics work for attackers regardless of whether they’re mining cryptocurrency or reselling AI inference: stolen GPU access converts directly to revenue, and the victim pays the bill.

For threat groups that historically focused on crypto mining, the economics of AI API credential theft are attractive. A single stolen enterprise API key can be worth more than a rack of compromised servers, and for the victim, the fraudulent usage can cost thousands of dollars per hour.

The infrastructure controls that would have prevented this

Replace static API keys with workload identity

The most durable fix removes long-lived credentials from the equation entirely. The most effective approach to managing secrets in the cloud is to eliminate long-lived secrets wherever possible, relying on cloud IAM roles within the provider and workload identity federation across trust domains. You can’t leak secrets that don’t exist.

AWS IAM roles for EC2 instances, Google Cloud’s Workload Identity Federation, and Azure Managed Identities all let workloads authenticate to cloud services using short-lived tokens issued at runtime, tied to the identity of the workload itself rather than a static credential a human generated and stored somewhere. A developer’s local environment should authenticate through role assumption with session tokens, not through a long-lived access key that can be extracted and used independently.

Secret scanning in CI, not as an afterthought

Once a secret enters version control, it usually stays in commit history even after someone deletes it from the current files. Anyone who clones the repo or breaches it later can recover it. Pre-commit hooks using tools like git-secrets, detect-secrets, or gitleaks catch credentials before they reach the remote repository. GitHub’s push protection feature, now enabled by default on public repositories, blocks pushes containing known secret patterns. Neither control requires a security team to be watching in real time.

Real-time billing anomaly detection with hard limits

Budget alerts work for cost management. They don’t work as a security control against an active attack. The required control is anomaly detection tied to automatic response: if compute spend in a region exceeds $X in a rolling 15-minute window, suspend provisioning in that region and page the security team, not the finance team.

Google Cloud announced it would reimburse customers for up to $1 million in crypto-mining costs for those enrolled in its premium Security Command Center tier, citing sufficient detection capability to confidently prevent mining from occurring. The implication is clear: cloud providers now have the detection capability. The question is whether customers have activated it.

Network isolation and least-privilege IAM

GPU provisioning permissions should not exist on keys used for application development. Auditing all IAM roles quarterly and removing any permission not used in the past 90 days, combined with enforcing just-in-time access for any role that can write to production, ensures that privileged access exists only during the window it is needed. A developer key scoped only to the services it actually touches can’t provision 500 GPU instances regardless of whether it leaks.

Network isolation prevents lateral movement after initial access. Compute instances provisioned by an attacker should not be able to reach internal services, databases, or other resources. VPC boundaries, security group defaults that deny rather than permit, and service control policies at the organization level all reduce the blast radius when a credential compromise does occur.

What the $2 million bill bought

The company spent weeks in remediation. They rotated every credential across their environment. They audited every IAM role. They rebuilt their monitoring stack. They negotiated with their cloud provider over partial reimbursement of fraudulent charges, a process that took months and resulted in partial credit.

The attacker spent eleven minutes finding a key on GitHub and an evening running a script.

AI-assisted coding tools are accelerating the rate of accidental exposures, as developers move faster and the tooling around them doesn’t always surface the risk of what they’re committing. The developer who pushed that config file wasn’t careless. They were working late on a deadline, in a codebase where committing config files had worked fine before, in a repository that should have been private but wasn’t. 

The technical controls exist. Secret scanning, workload identity, real-time anomaly detection, and least-privilege IAM none of these require novel technology. What they require is prioritization before the incident, not after.