AWS Detects and Quarantines Exposed IAM Credentials in Public GitHub Repositories

AWS can automatically quarantine exposed Identity and Access Management (IAM) access keys that appear in public GitHub repositories. This process involves applying a restrictive managed policy within seconds to reduce the risk of cloud abuse.

Researchers from Palo Alto Networks’ Unit 42 documented this response mechanism, showing that AWS employs the AWSCompromisedKeyQuarantine managed policy to deny a specific set of high-risk actions while preserving access to existing resources whenever possible.

AWS Detects and Quarantines Exposed IAM Credentials

Long-term IAM access keys remain a significant cloud security concern because they can be inadvertently committed to source code, configuration files, environment-variable files, or public package repositories.

Once discovered, an exposed key can allow attackers to enumerate cloud assets, create infrastructure for cryptomining, establish persistence, alter permissions, or generate unauthorized costs, depending on the permissions granted to the affected IAM identity.

AWS’s automated protection is integrated with GitHub’s secret-scanning partner program. GitHub scans public repositories and public npm packages for recognized secret patterns and notifies participating service providers when it detects a potentially exposed credential. AWS can then act on this report without waiting for the account owner to revoke the key manually.

In a test conducted by Unit 42, researchers pushed an AWS access key and secret to a public GitHub repository. AWS attached the AWSCompromisedKeyQuarantineV3 policy to the associated IAM user just 10 seconds after the credentials were exposed.

GitHub sent its notification one second later, followed by AWS Health alerts, email notifications, and an AWS Support case detailing the affected key and IAM user.

The quarantine policy matters because it does not disable the IAM user or revoke all permissions. Instead, it applies explicit Deny statements against actions commonly exploited after an account compromise.

In AWS policy evaluation, an explicit Deny overrides an Allow, meaning that the quarantine controls take precedence, even if the IAM user’s existing policies authorize the action.

The initial version of AWSCompromisedKeyQuarantine, introduced in August 2020, blocked 28 actions across IAM, Amazon EC2, AWS Organizations, AWS Lambda, and Amazon Lightsail.

AWS later expanded the control set, with Version 2 adding restrictions for Amazon S3 and broadening the deny list to cover 17 services, ultimately encompassing 61 additional high-risk permissions. Version 3 retained these expanded protections.

Examples of restricted actions include creating new IAM users or access keys, attaching policies, creating roles, launching EC2 instances, requesting Spot Instances, creating Lambda functions, and performing sensitive Lightsail operations.

These controls are designed to disrupt privilege escalation, persistence, resource hijacking, and fraud-related activities while avoiding immediate disruption to legitimate workloads tied to the identity.

However, this policy is not a substitute for credential rotation and incident response. AWS advises customers not to remove the managed policy and to follow the instructions provided in the support case.

Security teams should treat the event as a potential compromise, identify every system using the affected credential, replace the key, review IAM permissions, and investigate activity both before and after the exposure.

Defenders can monitor for quarantine events in AWS CloudTrail by identifying AttachUserPolicy events from the IAM service. The relevant policy ARN appears in the request parameters and can indicate when an AWSCompromisedKeyQuarantine policy has been attached.

Organizations should route these events to their SIEM or alerting platform so cloud engineering and security teams receive the same notifications.

This incident highlights the importance of a layered defense model: GitHub secret scanning identifies public exposure, AWS automatically limits dangerous actions, and internal responders complete containment by rotating credentials and investigating any misuse.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC