Zombie credentials in subsidiary clouds expose NHI governance gaps

At a glance

What this is: This is a case study on a dormant subsidiary IAM key that turned into a live reconnaissance path after years without rotation.

Why it matters: It matters because IAM, PAM, and NHI teams still lose control of long-lived credentials in lower-visibility environments, where compromise can stay hidden until discovery activity begins.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Prophet's analysis of zombie credentials in subsidiary infrastructure

Context

Zombie credentials are dormant access keys, tokens, or accounts that still authenticate even though the business has forgotten them. In this case, a subsidiary AWS environment held a long-lived IAM user key that had not been rotated in four years, which made it available for attacker use once it was discovered.

The identity governance problem is familiar across NHI programmes: lower-visibility environments often outlive the controls that protect core production, and long-lived credentials create a standing path into cloud APIs. This incident is a typical example of what happens when access ownership, rotation discipline, and environment visibility drift apart.

Key questions

Q: What breaks when dormant IAM keys are left in subsidiary environments?

A: Dormant IAM keys become standing attack paths when they are not tied to a current owner, rotation schedule, or retirement process. In practice, they let an attacker authenticate as a forgotten identity, probe cloud APIs, and stay inside lower-visibility environments long enough to map what exists.

Q: Why do stored NHI credentials increase cloud compromise impact?

A: Because the credential becomes a standing ticket into cloud services until it is rotated or revoked. Attackers can create resources, access data, and establish persistence before defenders notice, which turns one exposed secret into spend, data loss, and recovery work. The longer the secret lives, the larger the blast radius.

Q: How can security teams tell a compromised cloud identity from normal admin activity?

A: Look for context that does not fit the identity’s history, such as a new geography, a rare user agent, or API calls the identity has never made before. No single signal is enough, but the combination often turns weak telemetry into a strong compromise indicator.

Q: Who is accountable when stale access is not revoked?

A: Accountability sits with the identity governance owner, the application owner, and the access approver if the organisation has no clear offboarding or recertification path. Access control policy is only effective when revocation responsibilities are defined and measurable. Without that, stale access survives because no one is assigned to remove it.

Technical breakdown

How dormant IAM keys become active attack surfaces

An IAM access key can remain technically valid long after the original purpose disappears. If the key is not tied to lifecycle ownership, rotation, or usage monitoring, it becomes a latent authenticator rather than a managed identity asset. In subsidiary or legacy environments, that latency is dangerous because the account may still reach cloud control-plane APIs even when no one actively uses it. Attackers look for these forgotten credentials because they often sit outside routine review cycles and can be activated without triggering the normal developer workflows that defenders expect.

Practical implication: inventory dormant keys by last use and owner, then revoke or reissue any credential that lacks a current business purpose.

Why reconnaissance from cloud APIs is a high-signal NHI abuse pattern

The article’s attack sequence focused on discovery calls such as ListBuckets and CloudFront enumeration. Those actions do not need elevated privileges to be suspicious because they reveal attacker intent before exfiltration begins. In NHI cases, reconnaissance is often the first visible stage of credential abuse, especially when the actor starts with valid but stale access. Behavioural context matters here: geography, user agent, and prior command history can separate normal admin activity from a compromised identity probing the environment.

Practical implication: treat cloud API discovery from unusual sources as a credential abuse event, not a benign permissions check.

How behavioural correlation turns weak signals into a true positive

Prophet’s account-level analysis combined three low-confidence signals into one stronger conclusion: an unfamiliar source location, a rare user agent, and a change in command history. That is the right analytic pattern for NHI monitoring because single indicators are often noisy, but the combination can expose misuse clearly. The technical lesson is that stale credentials are only one part of the problem. Detection quality depends on whether telemetry can connect identity history, session context, and API intent across tools such as SIEM, cloud audit logs, and threat intelligence enrichment.

Practical implication: correlate identity, network, and API telemetry so that unusual credential use is judged in context, not in isolation.

Threat narrative

Attacker objective: The attacker wanted to map the subsidiary cloud environment and identify data or services worth abusing next.

1. Entry occurred through a dormant IAM user access key that remained valid in subsidiary AWS infrastructure after years without rotation.
2. Escalation took the form of reconnaissance API calls, including bucket and distribution enumeration, which revealed attacker intent and probed the cloud attack surface.
3. Impact was limited because the attempted actions returned AccessDenied errors, but the same credential path could have enabled data discovery or exfiltration if privileges were broader.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

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

NHI Mgmt Group analysis

