Password / Credential: Data Point Intelligence Guide

An exposed credential is a defensive workload, not an offensive opportunity. The only question worth asking is which of your accounts to protect, and how fast.

Understanding the Password / Credential as an intelligence artifact

A credential data point is an authentication secret exposed through a breach, an infostealer log or a misconfigured repository, usually paired with an identifier such as an email address or username. The secret may appear as plaintext, as a hash produced by an algorithm of widely varying strength, or as a session token or API key. As an artifact it is the combination that matters: the identifier locates the account, the secret determines urgency, and the source determines how the exposure should be interpreted.

Provenance separates the categories. A breach dump reflects one service at one point in time. An infostealer log reflects a compromised endpoint and typically contains many credentials, cookies and tokens from one user, which implies device compromise rather than site compromise. Combolists are aggregations with no reliable provenance. Hash format also matters analytically: a modern memory-hard function offers real protection where unsalted legacy hashing offers effectively none.

Why it matters

Credential exposure is the most common precursor to intrusion, so knowing which of your identities appear in circulating data lets you close the path before it is used. For responders it scopes an incident: an infostealer log tells you which endpoint was compromised and what else that user held. For risk teams the volume and recency of exposed corporate credentials is a measurable indicator of both user behaviour and endpoint hygiene.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

Whether the identifier is a corporate or personal address, which determines whose access is at risk and which policy applies.
Source type, distinguishing a single-service breach from an infostealer log implying a fully compromised endpoint and browser profile.
Hash algorithm and salting, which determine whether the exposed secret should be treated as effectively plaintext.
Exposure recency, since a credential from a recent stealer log demands immediate response where a decade-old hash may not.
Presence of session cookies or tokens alongside the password, which changes the response because rotation alone does not revoke them.
Password composition patterns across an organisation, which reveal weak policy enforcement without needing any individual secret.
Repetition of the same identifier across multiple unrelated corpora, indicating a user whose accounts are broadly exposed.
Associated device, application and browser metadata in stealer logs, which identifies the specific endpoint requiring forensic attention.

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

Have I Been Pwned — Free domain search for owned domains and breach attribution per exposed address, without exposing secrets
HIBP Pwned Passwords — K-anonymity API for checking whether a password hash prefix appears in known corpora without transmitting the secret
DeHashed — Contracted breach record search used for authorised exposure assessment of your own identities and domains
NIST SP 800-63B — Authoritative guidance on credential policy, blocklisting compromised passwords and abandoning forced rotation
CISA advisories — Defensive guidance and observed adversary use of valid accounts, with concrete mitigation recommendations
MITRE ATT&CK T1078 Valid Accounts — Detection and mitigation guidance for adversary use of legitimate credentials in intrusions
Identity provider audit logs — Your own authentication telemetry, which is the only authoritative source on whether exposure became access

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Scope by identifier, not by secret — Determine which of your accounts appear in exposure data. You do not need the secret itself to act on the exposure.
Classify the source — Establish whether the exposure came from a service breach or an infostealer log, because the second implies endpoint compromise.
Assess urgency — Weight by recency, hash strength, account privilege and whether tokens or cookies accompanied the credential.
Revoke sessions before resetting — Invalidate active sessions and refresh tokens first, since a password reset alone leaves stolen session material usable.
Hunt for prior use — Search authentication logs for anomalous sign-ins on affected accounts across the full exposure window, not just recent days.
Remediate the endpoint — Where a stealer log is involved, treat the device as compromised and rebuild it rather than resetting credentials on the same host.
Close the systemic gap — Enforce phishing-resistant MFA, screen new passwords against compromised-password blocklists, and reduce the value of any single secret.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Collected by these disciplines

