AWS Auto-Quarantines Exposed IAM Keys in 10 Seconds via AWSCompromisedKeyQuarantine Policy
A Unit 42 controlled test showed AWS attached its AWSCompromisedKeyQuarantineV3 managed policy just 10 seconds after an IAM key leaked to public GitHub, denying high-risk actions across IAM, S3, Lambda, Bedrock, and SageMaker without disabling the key itself.
Palo Alto Unit 42 details how AWS automatically neutralizes publicly exposed IAM access keys by attaching its AWSCompromisedKeyQuarantine managed policy, which denies attacker-favored actions without removing the underlying resources or revoking the key. In a controlled exposure test on December 19, 2025, AWS attached AWSCompromisedKeyQuarantineV3 to the affected IAM user just 10 seconds after researchers pushed the credential to a public GitHub repository; GitHub secret scanning reported the leak, and CloudTrail logged the AttachUserPolicy action at 18:50:15 UTC — attributing it to the affected IAM user rather than to AWS automation. The policy, created August 11, 2020, with V2 in April 2021 and V3 in August 2024, blocks selected high-risk actions across services including IAM, S3, Lambda, Bedrock, and SageMaker. Detection is powered by the GitHub-AWS secret scanning partnership, in place since 2020, which includes key validity checks and push protection. Unit 42 notes IAM key misuse remains a majority initial attack vector in AWS intrusions. Because the quarantine does not disable the key, AWS still expects administrators to rotate or deactivate exposed credentials and hunt surrounding CloudTrail activity; Unit 42 recommends alerting on AttachUserPolicy events naming AWSCompromisedKeyQuarantine, V2, or V3 for rapid incident response.
- AWS attached the AWSCompromisedKeyQuarantineV3 policy 10 seconds after an IAM access key was pushed to a public GitHub repository in a Unit 42 test on December 19, 2025.
- CloudTrail recorded the AttachUserPolicy action at 18:50:15 UTC but attributed it to the affected IAM user, not to AWS automation.
- AWSCompromisedKeyQuarantine was created August 11, 2020; V2 followed in April 2021 and V3 in August 2024.
- The quarantine policy denies selected high-risk actions across services including IAM, S3, Lambda, Bedrock, and SageMaker, but does not revoke or disable the exposed key.
- Detection relies on the GitHub-AWS secret scanning partnership operating since 2020, including key validity checks and push protection.
- IAM key misuse remains a majority initial attack vector in AWS intrusions, per Unit 42.
- AWS expects administrators to rotate or deactivate exposed keys and review surrounding CloudTrail activity.
- Unit 42 recommends alerting on AttachUserPolicy events involving AWSCompromisedKeyQuarantine, V2, or V3 to speed incident response.
Coverage timelineoldest first · each row is one article
- · 5d agoFrom Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies
Palo Alto Unit 42· 45
Unit 42 analyzes how AWS's AWSCompromisedKeyQuarantine managed policy automatically neutralizes exposed IAM access keys, plus monitoring strategies for quarantine events.
- · 5d agoAWS Automatically Quarantines Exposed IAM Keys Within 10 Seconds of GitHub Leak
Cyber Security News· 56
AWS quarantined a leaked IAM key 10 seconds after Unit 42 published it to public GitHub.
- · 5d ago