From Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies
AWS automatically quarantines exposed IAM access keys found in public GitHub repositories using the AWSCompromisedKeyQuarantine managed policy, denying risky actions within seconds of exposure. AWS attaches the AWSCompromisedKeyQuarantineV3 managed policy to IAM users within ~10 seconds of credential exposure in public GitHub repos. The policy denies 61+ permissions across 17 services to block common attack patterns like cryptomining, data deletion, and unauthorized API calls. Security teams can detect quarantine events via CloudTrail AttachUserPolicy logs and identify GitHub validity checks through specific user agents performing GetCallerIdentity.
Detection / Hunteropenrouter
Immediate Actions
- Create CloudTrail alerts for AttachUserPolicy events containing AWSCompromisedKeyQuarantine policy ARN
- Alert on GetCallerIdentity calls from GitHub ASN IPs with GHAS-AWS_KEYID-validation user agents
- Rotate any IAM access keys found exposed in public repositories immediately
- Enable GitHub secret scanning and push protection on all repositories including private
Key Takeaways
- AWSCompromisedKeyQuarantineV3 attached within 10 seconds of GitHub exposure in testing
- Policy evolved from 28 denied actions (V1) to 61+ across 17 services (V2/V3)
- GitHub push protection may miss secrets in pushes over 50 MB or with more than 5 secrets
- CloudTrail AttachUserPolicy event does not indicate it is AWS-automated; userIdentity shows the IAM user name
- GitHub validity checks generate GetCallerIdentity calls with identifiable user agents from GitHub ASN
Attack Chain
- Initial Exposure: IAM access key and secret pushed to public GitHub repository
- Detection: GitHub secret scanning identifies exposed AWS credentials and notifies AWS
- Quarantine: AWS attaches AWSCompromisedKeyQuarantineV3 managed policy within ~10 seconds
- Notification: AWS generates Health alerts, Support tickets, and email notifications
- Mitigation: Policy denies 61+ risky permissions while allowing normal business operations
Affected Systems
- AWS IAM users with long-term access keys
- AWS CloudTrail logging
- GitHub public repositories
- Amazon S3, Lambda, EC2, Bedrock, SageMaker services
Detection Availability
No detection rules or queries are published in the source article.
Detection Engineering Assessment
Hypotheses are starting points derived from the article, not findings about your environment; validate against your own telemetry.
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | None | This is a cloud identity and API threat; EDR agents have no visibility into AWS IAM or CloudTrail events. |
| Network Visibility | Medium | GitHub validity checks appear as STS GetCallerIdentity calls from GitHub ASN IPs with identifiable user agents. |
| Detection Difficulty | Easy | AttachUserPolicy events with AWSCompromisedKeyQuarantine policy ARN are straightforward to alert on in CloudTrail. |
Hunting Hypotheses
| Hypothesis | Telemetry | Stage | FP Risk |
|---|---|---|---|
| CloudTrail AttachUserPolicy events where PolicyArn contains AWSCompromisedKeyQuarantine indicate automated credential quarantine (T1078.004). | AWS CloudTrail management events | Defense Evasion | Low — policy name is specific to AWS quarantine process. |
| GetCallerIdentity API calls from GitHub ASN IPs with GHAS-AWS_KEYID-validation user agents indicate exposed credentials being validated by GitHub (T1552.001). | AWS CloudTrail STS API events with source IP and user agent | Reconnaissance | Low — user agent string is highly specific to GitHub scanning. |
| IAM users with long-term access keys making API calls from unfamiliar IPs after credential exposure may indicate active exploitation before quarantine (T1078.004). | AWS CloudTrail events with source IP correlation | Initial Access | Medium — legitimate users may use new IPs. |
Required Log Sources
- AWS CloudTrail management events
- AWS CloudTrail event source IAM
- AWS Health dashboard alerts
- AWS Support case notifications
- GitHub push protection alerts
Key Behavioral Indicators
- AttachUserPolicy event with AWSCompromisedKeyQuarantine in PolicyArn field
- GetCallerIdentity calls from GitHub ASN with GHAS-AWS_KEYID-validation user agent
- userIdentity field in quarantine event shows compromised IAM user name
- Support case creation without corresponding CloudTrail event
- AWS Health alert named Risk IAM quarantine in console
Control Gaps
- CloudTrail does not flag AttachUserPolicy as AWS-automated action
- AWS Health alerts and Support cases do not generate CloudTrail events
- GitHub push protection misses secrets in pushes over 50 MB
- GitHub push protection only alerts on first 5 secrets per push
- Email notifications may not reach security team if cloud engineering owns the inbox
False Positive Assessment
Low — The AWSCompromisedKeyQuarantine policy name and GitHub GHAS user agent strings are highly specific indicators with minimal legitimate alternative explanations.
Recommendations
Suggestions to evaluate against your own environment, tooling, and incident-response procedures — not directives.
Infrastructure Hardening
- Replace long-term IAM access keys with temporary credentials via IAM roles and STS
- Enforce least-privilege IAM policies to minimize impact of credential exposure
- Use AWS Systems Manager Explorer to aggregate Support cases for security team visibility
- Monitor GitHub push protection bypass for pushes exceeding size or secret count limits
User Protection
- Ensure security team has access to AWS account email notifications or configure forwarding
- Enable GitHub Advanced Security secret scanning on private repositories
- Pre-commit hooks to scan for AWS credentials before pushing to any remote
Security Awareness
- Train developers on risks of committing AWS credentials to public repositories
- Establish communication channels between cloud engineering and security teams for exposure notifications
MITRE ATT&CK Mapping
Initial Access
Credential Access
Collection
Impact
Plain-Language Summary
Attackers frequently find AWS access keys accidentally published in public code repositories and use them to run cryptomining, delete data, or make unauthorized API calls. AWS and GitHub collaborate to detect these exposed keys automatically; GitHub scans for them and notifies AWS, which then attaches a restrictive policy to the affected user within seconds. Organizations should monitor their AWS logs for these quarantine events and ensure their security and cloud engineering teams coordinate on exposure notifications.
Additional IOCs
- Other:
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.- GitHub user agent for AWS key validity checks (pre-Oct 2025)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.- GitHub user agent for AWS key validity checks (post-Oct 2025)
Related
- “Legitimate” phishing: how attackers weaponize Amazon SES to bypass email security·2
- Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers (2026-09-15)·1
- A Tale of Two SOCs: Insights From Two Red Team Assessments (2026-08-25)·1