Cyber Intelligence — Adversary Activity in Networks and Systems
Criminal Intelligence — Intelligence Supporting Criminal Investigation
Breach Intelligence — Exposed Credentials and Compromised Data
Threat Actor Intelligence — Tracking Adversary Groups Over Time
Dark Web Intelligence — Hidden Services and Closed Criminal Venues
Financial Intelligence — Following Value Through the Financial System
Cryptocurrency Intelligence — Tracing Value on Public Ledgers
Identity Intelligence — Resolving and Verifying Who Someone Is

Investigated in these domains

Pivots to these data points

File Hash — Cryptographic fingerprint of a file, used for malware identification.
CVE / Vulnerability — Common Vulnerabilities and Exposures identifier for a known flaw.
SSL/TLS Certificate — A digital certificate binding a public key to an identity.
Malware Family — A named class of related malicious software.
File / Document — A file or document artifact — malware sample, leaked document, image, or email attachment.
Onion / Hidden Service — A Tor hidden service address on the dark web.

Inside the platform: where Password / Credential lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

datapoint.php?dp=dp_password — Data point hub
ioc.php — Cyber Crime dashboard
domain.php?d=darkweb — Dark Web Intel dashboard
domain.php?d=opsec — Operational Security dashboard
blockchain.php — Fraud & Identity dashboard
search.php — Advanced search, filter and pivot
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Enrichment Runner
Enrichment → Local
Correlate Infrastructure
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Scope by identifier, not by secret is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Assess urgency turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Close the systemic gap feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Password / Credential

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Exposed credentials belonging to defence personnel and contractors are a force protection and counter-intelligence matter. The analytic task is scoping by identifier: which official accounts appear in circulating exposure data, which personnel used official addresses on external services, and which endpoints show infostealer indicators. The response is defensive and immediate: revoke sessions, force reset through the identity provider, enforce phishing-resistant authentication, and rebuild any endpoint implicated in a stealer log. Under no circumstances is an exposed secret tested against any account, including one belonging to your own organisation, because that constitutes unauthorised access. Products feed personnel security advice, endpoint remediation tasking and supply chain notifications.

🕵 National intelligence

For national services, credential exposure data is primarily a defensive and counter-intelligence input: identifying where national entities and cleared personnel appear in circulating corpora, and assessing whether a hostile actor is assembling access at scale against a sector. Handling of any corpus containing authentication secrets requires strict authority, segregation and logging, because these datasets are criminal in origin and their misuse is both unlawful and career-ending. Analysis works from identifiers, source classification and metadata rather than from the secrets themselves. Dissemination should reach the defending organisation quickly and in a form that enables remediation without redistributing secrets, which usually means identifiers and actions rather than records.

👮 Law enforcement

Law enforcement encounters exposed credentials as evidence of the offence rather than as a tool. A stealer log recovered from an actor's infrastructure evidences the scale of the intrusion set, identifies victims for notification, and supports charging on unauthorised access and data theft offences. Handling is tightly controlled: the corpus is evidence containing third-party personal data, so access is restricted, logged and filtered. Investigators must never test a recovered credential against any account, because doing so is itself unauthorised access, taints the investigation and may constitute an offence by the investigator. Victim notification and provider cooperation, obtained through proper process, are the routes to protective action.

🔍 Private investigation and corporate security

Corporate security uses exposure data for one purpose: closing the path before it is used. Determine which corporate identities appear, classify the source as service breach or infostealer log, revoke sessions, force resets, enforce phishing-resistant MFA and rebuild implicated endpoints. Private actors face hard limits. Do not purchase stolen credential data, do not ingest corpora containing third-party secrets without a lawful basis, and never test an exposed credential against any account, including your own organisation's, since authorisation to defend a system is not authorisation to authenticate as a user. Route anything involving another organisation's credentials to that organisation and to counsel.

📰 Journalism and OSINT media

