"One of the best ways to lower your AWS bill by 99 percent or more is by not checking your keys into public GitHub repositories." That blunt observation sits at the head of a longer, darker catalog of what can go wrong when AWS credentials leak — and what an AWS "Quarantine Policy" may fail to stop.
Truffle Security finding, reported by BleepingComputer: hundreds of leaked root keys remain active
BleepingComputer reported on a Truffle Security finding that hundreds of leaked AWS keys are root keys and are somehow still active and valid. The discovery revived a familiar but painful sequence: credentials exposed in public code repositories, attackers or researchers finding usable secrets, and cloud operators scrambling to contain damage.
AWS' quarantine policy: "limit the potential damage ... while not impacting the existing resources"
The source describes AWS' operational defensiveness. AWS' considered position on quarantining leaked credentials, as quoted in the report, is that it does not want to break customer environments: "The policy aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources." That trade-off — protecting availability of legitimate workloads at the cost of leaving many capabilities intact for an attacker — is the fulcrum of the critique.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleWhat a quarantine does not stop: a short list of dangerous allowances
The piece walks through, from the attacker's side, many concrete capabilities that remain if a credential is quarantined rather than fully revoked. The list is not presented as exhaustive, but it is specific and troubling:
- RDS can be used "to do anything I damn well feel like on RDS."
- ssm:SendCommand and ssm:StartSession are permitted, allowing commands to run as root on EC2 instances and to invoke instance role permissions.
- sts:AssumeRole remains allowed, enabling an attacker to assume other roles in the account and thereby negate many of the quarantine restrictions.
- autoscaling:CreateAutoScalingGroup and UpdateAutoScalingGroup are available, which can let an attacker launch instances using the Auto Scaling service-linked role so that ec2:RunInstances denies do not apply.
- CloudTrail read protections are uneven: cloudtrail:LookupEvents is denied, but cloudtrail:StopLogging and DeleteTrail are callable, removing the audit trail.
- SES actions are selective: ses:GetSendQuota and ListIdentities are denied, but SendEmail is not blocked — enabling spam or fraud delivery.
- SNS can be used to publish messages (sns:Publish) even if sms configuration reads are blocked (sns:GetSMSAttributes).
- S3 protections block s3:DeleteObject but permit s3:PutObject; an attacker can fill a bucket to petabytes.
- Object-protection APIs are available: s3:PutBucketVersioning, s3:PutObjectLockConfiguration, s3:PutObjectRetention, and s3:PutObjectLegalHold can be set to enable immutable retention. The report notes a bucket-default COMPLIANCE-mode retention can be set out to 2126 or applied per object; COMPLIANCE retention "can't be shortened or removed by anyone, including the account root and AWS Support," leaving deletion of the entire AWS account as the only escape.
- Secrets are exposed: secretsmanager:GetSecretValue, ssm:GetParameter* (WithDecryption), and kms:Decrypt are unencumbered.
- Backups and snapshots can be trashed: backup:DeleteRecoveryPoint, DeleteBackupVault, and rds:DeleteDBSnapshot are callable.
- CloudFormation cleanup is possible via cloudformation:DeleteStack, which would remove stacks.
What this means for technologists, affected enterprises, and adversaries
- Technologists and security teams: the report argues that quarantining credentials — rather than immediate revocation and forced rotation — leaves high-impact attack paths open (SSM, STS, RDS, S3 Object Lock, secrets access). Teams will need to assume that quarantine is an incomplete mitigation and plan rotation and containment accordingly.
- Affected enterprises and procurement leaders: the operational choice to avoid breaking "existing resources" can leave organizations exposed to data loss, account-level immutability changes, and the deletion of backups and stacks; buyers should evaluate how provider-side mitigations interact with incident response and contractual obligations.
- Adversaries and threat actors: the piece is explicit about the asymmetry. Even a restricted credential can be turned into stepped privileges or used to wreck backups, audit trails, and data retention settings — outcomes the author summarizes with a contemptuous "Hold my tea" before listing capabilities.
The author's demand and the unresolved choice for AWS
The author of the report models attack actions for about an hour and concludes that the current quarantine choices are "wrong." He writes, "I would make different choices" and asks AWS a pointed question: "how big of a customer incident needs to happen before you do?" That challenge frames the unresolved operational trade-off: preserve live customer workloads at the risk of enabling persistent and hard-to-reverse attacker actions, or accept disruption in order to remove a credential's potential for harm.
The specifics here are stark: a quarantined root key can be used to erase audit trails, excise backups, lock data into immutable retention, steal secrets, assume roles, and operate as root on instances. Until AWS changes the policy model or customers rotate and remediate leaked credentials, the report argues, quarantine is an incomplete defence — one that can leave the keys to the kingdom lying in plain sight.
Original story — The Register / BleepingComputer reporting on Truffle Security
