NHI Kill Chain: 8 Ways Your Credentials Are Already Compromised (And the One Fix That Addresses All of Them)

8 Ways You're Already Compromised

Over the past eight weeks, we dissected the NHI credential risks that hide inside organizations, one at a time. Each scenario was grounded in real incidents. Each one exposed a blind spot that security teams routinely miss. Now it's time to step back and see the full picture.

A departed developer's AWS key stayed active for 92 days. An infostealer on their personal laptop uploaded the credentials to a dark web marketplace. Production was compromised. Ghost Key.

During an incident response, a database password was shared across Slack, Confluence, and Jira. After the incident was resolved, nobody collected the credentials. Shadow Key.

A Terraform service account key went unrotated for three years. "If we rotate it, production goes down" was the only justification, and eventually it became the entry point for a supply chain attack. Aged Key.

A single Stripe API key was copied to 14 different services. Rotating it meant updating all 14 simultaneously. So nobody rotated it at all. Over-shared Key.

A GitHub secret scanning alert fired. The engineer marked it "Resolved." The file was deleted. But the key itself was never revoked. An attacker later extracted it from the git history. Zombie Key.

A single database password traversed 7 platform types, GitHub, Slack, Confluence, Jenkins, AWS Parameter Store, .env files, and Jira tickets. Detecting it in one platform still left it alive in six others. Drifted Key.

A .env file was pushed to a public GitHub repository. Attacker bots found it within 4 minutes. The first unauthorized API call came 12 minutes later. Public Key.

An audit of 3,400 secrets in one organization revealed that 60% had no identifiable owner. Who created them, which services they served, when they should be rotated, unknown. A key that nobody owns is a key that nobody manages, and a key that nobody manages is a key that eventually gets compromised. Unattributed Key.

Is there an organization where none of these apply?

The Verizon 2025 Data Breach Investigations Report found that credential exploitation was a factor in approximately 20% of all breaches analyzed. The IBM 2024 Cost of a Data Breach Report put the average cost of a data breach at $4.88 million, with stolen or compromised credentials as the most common initial attack vector. These numbers are not about NHI credentials specifically, but when NHI credentials outnumber human identities by 17 to 1, and the vast majority lack the lifecycle management that human identities receive, the attack surface implications are staggering.

This post is not about introducing a ninth threat. It is a meta-analysis: connecting all eight types, mapping them to the Cyber Kill Chain and MITRE ATT&CK, tracing their shared root causes, and delivering a governance framework that addresses all of them simultaneously.

The CRE Classification, Cremit's 8 NHI Risk Types

To systematically categorize these eight scenarios, Cremit developed the CRE (Credential Risk Enumeration) classification system. It is a framework designed to help security teams instantly identify the risk type of any discovered credential and apply the appropriate response procedure.

CRE | Type | Definition | Detection Criteria | Severity

CRE-001 | Ghost Key | Active credential of a departed employee | Owner inactive + key active | Critical

CRE-002 | Shadow Key | Credential exposed in non-code sources | Found in Slack/Jira/Confluence | High

CRE-003 | Aged Key | Long-unrotated credential | 90+ days without rotation | High

CRE-004 | Over-shared Key | Same secret duplicated across multiple sources | Same secret in 3+ locations | High

CRE-005 | Zombie Key | Valid credential in a deleted file | File deleted + key still valid | Medium

CRE-006 | Drifted Key | Credential spread across platform types | Present in 2+ platform types | Medium

CRE-007 | Public Key | Credential exposed in a public repository | Found in public repo | Critical

CRE-008 | Unattributed Key | Credential with no identifiable owner | Owner mapping impossible | High

The critical point about this classification is that a single credential can simultaneously belong to multiple types. A key created by a departed employee three years ago is both a Ghost Key and an Aged Key. If that same key was also shared in Slack, it's a Shadow Key as well. CRE types are not mutually exclusive categories, they are overlapping risk attributes. This overlap is precisely what makes the problem complex, and precisely why addressing each type with a separate tool fails.

The Attacker's Perspective: Cyber Kill Chain x MITRE ATT&CK Mapping

If the CRE classification defines risk types based on credential state, this section inverts the perspective entirely and views the same 8 types through the attacker's eyes. How does an attacker leverage each type across the 7 stages of the Lockheed Martin Cyber Kill Chain? Which MITRE ATT&CK tactics and techniques map to each exploitation?

