Exposed AWS configuration files expose NHI access and lateral movement

At a glance

What this is: This is a vendor analysis of how exposed AWS configuration files and .env content can leak NHI credentials and enable privilege escalation, lateral movement, and extortion.

Why it matters: It matters because IAM, PAM, and NHI programmes often treat secret discovery as the end state, when the real control problem is context, privilege scope, and offboarding of exposed machine identities.

Context

AWS configuration files such as .env files often hold environment variables that applications need to run, but they also become a secret store when teams place access keys, database credentials, and API tokens inside them. When those files are exposed, the security issue is not just disclosure; it is the transfer of machine identity context that lets an attacker act as the workload.

In this case, the critical failure was not the existence of AWS credentials alone. It was the combination of exposed secrets, weak privilege scoping, and missing identity context around which service owned the secret, what it could do, and how fast it could be revoked without breaking production.

For IAM teams, this is a governance problem as much as a detection problem. Exposed configuration files turn secret hygiene into an operational identity lifecycle issue because the blast radius depends on whether the credential is standing, reusable, and mapped to a live workload.

Key questions

Q: What breaks when AWS configuration files expose access keys?

A: When AWS configuration files expose access keys, the attacker inherits the workload’s identity and can often authenticate without triggering traditional login controls. If the credential is over-privileged, the incident quickly moves from exposure to escalation, lateral movement, and data theft. Treat the file as an identity-bearing object, not just a configuration artifact.

Q: Why do leaked AWS credentials often lead to privilege escalation?

A: Leaked AWS credentials lead to privilege escalation when they were issued with more permissions than the workload actually needs. A key that can create roles, attach policies, or list broad cloud resources gives attackers a path from simple authentication to higher privilege without another exploit. Least privilege only works if the credential is tightly scoped from the start.

Q: What are the signs that cloud secret exposure is being exploited rather than merely discovered?

A: Signs of exploitation include rapid access after exposure, immediate key use from unexpected regions, unusual reconnaissance across related assets, and follow-on activity such as malware download, cryptomining, or credential probing. If a secret is present in code, buckets, or public services, teams should treat early access as evidence of active abuse and investigate surrounding identities, sessions, and infrastructure.

Q: How should teams respond when an AWS secret is exposed in a configuration file?

A: Teams should revoke or rotate the secret only after mapping its owner and dependent services, then confirm that the replacement credential is in use before deleting the old one. If the secret is already privileged, teams should also review for role creation, policy changes, and adjacent-service abuse so containment matches the actual blast radius.

Technical breakdown

How exposed .env files become an AWS access path

Configuration files are meant to carry runtime settings, but .env files frequently hold credentials because developers use them as a convenient injection point for applications. In AWS environments, that means access keys and secret pairs may be stored next to application variables and copied across repos, build systems, or hosting layers. Once a file is exposed, the attacker does not need to bypass authentication in the traditional sense. The secret itself becomes the authenticator, and if the credential is long-lived, the exposure window remains open until revocation or rotation closes it.

Practical implication: treat exposed configuration files as live credential exposure, not simple data leakage.

Why weak privilege scoping turns exposure into escalation

A leaked key is most dangerous when it was never right-sized for the workload that used it. If a service account or access key can create roles, attach policies, or enumerate buckets, the attacker can move from initial access to privilege escalation without needing a second exploit. In AWS, identity and permission boundaries matter because a single credential may reach many downstream services. The article's escalation path shows why least privilege is not just a design goal. It is the boundary that determines whether a leaked secret becomes a nuisance or a full environment compromise.

Practical implication: review permissions attached to workload credentials before an exposure event proves they are too broad.

How compromised AWS credentials support lateral movement and extortion

Once attackers can authenticate into private AWS accounts, they can use that foothold to scan for more secrets, provision functions, or access adjacent services such as email or storage. That is lateral movement through legitimate cloud APIs, not noisy malware behavior. The same access can support extortion by listing buckets, exfiltrating content, or dropping ransom notes after controlling the workload identity. This is why exposed NHI credentials are not isolated incidents. They often become a platform for follow-on abuse inside the cloud control plane and the services it governs.

Practical implication: monitor post-authentication behaviour across cloud services, not just the original secret exposure source.

Threat narrative

Attacker objective: The objective was to turn exposed AWS credentials into broader cloud access, data theft, and extortion leverage.

