768 leaked AWS keys show full admin rights still persist

At a glance

What this is: Truffle Security re-verified leaked AWS keys and found that 768 live corporate keys still had full control of AWS accounts, including root and AdministratorAccess credentials.

Why it matters: This matters because leaked non-human credentials can still translate directly into account takeover, so IAM teams need inventory, rotation, and offboarding controls that assume public exposure persists.

By the numbers:

• 768 of the live ones belong to a company and carry full control of its AWS account.

👉 Read Truffle Security's analysis of 768 leaked AWS keys with full admin rights

Context

AWS access keys are non-human credentials that authenticate workloads, scripts, and users to cloud services. In this dataset, leaked keys were not just present in public sources, they were still active, still enumerable, and in many cases still attached to privileged AWS access.

The governance problem is not simply secret leakage. It is the combination of long-lived credentials, weak rotation discipline, and privilege that survives after a key becomes public. For IAM and NHI teams, that means exposure has to be treated as an operational state, not a historical event.

Truffle Security's analysis also shows why cloud credential governance cannot rely on discovery alone. Once a leaked key remains valid, the organisation has to assume the account may already be reachable through standing permissions, contact metadata, or permissive trust paths.

Key questions

Q: What breaks when a leaked AWS key is still active?

A: When a leaked AWS key is still active, the compromise is no longer about disclosure alone. The credential becomes a live identity that can authenticate, enumerate permissions, and potentially take over the account. If that key is root or AdministratorAccess, the blast radius includes data access, infrastructure changes, and cost abuse before the owner even knows the leak exists.

Q: Why do leaked AWS keys with AdministratorAccess create such high risk?

A: They turn secret exposure into broad account control. AdministratorAccess lets a leaked IAM user change resources, policies, and trust relationships, so the compromise is not limited to one workload or one bucket. The same logic applies even faster when the leaked credential is a root key.

Q: What are the signs that leaked AWS keys are failing governance controls?

A: Long-lived keys, unchanged key age, and leaked principals that still authenticate are strong warning signs. If you also see AdministratorAccess, root usage, or no budget alarms, the organisation is already depending on detective controls after exposure instead of preventing usable access in the first place.

Q: How should security teams respond when AWS keys are exposed in public developer forums?

A: Security teams should treat any public secret exposure as an active compromise, not a theoretical risk. The immediate steps are to revoke or rotate the key, review cloud activity for misuse, and remove the exposed content if possible. Public forums can be scanned by attackers or opportunistic users within hours, so speed matters more than post-incident cleanup.

Technical breakdown

Why leaked AWS keys still create full account control

AWS access keys map directly to an IAM principal, so a valid key is not just a token, it is an entry point into whatever permissions the principal already has. If the principal is root, the key inherits the account itself. If the principal is an IAM user with AdministratorAccess, the key can create, delete, or reconfigure most cloud resources. That is why leaked keys remain dangerous even when they were first exposed years earlier. The security problem is not the leak alone, but the persistence of authority attached to the credential.

Practical implication: Treat every public AWS key as a live access path until the principal, not just the secret, is revoked or constrained.

Why key age and rotation history matter more than detection time

A leaked key can remain valid long after the original exposure because AWS does not expire access keys by default. In the article's dataset, many keys were years old and had never been rotated, which means discovery and remediation are separated by a large exposure window. The older the key, the more likely it has escaped ordinary lifecycle processes and accumulated forgotten privilege. Rotation is not only about hygiene. It is the control that shrinks the time between disclosure and usable compromise.

Practical implication: Set maximum age and replacement rules for access keys so that old credentials cannot remain indefinitely operational.

Why root keys and AdministratorAccess are the highest-risk pattern

Root keys cannot be scoped down, and AdministratorAccess on an IAM user effectively gives the same problem a different shape. Both turn a leaked credential into broad authority over the account, budgets, policies, and trust relationships. In a multi-account organisation, a root key on an organisation management account is worse because it can cascade into every member account. That is why privilege attached to the leaked principal is the real risk multiplier. Exposure becomes a governance failure when the key can still control billing, policy, or organisation structure.

Practical implication: Prioritise immediate removal of root access keys and any leaked principals with account-wide administrative policy attachment.

Threat narrative

Attacker objective: The attacker aims to obtain persistent, high-privilege control of a cloud account that can be used for theft, abuse, tampering, or broader organisational compromise.

