Amazon Web Services' quarantine policy for leaked credentials contains critical gaps that permit attackers wide-ranging access to customer accounts, according to a security analysis published Friday by The Register. The analysis, which builds on a Truffle Security discovery that hundreds of exposed AWS keys remain active root credentials, examines the policy AWS applies when credentials leak to public repositories like GitHub. AWS says the policy aims to block fraud-driven unauthorized charges while preserving existing customer resources, but the analysis demonstrates this approach leaves accounts exposed to destruction and data theft.
The quarantine policy blocks specific high-risk actions but permits numerous attack vectors that can compromise entire AWS environments. Attackers with quarantined credentials retain unfettered access to RDS database operations, can execute commands as root on EC2 instances through permitted SSM actions, and can assume any role in the account via sts:AssumeRole, rendering the entire restriction list potentially irrelevant. The policy fails to block critical destructive actions including cloudtrail:StopLogging and DeleteTrail, which eliminate audit logs entirely. Email spam remains possible because ses:SendEmail goes unrestricted despite blocks on quota checks, and fraudulent SMS messages can be sent through sns:Publish even though configuration retrieval is denied. While s3:DeleteObject is blocked, attackers can enable versioning and apply COMPLIANCE-mode object retention extending to 2126, which cannot be shortened or removed by anyone including the account root user or AWS Support—the only remedy is deleting the entire AWS account. Critical backup deletion commands including backup:DeleteRecoveryPoint, backup:DeleteBackupVault, and rds:DeleteDBSnapshot remain unblocked, and cloudformation:DeleteStack goes unmentioned, permitting removal of all infrastructure stacks.
The analysis emphasizes that AWS Security's rationale for the limited quarantine approach—avoiding disruption to customer workloads—is fundamentally flawed. The report notes that deactivating leaked credentials will indeed break workloads relying on them until rotation occurs, which AWS considers unacceptable. But the analysis warns, "I promise you, as a bad actor, I can do far worse to you." The enumerated vulnerabilities demonstrate that quarantined credentials still permit filling S3 buckets to petabytes, accessing secrets through unencumbered secretsmanager:GetSecretValue and kms:Decrypt permissions, and launching instances through Auto Scaling to bypass EC2 restrictions entirely.
The analysis presents these exploits as an incomplete inventory compiled in roughly one hour and suggests actual malicious actors would identify far more attack paths. The report directly challenges AWS with a pointed question: "how big of a customer incident needs to happen before you do?" The analysis indicates AWS will almost certainly revise the policy in response to these findings, but frames the current approach as prioritizing convenience over security in ways that expose customers to catastrophic risk including permanent data lockout and complete infrastructure destruction. For enterprises managing cloud infrastructure, the tension between operational continuity and absolute security presents uncomfortable choices that technical safeguards alone cannot resolve. The expectation that protective measures will actually protect carries assumptions that merit regular interrogation rather than passive trust.