Loading story…
AWS automatically attaches the managed AWSCompromisedKeyQuarantine policy to an IAM user after detecting that the user’s long-term access key and secret were publicly exposed. A controlled GitHub exposure test showed the AWSCompromisedKeyQuarantineV3 policy applied within 10 seconds, followed by a GitHub notification, AWS Health alert, email notification, and AWS Support case. The policy uses explicit deny statements to block high-risk activity while retaining much of the user’s ordinary access.
The quarantine policy has expanded from 28 denied actions across five services in 2020 to restrictions spanning resource creation and services including Amazon S3, EC2, IAM, and Bedrock, reflecting evolving cloud-abuse tactics. Organizations should investigate CloudTrail AttachUserPolicy events involving this policy and GitHub secret-validation GetCallerIdentity requests, then rotate exposed credentials, assess activity performed before containment, and enforce least-privilege IAM controls; permissions not explicitly denied may remain available to an attacker.
See attribution, scope, and your downstream exposure.
11 events from the most recent confirmed update back to the earliest known activity.
AWS sent an email notification and subsequently created an AWS Support case containing details of the exposed access key and affected IAM user. Support-case creation did not generate a CloudTrail event in the test.
AWS created a Risk IAM quarantine AWS Health alert after detecting the exposed credentials. The Health-alert creation did not produce a CloudTrail event in the test.
GitHub sent an exposed-secret notification one second after AWS attached the quarantine policy to the affected IAM user.
Ten seconds after the public GitHub exposure, AWS attached AWSCompromisedKeyQuarantineV3 to TestUser through an IAM AttachUserPolicy event. The CloudTrail event's userIdentity field identified TestUser even though that user did not perform the attachment.
The test access key and secret were successfully pushed to a public GitHub repository. GitHub push protection had detected the credentials before the public push.
A controlled exposure test created an IAM user named TestUser and an access key for that user.
AWS released AWSCompromisedKeyQuarantineV2 version 5, adding restrictions affecting services including ECS, ECR, Bedrock, S3, SageMaker, SES, STS, Amplify, CodeBuild, Glue, IAM, Lambda, SNS, and MediaPackage v2.
AWS released AWSCompromisedKeyQuarantineV3. Its first version matched V2 version 4, while its second version matched V2 version 5.
AWS released AWSCompromisedKeyQuarantineV2, which ultimately grew through five revisions to deny 61 permissions across 17 AWS services.
AWS created the initial AWSCompromisedKeyQuarantine managed IAM policy. It denied 28 actions across IAM, EC2, AWS Organizations, Lambda, and Lightsail to limit abuse of exposed access keys.
GitHub added AWS to its secret-scanning partner program, enabling scanning of public GitHub repositories and public npm packages for AWS credential patterns.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See attribution, scope, and whether this vendor sits anywhere in your supply chain.
4 references tracked. Mallory keeps watching after this page renders.
unit42.paloaltonetworks.com
Open sourcedocs.aws.amazon.com
Open sourceaws.amazon.com
Open sourcedocs.aws.amazon.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
AWS has introduced Amazon Bedrock API keys in addition to its broader push away from long-lived IAM access keys toward modern, temporary authentication mechanisms. Bedrock supports locally generated short-term keys from presigned URLs as well as long-term bearer tokens backed by IAM users; the latter can be created without an expiration date and are submitted directly in HTTPS headers. By default, long-term keys receive the `AmazonBedrockLimitedAccess` policy, which may grant more access than is necessary for narrowly scoped model-invocation workloads. Researchers found long-term Bedrock API keys exposed in public GitHub repositories within two weeks of the feature's launch. AWS added the keys to its secret-scanning process and now quarantines associated IAM users and notifies affected customers when exposures are detected. Organizations should favor temporary, role-based credentials, restrict IAM-user creation through service control policies, and consider denying `bedrock:CallWithBearerToken` where Bedrock API keys are not required, blocking both long- and short-term API-key use.
Sep 3, 2026
Palo Alto Networks Unit 42 reported that exposed AWS IAM access keys were used in malicious operations that rapidly turned compromised cloud accounts into platforms for **cryptojacking** and broader resource abuse. Attackers leveraged valid IAM credentials to gain access without exploiting software flaws, then provisioned compute resources and manipulated cloud services to mine cryptocurrency while consuming victims’ infrastructure and budget. The activity highlights how leaked cloud credentials can enable fast, low-friction compromise across internet-facing environments, especially when keys are overprivileged or insufficiently monitored. Unit 42’s findings underscore that exposed IAM keys can support sustained unauthorized operations inside cloud tenants, making credential hygiene, least-privilege access, key rotation, and continuous monitoring of anomalous cloud activity critical defensive measures.
Jul 12, 2026
Truffle Security reported that more than **9,300 publicly exposed Amazon Web Services access keys** remained active and valid after being leaked between August 2022 and August 2026, highlighting a widespread cloud credential exposure problem. Across public sources, the researchers identified **64,024 unique AWS keys** and found that **88%** of a subset of **10,616** keys with complete credentials still successfully authenticated as of August 10. The leaked secrets included **526 root keys** and **242 IAM user keys** with **`AdministratorAccess`**, creating a path to full AWS account compromise. Researchers said the exposed credentials could allow attackers to steal or destroy data, take control of applications, establish persistence, and deploy cryptominers. **Hugging Face** was identified as the largest single source of leaked AWS keys in the dataset, while the persistence of valid credentials pointed to weak key rotation and poor credential hygiene across affected organizations. Truffle Security urged organizations to delete root access keys, rotate or revoke exposed credentials, review IAM key age and permissions, and enable AWS budget alerts to detect abuse.
Aug 24, 2026