Leaked Credentials
Leaked Credentials surfaces hardcoded secrets — passwords, API keys, tokens, connection strings, private keys — that ShadowMap's scanners extracted from source code in your public code repositories and decompiled mobile apps. Where a secret type can be validated, ShadowMap probes it against the live provider and tells you whether it is still active or already dead, so you can triage by real exploitability rather than guessing.
Overview
Each row is one detected secret. The page is built for triage at volume:
- A KPI strip at the top: Total Online, Investigating, Closed, and New This Week.
- An analytics panel (toggle in the header) with a 30-day detection trend, a status-distribution donut, and a top-rules bar chart — the donut and the bar chart are click-to-filter.
- Status tabs that split the queue by workflow disposition (Online, Reviewed, Investigating, To Be Closed, Closed) plus a Tested tab cut on the live-probe verdict.
- A table showing the originating asset (Source), the detection rule, the matched value, the probe status, and when it was last seen.
- A detail drawer with an Overview tab and a Probe Evidence tab carrying per-provider evidence and a probe-history timeline.
The matched value column shows the actual secret string that was found, so treat this page as sensitive. Access is gated behind the data-leaks.leaked-credentials permission.
How it works
These are the mechanics you cannot infer from the screen.
Where the data comes from
Leaked Credentials does not scan the open web for credential dumps — credentials exposed in third-party breaches and infostealer dumps are covered by the dark-web modules. This module is a code-secrets feed. Rows originate from two upstream ShadowMap surfaces:
| Source module | What's scanned | What links back to |
|---|---|---|
| Code Repositories (module 14) | Public Git repositories attributed to your organization | The exact repository + file path the secret was found in |
| Mobile Applications (module 15) | Decompiled APK/IPA artifacts of your published apps | The mobile app + file the secret was found in |
The underlying detection engine is a secret scanner (noseyparker-style rules). Each match carries a rule name — the pattern that fired (for example Credentials in ODBC Connection String, Google API Key, PEM-Encoded Private Key, Hashicorp Vault Service Token) — and a matched value, the literal string captured from the file. The Source cell links straight to the originating Code Repository or Mobile Application and shows the file path underneath, so you can jump from a leaked key to the line of code that exposed it.
Live-probe validation (Probe Status)
The hardest question with a leaked credential is "does it still work?" ShadowMap answers that with a live-probe layer (internally, the Zenitsu prober). For credential types that have a verifiable provider endpoint, the prober attempts a read-only validation against that provider and records a verdict. This is what the Probe Status column and the Probe Evidence drawer surface.
The verdicts you will see:
| Probe Status | Meaning | Badge |
|---|---|---|
| Live | The credential was confirmed to still authenticate against its provider. Highest urgency — rotate now. | Red |
| Dead | Confirmed no longer valid (rotated, revoked, or expired). | Grey |
| Active (decoded) | A leaked JWT whose payload decoded to an unexpired token. ShadowMap decodes the JWT offline (no signature check, no network call), so it cannot confirm the server still accepts it — but an unexpired leaked token is a live risk. | Amber |
| Expired | A leaked JWT whose decoded expiry is in the past. | Grey |
| Rate Limited | The provider rate-limited the validation attempt; verdict pending a retry. | Grey |
| No Validator | A prober for this credential type is configured but no validator was available for this row. | Grey |
| Probe Error | The validation attempt errored. | Grey |
| Inconclusive | The probe ran but could not return a definitive live/dead answer. | Amber |
| Not Probed | A probe is possible for this rule but has not run yet (pending). | Muted |
| Not Applicable | The secret type can never be externally validated by design — a generic password/secret/API key, a raw private key, or an internal vault token. There is no endpoint that could confirm it. | Grey |
Not Probed vs Not Applicable
These two look similar but mean different things. Not Probed means a verdict is still coming. Not Applicable means no verdict will ever come — the rule type (Generic Password, Generic Secret, Generic API Key, PEM/Base64-PEM private keys, Hashicorp Vault Service/Recovery tokens) is inherently unverifiable. Don't wait on a "Not Applicable" row; treat it on the merits of the secret itself.
Probes run asynchronously on their own cadence; a freshly detected credential typically shows Not Probed until the prober reaches it. The Last Probed time and the full per-attempt history are in the Probe Evidence drawer.
How rows enter, persist, and get hidden
A secret stays in the queue as long as it remains in your code surface — taking down or making a repository private does not remove the credential row, because the secret still leaked and must be rotated regardless. ShadowMap maintains a single is_suppressed flag per row to decide visibility, recomputed continuously from upstream disposition (a repository marked bad, a mobile app dispositioned) plus explicit analyst and automated false-positive judgments. The list, the KPI cards, the tab counts, and the analytics charts all read the same suppression-aware, company-scoped set, so they never disagree with each other.
Several classes of scanner noise are auto-suppressed before they reach you:
- Known boilerplate — localhost placeholder DSNs, test fixtures, the literal string
password, version strings, and similar library/SDK defaults. - Content false positives — for example a Hashicorp Vault rule misfiring on minified-JS accessor calls, or any Generic rule capturing the
ACRA-NULL-STRINGcrash-reporter sentinel.
These are intrinsic to the secret value, so they stay hidden even as repository disposition changes.
Understanding the data
Columns
| Column | Description |
|---|---|
| Source | The originating asset — a repository (with file path) or a mobile app (with file). Links to that asset. Falls back to the module name ("Code Repository" / "Mobile Application") when the exact asset can't be resolved. |
| Rule Name | The detection rule that fired, i.e. the kind of secret (ODBC connection string, Google API Key, private key, vault token, etc.). |
| Matching | The literal secret value captured from the file. Truncated in the table; full value in the drawer. Sensitive. |
| Probe Status | The live-probe verdict (see table above). |
| Last Seen | When the row was last updated by a scan. |
The Source, Rule Name, Matching, Probe Status, and Last Seen columns can be shown or hidden via the column customizer in the page header. Source is always visible and cannot be hidden. Columns are sortable except Probe Status.
Status tabs
The tabs split the queue by where each credential sits in your triage workflow. Status is set per row via the row's action menu or the bulk bar.
| Tab | What it contains |
|---|---|
| Online | Active, untriaged credentials. The default landing view and where new detections appear. |
| Reviewed | Credentials you've marked as reviewed (the analyst-facing label for the "False Positive" status). |
| Investigating | Credentials under active investigation. |
| To Be Closed | Triage finished; queued for closure. |
| Closed | Resolved — typically rotated/revoked and confirmed. |
| Tested | An orthogonal cut: every credential whose probe resolved to a definite verdict (Live, Dead, JWT Active, or JWT Expired), regardless of which workflow status it carries. Use it to jump straight to validated findings. |
Triage by exploitability first
Sort or filter the Online tab to Live probe status, or open the Tested tab, to put confirmed-working credentials at the top. A confirmed-live key in a public repo is an immediate rotation, not a backlog item.
KPI strip
| Card | Counts |
|---|---|
| Total Online | All credentials currently in the Online status. |
| Investigating | Credentials in the Investigating status. |
| Closed | Credentials in the Closed status. |
| New This Week | Online credentials first detected in the last 7 days. |
Each card is clickable and jumps the list to the matching view.
Analytics panel
Toggle the analytics panel from the page header. It renders three charts:
- 30-Day Detection Trend — new detections per day over the trailing 30 days.
- Status Distribution — a donut of the workflow-status split; clicking a slice opens that tab.
- Top Rule Names — the most frequent detection rules (top 10); clicking a bar filters the list to that rule.
The Status Distribution and Top Rule Names charts are click-to-filter; the detection trend is read-only.
Filtering & search
The filter bar supports the standard ShadowMap query builder (Add Filter) plus a free-text search across rule name and matched value. Available filter fields:
| Filter | Filters on |
|---|---|
| Module Name | The source module (Code Repository, Mobile Application). |
| Rule Name | The detection rule. |
| Probe Status | The derived live-probe verdict, including the "Not Probed" / "Not Applicable" buckets. |
| Probe Provider | The provider the credential was probed against. |
Additional controls in the filter bar:
- Bookmarked — toggle to show only credentials you've starred.
- Export — start an async export of the current view (see below).
- Free-text search box — matches against rule name and matched value.
You can also bookmark, tag, and comment on rows. Keyboard shortcuts speed up triage: j / k walk the list and open the drawer, Escape closes it, x toggles selection on the active row, and s bookmarks it.
Detail view
Click any row to open the detail drawer. Use the chevron buttons (or j / k) to move between rows without leaving it.
Overview tab shows the module, the linked source asset and file, the rule, the full matched value, and the current probe status and provider.
Probe Evidence tab shows the live-probe detail for the credential:
- Verdict and provider, and the Last Probed timestamp (or "Never").
- Evidence — the per-provider probe metadata (account ID, scope, decoded JWT claims such as subject/issuer/expiry, and other provider-specific fields), rendered as labeled values or pretty-printed JSON.
- Probe History — an append-only timeline of every probe attempt with its verdict and timestamp, so you can see when a credential flipped from live to dead.
Taking action
Open the per-row action menu (⋮) on any row:
| Action | Effect |
|---|---|
| Bookmark / Unbookmark | Star the credential for your own follow-up. |
| View Details | For a code-repository credential, opens that repository's overview in a new tab. |
| Set status: Online / Reviewed / Investigating / To Be Closed / Closed | Moves the credential through the triage workflow. |
| Mark False Positive | Permanently hides the row across every tab. |
Selecting rows (their checkboxes) brings up a bulk action bar, where Mark False Positive can be applied to the whole selection at once.
Mark False Positive is sticky
"Mark False Positive" sets a protected suppression reason. Unlike a workflow status change, it survives the continuous disposition reconcile — the row will not reappear when an upstream repository or app changes. Use it only for genuine non-secrets the auto-suppression missed, not as a substitute for closing a real, rotated credential.
Export
Export produces an async job (you're notified when the file is ready). It honors the current filters and sort and includes these columns: ID, Module, Rule, Matching, Probe Status, Probe Provider, Updated At. Because the matched value is included, exported files contain live secret material — handle them accordingly.
Common questions
Is this the same as the dark-web "leaked credentials" feed? No. This module is about secrets your scanners pulled out of your own public code and mobile apps. Credentials exposed in third-party breach dumps and infostealer logs are covered separately by the dark-web modules (Data Breaches and Stealer Logs) — distinct sources, distinct remediation.
A credential shows "Live." What should I do? Treat it as an active incident. Rotate or revoke the credential at the provider immediately, then confirm the new probe verdict flips to Dead and close the row. The Source link takes you to the exact repository or app file to scrub the secret from history.
Why does a row still appear after I deleted the repo / made it private? Removing or privatizing the repo doesn't un-leak the secret — anyone who already cloned it has the credential. ShadowMap keeps the row so you remember to rotate. Close it after the secret is actually rotated/revoked.
What does "Not Applicable" mean for probe status? The secret type cannot be validated against any external endpoint by design (a generic password, a raw private key, an internal vault token). There is no automatic way to tell if it still works — assess it manually and rotate if it's real.
Why are some obvious test secrets missing? ShadowMap auto-suppresses known boilerplate (placeholder DSNs, test fixtures, the literal password, version strings) and high-confidence scanner false positives before they reach your queue, so you triage real exposures rather than noise.
Do the KPI cards, tabs, and charts ever disagree? No. All of them read the same company-scoped, suppression-aware set of rows, so counts reconcile across the strip, the tabs, and the analytics panel.
Related
- Code Repositories — the upstream source for repo-based credentials; the Source link drills into the exact repo and file.
- Mobile Applications — the upstream source for credentials found in decompiled apps.
- Data Leaks Overview — module landing page aggregating all data-exposure findings.
- Data Breaches and Stealer Logs — the dark-web counterparts: credentials exposed via third-party breaches and infostealer dumps rather than your own code.
- Alerts — confirmed-live and newly detected credentials can surface as alerts for response workflows.
- Status Workflow — how the Online → Reviewed → Investigating → To Be Closed → Closed disposition works across modules.
- Exports — how async exports are generated and delivered.