Leaked an AWS key on GitHub? Here's what happens in the first 5 minutes

Most people think a leaked key is a “fix it on Monday” problem. It isn’t.

In 2023, Palo Alto’s Unit 42 team watched a campaign they called EleKtra-Leak in real time. They put AWS keys into a public GitHub repo on purpose and timed what happened. The attackers found the keys and started using them within five minutes of the push. (Unit 42)

So “I’ll delete it in the next commit” doesn’t work. By then the key has already been copied, and it stays in your git history anyway.

What the attacker actually did

Unit 42’s CloudTrail logs show a short, very automated playbook:

1. Look around. Calls like DescribeAccountAttributes, DescribeInstanceTypeOfferings and DescribeRegions: what is this account allowed to do, and where?
2. Prepare. Create security groups.
3. Spend your money. Launch large c5a.24xlarge EC2 instances, several per Region, in every Region the key could reach.
4. Mine crypto. A miner was installed through instance user data, which CloudTrail doesn’t log.

All of that came to more than 400 API calls in about seven minutes. Nobody was typing. It was a script.

What AWS does on its own (and why you shouldn’t undo it)

GitHub scans public repos for AWS keys and tells AWS. AWS then attaches a quarantine policy (AWSCompromisedKeyQuarantine) to the IAM user. It blocks risky actions such as launching EC2 instances or changing IAM.

In the Unit 42 test, AWS applied it within about two minutes of the leak, and the researchers say the quarantine “would have successfully prevented this attack.” They removed it on purpose to watch the full campaign.

Two things to take from this:

• Never remove the quarantine policy to “get the app working again”. Rotate the key instead.
• Don’t rely on it. It only covers keys GitHub finds in public repos. A key in a private repo, a CI log, a Slack message or a laptop backup gets no warning.

The 6 steps to take right now

#	Step	Where
1	Deactivate the key (don’t just delete the commit)	IAM → Users → Security credentials
2	Create a new key only if you really need one, and update whatever used it	IAM
3	Check CloudTrail for anything that key did: new users, new keys, EC2 in odd Regions, RunInstances calls	CloudTrail → Event history
4	Delete anything you didn’t create: instances, users, access keys, Lambda functions, roles	Every Region you use, and the ones you don’t
5	Check Billing for spikes and open a case with AWS Support if you see unknown charges	Billing
6	Remove the key from git history, not just the latest commit	Your repo

AWS’s own walkthrough of the same steps: What to do if you inadvertently expose an AWS access key.

How to stop it happening again

• Turn on push protection and secret scanning in GitHub (or your git platform). It blocks the push before the key goes public.
• Stop using long-lived access keys. Use IAM roles, IAM Identity Center or OIDC for CI/CD (GitHub Actions can assume an AWS role with no stored key at all).
• Scan on every commit, in your own pipeline, not only on the public side.
• Alert on the obvious: RunInstances in Regions you never use, new IAM users, new access keys.

My rule of thumb after more than 15 years in this field: if a credential can be copied, assume it will be. Design so a copied key is useless (short-lived, narrow, and watched) instead of hoping it never leaks.

---

Sources

• Unit 42, EleKtra-Leak: Cloud-Based Cryptojacking Campaign Uses Exposed IAM Keys on GitHub: unit42.paloaltonetworks.com
• AWS Security Blog, What to do if you inadvertently expose an AWS access key: aws.amazon.com