Most write-ups about compromised cloud credentials are security write-ups. This one is about the cost signal, because in practice the bill is frequently the first place anyone notices.
That is not because cost monitoring is better than security monitoring. It is because an attacker using your credentials to run inference or mine cryptocurrency is not doing anything a security tool considers anomalous — they are making valid API calls with valid credentials. What is anomalous is the volume, and volume is a cost signal.
What it looks like in the data
A compromised credential has a distinctive shape, and it differs from every ordinary cause of a cost increase.
It starts abruptly. Not a ramp, not a step to a new plateau — a near-vertical rise from baseline, usually within a single hour.
It does not follow your traffic pattern. Legitimate spend has a daily rhythm: quiet overnight, busy during working hours. Credential abuse runs flat, because it is not driven by your users. A cost curve that stays high at 3am when it has never done so before is the single most reliable tell.
It concentrates in an unusual service or region. Inference endpoints, GPU instances and compute in regions you do not deploy to. The attacker picks what monetises, not what you normally run.
It is sustained. A misconfigured job usually errors out or completes. Abuse continues until stopped.
Any one of these could be innocent. All four together is not.
Why the absolute number misleads you early
The reason these incidents run for days is that the first hours look unremarkable.
Consider a burn of $5,000 an hour. That is catastrophic, and at the four-hour mark it is $20,000. But if your normal monthly spend is $150,000, then four hours in you are looking at a daily figure that is high but not obviously alarming — the sort of number a busy team explains away as a backfill.
The signal is not the total. It is the deviation from that service's own baseline, and the rate of change. A service that normally costs $40 a day sitting at $5,000 an hour is a five-alarm event at hour one, and no dashboard showing monthly totals will present it that way.
This is the whole argument for statistical baselines over fixed thresholds. A fixed threshold set against your monthly budget will not fire until the damage is done. A baseline per service fires in the first hour.
The first ten minutes
If the pattern matches, treat it as a security incident and revoke first. The cost investigation can wait; the burn cannot.
Revoke the credential. Disable the key, role or service account outright rather than trying to scope it down. You can restore access later.
Check for persistence. Attackers commonly create additional credentials once inside. Review recently created keys, users, roles and service accounts across the affected project or account, not just the one you know about.
Look for the entry point. A leaked key in a public repository, an over-permissioned CI credential, an exposed metadata endpoint. If you do not find it, assume it is still open.
Then quantify. Now the cost work matters: what ran, in which regions, for how long, and what it will cost.
Quantifying it for the write-up
Someone will ask what it cost, and the honest answer has two numbers.
Incurred — what was actually billed before you stopped it. This is the loss.
Avoided — burn rate multiplied by how much longer it would plausibly have run undetected. If your previous detection mechanism was the monthly invoice, that multiplier is the days remaining in the billing cycle, and it is usually an order of magnitude larger than the incurred figure.
Both belong in the incident report. The first is what happened; the second is the argument for the detection you are about to ask for.
Most cloud providers will consider a credit for verified credential abuse, particularly where you can demonstrate rapid detection and revocation. Documented timelines materially improve that conversation.
Preventing the next one
The security fixes are standard: short-lived credentials, least privilege, secret scanning in CI, no long-lived keys in environment variables, and alerting on credential creation.
The cost-side fix is a different control, and it catches what the security fixes miss. Statistical baselines per provider and service, evaluated daily, mean that "this service is running at a hundred times its normal rate" reaches a human within hours. That is the control that turns a month-long incident into a two-hour one.
We have run exactly this. A compromised service role was firing thousands of requests at Gemini endpoints; nothing in the cloud console raised it, and the burn had reached $5,000 an hour by the time a baseline flagged the deviation. The role was revoked two hours later. The difference between two hours and thirty days is the entire cost of the incident.
FAQ
How quickly can a compromised cloud credential run up a bill?
Fast enough that hours matter. Cryptomining and inference abuse can reach thousands of dollars per hour on a single credential, and because the activity is technically valid API usage, nothing blocks it until someone notices the volume.
Will my cloud provider refund fraudulent usage?
Often, at least partially, for verified credential compromise. Providers weigh how quickly you detected and revoked, so a documented timeline improves the outcome. Treat a credit as likely but not guaranteed.
What is the difference between a cost anomaly and a security incident?
A cost anomaly caused by your own team follows your traffic pattern and usually correlates with a change you can find. Credential abuse runs flat regardless of traffic, concentrates in services you do not normally use, and does not correlate with any deploy. The second is a security incident that happens to be visible in billing.
Why didn't security tooling catch it first?
Because the attacker is making valid calls with valid credentials. Nothing is technically unauthorised. The anomaly is in volume and pattern, which is what cost monitoring measures and access monitoring generally does not.
