How AWS Quarantines Exposed IAM Credentials

Long-term AWS IAM access keys remain a practical cloud security risk because they can be copied, reused and operated outside the normal controls applied to interactive users. A key and its secret may be committed to a public code repository, included in an exposed environment file or disclosed through another external channel. If the associated IAM identity has broad permissions, an attacker who obtains both values may be able to perform unauthorized actions in the account.

Research from Palo Alto Unit 42 examines how AWS responds when it receives notice that an access key has been exposed publicly. The research focuses on the AWSCompromisedKeyQuarantine managed policy, GitHub’s secret-scanning partnership with AWS, and the CloudTrail events that can help defenders identify and investigate the resulting containment process.

The cloud exposure path

The scenario described by Unit 42 begins with a long-term IAM access key and its secret becoming visible on a public GitHub surface. GitHub scans public repositories by default and can also scan private repositories when administrators enable the capability. Its secret-scanning partner program uses provider-specific detection patterns and can notify the issuing service when a likely credential is found.

AWS can then take automated action. According to Unit 42, the response can include attaching an AWSCompromisedKeyQuarantine managed policy to the IAM user associated with the exposed key, sending notifications, and creating an AWS Support case containing details of the exposure. The purpose is not to erase the identity or immediately deny every possible operation. Instead, the policy adds explicit denies for actions that AWS considers particularly useful during abuse of compromised credentials.

This distinction matters. An exposed key is not automatically equivalent to a fully disabled account. The identity may retain permission to perform actions that are not covered by the quarantine policy, especially where the original permissions are extensive or unusual. The quarantine mechanism is therefore a containment measure, not a substitute for credential rotation, incident investigation or least-privilege design.

What Unit 42 observed in its exposure test

Unit 42 conducted a controlled test using a newly created IAM user and access key. The researchers pushed the key and secret to a public GitHub repository and recorded the sequence of platform responses. In that test, AWS attached the V3 quarantine policy within approximately 10 seconds of exposure. GitHub generated its own notification shortly afterward, followed by AWS Health and Support notifications.

The reported timeline included several relevant CloudTrail events. The initial account activity showed creation of the test user, creation of the access key and a GetCallerIdentity request. After the public exposure, CloudTrail recorded an AttachUserPolicy event associated with the IAM service. The policy ARN in the request parameters identified the AWSCompromisedKeyQuarantineV3 policy.

Unit 42 noted an important logging nuance: the CloudTrail record did not clearly identify the attachment as an AWS automated action. Its userIdentity field listed the IAM user’s name, even though the test user did not perform the attachment. Organizations should avoid assuming that the apparent identity in this event fully explains who or what initiated the containment action.

The AWS Health alert and Support case observed during testing did not generate corresponding CloudTrail events. This creates an operational visibility gap for teams that rely only on CloudTrail. Unit 42 recommends monitoring the policy-attachment event while also ensuring that AWS Support cases and account notifications reach the security function rather than remaining solely with cloud engineering or account administrators.

Why the quarantine policy is useful—and limited

AWSCompromisedKeyQuarantine uses explicit deny statements. Under AWS IAM evaluation rules, an explicit deny overrides an explicit allow. Consequently, attaching the policy can block a listed action even when the IAM user’s existing policies allow it.

The original policy, released in 2020, focused on a set of actions across IAM, EC2, Organizations, Lambda and Lightsail. Unit 42 reports that later policy revisions expanded the deny list. The V2 policy added protections involving S3 and other services, while subsequent updates addressed activities involving areas such as reserved capacity, ECS, ECR, Amazon Bedrock, SageMaker, SES, CodeBuild, Glue, SNS and additional IAM and Lambda operations. AWS released V3 in August 2024, with the research stating that its permissions matched the later V2 set described in the analysis.

Unit 42 interprets these changes as evidence that the policy has been adjusted in response to changing abuse patterns. Examples discussed in the research include attempts to create Lambda functions and supporting IAM roles, deletion of S3 data after exfiltration, and unauthorized use of Amazon Bedrock APIs. These examples explain why a managed policy intended for compromised credentials cannot remain static.

There is also a deliberate trade-off in the design. AWS has another policy, AWSDenyAll, which would have a much broader operational effect. AWSCompromisedKeyQuarantine instead blocks selected actions while attempting to preserve ordinary business functions. That approach can reduce disruption, but it also means that an attacker may still use the exposed credentials for actions absent from the deny list. Defenders should treat any quarantine attachment as evidence of credential compromise, not as proof that all abuse has stopped.

GitHub validation activity as a detection signal

GitHub’s secret-protection features can perform validity checks against provider APIs. For AWS access keys, Unit 42 says these checks use the AWS Security Token Service GetCallerIdentity API request to determine whether a discovered credential remains active. That request can appear in the affected account’s CloudTrail data.