1. Entry occurs when a publicly exposed AWS access key remains valid and can still authenticate against AWS services.
2. Credential access is achieved because the leaked key reveals a live IAM principal that can be enumerated for its attached permissions and trust paths.
3. Escalation and impact follow when that principal is root or has AdministratorAccess, giving the attacker account-wide control over resources, billing, or organisation-wide accounts.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Leaked cloud credentials are not a disclosure problem alone, they are an access problem. Once an AWS key is public and still valid, the organisation has already lost control of the credential lifecycle. The governance failure is that secret detection often runs faster than revocation and replacement, leaving a standing path into cloud resources. The practitioner conclusion is simple: leaked NHI credentials must be treated as active access until proven otherwise.

Root access keys are an anti-pattern, not a special case. A root key cannot be meaningfully scoped down, so its presence means the account can be fully controlled by a single leaked secret. The same is effectively true when an IAM user carries AdministratorAccess. This is not just privilege creep, it is a structural failure of entitlement design. The practitioner conclusion is to remove account-wide authority from reusable credentials wherever possible.

Ephemeral exposure is the wrong mental model for cloud key leakage. The median leaked key in this dataset was five years old, which means exposure can outlive the original incident by years. That breaks the assumption that a secret leak is quickly self-limiting. The practitioner conclusion is to govern access keys as durable lifecycle assets, not as disposable implementation details.

Identity blast radius is the right concept for leaked AWS keys. The key question is not whether a secret is secret, but how far the linked principal can move if it is used. Billing access, organisational control, and trust relationships all expand the blast radius beyond the initial secret. The practitioner conclusion is to rank remediation by reachable authority, not by where the leak was first found.

NHI-07 Long-Lived Secrets and NHI-05 Overprivileged NHI describe the same failure from two angles. A secret that survives for years and a principal that can administer the account are a compound risk, not separate issues. OWASP-NHI and NIST CSF access control both point to the same governance gap: standing privilege attached to durable credentials. The practitioner conclusion is to reduce both lifetime and scope together, or the control remains incomplete.

What this signals

Leaked AWS keys expose a governance gap, not just a secret management gap. When a public key can still authenticate, lifecycle controls have failed to keep pace with exposure. IAM teams should assume the remediation clock starts at publication, not at detection, because standing access remains usable until the principal is changed.

Identity blast radius is the more useful metric than leak count. A single root key or an IAM user with AdministratorAccess can be far more damaging than many low-privilege keys. Programme owners should therefore triage leaked credentials by reachable authority, trust scope, and account criticality, not by volume alone.

For practitioners

• Delete root access keys Find every root access key in every AWS account you own and remove it. A root key cannot be scoped down, so any live root credential should be treated as an account takeover path rather than a recoverable exception.
• Set a maximum access-key age Apply a hard age limit to IAM access keys and rotate before the limit is reached. Use key age as a governance metric, because leaked keys that survive for years indicate that rotation is not operating as a lifecycle control.
• Review leaked-key principals for account-wide privilege Prioritise any leaked key attached to AdministratorAccess, IAMFullAccess, or similar broad policy sets. The remediation target is the principal and its permissions, not just the secret value.
• Watch for AWSCompromisedKeyQuarantine Treat AWSCompromisedKeyQuarantine as confirmation that AWS believes the key is public and should be investigated as an active exposure. Do not wait for a secondary alert to validate the risk.
• Set budget alarms on every account Create low-threshold budget alerts on accounts that use access keys, including small or experimental environments. A live leaked key often shows up first as spend, not as a security alert.

Key takeaways

• Leaked AWS keys remain dangerous when they still authenticate, because exposure turns into active access rather than historical risk.
• The highest-risk pattern is a public key attached to root or AdministratorAccess, which can translate into full control of the AWS account.
• Teams need lifecycle controls for access keys, including age limits, rotation, and rapid revocation, because discovery alone does not reduce the blast radius.

Key terms

• Leaked Credentials Data: Leaked credentials data is the collected set of usernames, passwords, hashes, or account records found on the open web, dark web, paste sites, or in criminal data dumps. Security teams use it to estimate whether external credential leakage could translate into real account compromise.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
• Overprivileged Nhi: An overprivileged NHI is a service account, token, key, or other machine identity that has been granted more access than it needs to do its job. The risk is not theoretical. Excess scope increases blast radius, makes compromise more valuable to attackers, and slows containment when the identity is abused.

What's in the full report

Truffle Security's full article covers the operational detail this post intentionally leaves for the source:

• The full re-verification method used to enumerate AWS principal type, policy names, and account metadata without reading policy documents
• The breakdown of how many leaked keys were root, IAM user, or not classifiable at verification time
• The account-level findings on budgets, spend, and quarantine policy coverage across the leaked-key population
• The methodology notes on how public sources such as repositories, datasets, and container images were deduplicated

👉 Truffle Security's full article covers the re-verification method, privilege breakdown, and account-level exposure patterns.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.