Exploited Vulnerability Breaches: Why Patching Is Not Enough When the Exploit Steals Credentials

When an attacker exploits a server, the patch closes the hole but not the access: keys, tokens and service account passwords read during the intrusion keep working until someone rotates them. This guide draws lessons from exploited vulnerability breaches in the NHI Mgmt Group breach database where the exploit was only the first step and the lasting damage came from machine credentials taken afterwards. It covers which credentials an exploited host typically gives up, how to scope what to rotate, in what order, and how to measure that the job is done. It is for vulnerability management, incident response and platform teams. The step by step incident template lives in the Zero-Day Exploitation Playbook; this page is the credential layer that sits on top of it.

Key takeaways

• Exploits are a major entry route. 36 breaches in our database began with a vulnerability exploit, according to NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026, and many of them turned into credential incidents within hours.
• Patching does not revoke anything. In the SharePoint ToolShell intrusions, stolen ASP.NET machine keys let attackers forge trusted requests after the fix was installed, which is why CISA told defenders to rotate keys, patch, rotate again and restart IIS.
• The host's identity is the prize. Application service accounts, environment variables, configuration files, registry hives and build server tokens are what attackers read first, because those credentials work from anywhere.
• Scope rotation by reachability, not by evidence of theft. If a vulnerable instance was exposed while exploitation was known, treat every secret it could read as exposed, even when logs cannot prove exfiltration.
• Design so the next exploit yields less. Short-lived workload identities, secrets fetched at runtime, signing keys in HSMs and tight egress rules shrink what any future exploit can steal.

Why exploited vulnerability breaches become NHI breaches

An exploited internet-facing application (ATT&CK T1190) runs attacker code with the identity of the process. That process was built to talk to databases, cloud APIs, mail relays and other servers, so it holds the credentials to do it. Once attackers have code execution they move from the vulnerability to the credential: reading files and environment variables (T1552.001 Credentials In Files), private keys (T1552.004), the local SAM and LSA secrets (T1003.002), and Kerberos material (T1558). With those in hand, they forge web credentials (T1606) or simply log in as valid accounts (T1078), which looks like normal traffic.

This shift matters for response. Vulnerability management measures time to patch. Incident response measures time to contain. Neither, on its own, measures time to revoke the machine credentials the exploited host held, and that is the gap the breaches below share.

Five breaches and what each one teaches

These cases were chosen because the lesson is on the customer side: what defenders running the product could have rotated, isolated or detected. Each is linked to its full analysis page.

KEV dates are from the CISA Known Exploited Vulnerabilities catalogue. In the Langflow case, the analysis notes that the specific secrets taken from specific servers were not confirmed; the lesson is about what the process could read, which is exactly how rotation should be scoped. A sixth case shows the same pattern outside classic enterprise software: in ShadowRay 2024, exposed Ray AI clusters gave up cloud keys, AI API tokens and database credentials. The underlying CVE is disputed by the maintainer, who says Ray must only run on trusted networks, which makes the lesson about exposure and credential placement rather than patching.

What an exploited host gives up: a credential inventory

Before rotation can be scoped, the team needs to know what credentials a given class of server holds. This table is a starting inventory by server role. Build your own per application and keep it with the asset record so it is ready before the next advisory lands.

Edge devices have their own investigation steps, covered in the Edge Device Compromise Investigation Playbook. Configuration-file keys of the ASP.NET kind are covered in depth in the ASP.NET Machine Key Exposure guide.

How to scope what to rotate

The question after a known exploited vulnerability is rarely "was this credential stolen?" because logs seldom answer it. The better question is "could the exploited process have read it?" We recommend (NHI Mgmt Group guidance) using three tiers.

The exploitation start date is often weeks before public disclosure. In the Oracle E-Business Suite case, Google Threat Intelligence Group reported suspicious traffic from 10 July 2025, which it could not confirm as exploitation, and likely zero-day exploitation from 9 August 2025, while the patch came on 4 October. A server patched on day one of disclosure could still sit in tier 1 or 2.

Rotation order: why the sequence matters

Rotating a key while the attacker still has code execution simply hands them the new key. CISA's ToolShell guidance spells out the order: rotate the ASP.NET machine keys, apply the update, rotate the keys again, then restart IIS, removing malicious module entries from applicationHost.config and web.config before the restart so they do not reload. The general pattern for any exploited host:

1. Contain first: cut internet exposure or block egress so the attacker cannot reach the host or receive anything new. Google's guidance for E-Business Suite stresses that blocking non-essential outbound traffic can disrupt an attack chain even on a compromised server.
2. Preserve evidence: capture memory where implants are in-memory, plus web server logs and configuration files, before anything is rebuilt.
3. Remove persistence: web shells, added modules, scheduled tasks and new local accounts. The joint TeamCity advisory AA23-347A describes scheduled tasks and forged Kerberos tickets used to hold access.
4. Patch or rebuild: from a known good image where compromise is confirmed.
5. Rotate after the host is clean: start with keys that let an attacker forge trust (machine keys, signing keys, token signing certificates), then credentials that reach other systems (cloud keys, database and service accounts), then local secrets. Where Kerberos tickets may have been forged, follow your directory's recovery process.
6. Revoke issued sessions and tokens: rotation of a secret does not always invalidate tokens already minted with it. Check each system's revocation behaviour.
7. Verify: confirm the old credential fails, watch for use of old values, and record the evidence.

