Security1 publisher2 min readPublished
AWS automatically quarantines leaked IAM keys and opens a support case for the affected user
Unit 42 traced AWSCompromisedKeyQuarantine through three versions since August 2020 and documented the GitHub secret scanning integration that lets AWS attach the policy to an exposed IAM user automatically, with the owner notified afterwards.
The Watch · Security desk
What happened
- Unit 42 documented how AWS's AWSCompromisedKeyQuarantine managed policy is attached automatically to an IAM user whose access key and secret turn up publicly, including a timeline from its own exposure test.
- Reports reach AWS through the partner integration with GitHub's secret scanning program and through other notices, after which AWS secures the credential and notifies the owner.
- Unit 42 says misuse of IAM user access keys still accounts for a large majority of initial attack vectors in attacks against AWS environments.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure The deny lands on the IAM user without the owner doing anything, so the first person in the organization to see it can be whoever runs a job that worked yesterday and fails today.
- constraint AWS's wording keeps existing resources running, so what actually breaks is confined to the API calls an automation identity makes with that key inside the deny set.
- capability Alerting on the policy attachment gives a team leak detection it did not have to build, covering public repositories and environment files outside its control.
- decision Because the deny set has been revised twice, response procedures that name specific blocked calls need a review date attached to them.
The attachment path runs through GitHub. AWS and GitHub operate a partner integration around GitHub's secret scanning program, and when a key and its secret appear in a public repository, AWS secures the credential and then notifies the owner. Unit 42, the research group at Palo Alto Networks, published a step-by-step timeline from an exposure test it ran itself.
AWS's description of V3, as quoted by Unit 42, says the policy "Denies access to certain actions, applied by AWS in the event that an IAM user's credentials have been compromised or exposed publicly," and that it "aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources." The last clause is the one that governs triage. Existing resources stay up. Whatever the key is used for inside the deny set stops, and AWS's instruction is to read the support case rather than detach the policy: "Do NOT remove this policy." The action-by-action breakdown sits in a later section of the Unit 42 post.
Access keys grant long-term command line access to an IAM user, so how much an exposure costs depends on whether that user's permissions followed least privilege in the first place.
The dates: created Aug. 11, 2020, V2 on April 21, 2021, V3 on Aug. 21, 2024. V2 arrived about eight months after the original, V3 three years and four months after V2. Unit 42 relates those permission changes directly to new attacks against AWS environments. An incident runbook that enumerates denied calls from the 2021 policy is describing something two revisions behind what AWS attaches today.
The automation itself is old. Cloud security researcher Pawel Rzepa documented AWS's response to keys leaked in GitHub repositories in two posts, "AWS Access Keys Leak in GitHub Repository" and "Some Improvements in Amazon Reaction," which Unit 42 cites as the earlier record of the process.
Unit 42 recommends detecting quarantine events inside an organization's own logging environment so response starts quickly. Keys leak through publication in public code repositories and through environment variable files, and Unit 42 says misuse of IAM user access keys continues to account for a large majority of initial attack vectors when organizations are attacked in AWS.
One caution on reading the policy as protection: it denies certain actions and leaves the rest. AWS frames the goal as limiting fraud-related unauthorized charges. That is a billing containment goal. The same document tells owners to follow the support case for the rest of the response.
What to watch
- A V4 of AWSCompromisedKeyQuarantine, and whether the revision denies more API actions than the August 2024 set.
- Whether code hosts other than GitHub get the same automatic-quarantine reporting arrangement with AWS.
- Incident write-ups in which the quarantine attachment was the first sign a key had leaked.