1. Entry occurred when attackers found access key and secret pairs in exposed .env files and used them to authenticate into private AWS accounts.
2. Escalation followed when some of those credentials were not properly right-sized, allowing attackers to create a new IAM role and attach admin policies.
3. Lateral movement and impact followed as privileged access was used to scan buckets, harvest more credentials, abuse adjacent services, and extort victims by listing data and leaving ransom notes.

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

Exposed AWS configuration files are now an identity governance problem, not just a secret-sprawl problem. The file is only the container. The real issue is that the credential inside it often carries workload identity context that can be reused outside the application that created it. That means secret discovery, ownership mapping, and revocation are one control plane, not separate tasks. Practitioners need to treat exposed configuration files as governed identity objects, not inert text artifacts.

Standing privilege turns secret exposure into an environment-wide event. The article's escalation path depends on credentials that could be used beyond their original purpose, including role creation and policy attachment. That is the failure mode: the access token was not bounded tightly enough to the workload that needed it. When a leaked key can shape additional privilege, blast radius becomes a property of entitlement design, not attacker skill. IAM teams should read this as a test of permission architecture, not just monitoring coverage.

Ephemeral secret rotation without identity context is not enough. The post makes clear that rotation only works safely when teams know what depends on the secret, who owns it, and how to replace it without breaking the application. That makes context mapping a prerequisite to action, not an optional enrichment layer. In practice, NHI programmes need a complete inventory of which secrets back which services before they can close exposure windows with confidence.

Identity blast radius is the more useful concept here than credential hygiene. The campaign shows that one exposed file can become multiple failures at once: initial access, escalation, adjacent service abuse, and extortion. The control question is not whether secrets exist, because they do. The question is how much of the cloud estate can be reached once one secret is exposed. Practitioners should use this incident to re-evaluate their assumptions about contained risk.

Comprehensive NHI governance now sits at the intersection of detection, ownership, and revocation. Exposed credentials are only actionable if the organisation can find them, understand them, and safely remove them from use. That requires the same lifecycle discipline applied to human identities, but at machine speed and cloud scale. Security teams that still treat workload secrets as a narrow engineering issue will continue to miss the governance gap the article exposes.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Leaked Credential and Secret Incident Response Playbook

What this signals

Exposed configuration files are a governance failure because they collapse discovery, ownership, and privilege into a single incident. The practical question for IAM and NHI teams is no longer whether secrets exist in code-adjacent files. It is whether every exposed secret can be traced to a live owner fast enough to revoke it before an attacker turns it into durable access.

Identity blast radius is the concept practitioners should use to prioritise remediation. A leaked AWS key is not equally dangerous in every case. The deciding factor is what that key can reach, whether it can mint more privilege, and whether the organisation can rotate it without breaking the application. That is where governance, not just scanning, changes outcomes.

For practitioners

• Discover exposed configuration files continuously Scan repositories, object storage, build artefacts, and hosted assets for .env files and other configuration files that contain access keys, tokens, or certificates.
• Map each secret to a live owner Record which workload, service, or team depends on each secret so that you can revoke or replace it without losing application context.
• Right-size workload permissions Review whether exposed AWS credentials can create roles, attach policies, enumerate storage, or call adjacent services beyond their intended scope.
• Rotate with dependency validation Replace compromised secrets only after confirming that downstream consumers have migrated to the new credential and that the old one no longer authenticates.
• Watch for post-exposure cloud abuse Alert on role creation, policy attachment, bucket enumeration, and unexpected use of email or compute services after credential exposure is detected.

Key takeaways

• Exposed AWS configuration files can turn routine environment variables into live NHI access paths when keys, tokens, or certificates are left in plain text.
• The article's attack chain shows how one leaked credential can lead to escalation, bucket discovery, adjacent-service abuse, and extortion.
• The limiting control is not secret discovery alone but the ability to map ownership, right-size privilege, and rotate without losing application continuity.

Key terms

• Configuration File Secret Leakage: Configuration file secret leakage occurs when application settings files such as .env files contain access keys, tokens, or credentials that should never be broadly exposed. In NHI governance, the file is only the carrier; the real risk is that a reusable machine credential can be copied and abused outside its intended workload boundary.
• 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.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Identity Context Mapping: Identity context mapping links a secret or credential to the workload, service, or owner that depends on it. This is what turns secret discovery into actionable governance, because teams can determine whether rotation is safe, who must approve it, and what applications will fail if the credential changes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.