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

> Attackers found and used exposed AWS keys within five minutes in one real campaign. What they did, what AWS does automatically, and the 6 steps to take right now.

- Published: 2026-10-22
- Topics: AWS, IAM, Incident response
- Canonical page: https://thesecguy.com/notes/leaked-aws-key-first-5-minutes/
- Publisher: The Sec Guy (https://thesecguy.com)

**Short answer:** Attackers can find and use an AWS access key pushed to a public GitHub repo within about five minutes; in Unit 42's EleKtra-Leak research they used exposed keys to launch crypto-mining instances. Deleting the commit is not enough: deactivate the key at once, check CloudTrail for what it did, and move to short-lived credentials.

---

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](https://unit42.paloaltonetworks.com/malicious-operations-of-exposed-iam-keys-cryptojacking))

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](https://aws.amazon.com/blogs/security/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](https://unit42.paloaltonetworks.com/malicious-operations-of-exposed-iam-keys-cryptojacking)
- AWS Security Blog, *What to do if you inadvertently expose an AWS access key*: [aws.amazon.com](https://aws.amazon.com/blogs/security/what-to-do-if-you-inadvertently-expose-an-aws-access-key/)