Kill Chain 7 Stages x CRE Overlay

Kill Chain Stage | Attacker Action | CRE Types Leveraged | MITRE ATT&CK

Reconnaissance | Scanning public sources for credentials | Public Key (GitHub, Pastebin scanning) | T1593 Search Open Websites/Domains

Weaponization | Validating harvested credentials for attack readiness | Zombie Key (git history mining), Aged Key (long-term validity assured) | T1588 Obtain Capabilities

Delivery | Establishing credential acquisition channels | Ghost Key (dark web purchase), Shadow Key (non-code source access) | T1650 Acquire Access

Exploitation | Authenticating with valid credentials | Aged Key, Ghost Key, Public Key | T1078 Valid Accounts

Installation | Creating additional credentials, establishing backdoors | Unattributed Key (no owner = no detection) | T1136 Create Account

C2 (Command & Control) | Maintaining persistent access channels | Aged Key (never rotated = long-term use), Unattributed Key | T1078.004 Cloud Accounts

Actions on Objectives | Lateral movement, data exfiltration, further compromise | Over-shared Key (one key = N services), Drifted Key (cross-platform movement) | T1552 Unsecured Credentials, T1550 Use Alternate Auth Material

What this mapping reveals is clear. The 8 CRE types are not confined to specific Kill Chain stages. A Public Key is discovered during Reconnaissance but also used directly during Exploitation. An Aged Key assures validity during Weaponization, enables authentication during Exploitation, and maintains persistence during C2. A single type spans multiple stages, and a single stage involves multiple types.

Chained Attack Scenario: From One Public Key to Full Infrastructure

This is not theory. This is the kind of scenario that happens. A single attack progresses through the Kill Chain, exploiting multiple CRE types in sequence.

Stage 1, Reconnaissance. An attacker runs automated scanning on GitHub. A .env file is found committed to a public repository. Inside it: an AWS IAM access key. This is a Public Key (CRE-007). MITRE ATT&CK T1593.

Stage 2, Exploitation. The attacker runs sts:GetCallerIdentity to validate the key. It's active. They authenticate to AWS. The key was created 6 months ago and has never been rotated. It's a Public Key, but it's also an Aged Key (CRE-003). T1078 Valid Accounts.

Stage 3, Discovery. After authenticating, the attacker explores the internal environment. In AWS Systems Manager Parameter Store, they find a Slack webhook URL and a Confluence API token. These credentials also exist in non-code sources. The attacker searches internal Slack channels and Confluence pages, finding a database password shared during a previous incident response. Shadow Key (CRE-002). T1552 Unsecured Credentials.

Stage 4, Lateral Movement. The database password from Slack grants access to the production database. The same password also exists in Jenkins, .env files, and Jira tickets. A single credential traverses 7 platform types. Drifted Key (CRE-006). T1550 Use Alternate Auth Material.

Stage 5, Persistence. To avoid detection, the attacker leverages an existing service account with no owner mapping. They use this account to create a new IAM user and access key. There is nobody configured to receive alerts about this account's activity. Unattributed Key (CRE-008). T1136 Create Account.

Stage 6, Defense Evasion. The keys the attacker is using haven't been rotated in 3 years. Monitoring systems treat their activity as normal, because these keys have always been active, and the usage patterns don't appear to have changed. Aged Key (CRE-003). T1078.004 Cloud Accounts.

In this scenario, the attacker exploited 6 CRE types. The initial entry point required was exactly one, a .env file on GitHub. One Public Key ignited the entire Kill Chain, and at each stage, the absence of governance against another CRE type enabled the next step in the chain.

Defense Perspective: Where to Break the Chain

The core principle of the Kill Chain is straightforward: break any single stage, and the entire attack stops. CRE governance creates defense points at every stage of the Kill Chain.

Kill Chain Stage | Defensive Action | Corresponding CRE Governance

Reconnaissance Block | Remove credentials from public sources | Public Key scanning + immediate rotation

Delivery Block | Monitor non-code sources, revoke departed employees' keys | Ghost Key offboarding automation, Shadow Key detection

Exploitation Block | Eliminate long-lived credentials | Aged Key rotation policy, Zombie Key complete revocation

Lateral Movement Block | Isolate keys, enforce least privilege | Over-shared Key separation, Drifted Key unified management

Persistence Block | Map an owner to every key | Unattributed Key elimination