Journalists reporting on credential exposure should never authenticate with an exposed credential, even to verify a claim, because that is unauthorised access regardless of intent and it has led to prosecutions of reporters. Verification comes from structural analysis of a sample, corroboration with the named organisation, regulatory filings and independent expert assessment. Never publish credentials, even partially redacted, and never publish data that lets a reader identify an individual account. Notify the affected organisation before publication and give it time to protect users. Where a source supplies a corpus, take legal advice on possession, because handling authentication secrets carries different exposure than handling documents.

🌍 NGO, humanitarian and human rights

Civil society staff and partners are heavily targeted through credential theft, often with infostealers delivered by targeted phishing. The protective response is practical and victim-centred: help people move to phishing-resistant authentication, rebuild compromised devices rather than only changing passwords, and explain the risk in plain language and in the right language. Do not collect corpora containing beneficiary or partner credentials, since holding them recreates the harm and creates an obligation you cannot discharge safely. Use domain-level exposure services for organisational assessment. Where a partner in a repressive context is exposed, treat it as an urgent safety issue with a defined support pathway rather than an IT ticket.

🎓 University and research

Research on credential exposure covers password policy effectiveness, reuse rates, the economics of stealer markets and the impact of blocklisting on user behaviour. Ethics review is essential and institutions are increasingly explicit that authenticating with exposed credentials is prohibited under any circumstances. Defensible designs analyse structure and aggregate statistics rather than record-level secrets, use k-anonymity services where membership questions can be answered without transmitting values, and never attempt validation against live services. Publish methodology, aggregate distributions and code, never sample credentials, and pin dataset versions so results are reproducible without redistributing the corpus.

Playbook: working Password / Credential end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Establish authority and handling rules first

Before any exposure data enters the organisation, record the lawful basis, the responders permitted to access it, the storage controls and the deletion schedule, and state in writing the absolute prohibition on testing any exposed secret against any account. This is the control that keeps a defensive activity defensive. A good output is a signed handling standard referenced by every subsequent action. Stop and take legal advice before ingesting any corpus, because possession of stolen authentication data carries different exposure than possession of documents.

Phase 2 — Scope by identifier, never by secret

Determine which of your accounts, domains and third parties appear in exposure data using identifiers and metadata alone. You do not need the secret to act on the exposure, and you should not want it. Domain-level services answer the question without transferring records. A good output is a list of affected internal identities and suppliers with source and date per entry. Stop here and act; any workflow that requires an analyst to read a plaintext password has been designed wrongly.

Phase 3 — Classify the source

Establish whether each exposure came from a service breach, an infostealer log, a combolist aggregation or a misconfigured repository, because the implication differs completely. A service breach means one account at one provider. A stealer log means the endpoint is compromised and everything the user held on it is exposed, including cookies and tokens. A good output is a source classification per exposure with the evidence. This single classification decision determines whether you reset a password or rebuild a machine.

Phase 4 — Assess urgency

Rank by recency, source type, account privilege, whether session material or tokens accompanied the credential, and whether the identity is externally reachable. A months-old exposure of a low-privilege account with a strong modern hash and enforced MFA is not the same problem as a stealer log containing live session cookies for an administrator. A good output is a prioritised remediation queue with a stated reason per ranking, so asset owners can challenge priorities intelligently rather than receiving an undifferentiated list.

Phase 5 — Revoke sessions and tokens before resetting

Invalidate active sessions, refresh tokens, application passwords and API keys before or alongside the password reset, because stolen session material remains valid after a reset in many applications and is exactly what infostealers collect. Cover federated applications and anything caching sessions independently of the identity provider. A good output is verified revocation across every application in scope, evidenced from logs. Stop treating a completed password reset as remediation until revocation is confirmed.

Phase 6 — Force credential rotation through the identity provider

Reset centrally rather than asking users to change passwords voluntarily, and require enrolment or re-enrolment in phishing-resistant authentication at the same time. Where the account holds delegated access, application secrets or recovery methods, rotate those too, since attackers persist through recovery paths far more often than through the primary credential. A good output is a completed rotation record per account including secondary factors and recovery methods. Verify from logs rather than from user confirmation.

