How does a leaked key turn into such a big bill so fast?

Scanners pick up a public key in about four minutes, and mining infrastructure can be running within ten. Attackers launch expensive instances across many regions at once, often auto-scaling into the hundreds, and disable termination so you cannot easily kill them. Because AWS billing data lags real usage by hours, the compute is already burning long before the charge appears or any alert fires.

Will AWS refund a bill from a hacked account?

Often, yes. In one well-known case a developer who leaked a key for ten minutes was billed over fourteen thousand dollars and received a full refund within days, classified as unauthorized usage. But it is a discretionary review, not a guarantee. Your odds are best when you secured the account quickly and can show the timeline. Treat a refund as likely, never as the plan.

What do all these stories have in common?

A standing credential with broad power that lived long enough to be found. The specific leak varies, a public repo, a stolen laptop, a departed contractor, but the root cause is always the same: a permanent key that could do a lot of damage, sitting somewhere it could eventually be exposed. Remove the standing key and most of these stories never start.

← All posts

July 28, 2026 · Nick Krykunov

A ten-minute mistake and a $14,000 bill: how AWS account hacks actually happen

When people picture an AWS account getting hacked, they picture someone breaking into Amazon, and that is almost never what actually happens. What happens is quieter and a lot more ordinary, because one of your own keys ends up somewhere it shouldn’t, a bot finds it within minutes, and by the time you notice, a stranger has been running compute on your card in regions you have never once opened. Here is how it really plays out, told through cases that really happened to people, and the one thing every single one of them turns out to share.

The ten-minute window

Back in 2018 a freelance developer named Juan Manuel Ramallo put a side project on GitHub for about ten minutes to show a friend, then moved it to a private repo, with his AWS credentials sitting in a config file he had forgotten to gitignore. Ten minutes of exposure, and that was plenty.

Two days later he got a cheerful email from AWS welcoming him to EC2, a service he had never switched on, and his bill for the month had jumped from about a dollar to $14,267.86. Somebody had grabbed the key inside that ten-minute window, and it made no difference at all that the repo was long gone, because the key had already been copied.

Ten minutes isn’t freak bad luck either, it’s roughly the window you actually get, because when a live AWS key lands in a public repo the scanners detect and test it in about four minutes on average. There are bots whose whole job is to watch every public commit on GitHub for anything shaped like a credential, so you’re not racing a person here, you’re racing something that never sleeps.

What they actually do with your key

The sequence is almost boring once you’ve watched it a few times, and that is exactly why it works so reliably. They find the key, they run one quiet call to confirm it’s live and see what it can reach, and then, if the permissions are broad enough, the spending starts.

In a campaign AWS caught starting on November 2, attackers holding valid admin-like credentials had crypto miners running within ten minutes of getting in, and they probed their permissions carefully first, calling the RunInstances API with a dry-run flag so nothing hit the bill yet before they committed. From there they stood up dozens of ECS clusters, sometimes more than fifty in a single account, and set auto-scaling groups to climb from 20 instances toward 999.

Then they made it hard to undo, because in that same campaign the attackers turned off API termination on the instances so the victim couldn’t simply delete them, and they left IAM roles and Lambda functions behind to keep a way back in even after the original key was rotated. That is why people clean up, feel relieved, and then watch the bill keep climbing, because they killed the one instance in the region they use and never saw the four hundred others spread across the rest of the planet.

Why it gets so expensive before you notice

Two things stack on top of each other. The compute is expensive on purpose, GPU and large instances chosen for mining throughput and copied across every region so that no single console view ever shows you the whole picture, and on top of that AWS billing data trails real usage by hours. So the machines are quietly burning thousands of dollars an hour while your dashboard still shows you yesterday, and by the time a billing alert finally fires, the damage is already a day old. The alert was never going to be a brake, only a receipt.

That is how you get to $14k, or to the $170,000 invoice a Google Cloud user woke up to after a hack, or the $30,000 to $50,000 Azure bills people keep posting about across every cloud. Same story, a different logo on the front.

The part that stings

Look again at what did not happen in any of these, because nobody broke into Amazon, no firewall got bypassed, and there was no clever zero-day anywhere in the story. The system did precisely what it was built to do, which is take a valid credential and honor it, so Ramallo’s key was allowed to launch EC2 and it dutifully launched EC2. The account had no way to tell him apart from whoever grabbed his key, because an account never knows who is holding a credential, it only knows what that credential is allowed to do. That is why fixing this is really an access problem, not a taller-fence problem, and it stays true whether the hands on the key belong to a stranger, a contractor, or a tired engineer.

The good news, and the catch

If this already happened to you, the ending is usually kinder than it feels at 2am. Ramallo got a full refund within days once AWS classified the charges as unauthorized, and AWS does waive fraudulent charges fairly often when you locked the account down quickly and can show your work. It is a discretionary review rather than a promise, but the base rate really is on your side.

The actual steps, securing the account, hunting down what they spun up in every region, and getting the charges reviewed, are their own checklist, and I wrote it out in order over here: your AWS account got hacked and the bill is huge, do this now. If you’re in the middle of this right now, start there and come back.

The one thing every story shares

Strip away the specifics, the public repo, the forgotten config file, the contractor who kept a key after the job ended, and you land on the same root cause every single time, which is a standing credential with broad power that lived long enough to be found. The cause is almost never a genius attacker, it’s a permanent key that could do real damage, parked somewhere it could eventually leak, and that is the one thing you can actually go remove.

So the move is to stop handing out standing keys in the first place, because if access is requested for a task and expires on its own instead of living in the account forever, there is nothing left sitting around for a bot to find six months later. If nothing holds a long-lived credential in your code, your config, or someone’s laptop, then there is nothing left to leak, and that is what zero standing privileges means once you get past the phrase, and it quietly turns Ramallo’s ten-minute window into a non-event, because the key that leaked would already be dead by the time anyone found it.

And for the moment a credential does get abused anyway, something has to be watching the live session and cut it off the instant it tries to launch a hundred instances across six regions, in seconds rather than hours, because that is the kind of judgment a billing alert can never make. That real-time call is the part Korvalis is built for, since it installs inside your own cloud account, watches what live sessions are actually doing, and stops a session on its own when it turns anomalous, whether the credential belongs to a leaked key, a contractor, an engineer, or an agent, because your account can’t tell them apart and neither can your bill.

The takeaway

Every one of these reads like bad luck and turns out to be the same design flaw, because a powerful key existed forever, and forever is long enough for anything to leak. You will never fully stop a key from occasionally ending up in the wrong place, so the thing you actually get to decide, well ahead of time, is whether the key that leaks is a standing admin credential with your whole account behind it, or a scoped one that expired twenty minutes after the work was done and is worth nothing to the bot that finds it. That is the boring foundation work almost nobody does until the bill shows up.

Frequently asked questions

How do AWS accounts actually get hacked? Almost always through one leaked credential, not a break-in at AWS. A key ends up in a public repo, a config file, or an ex-contractor’s hands, and automated scanners find and use it within minutes to spin up expensive compute.

How does it get so expensive so fast? A leaked key is exploited in minutes and mining can be running within ten. Attackers spread expensive instances across many regions and disable termination, and the charges surface hours later because billing data lags real usage.

Will AWS refund it? Often. One developer who leaked a key for ten minutes was billed over $14,000 and got a full refund within days. It is discretionary, not guaranteed, and your odds are best if you secured the account fast. Here is the step-by-step playbook for handling it.

If a standing key with your whole account behind it is the thing you would rather not lie awake over, see how Korvalis handles it or join the waitlist.