# Hundreds of AWS Master Keys Are Sitting in the Open — and Attackers Know It
Forget the low-grade credential leaks. Researchers have turned up hundreds of AWS access keys with full administrative control over their respective corporate accounts — not scoped tokens, not read-only service credentials, but the keys to the kingdom. Whoever finds them can spin up infrastructure, drain S3 buckets, create backdoor IAM users, and delete everything on the way out.
The finding isn't theoretical. These keys are live, leaked, and in the wild.
## The Anatomy of a "Full Control" Leak
AWS access keys come in two flavors that matter here: scoped service credentials and root-equivalent administrative keys. The latter carry permissions that let a single API call touch every AWS service in an account — EC2, S3, RDS, IAM, Lambda, CloudTrail, all of it.
When a developer hardcodes a key like that into a .env file, a Docker image, a GitHub Actions workflow, or a public repository, they've handed an attacker more leverage than most corporate IT departments have over their own infrastructure. The blast radius isn't a compromised endpoint. It's a compromised cloud account.
Hundreds of these have leaked. The research suggests they're not legacy orphaned keys from dead projects, either — these represent active accounts where the keys still authenticate.
## How They End Up in the Open
The path from secure secret to public exposure is painfully well-worn. A developer commits a configuration file without stripping credentials. An npm package ships with a .env bundled by mistake. A Docker image gets pushed to a public registry with environment variables baked into an early layer. A CI/CD pipeline logs environment variables in plaintext. A Terraform state file lands in a public S3 bucket.
GitHub alone processes billions of commits. AWS and GitHub run a secret scanning partnership that catches some of these before damage is done — AWS gets notified of leaked keys and can auto-quarantine them. But the coverage isn't complete, it's not instant, and it doesn't touch GitLab, Bitbucket, public Docker registries, NPM, or any of the dozens of other surfaces where credentials leak quietly.
The attackers scanning for these keys are automated. Tools that scrape GitHub's event stream, parse public Docker layers, and crawl npm tarballs for credential patterns run continuously. The window between a key hitting a public surface and a scanner picking it up is measured in minutes, sometimes seconds.
## What Happens the Moment an Attacker Finds One
Incident responders who've worked AWS account compromises describe a consistent playbook that attackers execute in under an hour.
First: reconnaissance. iam:GetUser, sts:GetCallerIdentity, iam:ListAttachedUserPolicies — cheap API calls that confirm the scope of access without triggering obvious alerts. If the key has AdministratorAccess, the attacker knows immediately.
Second: persistence. A new IAM user, a new access key, a new console login profile — all created before anything destructive happens. Even if the original key gets rotated, the attacker has a backdoor.
Third: objectives. Cryptomining is common — EC2 spot instances in obscure regions racking up bills. Data exfiltration is common — S3 ListAllMyBuckets, then selective downloads of anything that looks valuable. Ransomware-style destruction is rare but documented — S3 versioning disabled, buckets deleted.
CloudTrail is the natural forensic trail, but attackers with full IAM permissions can disable logging, delete trails, or create so much noise in the logs that incident responders struggle to reconstruct the timeline.
## The Rotation Problem
Rotating AWS keys is trivially easy in principle. In practice, organizations discover that a key has propagated to eight different services, three external vendors, and a deployment pipeline nobody's touched in two years. Rotating it breaks something. So it doesn't get rotated. The key sits there, potentially leaked, while teams weigh the operational disruption of fixing the underlying architecture against the risk they're hoping doesn't materialize.
That calculus fails every time.
AWS IAM provides the tools to do this right: short-lived credentials via IAM Roles and STS, EC2 instance profiles, Lambda execution roles, and ECS task roles all eliminate the need for long-lived access keys entirely for workloads running inside AWS. For external integrations, OIDC federation with GitHub Actions and similar platforms means CI/CD pipelines can authenticate without storing a static key anywhere.
The architecture to avoid this problem exists and has been the AWS best-practice recommendation for years. The gap is adoption.
---
## HackWire Analysis
The "leaked credentials" story never really goes away, but this one deserves more attention than the typical breach-du-jour. A few things stand out.
The severity tier matters. Most credential leak stories involve scoped service keys — bad, but bounded. Full admin keys are categorically different. They don't just expose data; they expose the ability to destroy forensic evidence, create persistent access, and pivot to every service in the account. Organizations treating this as a "rotate and move on" problem are missing the point. When a full-admin key leaks and gets used, you're not cleaning up a compromised key — you're investigating a potential full account takeover where the attacker had time and capability to plant backdoors across the entire IAM structure.
The scale suggests systemic failure, not isolated mistakes. Hundreds of full-control keys in the wild isn't a developer education problem. It's an organizational controls problem. Companies that are genuinely serious about this have already removed the ability to create long-lived admin keys entirely — through SCPs (Service Control Policies) that block key creation for certain users, or through enforcing IAM Identity Center for all human access. If hundreds of these keys exist across real corporate accounts, those controls aren't in place.
The timing is significant. AWS's secret scanning partnership with GitHub is mature, and AWS has been aggressive about proactive notifications when keys appear in public repos. The fact that hundreds remain valid and functional suggests either (a) they're leaking through channels the partnership doesn't cover, (b) account owners are ignoring AWS alerts, or (c) both. Security teams should audit their AWS account email addresses — alerts about leaked credentials often go to an unmonitored alias.
For defenders: pull a report of all IAM users with long-lived access keys right now. Cross-reference against aws iam generate-credential-report. Any key older than 90 days that isn't on an approved exception list should be rotated immediately. Any key attached to a user with admin policies that isn't tied to a specific human should be replaced with an IAM Role.
The architecture to eliminate this problem wholesale is documented, mature, and not optional anymore.
— HackWire Editorial
---
## Related Coverage