What This Alert Means.
This alert means material that appears to belong to you has been published outside your control. It may be a database export, a copy of source code, a configuration file or an API key. API keys and similar secrets (passwords, tokens and certificates your software uses to prove who it is) are the most urgent part, because anyone who reads them can use them.
Once a post is public, assume others have found it. Treat every secret in the leak as already in use by a stranger, even if you have seen no misuse yet. Then work out what else was exposed.
First 24 Hours.
Work in this order. Each step names who does it.
- SOC analyst Open the alert from the Brandefense dark web monitoring module and record the link, the date and what the post containsSave a copy of the evidence in a safe place before the post changes or disappears
- Security engineer Check whether the material is real and current, and list every secret in itLook for keys, passwords, tokens, certificates and connection strings
- IT admin Revoke and replace each exposed secret, starting with those that reach production or customer dataRevoke first, then issue a new one through your normal secrets process
- Developer Search all repositories, including history, for the same secrets and for other copiesDeleting a file does not remove it from version history
- Incident lead Decide how far the exposure goes: which systems, which records and which peopleWrite down what you know and what you do not know yet
- Legal Ask whether the leaked data triggers any notification dutyCheck with your legal counsel before you contact customers, partners or authorities
- Communications Prepare a holding statement and a short list of who may speakDo not confirm details until the facts are checked
Investigation Checklist.
Use this list to scope the leak. Tick each item and keep notes.
- Is this a database export, a code repository, or a configuration file?Each points to a different place to look
- Which secrets are inside, and what does each one open?Rank them by what an attacker could reach
- Do the records match your real customers, staff or partners?Some leaks hold fake or recycled data
- How recent is the newest record?This dates the leak and narrows the logs to check
- Which internal system, backup or vendor could have produced this copy?Check access logs for large exports and downloads
- Were any leaked keys used since the post date, from unknown addresses?Review the logs of each service the keys reach
- Did anyone push secrets to a public repository, a ticket or a chat?Scan with a secrets scanning tool across your history
- Do any new accounts, tokens or scheduled tasks exist that nobody can explain?Attackers can create these to stay in
- Is any third party's data in the leak?Ask your legal counsel whether your contracts say you must tell them
Containment And Removal.
You cannot pull material back once it is public, but you can make the secrets worthless and shorten how long the copy stays online. The OWASP secrets cheat sheet gives this order for exposed credentials: revoke, rotate, delete and log.
- Your own systems: revoke and replace the leaked secrets, force sign-outs, and delete the secrets from code history, build logs and chat.
- Paste or code hosting platform: use the platform's abuse or content removal form to report the post, naming the exact URL and explaining that it holds your private data.
- Hosting provider or registrar: if the files sit on a hosted site, send an abuse report to the host's abuse contact, and to the domain registrar if the host does not act.
- Search engines: ask the search provider to remove cached copies of the leaked URL.
- Third parties: tell cloud, payment and email vendors whose keys leaked, so they can watch for misuse on their side.
- Law enforcement or national CERT: for serious leaks, report to the national CERT. In Turkiye, USOM (usom.gov.tr) handles cyber incident reporting, and its services are moving to www.siberguvenlik.gov.tr.
- PreserveSave the evidence
- RevokeCancel every leaked secret
- RotateIssue new ones through a safe process
- ScopeFind what else was copied
- ReportPlatforms, vendors, counsel
Longer-Term Hardening.
Fix the habits that put secrets into code and data into exports.
- Keep secrets out of code. Store them in a central secrets manager and load them at run time.
- Rotate on a schedule. OWASP says to rotate secrets regularly so that stolen ones work only for a short time, and prefers automated rotation to manual.
- Detect early. OWASP recommends detecting secrets at the developer stage, for example in editors and pre-commit hooks.
- Audit use. Log who requested a secret, when it was used and failed attempts, so you can answer "was it used?" quickly next time.
- Limit data in exports. Restrict who can export databases, mask real data in test copies, and watch for large downloads.
- Prepare in advance. NCSC says that only one thing helps you deal well with a cyber incident: good preparation. NIST SP 800-61 Rev. 3 gives recommendations to help you prepare for and respond to incidents.
- Make repositories private by default and review who has access, including former staff and contractors.
How To Measure That It Worked.
Use checks you can show to someone else.
- Every leaked secret is revoked and replaced, with a log entry for each.
- No successful use of an old secret after the revoke time.
- Repository scans, including history, come back clean for the exposed values.
- The source of the leak is named and closed.
- The platform or host confirms the post is removed, and later alerts show no new copies.
- Counsel has recorded the notification decision.
Common Mistakes.
These mistakes leave the door open.
- Rotating one key and stopping. Leaks often hold several secrets. List them all.
- Removing the file from the latest commit only. The secret remains in history and in forks.
- Trusting the age of the post. Old posts can still hold live keys.
- Asking the poster to delete it. This may warn them and does not stop copies.
- Telling people before the facts are checked. Wrong statements are hard to correct.
- Skipping the log review. Without it you cannot say whether the secret was used.
Questions.
-
What should I do first if my API keys are leaked?
Revoke them, then issue new ones through your normal secrets process. OWASP lists the order as revoke, rotate, delete from exposed systems and log the details. Do this before you chase the post, because the leaked key works until you cancel it.
-
Is deleting a leaked repository or file enough?
No. Anyone may already have a copy, and the secret may remain in version history, forks and caches. Revoke and replace the secrets first. Then remove the post, and scan all history for the same values.
-
How do I find out if a leaked database is really mine?
Compare a sample of records with your own data, check field names and dates against your systems, and look for the newest record to date the leak. Some leaks are old or recycled, so confirm before you announce anything. Ask counsel what notice applies.
-
How can I scan my repositories for leaked secrets?
Run a secrets scanning tool over every repository, including full commit history, and check forks and other copies. OWASP also recommends detection at the developer stage, such as in editors and pre-commit hooks, so new secrets are caught before they are pushed.
-
Do I have to notify anyone about a data leak?
That depends on what data was in it, where the people live and your contracts. Do not guess. Check with your legal counsel, who can tell you whether customers, partners or authorities must be told and by when.
Sources
This page is general security guidance. It is not legal advice. Notification duties and takedown rights depend on your country, your contracts and the facts of the case, so ask your legal counsel before you act on them.