Phase 7 — Rebuild endpoints implicated in stealer logs

Where the source is an infostealer log, treat the device as compromised and rebuild it from known-good media rather than resetting credentials on the same host. Resetting on an infected machine hands the new value straight back to the operator. Preserve a forensic image first if the incident may be investigated. A good output is a rebuild record with the date and the confirmation that credentials were only rotated after the device was clean. This step is the one most often skipped for convenience.

Phase 8 — Hunt for prior use across the full window

Search authentication logs for anomalous sign-ins on affected accounts across the entire exposure window, not just recent days, looking for unfamiliar source addresses, impossible travel, new device registrations, mailbox rules, delegated permissions and OAuth grants. Attackers establish persistence quickly and quietly. A good output is a documented hunt with scope, queries and findings, including an explicit statement of the log retention limit, since absence of evidence beyond retention is not evidence of absence.

Phase 9 — Check for persistence beyond the password

Review mailbox forwarding rules, delegated access, application registrations, OAuth consents, recovery email and phone numbers, registered authenticators and API tokens on every affected account. These survive a password reset and are the standard persistence mechanisms after credential compromise. A good output is a completed persistence checklist per account. This is where accounts that were remediated and then reused by the attacker a fortnight later were actually lost.

Phase 10 — Screen new credentials against compromised lists

Implement screening of newly chosen passwords against known-exposed corpora using a k-anonymity service, so the candidate secret is never transmitted, and reject matches at the point of choosing. This is the defensive use of exposure data and it is the one with measurable effect. A good output is screening enforced at every credential-setting path, including self-service reset and administrative provisioning. Verify the coverage, since bypasses in legacy provisioning paths are common and invisible.

Phase 11 — Close the systemic gap

Move the estate toward phishing-resistant authentication, reduce the value of any single secret through conditional access and short-lived tokens, remove passwords where a passkey or certificate can replace them, and follow current guidance by abandoning forced periodic rotation in favour of screening and event-driven reset. A good output is one structural change per cycle with an owner. Programmes that only process exposures will keep processing the same exposures indefinitely.

Phase 12 — Notify, record and delete

Tell affected individuals what happened, what to do and why, in plain language, following employment and privacy policy. Retain only the record of the exposure and the action taken, not the secrets. Delete any ingested corpus on the defined schedule with verifiable destruction, and audit access afterwards. A good output is an access log mapping every query to an authorised responder and purpose, plus a destruction record. Anything else means the response created a second exposure inside your own environment.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
Have I Been Pwned	Open	Verified breach catalogue with free domain search for owned domains, returning affected addresses and breach attribution without secrets.	The primary lawful mechanism for identifying which organisational identities appear in known breaches.
Pwned Passwords	Open	Service exposing hundreds of millions of previously exposed password hashes, queryable by hash prefix using k-anonymity.	Screens newly chosen passwords against compromised corpora without ever transmitting the candidate secret.
NIST SP 800-63B	Open	Authoritative digital identity guidance covering authenticator assurance, blocklisting compromised passwords and abandoning forced rotation.	The controlling reference for credential policy design and for justifying the removal of periodic rotation.
NCSC password guidance	Open	UK national technical authority guidance on password policy, deny lists, account lockout and phishing-resistant authentication.	Practical policy guidance aligned to UK expectations, useful for board and audit conversations.
CISA advisories on valid accounts	Open	Government advisories describing adversary use of valid credentials, associated indicators and concrete mitigation recommendations.	Supplies hunting guidance for detecting use of exposed credentials in your own environment.
MITRE ATT&CK credential access and valid accounts	Open	Technique documentation covering credential theft, infostealers, session hijacking and use of valid accounts for persistence.	Maps the exposure to the detection and mitigation requirements that follow it.
FIDO Alliance	Open	Specifications and guidance for passkeys and phishing-resistant authentication built on public key cryptography rather than shared secrets.	The reference for eliminating the shared secret entirely, which is the only durable fix.
OWASP Authentication Cheat Sheet	Open	Practitioner guidance on secure authentication implementation, credential storage, session management and account recovery.	Reference for application-level controls including session revocation and recovery path hardening.
DeHashed	Licensed	Commercial breach record search across many corpora, used under contract for authorised exposure assessment.	Contracted assessment of your own domains where free indirect services do not provide sufficient coverage.
Spycloud and equivalent contracted services	Licensed	Commercial services providing infostealer log exposure alerting keyed to owned domains and identities.	Identifies stealer-derived exposure, which requires endpoint rebuild rather than only credential rotation.
Microsoft and Google identity security guidance	Open	Platform guidance on session revocation, conditional access, token lifetimes and detecting anomalous sign-in behaviour.	Provides the exact administrative actions that revoke sessions and tokens in the dominant identity platforms.
abuse.ch feeds	Open	Open indicator feeds covering infostealer distribution infrastructure, payload hashes and command and control endpoints.	Supports detection of the stealer families that generate credential exposure in the first place.
Verizon Data Breach Investigations Report	Open	Annual analysis showing the persistent role of stolen credentials as an initial access vector across sectors.	Provides the evidence base for prioritising credential controls in board-level risk discussions.
ICO and EDPB guidance on personal data breaches	Open	Regulatory guidance on notification thresholds and obligations where authentication data is among the exposed classes.	Determines whether and how affected individuals must be notified after credential exposure.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Password / Credential. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

Identity provider administrative console — Executes forced reset, session revocation and MFA enforcement centrally. Limitation: applications outside the identity provider retain independent sessions and credentials.
Token and session revocation API — Invalidates refresh tokens and application sessions programmatically at scale. Limitation: some applications cache authorisation and honour it until expiry regardless.
Pwned Passwords k-anonymity API — Checks a password hash prefix against exposed corpora without transmitting the secret. Limitation: detects known-exposed values only, not weak novel ones.
Password policy and deny list enforcement — Rejects compromised and predictable candidates at the point of choosing. Limitation: bypasses in legacy provisioning and self-service paths are common and unmonitored.
Passkey and FIDO2 enrolment tooling — Moves accounts to phishing-resistant public key authentication. Limitation: legacy and third-party applications frequently cannot consume it.
Endpoint detection and response — Detects infostealer execution and supports the decision to rebuild a device. Limitation: stealers often complete their work in seconds before any response fires.
Authentication log analytics — Hunts anomalous sign-ins, impossible travel and new device registrations across the exposure window. Limitation: retention is usually shorter than the exposure window.
Domain exposure alerting — Notifies when organisational identities appear in newly catalogued corpora. Limitation: coverage lags behind circulation, so absence of an alert is not assurance.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

You never need the secret to act on the exposure. Every defensive action follows from the identifier, the source classification and the date, so any workflow that puts a plaintext password in front of an analyst has been designed badly and should be redesigned.
Testing an exposed credential against any account is unauthorised access. That includes accounts belonging to your own organisation and your own users, because authorisation to defend a system is not authorisation to authenticate as its users, and it has ended careers and produced prosecutions.
Source classification is the highest-value decision in the process. A service breach means rotate a password; an infostealer log means the endpoint is compromised, and resetting credentials on an infected machine hands the new value straight back to the operator.
Session and token material outlives password resets in most applications. Infostealers collect cookies precisely because they bypass both the password and the second factor, so revocation before rotation is the ordering that actually closes the path.
Persistence lives in the places nobody resets: mailbox rules, delegated access, OAuth grants, application passwords, API tokens and recovery contact details. An account remediated without checking those is frequently lost again within weeks.
Hash strength changes urgency, not the requirement to act. A modern memory-hard function buys time; unsalted legacy hashing offers effectively none. Either way the credential must be treated as exposed, because you cannot know how long the corpus has circulated privately.
Screening against compromised-password lists using a k-anonymity service is the one use of exposure data with a measurable defensive effect, and it works precisely because the candidate secret is never transmitted. Verify that every credential-setting path enforces it, including legacy provisioning.
Forced periodic rotation is counterproductive and current guidance has abandoned it. Rotate on evidence of compromise, screen at the point of choosing, and spend the effort saved on phishing-resistant authentication, which removes the shared secret rather than churning it.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Password / Credential is producing anything, and they are worth baselining before you change process or tooling.

Median time from exposure alert to completed session revocation and credential rotation for affected accounts, verified from logs rather than from ticket closure.
Proportion of stealer-derived exposures where the implicated endpoint was rebuilt rather than only credential-rotated. Anything less than complete leaves compromised devices in the estate.
Coverage of phishing-resistant authentication across privileged and internet-reachable accounts, which is the structural measure that makes exposure less consequential over time.
Percentage of credential-setting paths enforcing compromised-password screening, including self-service reset and administrative provisioning, verified by test rather than by configuration review.
Recurrence rate of exposure for the same identity within twelve months, which indicates whether remediation addressed the endpoint and behaviour or only the password.
Proportion of remediated accounts where persistence checks covering mailbox rules, OAuth grants and recovery methods were completed and recorded.
Number of workflows requiring an analyst to view a plaintext secret. The target is zero, and any occurrence is a process design defect rather than an operational one.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

Combolists recycle old credentials endlessly, so an appearance in a dataset does not prove a current or valid password.
Resetting a password without revoking sessions and tokens leaves the intruder's existing access completely intact.
Forced periodic rotation degrades password quality and is explicitly discouraged by current standards in favour of compromise screening.
Corporate exposure through personal accounts on shared devices is invisible to domain-based searches and is routinely missed.
Ingesting full credential corpora to assess exposure creates a high-value internal dataset and significant regulatory liability.
Notifying users without a clear, actionable instruction produces alert fatigue and no measurable improvement in account security.

Legal and ethical considerations

Exposed credentials are personal data and frequently the product of criminal activity. Testing a credential against any account, including apparently your own users' accounts, may constitute unauthorised access and must never be used to validate exposure. Work from identifiers and metadata rather than secrets, prefer services that answer exposure questions without transferring records, and where corpora must be held, restrict access to named responders, encrypt at rest, log all queries and delete on a short defined schedule. Notification should follow employment and privacy policy.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Password / Credential, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 8 intelligence disciplines, 4 mission domains, 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Can we test an exposed password to confirm whether the account is really compromised?

No. Authenticating with a credential you were not issued is unauthorised access in most jurisdictions, and that holds even where the account belongs to your own organisation and your own employee, because your authorisation to administer a system is not authorisation to log in as a user. It also destroys evidence and creates log entries that confuse the subsequent investigation. Confirmation is never necessary: the correct response to a credible exposure is to revoke sessions, rotate the credential and hunt authentication logs for prior anomalous use. Treat the exposure as true and act.

Why revoke sessions before resetting the password?

Because a password reset does not invalidate existing sessions in many applications, and stolen session cookies and refresh tokens are exactly what infostealers collect. An attacker holding a valid session continues to have access after the user changes their password, and in some platforms can re-establish long-lived access from that session. Revoke sessions, refresh tokens, application passwords and API keys first or simultaneously, then rotate the credential, then verify from logs that revocation actually applied across federated and legacy applications rather than only in the identity provider.

What should we do differently for infostealer logs?

Treat the endpoint as compromised, not just the account. A stealer log means malware ran on that device and harvested everything it could reach: saved passwords across all sites, cookies, session tokens, autofill data, cryptocurrency wallets and sometimes files. Rebuild the device from known-good media, preserving a forensic image first if investigation is likely, and only rotate credentials after the device is clean. Then rotate every credential the user held on that machine, not only the corporate one, and check for persistence on each affected account. Resetting first on an infected host achieves nothing.

Does password hash strength change what we should do?

It changes urgency, not the requirement to act. A modern memory-hard function such as Argon2 or scrypt with sensible parameters makes bulk recovery expensive and buys you time; unsalted MD5 or SHA-1 offers effectively no protection and should be treated as plaintext. But you never know how long a corpus circulated privately before it surfaced, so the credential must be treated as exposed regardless. Use hash strength to sequence the remediation queue alongside privilege, recency and whether session material accompanied the credential, not to decide whether to remediate.

Should we still force periodic password changes?

No. Current guidance from NIST and from national technical authorities is explicit that forced periodic rotation degrades security, because users respond with predictable transformations of the previous value and with reuse across services. Rotate on evidence of compromise. In steady state, screen candidate passwords against compromised corpora at the point of choosing, allow long passphrases, remove composition rules that push users toward predictable patterns, and invest the effort saved in phishing-resistant authentication. Where an auditor insists on rotation, the guidance documents are the argument to make.

How do we screen passwords against exposed lists without handling secrets?

Use a k-anonymity service. The client hashes the candidate password locally, sends only the first five characters of the hash prefix, and receives back the set of matching suffixes to compare offline. The full hash and the password itself never leave the client, so the service learns nothing usable and you never hold a corpus of secrets. Enforce the check at every path where a credential can be set, including self-service reset, help desk resets and automated provisioning, and test the enforcement rather than assuming the configuration applies everywhere.

What do we tell an employee whose credentials appear in exposure data?

Tell them plainly what appeared, where it came from if you know, what you have already done, and what they need to do. If the source is an infostealer log, explain that their device is being rebuilt and that they should rotate personal accounts used on that machine too, especially email and anything reusing the same password. Avoid blame; credential exposure is usually not the user's failure and treating it as one suppresses future reporting. Follow employment and privacy policy on how the exposure was discovered and what was and was not examined.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

NIST SP 800-63B defines authenticator assurance levels, requires screening against compromised password lists and advises against forced periodic rotation.
NCSC password administration guidance sets national technical authority expectations on deny lists, lockout and reducing password burden.
FIDO2 and WebAuthn specifications define phishing-resistant public key authentication that removes the shared secret entirely.
OWASP Application Security Verification Standard defines verifiable requirements for authentication, session management and credential storage.
MITRE ATT&CK documents valid accounts, credential access and session hijacking techniques that follow credential exposure.
GDPR Articles 33 and 34 govern notification where authentication data forms part of a personal data breach.
ISO/IEC 27001 Annex A controls cover access control, authentication and secret management within a certified management system.
Computer Fraud and Abuse Act, Computer Misuse Act and equivalent statutes make authenticating with another party's credential an offence regardless of intent.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

Digital Identity Guidelines SP 800-63B — National Institute of Standards and Technology. Authoritative guidance on authenticator assurance, compromised password screening and rotation policy.
Pwned Passwords — Have I Been Pwned. K-anonymity service for screening candidate passwords against known-exposed corpora without transmitting the secret.
Password administration for system owners — UK National Cyber Security Centre. National guidance on password policy, deny lists and reducing reliance on shared secrets.
Passkeys and FIDO2 specifications — FIDO Alliance. Standards for phishing-resistant authentication based on public key cryptography.
Authentication Cheat Sheet — OWASP. Practitioner guidance on authentication, session management and recovery path security.
ATT&CK credential access techniques — MITRE. Technique documentation covering credential theft, stealers and use of valid accounts.
Advisories on valid account abuse — Cybersecurity and Infrastructure Security Agency. Government advisories with indicators and mitigations for adversary use of stolen credentials.
Data Breach Investigations Report — Verizon. Annual evidence base on stolen credentials as a leading initial access vector.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: domain-level credential exposure monitoring with source classification and prioritised reset and revocation guidance. Explore the platform, or browse the rest of the library by following any tag above.