When a credential leaks, the clock starts immediately. Attackers run automated scanners against public repositories, package registries, container images and paste sites: in Palo Alto Networks Unit 42's EleKtra-Leak research, an actor found and used AWS keys exposed on GitHub within five minutes. Yet many leaked secrets stay valid for months or years, because nobody knows who owns them, what depends on them or how to rotate them without breaking production. This playbook gives a repeatable response for leaked API keys, cloud access keys, tokens, passwords, certificates, SSH keys and OAuth grants: triage, contain, rotate, investigate, recover and prevent. It is written for security operations, platform teams and credential owners, and is designed to sit inside an incident response plan aligned to NIST SP 800-61 Rev. 3.
Key takeaways
- Assume a leaked secret has been used until logs prove otherwise, and investigate from the moment of exposure, not the moment of discovery.
- Revoke or disable first, then rotate. Deleting a commit, image or file does not invalidate the credential, and GitHub's own guidance says to revoke or rotate a secret before rewriting history.
- Speed depends on preparation: an inventory with owners, dependency maps, documented revocation steps per credential type and automated rotation.
- Investigate reach as well as use: what the credential could access, what it did access, and what persistence an attacker could have created with it.
- Every leak is a process gap. Fix the root cause, such as a missing vault, missing push protection or a static key that should be a federated, short-lived credential.
Where credentials leak
The OWASP Non-Human Identities Top 10 lists secret leakage as NHI2 and notes that detection is hard because secrets spread to developer endpoints, logs, configuration files, SaaS providers and cloud platforms. GitGuardian's State of Secrets Sprawl 2026 reports that about 28% of incidents it saw originated in collaboration and productivity tools rather than code repositories, and that internal repositories are six times more likely than public ones to contain hard-coded secrets (vendor figures).
| Source | Example | What to check |
|---|---|---|
| Source code and history | The GitLab Public Repositories Secrets Study 2025 found 17,430 verified live secrets; a Toyota T-Connect key was public for almost five years | All branches, forks and old commits, not just the current tree |
| Web servers | Exposed .git folders (Misconfigured Git Servers 2026) and .env files (230 Million AWS Cloud Environments Campaign 2024) | Files a web server can serve |
| Build and CI systems | The Codecov Breach 2021 sent CI environment variables to attackers | Logs, artefacts, runner environments, workflow secrets |
| Packages and images | The Docker Hub Secrets Leak 2025 and the Shai-Hulud npm Worm 2025 | Image layers, published package versions, publishing tokens |
| Collaboration and online tools | The JSONFormatter and CodeBeautify Leak 2025 | Tickets, chat, wikis, support cases, paste and formatter sites |
| Signed URLs and shared links | The Microsoft SAS Token Exposure 2023 granted full control of a storage account | Scope and expiry of every signed URL |
| Third parties | The Red Hat Consulting GitLab Breach 2025 exposed customer tokens in reports | Which suppliers hold which of your credentials |
| Endpoints | Infostealer malware on developer and admin machines | Browser stores, CLI credential files, IDE extensions |
Step 1: Triage (minutes)
SP 800-61 Rev. 3 maps triage to the CSF 2.0 outcomes RS.MA-02 (incident reports are triaged and validated) and RS.MA-03 (incidents are categorised and prioritised). For a leaked secret, triage should take minutes, not hours.
- Confirm it is live using the provider's safe verification method rather than exercising its privileges. GitHub validity checks show whether a detected GitHub token is active, and can be enabled for partner patterns on some plans. GitGuardian notes many critical secrets, such as passwords and private keys, cannot be validated automatically, so an unvalidated secret is not a safe one.
- Identify it: credential type, issuing system, account or tenant, and owner. If there is no known owner, escalate to the platform team for that system rather than waiting.
- Size the blast radius: what permissions and data it grants, whether it can create other credentials, roles or policies, and whether it is reused elsewhere.
- Record where and when it was exposed, and whether exposure was public or internal. The earliest possible exposure time sets the start of the investigation window.
- Set severity from privilege and exposure, using a matrix agreed in advance.
| Privilege of credential | Public exposure | Internal exposure |
|---|---|---|
| Admin, can create identities or keys, signing keys | Critical | High |
| Read or write access to sensitive data or production | High | Medium |
| Narrow scope, non-production, already expired | Medium | Low |
This matrix is an example to adapt. A credential that turns out to have been used moves straight to the highest severity in its row.
Step 2: Contain
Containment means making the credential useless, and that usually requires the issuing provider. The OWASP Secrets Management Cheat Sheet puts revocation first: exposed keys should be revoked immediately, and systems must be able to show revocation status.
| Credential | Containment action |
|---|---|
| AWS access key | Deactivate the key (AWS advises deactivating before deleting, so it can be restored if something breaks); check for the AWSCompromisedKeyQuarantineV2 policy AWS may attach; revoke role temporary credentials; remove identities, keys and policies created with it |
| Google Cloud service account key or token | Disable the old key; to block tokens already issued, disable the service account or apply an IAM deny policy, because Google says service account access tokens cannot be revoked and last up to 60 minutes by default, or 12 hours with an extended lifetime |
| Microsoft Entra user or app credential | Disable the account, revoke sessions and refresh tokens, and remember that applications issue their own session tokens that Entra ID revocation may not end |
| SaaS or API key | Revoke in the provider's console; restrict by IP where supported |
| OAuth access and refresh tokens | Revoke the grant, revoke refresh tokens and disable the OAuth app if it is compromised. See the SaaS and OAuth App Governance Guide |
| Personal access token (GitHub, GitLab, npm, PyPI) | Revoke the token; check for new tokens, SSH keys, deploy keys, workflows or package versions created with it |
| Password (service account or user) | Reset, revoke sessions and refresh tokens, check MFA registrations |
| Private key or certificate | Revoke the certificate and issue a new key pair; for signing keys, assess what was signed. See the Cryptographic Key Management Guide |
| SSH private key | Remove the public key from every authorized_keys file and revoke any SSH certificates. See the SSH Key Management Guide |
| Session cookies and tokens | Revoke sessions for the affected accounts. See the Token and Session Security Guide |
Removing the secret from the repository, image or page is still worth doing to stop reuse, but it is not containment. The credential stays valid until revoked, and copies already exist: in the Docker Hub study, Flare found that in most cases the credential itself was not revoked, even where the secret was removed from the image.
Step 3: Rotate and restore service
Google's guidance summarises the safe order: generate a new credential, deploy it to everything that needs it, then revoke the old one. When the credential is already being abused, revoke first and accept the outage, or use a deny policy to buy time.
- Issue a replacement with the minimum privilege actually needed, which is often less than the original.
- Deploy it through the vault or secrets manager rather than editing configuration by hand. See the Secrets Management Guide.
- Where possible, replace the static secret entirely with workload identity federation or short-lived credentials, which OWASP NHI2 lists as the first prevention. See the NHI Authentication Guide.
- Confirm dependent services are healthy, and watch for failed authentication from anything you missed: those failures map the consumers your inventory did not know about.
The Secrets Rotation Runbook Template gives a step-by-step format for planned and emergency rotation.
Step 4: Investigate
- Pull provider logs for the credential from the time of exposure (or earlier, if the exposure date is uncertain) to now: CloudTrail, Google Cloud audit logs, Entra sign-in logs, SaaS audit logs.
- Look for unfamiliar use: IP addresses, regions, user agents or tools. In EleKtra-Leak, Unit 42 saw more than 400 API calls across regions in seven minutes, run from behind a VPN.
- Look for persistence: new users, keys, roles, OAuth apps, SSH keys, webhooks, CI secrets, workflows or package versions. AWS tells customers to review CloudTrail for creation of access keys, policies, roles or temporary credentials.
- Look for data access and resource creation, such as compute for cryptomining or LLMjacking. See the LLMjacking Guide.
- Check reuse: whether the same secret, or secrets in the same file, were reused elsewhere.
- Preserve evidence before deleting attacker resources; AWS suggests snapshots where resources must be kept for investigation.
- Decide on notification duties for customers, partners and regulators with legal and privacy teams.
Step 5: Recover and close
- Remove any persistence found, and rotate anything the attacker could have reached with the leaked credential.
- Purge the secret from repository history, images and caches where practical. GitHub warns that rewritten history can return from old clones, and that forks keep the data unless their owners remove it.
- Update the credential's inventory record: confirmed owner, new expiry, new scope and consumers.
- Close with a timeline: exposure, detection, revocation, rotation and recovery times, and the root cause.
- Feed lessons learned into improvement; SP 800-61 Rev. 3 places this under the CSF Identify function's Improvement category.
Step 6: Prevent the next one
- Block before commit: GitHub push protection stops supported secrets reaching a repository, rather than alerting afterwards. Add pre-commit and IDE scanning, as the OWASP cheat sheet recommends.
- Scan beyond code: images, packages, CI logs, tickets, chat and wikis.
- Use provider auto-revocation: GitHub's partner programme sends secrets found in public repositories and npm packages to the issuing provider, and SP 800-61 Rev. 3 suggests authorising cloud providers to contain some incidents automatically.
- Vault and federate: move secrets into a vault, inject them at runtime, and replace long-lived secrets with short-lived, federated credentials.
- Owners for every NHI, so triage does not stall. See the NHI Ownership Guide.
- Canary tokens: deploy decoy credentials that alert when used, to catch leaks you do not know about.
Detection and monitoring
Detection has two sides: finding the leak, and finding use of the leaked credential.
| What to detect | Source | Reference |
|---|---|---|
| Secrets committed or pushed | Secret scanning, push protection, pre-commit hooks | OWASP NHI2 |
| Provider notice of an exposed key | Cloud provider abuse notices, partner programme alerts | AWS, GitHub |
| Credential files read by unusual processes (.env, ~/.aws/credentials, mounted secrets) | EDR and container telemetry | ATT&CK T1552.001 |
| Cloud API calls beyond normal scope, such as IAM changes or services never used before | CloudTrail, cloud audit logs | ATT&CK T1078.004 |
| Use of a key from new networks, regions or tools | Cloud and SaaS audit logs | ATT&CK T1078.004 |
| Canary token used | Deception platform alert | High-fidelity leak signal |
| Failed authentication after rotation | Application and provider logs | Missed consumer or attacker retry |
Route all of these to one queue with the credential's owner attached.
Roles and timings
| Role | Responsibility | Example target |
|---|---|---|
| Security operations | Detection, triage, severity, coordination and investigation | Triage within 15 minutes of a critical alert |
| Credential owner | Rotation, dependency knowledge and service recovery | Replacement deployed within 4 hours |
| Platform or cloud team | Revocation where the owner is unknown; log access; persistence checks | Public critical credential revoked within 1 hour |
| Supplier management | Revocation and rotation of credentials shared with or held by third parties | Supplier credentials listed within 1 day |
| Legal and privacy | Notification decisions | Within regulatory deadlines |
The targets are examples: agree your own in advance and measure every incident against them. The xAI API Key Leak 2025 shows why ownership matters: an automated alert reached the developer the same day, but the key stayed live for about two months.
Framework mapping
IDs were checked against NIST CSF 2.0, SP 800-61 Rev. 3, the NIST SP 800-53 Rev. 5 (release 5.2.0) catalogue, the ISO/IEC 27001:2022 Annex A control list, the CIS Controls v8.1 list and the OWASP NHI Top 10 2025. This is an NHI Mgmt Group alignment, not an official crosswalk.
| Playbook stage | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 |
|---|---|---|---|---|---|
| Inventory and owners | PR.AA-01 | IA-4, IA-5 | A.5.9, A.5.17 | 5, 6 | NHI1 |
| Plan and rehearse | RS.MA-01, ID.IM-04 | IR-3, IR-8 | A.5.24 | 17 | NHI2 |
| Triage and severity | RS.MA-02, RS.MA-03 | IR-4, IR-5 | A.5.25 | 17 | NHI2 |
| Contain (revoke) | RS.MI-01 | IR-4, AC-2(3) | A.5.26 | 5, 6, 17 | NHI2 |
| Rotate and eradicate | RS.MI-02 | IA-5 | A.5.17, A.5.26 | 5 | NHI7 |
| Investigate and preserve evidence | RS.AN-03, RS.AN-07 | AU-6, IR-4 | A.5.28, A.8.15 | 8 | No direct item |
| Notify | RS.CO-02, RS.CO-03 | IR-6 | A.5.5, A.5.26 | 17 | No direct item |
| Recover and learn | RC.RP-01, ID.IM-03 | IR-4, IR-8 | A.5.27 | 17 | No direct item |
| Prevent leaks in code and pipelines | PR.PS-06 | IA-5(7), SA-11 | A.8.4, A.8.28 | 16 | NHI2 |
| Detect leaks and misuse | DE.CM-03, DE.AE-02 | SI-4, AU-6 | A.8.16 | 8 | NHI2 |
| Suppliers holding credentials | GV.SC-08 | IR-4(10) | A.5.19, A.5.21 | 15 | NHI3 |
Common failure patterns
- Deleting instead of revoking: the file or commit is removed, the alert is closed and the key keeps working, as Flare found in most Docker Hub cases.
- "Unused" credentials left alone: in the Cloudflare Thanksgiving Breach 2023, a service token and three service account credentials from the Okta breach were not rotated because Cloudflare wrongly believed they were unused.
- Alerts that reach only the developer: notification is not revocation, as the xAI key showed.
- Prioritising only validated secrets: passwords, private keys and custom tokens often cannot be validated, so validation-only triage misses high-risk leaks, according to GitGuardian.
- Over-scoped, long-lived secrets: the Microsoft SAS token covered a whole storage account with full control, and Wiz says its expiry was extended to 2051.
- Investigating from discovery, not exposure: the Toyota key was public for almost five years, so the log window must start at first exposure, and missing logs must be stated as a limit.
- Forgetting supplier copies: after the Red Hat Consulting breach, Belgium's Centre for Cybersecurity told organisations to revoke and rotate everything shared with Red Hat.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Median time from exposure to detection | Coverage and speed of scanning | Down |
| Median time from detection to revocation, by severity | Containment speed | Down, within agreed targets |
| Median time from revocation to healthy service on the new credential | Rotation readiness | Down |
| Leaks closed by deletion without revocation | Process discipline | Down, to zero |
| Leaked credentials with no known owner at triage | Inventory quality | Down |
| Pushes blocked by push protection versus secrets found after commit | Shift-left effectiveness | Up |
| Replaced leaked secrets moved to federated or short-lived credentials | Root cause fixed | Up |
| Credential types with a tested revocation procedure | Playbook readiness | Up, to 100% |
Implementation roadmap
| Phase | Actions | Outcome |
|---|---|---|
| First 30 days | Write revocation steps for each credential type in use; agree the severity matrix and target times; enable secret scanning and push protection on all repositories; set up one alert queue; list credentials shared with suppliers | A leak can be triaged and contained the same day |
| Days 31 to 90 | Build the NHI inventory with owners and consumers; extend scanning to images, packages, CI logs, tickets and chat; enrol in provider auto-revocation where available; run a tabletop exercise on a public cloud key leak | Owners are known and the playbook has been rehearsed |
| Days 91 to 180 | Automate rotation through the vault; replace high-risk static keys with federated, short-lived credentials; deploy canary tokens; report the metrics above monthly | Leaks are rarer, shorter and cheaper to fix |
For cloud-specific steps, see the Cloud Credential Compromise Playbook.
Practitioner checklist
- Maintain an inventory of NHI credentials with owners, scopes, consumers and dependencies.
- Document how to revoke each credential type you use, including tokens that cannot be revoked directly, and test it.
- Agree a severity matrix and target times for triage, revocation and rotation.
- Revoke first, then rotate; never treat deleting the file or commit as containment.
- Investigate for use, persistence and data access from the earliest exposure date.
- Replace leaked static secrets with federated or short-lived credentials where possible.
- Scan code, images, packages, logs and collaboration tools, with push protection on every repository.
- Enrol in provider auto-revocation and secret scanning partner programmes where available.
- List credentials held by suppliers and rotate them when a supplier is breached.
- Track time to detect, revoke and rotate for every incident, and feed lessons into the plan.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- OWASP: Non-Human Identities Top 10, NHI2:2025 Secret Leakage
- OWASP: Secrets Management Cheat Sheet
- GitHub Docs: Secret scanning
- GitHub Docs: Push protection
- GitHub Docs: Removing sensitive data from a repository
- AWS: Resolve issues with unauthorized activity in AWS accounts
- Google Cloud: Respond to compromised Google Cloud credentials
- Microsoft: Revoke user access in an emergency in Microsoft Entra ID
- Palo Alto Networks Unit 42: CloudKeys in the Air, Tracking Malicious Operations of Exposed IAM Keys
- GitGuardian: The State of Secrets Sprawl 2026
Related NHI Mgmt Group resources: Secrets Management Guide · API Key Management Guide · Top 10 Secrets Management Mistakes · Incident Response Guide · ITDR Guide