Zombie credential risk is a lifecycle failure, not just a detection problem. The core issue is that an access key can remain valid long after the business relationship, owner, or use case has ended. That means NHI governance failed before the attacker arrived, because the identity lifecycle was never closed. Practitioners should treat stale credentials as evidence of incomplete offboarding, not merely weak monitoring.

Subsidiary infrastructure creates identity blind spots that core IAM programmes often ignore. The incident happened in a lower-visibility AWS environment, which is exactly where governance assumptions tend to weaken. Core platforms usually get tighter review, while subsidiaries, sandboxes, and legacy development estates accumulate unmanaged keys. The implication is that identity assurance must be measured across the full estate, not only the crown jewels.

Zombie credential persistence is a standing privilege problem with a long tail. Once an NHI credential remains active for years, exposure is no longer measured in minutes or days but in the entire time the key was forgotten. That persistence widens the identity blast radius and turns routine discovery into a plausible prelude to exfiltration. Practitioners should interpret age, ownership, and last-use data as governance signals, not just inventory metadata.

Rare user-agent and location anomalies are useful because they expose intent before impact. The attacker’s third-party S3 browser and unfamiliar geography mattered because they showed manual exploration rather than legitimate system use. This is where behavioural analytics complement lifecycle controls: one reveals that a credential should not exist, the other reveals that it is being abused. Security teams need both if they want to catch compromise early.

Identity blast radius is the right concept for subsidiary NHI risk. A key in a peripheral account may look low value until it becomes the path to discovery, lateral movement, or data exposure. The practical lesson is that access scope alone does not define risk; visibility gaps and unused credentials define how far an attacker can move before anyone notices.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, including 46% confirmed and 26% suspected.
• The 52 NHI Breaches Analysis shows how dormant credentials, standing privilege, and missed offboarding combine into repeatable breach patterns.

What this signals

Zombie credential persistence: subsidiary accounts and legacy development estates often preserve access longer than the teams that created them, so governance has to follow the environment, not the org chart. That is why the NHI Lifecycle Management Guide matters for every programme that still relies on periodic review alone, because revocation has to be triggered by ownership change, not just calendar time.

The pattern also reinforces the broader warning in Ultimate Guide to NHIs , Why NHI Security Matters Now: unused credentials remain usable credentials. When organisations do not maintain full visibility across subsidiaries, dormant keys become the easiest route for attacker discovery and the hardest gap for analysts to notice until the API trail is already active.

For practitioners

• Audit dormant keys in subsidiary estates Review every non-production and subsidiary AWS account for access keys with no recent use, no named owner, or no current business justification. Revoke credentials that have survived multiple review cycles without evidence of active service use.
• Tie offboarding to credential retirement Make offboarding and environment decommissioning explicit triggers for key revocation, secret rotation, and account closure so that forgotten development identities do not remain valid indefinitely.
• Alert on reconnaissance from unusual contexts Create detections for bucket enumeration, distribution discovery, and similar control-plane probing when the source geography, user agent, or session pattern has not been seen for that identity before.
• Correlate identity history with API intent Join cloud audit logs, SIEM alerts, and enrichment data so analysts can see whether an identity’s present behaviour matches its recent history before accepting a benign explanation.
• Measure credential age as a governance risk Track how many live NHI credentials have exceeded their intended lifespan and tie that metric to remediation ownership across subsidiaries and legacy environments.

Key takeaways

• A forgotten IAM key in a subsidiary AWS account became a live reconnaissance path, proving that dormant NHIs can become attack infrastructure when lifecycle governance fails.
• The incident was contained because the suspicious key hit denied permissions, but the exposure window still showed how a stale credential can enable discovery before any broader compromise is visible.
• The control that would have mattered most was lifecycle retirement of the key, backed by visibility into subsidiaries and anomaly detection on unusual API behaviour.

Key terms

• Zombie Credential: A zombie credential is a valid secret, token, or access key that remains active after the business has stopped watching it. In NHI programmes, the danger is not only that it exists, but that no one can quickly explain why it still has authority or who is responsible for retiring it.
• 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.
• Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.

What's in the full article

Prophet's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step investigation logic for correlating a single GuardDuty alert with SIEM, cloud audit, and threat intelligence sources
• The complete evidence chain behind the unusual geography, rare user agent, and behavioural mismatch verdict
• The remediation sequence used to revoke the compromised key and clean up additional stale credentials in subsidiary infrastructure
• How Prophet's query trace and reviewable evidence helped analysts validate the investigation outcome

👉 The full Prophet post covers the investigation trace, API activity, and remediation steps in more detail.

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 programme maturity, it is worth exploring.