AWS Automatically Quarantines Exposed IAM Keys Within 10 Seconds of GitHub Leak
AWS quarantined a leaked IAM key 10 seconds after Unit 42 published it to public GitHub.
Palo Alto Networks Unit 42 published a controlled test showing AWS attached the AWSCompromisedKeyQuarantineV3 policy 10 seconds after an IAM access key was pushed to a public GitHub repository on December 19, 2025. GitHub secret scanning reported the secret, and CloudTrail recorded AttachUserPolicy at 18:50:15 UTC, though the event attributed the action to the affected user. The managed deny policy, evolved from a 2020 original through V2 and V3, blocks selected high-risk actions across services including IAM, S3, Lambda, Bedrock, and SageMaker without revoking the key. AWS still expects administrators to rotate or deactivate exposed keys and hunt surrounding CloudTrail activity.
- Unit 42 saw AWSCompromisedKeyQuarantineV3 attached 10 seconds after a public GitHub push.
- CloudTrail named the IAM user as the actor, not AWS automation.
- Quarantine denies selected high-risk actions but does not disable the key.
- Alert on AttachUserPolicy events for AWSCompromisedKeyQuarantine, V2, or V3.
Full article650 words · extracted from cybersecuritynews.com · click to collapse
Amazon Web Services can move from detection to containment in seconds when an Identity and Access Management access key appears in a public GitHub repository.
In a controlled Unit 42 exposure test, AWS attached its AWSCompromisedKeyQuarantineV3 managed policy to the affected IAM user only 10 seconds after researchers published the credential, sharply reducing the window available for abuse.
Long-term IAM access keys remain attractive initial-access vectors because they can provide programmatic access without interactive authentication. Developers may accidentally commit them to source code, configuration files, or publicly accessible environment files.
GitHub secret scanning searches public repositories and other public surfaces for recognized credential patterns; through its partner integration, it reports detected AWS secrets directly to AWS so the provider can respond.
AWS Automatically Quarantines Exposed IAM Keys
According to research published by Unit 42, the December 19, 2025 test offers a precise view of that automation. Researchers pushed an access key and secret to a public repository at 18:50:05 UTC after GitHub push protection warned about both values.
At 18:50:15, CloudTrail recorded an AttachUserPolicy event showing AWSCompromisedKeyQuarantineV3 attached to TestUser.
GitHub emailed an alert one second later, AWS Health displayed a “Risk IAM quarantine” notice at 18:50:17, AWS sent an email at 18:50:26, and a Support case appeared by 18:50:59.
One logging detail could complicate incident triage. CloudTrail’s userIdentity field named TestUser as the actor behind the policy attachment even though the user did not perform it, and the record did not clearly identify AWS automation.
The Health alert and Support-case creation also produced no CloudTrail event in the test, making the AttachUserPolicy record the most dependable machine-readable signal.
AWS introduced the original AWSCompromisedKeyQuarantine policy in August 2020, followed by V2 in April 2021 and V3 in August 2024. The first release explicitly denied 28 actions across IAM, EC2, Organizations, Lambda, and Lightsail.
V2 expanded restrictions into S3 and ultimately accumulated 61 additional denied permissions across 17 services, while later revisions addressed abuse involving ECS, ECR, Bedrock, SageMaker, STS, and other services.
This evolution mirrors changes in cloud attacks. Restrictions on role and Lambda creation hinder cryptomining persistence, S3 deletion controls can disrupt data-extortion attempts, and Bedrock-related denials address unauthorized generative-AI consumption.
Because an explicit Deny overrides an Allow during IAM policy evaluation, the quarantine can block listed high-risk actions without rewriting the user’s existing permissions.
Quarantine, however, is not revocation. AWS deliberately blocks selected operations instead of disabling the key or applying AWSDenyAll, reducing potential disruption to legitimate workloads.
Consequently, an attacker may still execute actions absent from the deny list. Administrators should treat the attachment as a confirmed credential-exposure incident, follow the AWS Support case, rotate or deactivate the key, and review activity surrounding the leak.
Security teams should alert on IAM AttachUserPolicy events where requestParameters.policyArn contains AWSCompromisedKeyQuarantine, AWSCompromisedKeyQuarantineV2, or AWSCompromisedKeyQuarantineV3.
They should correlate the affected username with preceding and subsequent CloudTrail activity, including GetCallerIdentity requests carrying GitHub’s automated validation user agent, and centralize Support cases through AWS Systems Manager Explorer to prevent notifications from remaining siloed with cloud engineering.
Palo Alto Networks says Cortex Cloud can add behavioral context to identity-driven cloud threats, while Idira PAM supports centralized secrets management, just-in-time access and zero standing privileges.
Organizations can also use a Unit 42 Cloud Security Assessment to identify cloud misconfigurations and security gaps; they should escalate suspected compromises immediately to the Unit 42 Incident Response team across complex multi-account cloud environments.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC
Guru Baranhttps://cybersecuritynews.com
Gurubaran KS is a cybersecurity analyst, and Journalist with a strong focus on emerging threats and digital defense strategies. He is the Co-Founder and Editor-in-Chief of Cyber Security News, where he leads editorial coverage on global cybersecurity developments.