The most effective defense point is the Reconnaissance stage. If Public Keys are detected in real time and rotated immediately, the Kill Chain never starts. But defense must not depend on a single point. If an attacker bypasses Reconnaissance by purchasing credentials on the dark web (Ghost Key), you need to defend at the Delivery stage. If Delivery is breached, defend at Exploitation. If Exploitation is breached, defend at Lateral Movement. This is defense in depth, and it's the reason CRE governance creates defense points across the entire Kill Chain.

The Connection Map, One Creates Another

Treating the 8 CRE types as independent problems is a fundamental error. In practice, they trigger, reinforce, and amplify each other. A single credential simultaneously belonging to multiple types is not the exception, it's the default state.

Chain Pattern 1: From exposure to sprawl.

Public Key (public repository exposure) → if not immediately rotated → Aged Key (long-unrotated) → if multiple services reference the same key → Over-shared Key (multi-source duplication). A single exposure evolves into three types over time.

Chain Pattern 2: From departure to loss of control.

Ghost Key (departed employee's credential) → if no owner mapping exists → Unattributed Key (no identifiable owner) → if the same key persists in non-code sources → Shadow Key (non-code source exposure). One person's departure simultaneously activates three risk types.

Chain Pattern 3: From deletion fallacy to cross-platform sprawl.

Zombie Key (file deleted but key still valid) → if the key persists in git history and someone copies it to another platform → Drifted Key (cross-platform spread) → if found in 3+ locations → Over-shared Key (multi-source duplication).

Chain Pattern 4: Reverse, a single governance failure creates multiple types simultaneously.

Missing owner mapping → cannot identify departed employees' keys (Ghost Key) + no one is responsible for rotating keys (Aged Key) + cannot even confirm keys exist (Unattributed Key). One root cause generates three or more types simultaneously.

The practical implication of these connections is clear. When you handle a single Public Key alert, you must simultaneously check whether that key is also an Over-shared Key, an Aged Key, or a Drifted Key. If you address only the Public Key aspect and ignore the rest, the same key will resurface as a different type. This is the structural reason why whack-a-mole remediation fails.

Root Cause Analysis, Why These 8 Types Keep Recurring

On the surface, the 8 CRE types appear to be distinct problems. Ghost Key is an offboarding problem. Aged Key is a rotation problem. Shadow Key is a monitoring problem. But when you trace each type to its root cause, they converge on 6 shared structural gaps.

Root Cause | Related Types | Explanation

Missing NHI owner mapping | Ghost, Unattributed, Aged | If you don't know who created a key, you can't revoke it upon departure (Ghost), the owner becomes unknown (Unattributed), and nobody is responsible for rotation (Aged)

No non-code source monitoring | Shadow, Drifted | Scanning only GitHub leaves credentials in Slack, Jira, and Confluence invisible

No credential lifecycle management | Aged, Zombie | Processes exist for creating keys but not for rotating or revoking them

No cross-platform visibility | Over-shared, Drifted, Shadow | Cannot determine how many locations hold the same secret or which platform types it traverses

"Deletion equals revocation" fallacy | Zombie, Public | Deleting a file or reverting a commit does not invalidate the key, it remains active until explicitly revoked

No HR-IAM integration | Ghost | HR knows the employee departed. IAM knows the service account exists. If these two systems aren't connected, Ghost Keys are not a risk, they're a certainty

The root causes with the broadest impact are "missing NHI owner mapping" and "no cross-platform visibility", each directly contributes to 3 types. Solving these two alone would eliminate or make detectable 5 of the 8 types.

The conclusion follows directly. Addressing individual types with individual tools is a losing strategy. Deploy a Ghost Key detection tool, an Aged Key rotation policy, a Shadow Key scanner separately, you need 8 tools, 8 policies, and 8 processes. Address the root causes instead, and a single framework handles all 8 types simultaneously.

This mirrors a pattern that security leaders already recognize from other domains. Vulnerability management evolved from patching individual CVEs to risk-based prioritization. Threat detection evolved from signature-based rules to behavioral analytics. NHI credential security needs the same evolution: from alert-by-alert remediation to governance-by-root-cause. The 6 root causes above are the starting point for that shift.

NHI Governance Framework, 4 Phases Starting Tomorrow

Root causes identified, now it's time for execution. Below is a phased approach that CISOs and security program managers can start tomorrow. Trying to do everything at once guarantees failure. The realistic path is to secure visibility first, eliminate immediate risks, build processes, and transition to continuous governance.

Phase 1: Establish Visibility (Weeks 1-2)

Everything starts with knowing the current state. If you don't know how many NHI credentials exist, where they are, and who created them, every subsequent action is guesswork.

Build a complete NHI credential inventory. Scan everywhere credentials can exist: GitHub repositories, CI/CD pipelines, cloud providers (AWS, GCP, Azure), SaaS integrations, internal tools. Attempt owner mapping for every credential. Extract creator information from CloudTrail, audit logs, and commit histories. Determine the percentage of keys where mapping is impossible. This is your Unattributed Key ratio, the most intuitive indicator of NHI security maturity.

According to CSA's 2026 State of NHI Security report, NHI credentials outnumber human identities by an average of 17 to 1. For a 100-person organization, that means 1,700+ NHI credentials may exist. Building security policy without knowing this number is planning a war without knowing the size of the opposing force.

Phase 2: Eliminate Immediate Risks (Weeks 2-4)

With visibility established, address the highest-risk types first. Priority is determined by severity and ease of exploitation.

First, conduct a comprehensive Ghost Key audit. Cross-reference HR's departed employee records with your NHI credential inventory. Check whether keys created or managed by departed employees are still active, and revoke them immediately upon discovery. This is why OWASP's NHI Top 10 ranks Improper Offboarding as the number-one risk.

Second, run Public Key scanning across all public repositories to identify exposed credentials, and rotate them immediately upon discovery. GitGuardian's 2025 State of Secrets Sprawl report found that over 90% of secrets exposed on GitHub were still valid 5 days after detection.

Third, identify all Aged Keys, credentials unrotated for 90+ days. Catalog them and begin rotation starting with the highest-risk items. Keys with high production dependencies should be handled through a dedicated process in Phase 3.

Phase 3: Build Processes (Months 1-3)

If Phases 1-2 clean up the current state, Phase 3 ensures new problems don't arise.

Mandate owner tagging at credential creation. Every new NHI credential must have an assigned owner at the moment of creation. Block ownerless key creation technically, or at minimum prohibit it by policy. This single measure stops the inflow of new Unattributed Keys.

Include NHI credential revocation in employee offboarding. When the HR event fires (employment termination), every NHI credential mapped to that employee should be enumerated, and a revocation or reassignment workflow should trigger automatically. This must be an automated workflow, not a manual checklist.

Deploy non-code source monitoring. Slack, Jira, Confluence, Notion, developers share credentials in places far beyond GitHub. Adding non-code source scanning dramatically expands detection coverage for Shadow Keys and Drifted Keys.

Establish and automate rotation policies. Define maximum credential lifetimes by type and implement automated rotation. For keys where automation isn't feasible, create alerting and manual rotation processes.

Phase 4: Continuous Governance (Ongoing)

With Phases 1-3 complete, transition to continuous operations.

Run cross-platform drift monitoring continuously. Receive immediate alerts when the same credential appears on a new platform. Detect Drifted Keys and Over-shared Keys in real time.

Operate a credential sprawl dashboard. Track core metrics in real time: total NHI credential count, distribution by type, Unattributed Key ratio, average credential age, rotation compliance rate.

Conduct quarterly NHI audits. Revalidate the complete inventory, update CRE classifications, and identify emerging risk patterns. Feed audit results back into the governance framework.

The timeline matters. Phase 1 delivers value within two weeks, you will know numbers you didn't know before, and that knowledge alone changes decision-making. Phase 2 eliminates the risks most likely to result in a breach in the next 90 days. Phase 3 closes the structural gaps that create new risks. Phase 4 ensures the organization doesn't regress. Each phase builds on the previous one, and each phase is independently valuable even if subsequent phases are delayed.

Self-Assessment Checklist, How Many Can Your Organization Check?

While reading this series, did you think "this doesn't apply to us"? The following 8 items will tell you. Each one directly corresponds to one of the 8 CRE types.

• [ ] Do you know the total number of NHI credentials in your organization?
• [ ] Is every credential mapped to an identifiable owner? (Unattributed Key)
• [ ] Do you have a process to revoke NHI credentials upon employee departure? (Ghost Key)
• [ ] Do you identify credentials that haven't been rotated in 90+ days? (Aged Key)
• [ ] Do you monitor secrets in non-code sources (Slack, Jira, Confluence)? (Shadow Key)
• [ ] Do you know how many locations hold each secret? (Over-shared Key)
• [ ] When a credential is deleted from a file, do you verify that the credential itself is revoked? (Zombie Key)
• [ ] Do you detect cross-platform credential drift? (Drifted Key)

If you checked 3 or fewer, at least one scenario from this series is happening inside your organization right now.

If you checked 4-5, you have basic visibility but are vulnerable to chain patterns. Detecting one type while missing connected types is highly likely.

If you checked 6-7, you're running a strong NHI security program. But that one unchecked box could be the attacker's entry point.

If you checked all 8, you have defenses against every scenario in this series. The next step is maintaining this state, governance is not a one-time project but an ongoing operation.

Cremit Argus, The Only Way to See the Full Picture

What happens when you try to address 8 CRE types with 8 separate tools? You deploy a Ghost Key detector, a Public Key scanner, an Aged Key monitor, a Shadow Key detector, each with its own dashboard, its own alert stream, its own process. Eight tools, eight dashboards, eight processes. And still no visibility into how the types connect. You discover too late that the Over-shared Key you remediated was also a Drifted Key.

Cremit Argus takes a fundamentally different approach. One platform detects, classifies, and tracks the connections across all 8 CRE types.

CRE classification-based automatic detection and categorization. Every discovered credential is automatically classified against the 8 types. When a single credential belongs to multiple types, Argus provides overlapping classification.

Cross-platform unified scanning. Not just code repositories. Slack, Jira, Confluence, CI/CD pipelines, cloud providers, Argus scans every surface where NHI credentials can exist. Shadow Keys and Drifted Keys are detected with the same level of visibility as code-based secrets.

Automatic owner inference and mapping. Cross-analyzing CloudTrail, audit logs, commit history, and organizational structure to automatically infer the owner of each credential. The goal is driving the Unattributed Key ratio as close to zero as possible.

NHI governance dashboard. Complete credential inventory, CRE type distribution, connection map, Unattributed Key ratio, rotation compliance rate, Kill Chain mapping, everything a CISO needs to assess NHI security posture on a single screen.

See how Argus gives you the full NHI credential picture at cremit.io.

Series Conclusion, 8 Paths, One Principle

Over eight weeks, we analyzed 8 types of NHI credential risk. Each post was an independent scenario, but as this summary has shown, the 8 types share root causes, trigger each other, and operate in cascading chains across the attacker's Kill Chain.

1. Ghost Key: The Departed Developer Whose AWS Key Still Clocks In Every Morning. An AWS key left active for 92 days after its creator's departure, sold on the dark web via infostealer malware.
2. Shadow Key: Quietly Hardcoded Right Next to the Secrets Manager. Credentials shared in Slack and Confluence during incident response, never collected afterward.
3. Aged Key: The Skeleton Key That Held Production Together for 3 Years. A key left unrotated for 3 years because "touching it brings production down", until it became a supply chain attack vector.
4. Over-shared Key: What Happens When 10 People Share a Single Slack Bot Token. A single key duplicated to 14 locations, making rotation effectively impossible.
5. Zombie Key: Deleting It from Code Doesn't Mean It's Dead. A file deleted, an alert resolved, but the key itself was never revoked, and an attacker extracted it from git history.
6. Drifted Key: When the CI/CD Bot Auto-Attaches a DB Password to Jira. A single credential traversing 7 platform types.
7. Public Key: What Happens 4 Minutes After a .env Hits GitHub. A credential found by attacker bots within 4 minutes of public repository exposure.
8. Unattributed Key: 60% of 3,400 Secrets Have No Known Owner. The structural risk of credentials that operate without owner mapping.

The conclusion of this series is simple. The starting point for NHI credential security is "map an owner to every NHI credential." Once owners are mapped, you can revoke upon departure (Ghost Key solved), assign rotation responsibility (Aged Key solved), ensure alert recipients exist (Unattributed Key solved), and gain awareness of credential existence (Shadow Key and Drifted Key detectable). One principle addresses multiple types simultaneously.

NHI credentials are invisible. What's invisible cannot be managed. What cannot be managed will eventually be compromised. Visibility comes first, owner mapping comes second, and continuous governance comes third. With these three in place, all 8 paths can be blocked.

Thank you for reading the series.

Cremit is an NHI security company. [Learn more at cremit.io](https://cremit.io)