Rotation at this scale is easier when it is already automated; see the Credential Rotation at Scale guide.

Prevention: making the next exploit yield less

• Take secrets out of the process environment: fetch them at runtime from a secrets manager with short leases rather than long-lived environment variables. See Environment Variables and .env Files.
• Prefer workload identity to static keys: a federated, short-lived token expires on its own; a static access key waits for someone to rotate it. See the Cloud Workload Identity Guide.
• Keep signing keys off application and build hosts: use an HSM or managed signing service so code execution on the host cannot export the key.
• Run application pools and service accounts with least privilege: the applmgr and IIS app pool examples show the account defines what an attacker inherits.
• Restrict egress from servers: default-deny outbound with allow lists stops many implants calling home and limits exfiltration.
• Keep admin and builder tools off the internet: CI servers, AI agent builders and cluster dashboards belong behind single sign-on, VPN or zero trust access.
• Prioritise known exploited flaws: use the KEV catalogue as a patching trigger; see the CISA KEV Catalogue Guide.

Detection and measurement

Detection should cover both the exploit stage and the later credential use, because the second often happens from attacker infrastructure far from the exploited host.

• Host signals: web server processes (w3wp.exe, java) spawning shells or PowerShell; reconnaissance commands such as printenv or whoami from application processes; registry hive exports; new scheduled tasks on servers.
• Credential use signals: service account or API key use from new IP ranges or regions; cloud API calls from a key outside its usual workload; spikes in AI provider spend; use of a credential after its rotation date.
• Configuration signals: new or changed files in web roots, new IIS modules, new database templates or stored code.

Metrics that show the programme works:

1. Time to revoke: hours from KEV listing or compromise confirmation to completed rotation of tier 1 and 2 credentials.
2. Rotation coverage: share of credentials in the server's inventory rotated and verified, target 100% for tier 1.
3. Static secret ratio: share of internet-facing applications that still hold long-lived secrets in files or environment variables.
4. Post-rotation use: count of authentication attempts with retired credentials, which should trend to zero and each be investigated.
5. Exposure count: admin, build and AI tooling interfaces reachable from the internet.

Framework mapping

NIST SP 800-61 Rev. 3, published in April 2025, frames incident response as a CSF 2.0 Community Profile, which is the right place to write credential rotation into your response plan.

Common failure patterns

• Patch and close: the ticket closes when the update is installed, with no rotation. The ToolShell intrusions are the clearest example of why stolen keys keep working.
• Rotating before cleaning: new keys are generated while a web shell is still present, and the attacker reads those too.
• Forgetting the build server's reach: a CI server is treated as one host when its tokens reach repositories, registries and production, as the TeamCity advisory warned.
• Waiting for proof of theft: rotation is held back because logs do not show exfiltration, even though the exposure window covered known exploitation.
• Unowned AI tooling: agent builders and clusters deployed outside change control carry production keys and never reach the patch list, as in Langflow.
• Trusting shared vendor keys: hard-coded or default keys are left in place after upgrade, as the Gladinet case shows.

Practitioner checklist

• Keep a credential inventory per internet-facing application: what it holds, where, and who owns rotation.
• Add a "credentials exposed?" decision with the three tiers to your KEV and zero-day response process.
• Write the rotation order (contain, preserve, remove persistence, patch, rotate, revoke, verify) into runbooks.
• Rotate machine and signing keys after any confirmed or likely exploitation of a host that holds them.
• Move secrets out of environment variables and config files into runtime retrieval with short leases.
• Replace static cloud keys on servers with workload identity where the platform supports it.
• Default-deny egress from application and build servers.
• Alert on use of retired credentials and on application processes spawning shells.
• Track time to revoke alongside time to patch and report both.

Standards and references

• CISA: UPDATE: Microsoft Releases Guidance on Exploitation of SharePoint Vulnerabilities
• CISA, FBI, NSA and partners: Russian Foreign Intelligence Service (SVR) Exploiting JetBrains TeamCity CVE Globally (AA23-347A)
• CISA: Known Exploited Vulnerabilities Catalog
• Google Threat Intelligence Group: Oracle E-Business Suite Zero-Day Exploited in CL0P Extortion Campaign
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• MITRE ATT&CK: T1190 Exploit Public-Facing Application
• MITRE ATT&CK: T1552 Unsecured Credentials

Related NHI Mgmt Group resources: Zero-Day Exploitation Playbook · Stolen credential breaches · Leaked secret breaches · Zero-Day and Exploited Vulnerabilities Guide