AWS Quarantines an Exposed IAM Key While CloudTrail Names the User

An AWS IAM access key published in a public GitHub repository triggered an automatic quarantine policy attachment in a Unit 42 exposure test. The attachment arrived 10 seconds after the push. In CloudTrail, the AttachUserPolicy event named the affected IAM user in userIdentity, though the researcher says AWS performed the action. A security team treating that field as proof the user attached the policy could miss the credential-exposure response.

September 28, 2026: Unit 42 published this December 2025 test on September 21. Route quarantine attachments to the team that can disable and replace exposed keys, even if cloud engineering handles the AWS account-owner email. Unit 42 measured the 10-second interval in one controlled exposure test.

A public push starts quarantine

The test user had a long-term access key and secret. GitHub push protection warned on the attempted push, and the researcher then pushed the credentials to a public repository at 18:50:05 UTC on December 19. At 18:50:15, CloudTrail recorded AWS attaching AWSCompromisedKeyQuarantineV3. GitHub sent its exposure email a second later; AWS Health posted a “Risk IAM quarantine” alert, and an AWS Support case identifying the key and user appeared at 18:50:59.

GitHub describes how its secret scanning works: it scans public repositories automatically and reports partner secrets directly to providers. Private and internal organization repositories require GitHub Secret Protection under the documented availability rules. Push protection helped in this test, but Unit 42 warns that very large pushes and pushes containing more than five secrets can leave detection gaps. Use repository scanning and a cloud-side quarantine alert together.

Denied actions leave remaining access

An IAM managed policy attaches to a principal; an explicit Deny overrides an existing Allow for the named actions. AWS describes the V3 quarantine policy as a restriction intended to limit fraud-related damage while keeping existing resources running. Its current default version is v3, edited March 16, 2026. The policy denies actions including ec2:RunInstances, s3:GetObject, bedrock:InvokeModel and selected KMS and CloudWatch Logs actions. It targets specified actions rather than disabling every request made with the exposed key. The policy’s description says: “Do NOT remove this policy. Instead, please follow the instructions specified in the support case created for you regarding this event.”

If an exposed key had other allowed permissions, treat it as a credential incident even after quarantine. An attacker could have used it before the attachment or could seek operations outside the policy’s deny list.

Find the attachment and key

Search CloudTrail IAM management events for AttachUserPolicy. Match requestParameters.policyArn to the quarantine policy name, including arn:aws:iam::aws:policy/AWSCompromisedKeyQuarantineV3 for V3; Unit 42 says any version produces this event. Correlate the event time and affected user with the Health alert and the access key identified in the Support case. In this test, Health and Support creation did not produce CloudTrail events. Check those services directly if the account owner received an exposure notice but your CloudTrail alert is quiet.

Unit 42 also observed GitHub validity checks using the STS operation GetCallerIdentity. For a narrower exposure lead, correlate that operation with GitHub-origin network details and the following two user-agent values. The suffix changed in October 2025; the asterisks represent SDK version wildcards. These values identify GitHub’s automated testing process in the research, not an attacker indicator:

• aws-sdk-go-v*/*.*.* os/linux lang/go#*.*.* md/GOOS#linux md/GOARCH#amd64 api/sts#*.*.* GHAS-AWS_KEYID-validation-1.0.0-This-call-originates-from-an-automated-process-that-tests-AWS_KEYIDs-committed-to-GitHub-repos.-Please-contact-secret-scanning-github.com-for-more-info.
• aws-sdk-go-v*/*.*.* os/linux lang/go#*.*.* md/GOOS#linux md/GOARCH#amd64 api/sts#*.*.* GHAS-AWS_KEYID-validation-1.0.0-This-call-originates-from-an-automated-process-that-tests-AWS_KEYIDs-committed-to-GitHub-repos.-For-questions-on-our-processes--please-contact-secret-scanning-github.com.

Replace the exposed credential

Manage the IAM user’s access keys from an administrator identity: identify the affected key, deactivate it, replace it where workloads use it and delete the old key after migration. AWS recommends temporary credentials such as IAM roles over long-term keys. Inspect CloudTrail usage of the exposed key around the repository push for operations inconsistent with the workload’s expected access, and work through the account’s Support case before changing the quarantine policy. Use the quarantine policy ARN and Support case to identify AWS’s response when the attachment names the protected user.

Make quarantine reach the responder

Alert the cloud security team on AttachUserPolicy with a quarantine policyArn, and connect that alert to the AWS Health notification and Support case for the same user. Deactivate and replace the exposed key; verify the old key is inactive or deleted and that the workload works with its replacement. Preserve CloudTrail key-use history from before the attachment for incident triage. A single automatic policy change buys time, while credential replacement and review of earlier requests address the exposure itself.