The researchers identified user-agent patterns associated with the automated validation process. The patterns begin with an AWS SDK for Go identifier and include a marker similar to GHAS-AWS_KEYID-validation-1.0.0. Unit 42 reports that GitHub updated the wording of this marker in October 2025. The research also states that the source IP addresses observed in testing resolved to GitHub’s autonomous system number.

These signals should be used carefully. A GetCallerIdentity request with a GitHub-associated user agent may indicate that GitHub is validating a detected secret rather than that an attacker is conducting reconnaissance. It is nevertheless valuable because it can provide an early indication that a credential has appeared on a public repository. Security teams can correlate the event with the IAM access key, repository-management records, the subsequent AttachUserPolicy event and any other activity by the same identity.

Unit 42 also identifies limitations in GitHub push protection. The research says that very large pushes may not be scanned in the same way, and that a single push containing more than five exposed secrets may produce alerts for only five of them. These cases can create an identification gap, so repository security controls should be complemented by broader secret scanning and cloud-side monitoring.

Reconstructing activity with CloudTrail

CloudTrail is central to the response workflow described by Unit 42. The default logs record management events for the account, and in the test they captured the IAM user and access-key creation, the credential validation request and the quarantine-policy attachment. The most direct alert condition is an IAM AttachUserPolicy event where the request parameters reference any version of the AWSCompromisedKeyQuarantine managed policy.

After that alert, responders should review the same access key’s preceding and subsequent activity. The goal is to establish whether the key was merely exposed, validated by GitHub, or used for additional AWS operations. Organizations should also review the identity’s original permissions, determine which actions remain possible under quarantine, and look for unexpected changes or resource activity. The supplied research does not establish that every exposed credential is used by an attacker, nor does it provide a universal set of post-compromise events. Those questions require account-specific investigation.

CloudTrail alone does not capture every notification or support workflow. AWS Health and Support case creation did not appear as CloudTrail events in the Unit 42 test. Security operations teams should therefore combine log analytics with AWS account notifications and a process for aggregating Support cases. Unit 42 specifically identifies AWS Systems Manager Explorer as one option for helping security teams view AWS Support cases centrally.

What organizations should do now

• Alert on quarantine attachments. Create a high-priority detection for IAM AttachUserPolicy events whose PolicyArn identifies AWSCompromisedKeyQuarantine, AWSCompromisedKeyQuarantineV2 or AWSCompromisedKeyQuarantineV3.
• Rotate exposed credentials. Treat the attachment as a confirmed exposure signal. Disable or replace the affected access key through the organization’s approved response process, then verify that dependent applications use a secure replacement.
• Correlate GitHub validation activity. Search CloudTrail for GetCallerIdentity requests carrying the GitHub secret-scanning user-agent markers described by Unit 42. Defang the email-like contact string in dashboards and documentation as secret-scanning-github[.]com.
• Review activity before and after exposure. Examine actions performed by the affected IAM identity, compare them with its normal business purpose, and investigate unexpected resource creation, configuration changes, data access or deletion.
• Route AWS notifications to security. Ensure that Health alerts, account email and Support cases are visible to incident responders, not only to the team that administers the AWS account.
• Reduce standing privilege. Apply least privilege to IAM users and replace long-term access keys with more controlled identity mechanisms where practical. The research supports this as a general defensive principle, but does not prescribe a single migration design.
• Strengthen repository controls. Enable secret scanning and push protection across appropriate repositories, while recognizing the large-push and multi-secret limitations reported by Unit 42. Prevent secrets from entering source control through development workflows and pre-commit controls.
• Do not remove the quarantine policy prematurely. Unit 42 reports that the policy description instructs customers not to remove it and instead to follow the related AWS Support guidance. Any removal decision should occur only after the exposure and associated activity have been investigated.

What remains unknown

The research describes a controlled exposure test and policy evolution; it does not identify a specific victim organization, threat actor or malware family. It also does not establish that AWS quarantine blocks every possible use of a compromised key. The policy’s deny list changes over time, and permissions outside that list may remain available. Finally, a GitHub validation request is not, by itself, proof of malicious use. Attribution and impact require additional evidence from the affected account, repository and surrounding systems.

Conclusion

AWS’s automated quarantine process can reduce the harm from publicly exposed IAM credentials, but its value depends on rapid detection and coordinated response. The strongest operational approach combines repository scanning, alerts for quarantine-policy attachments, CloudTrail correlation, visibility into AWS Support cases and immediate credential replacement. Organizations should regard the AWSCompromisedKeyQuarantine policy as an early-warning and containment control—valuable, but not a complete incident-response solution.

Sources

• Palo Alto Unit 42: From Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies