Leaked Credential Response
A credential leaked — an AWS access key, a GitHub token, a Stripe key, a database connection string. Pick what leaked and how, and this builds an ordered, provider-specific incident-response runbook: contain it, rotate it safely (new → verify → update consumers → then revoke), investigate abuse in the real audit logs, hunt for planted persistence, notify, and prevent a repeat. Track progress as you go, then copy or download the plain-text runbook. Everything runs in your browser — you never type the secret itself.
Runs entirely in your browser. You never enter the leaked secret itself — only its type and how it was exposed — and nothing is uploaded, logged or sent anywhere.
What this tool is
- A free, in-browser runbook builder for when a credential leaks: pick the credential type (AWS, GCP, Azure, GitHub, Stripe, OpenAI/Anthropic, a database connection string, or a generic API key) and optionally how it was exposed.
- Output is an ordered, provider-specific checklist across six phases: contain, rotate safely, investigate abuse, check for persistence, notify, and post-mortem / prevention.
- The rotation phase enforces the golden rule — generate the new credential, verify it works, update every consumer, and ONLY THEN revoke the old one. Never revoke-before-verify, or a leak becomes an outage.
- Every investigate step names the real log you check: AWS CloudTrail, GCP Cloud Audit Logs, the GitHub audit/security log, the Stripe Events log, the LLM provider Usage dashboard, or your database audit logs.
- Track progress with live checkboxes, then copy or download the whole thing as a plain-text runbook. You never type the secret itself, and nothing is uploaded, logged or sent anywhere.
What to do when a credential leaks
A leaked secret is a time-critical incident, and the instinct to immediately delete the key is usually the wrong first move. The right response follows a fixed order: contain the damage, rotate the credential safely, find out what the key already did, make sure the attacker left no way back in, notify the people who need to know, and close the gap that let it leak. This tool turns that order into a concrete, clickable checklist for the specific credential you lost.
The six phases
- 1 · Contain. Disable or limit the key without blindly breaking production — set an AWS key Inactive, delete an Entra client secret, tighten network access on a leaked database string. Buy time.
- 2 · Rotate safely. Generate the new credential, verify it works in every consumer, update them all, and only then revoke the old one. Never revoke-before-verify.
- 3 · Investigate abuse. Read the provider’s real logs — CloudTrail, Cloud Audit Logs, the GitHub audit log, the Stripe Events log — for calls you did not make, new resources and spend spikes.
- 4 · Check for persistence. New IAM users and keys, consented OAuth grants, new SSH keys, changed webhooks, new database roles — anything planted to survive the rotation.
- 5 · Notify. The provider’s support/abuse channel, and — if personal or customer data could have been touched — your internal breach process and the affected people.
- 6 · Post-mortem & prevention. Secret scanning with push protection, a secrets manager, short-lived credentials and least privilege, so the same key cannot leak the same way again.
The AWS crypto-mining scenario
The textbook case is an AWS access key committed to a public repository. Automated bots scrape public commits within minutes, and AWS itself detects the exposure and emails you — often attaching its AWSCompromisedKeyQuarantineV3 policy and, in bad cases, locking the account. You may log in to find thousands of blocked API calls and unexpected GPU instances spun up in regions you never use, mining cryptocurrency on your bill. The response is exactly the six-phase runbook: Inactive the key, rotate via a second IAM key, sweep CloudTrail and Cost Explorer across all regions, remove any new IAM users or keys, open an AWS Support case, and move to roles or STS so there is no long-lived key to leak next time.
The one rule that prevents a self-inflicted outage: rotate in the order new → verify → update → revoke. The most common way a credential leak becomes a second incident is revoking the old key before the replacement has been proven to work in every consumer. Use providers that allow two live credentials at once (AWS IAM keys, a rolled Stripe key, a second GCP key) to make the swap zero-downtime.
Frequently asked questions
My AWS access key leaked — what do I do first?
Do not panic-delete it. First set the exposed access key to Inactive in the IAM console (or with aws iam update-access-key --status Inactive) so you keep it for forensics but it can no longer be used. If AWS has already emailed you or locked the account, it has likely attached its AWSCompromisedKeyQuarantineV3 managed policy — leave that in place. If you see active abuse such as thousands of blocked API calls or unexpected EC2 instances, attach an explicit Deny policy to cap the blast radius. Then rotate: an IAM user can hold two access keys at once, so create a second key, roll it out and verify it everywhere, and only then delete the old one. Finally review CloudTrail across all regions and Cost Explorer for a spend spike, because exposed AWS keys are commonly abused for crypto-mining within minutes of a public leak.
Do I really need to rotate a key that only leaked in a private log or an old service?
Yes. An active credential is an active credential regardless of where it appeared or how obscure the service is. If it hit application or CI logs, assume everyone who can read those logs now has it. If it belonged to a deprecated service, "we do not use that anymore" is not containment — the key still works until you revoke it. The only safe assumption after any exposure is that the secret is compromised, so revoke and replace it. The cost of rotating a key you did not strictly need to is minutes; the cost of leaving a live leaked key is an incident.
What is the safe order to rotate a credential?
Generate the new credential first, deploy it to every consumer, make a real authenticated call to confirm the new one actually works, and ONLY THEN revoke or delete the old one. Revoking before the replacement is verified is the single most common way a credential leak turns into a self-inflicted outage — the old key dies, the new one was misconfigured, and production goes down. Where the provider allows two credentials at once (AWS IAM keys, rolling a Stripe key, a second GCP key), use that to make the rotation zero-downtime. For a shared database password, stage the change so you do not cut off every consumer at the same instant.
How do I tell whether a leaked key was actually abused?
Read the provider’s own activity and audit logs for the window since exposure, and compare against your normal baseline. For AWS that is CloudTrail event history (filtered to the access key ID) plus GuardDuty findings and Cost Explorer; for GCP it is Cloud Audit Logs and the billing reports; for Azure/Entra it is the sign-in and audit logs; for GitHub it is the org audit log or personal security log; for Stripe it is the Developers → Events and request logs; for an LLM provider it is the Usage dashboard; for a database it is your DB audit logs (pgAudit, the MySQL audit log, or the cloud provider’s DB auditing). You are looking for calls you did not make, new resources, spend spikes, and signs of bulk data reads.
After containing and rotating, what persistence should I check for?
Attackers who get a working credential often plant a way back in before you notice. Across providers, check for: new users, roles and access keys (a second AWS access key or a new admin IAM user is classic); new service accounts or app credentials; newly consented OAuth or API permissions; new SSH/GPG/deploy keys and authorized apps on GitHub; new or changed webhooks; changed payout or bank details on a payments provider; new database users, grants, triggers or scheduled jobs; and resources created in regions or projects you never use. Remove anything you did not create, then write a short post-mortem and add one concrete control — secret scanning with push protection, a secrets manager, short-lived credentials, least privilege — so the same path cannot leak the same way again.