Breach Intelligence (BREACHINT): Intelligence Discipline Guide

Most intrusions begin with a password that already worked somewhere else. Breach intelligence is the discipline of knowing which of your credentials are already in circulation.

What Breach Intelligence is as a discipline

Breach intelligence is the systematic collection, verification and analysis of data exposed through third-party compromise: credential pairs, password hashes, session tokens, personal records, internal documents and database dumps. Practitioners track breach events from disclosure through to circulation, establish provenance for each dataset, and match exposure against their own identity estate. Collection relies on notification services, licensed breach corpora, tenant-level identity protection alerts and monitoring of the venues where dumps circulate, always through lawful acquisition and under strict handling and minimisation controls.

Sub-methods split by object. Credential exposure covers email and password pairs, hash-cracking risk and reuse patterns. Stealer-log intelligence covers infostealer output containing browser-stored credentials and live session cookies. Record exposure covers personal, health and financial data with regulatory consequences. Maturity progresses from reactive breach notification, to continuous domain monitoring, to identity-graph matching that resolves aliases and personal accounts used for work. Output feeds detection engineering and forced-reset workflows directly.

Why it matters

Only breach intelligence answers which of your accounts an attacker can log into right now without exploiting anything at all. It converts an unbounded threat into a finite, actionable list of identities. It also dates the exposure, and the date determines urgency: a decade-old salted hash is a hygiene item, while a stealer log captured last week containing a valid session cookie bypasses multi-factor authentication entirely and demands immediate session revocation and endpoint rebuild.

What analysts actually look for

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

Corporate email addresses appearing in named breach corpora, with breach date, source dataset and the exact fields exposed
Plaintext or weakly hashed passwords tied to organisational accounts, indicating reuse risk against SSO, VPN and remote access
Infostealer log entries containing browser-stored credentials, autofill data and live session cookies for corporate SaaS applications
Machine fingerprints inside stealer logs: hostname, local username, operating system and installed software identifying the infected endpoint
Personal-account exposure where a shared password pattern or recovery address links an employee identity to a corporate account
Executive and privileged-account exposure, weighted separately because of authority over payments, approvals and administrative access
Customer records attributable to your own systems or a processor, starting regulatory notification clocks the moment they are confirmed
Supplier and contractor credential exposure granting third-party access to your tenants, VPN concentrators or shared file platforms

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 — Breach and paste exposure by address or verified domain, with dataset provenance, dates and exposed field lists
Pwned Passwords k-anonymity API — Checks a password hash prefix against exposed corpora without ever transmitting the password itself
Microsoft Entra ID Protection — Tenant-level leaked-credential risk detections raised when your users appear in known credential corpora
Intelligence X — Licensed archive search across breach corpora, leaks and historical paste content with field-level queries
DeHashed — Commercial breach-corpus search supporting domain, username and hash queries under a licensed acquisition model
State attorney-general breach registries — Maine and California notification databases give confirmed incident facts, dates and affected-population counts
Mozilla Monitor — Consumer breach notification built on public breach data, useful for employee personal-account awareness programmes

A working method

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

Define the identity perimeter — Enumerate owned domains, SSO identities, service accounts, contractor tenants and the executive aliases you are authorised to monitor.
Match continuously — Subscribe to domain-level breach monitoring and licensed corpus search, capturing every new hit with breach name, date and exposed fields.
Verify and date — Confirm the record is genuine rather than recycled from an older combolist. Establish first-seen date, originating incident and hash algorithm.
Triage by exploitability — Rank plaintext above hashed, recent above historic, privileged above standard, and live session tokens above every other category.
Contain — Force credential reset, revoke sessions and refresh tokens, and step up authentication. For stealer-log hits, isolate and rebuild the implicated endpoint.
Hunt for use — Search authentication logs for the exposed identity from unusual sources, and for successful logins preceding the public disclosure date.
Feed the controls — Update password blocklists, policy and phishing-resistant MFA rollout priorities using the reuse patterns the exposure data reveals.

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.

Applied in these mission domains

Operates on these data points

Email Address — Electronic mail address tied to an individual or organization.
Password / Credential — An exposed password or credential pair from leaks or dumps.
Data Breach — A known data breach or leak incident with exposed records.
Domain Name — Human-readable address that maps to IP infrastructure via DNS.
URL — Uniform Resource Locator pointing to a web resource.
Cryptocurrency Address — Blockchain wallet address for receiving or sending crypto assets.
Person / Name — A named individual — the subject of identity resolution and profiling.

Related disciplines

Attack Surface Intelligence — Your Own Exposed Attack Surface
Certificate Intelligence — TLS Certificates and Certificate Transparency
Cyber Intelligence — Adversary Activity in Networks and Systems
Dark Web Intelligence — Hidden Services and Closed Criminal Venues
Domain Intelligence — Domains, DNS, and Registration Intelligence
Malware Intelligence — Understanding Malicious Code

Inside the platform: where Breach Intelligence 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:

discipline.php?d=BREACHINT — Discipline hub
source-catalog.php?disc=BREACHINT — Source catalogue filtered to this discipline
email-profile.php — Email Address profile
url-profile.php — Domain Name profile
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:

Threat Hunt
Auto-Collect Feeds
Enrichment → Local
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. Define the identity perimeter 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. Verify and date 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. Feed the controls 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 Breach Intelligence

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

Defence organisations practise breach intelligence as a personnel and access assurance function. The authority is over service and civilian accounts held on defence systems and, by policy, over the use of official addresses on external services. Practice is exposure matching rather than data acquisition: official identifiers are checked against exposure services using hash-prefix methods, and any confirmed match triggers forced credential rotation and a counterintelligence referral where the individual holds sensitive access. The output supports personnel security reviews, operations security assessments and force protection where exposure reveals deployment patterns. Constraint: personal accounts of service personnel are not a legitimate collection target absent a specific authorised investigation, and monitoring them would be unlawful intrusion.

🕵 National intelligence

National services use breach exposure as both a defensive assurance measure over their own establishment and, under proper authority, as a source that must be handled with extreme care. Requirements-driven collection asks whether identifiers associated with cleared personnel, covers or facilities appear in circulating datasets, since that exposure is a counterintelligence problem before it is a security one. Fusion combines exposure data with travel, personnel and technical reporting. The governing constraint is that the underlying datasets are stolen personal data, so acquisition, retention and processing require specific legal authority, defined retention limits and audit. Products are classified because the fact of exposure of a specific cover or identity is itself sensitive.

👮 Law enforcement

Investigators use breach data in two distinct ways. As intelligence, it supports victim identification and notification after a compromise, and helps attribute criminal marketplaces. As evidence, it is difficult: a dataset of unknown provenance circulating on criminal venues has no established chain of custody and its integrity cannot be assumed. Lawful acquisition normally runs through seizure under warrant, direct provision by the breached entity under production order, or transfer from a partner agency, never through purchase from a criminal seller. Every record relied on must be corroborated against an authoritative source before it supports a charging decision, and possession of bulk personal data requires a documented lawful basis and retention schedule.

🔍 Private investigation and corporate security

Corporate security teams practise breach intelligence over their own identity estate: which corporate addresses, service accounts and executive identifiers appear in circulating datasets, and which credentials are still valid. The lawful method is k-anonymity hash matching against reputable exposure services, or use of a licensed provider under contract. A private actor must not purchase breach dumps, must not download stolen databases, and must not test recovered credentials against third party services, all of which risk offences and regulatory exposure. Findings drive forced resets, conditional access changes and executive protection advice. Where third party or customer data is implicated, notification obligations belong to legal and privacy, not to the analyst.

📰 Journalism and OSINT media

Journalists use breach material to evidence stories about negligent data handling, criminal marketplaces and covert relationships. Verification means confirming the dataset is what it claims to be by testing a small number of records with the consent of the individuals concerned, or by comparing structure and field composition against a known-good sample, rather than by mass reidentification. Do not publish personal data, do not permit search of the dataset as a public service, and store any copy encrypted with restricted access. Give the breached organisation a real right of reply and time to notify victims. The public interest test must be applied to each category of data, not to the story as a whole.

🌍 NGO, humanitarian and human rights

Human rights and civil society groups practise breach intelligence defensively, because exposure of a staff or beneficiary identifier can translate directly into physical risk in a repressive environment. Practice is checking organisational identifiers through hash-prefix services and helping at-risk partners do the same, then supporting recovery with credential rotation, multifactor enrolment and account audit. Victim-centred handling means the affected person is told plainly what is exposed and what it enables, with support available at the point of disclosure. Do no harm forbids acquiring or holding dumps that contain beneficiary data, since the organisation then becomes the custodian of the very risk it is trying to reduce.

🎓 University and research

Researchers study breach data as a measurement problem: password reuse rates, credential stuffing success, breach detection latency, and the economics of data resale. The methodological and ethical requirements are strict and interlinked. Ethics approval is mandatory where the dataset contains identifiable personal data, and most institutions require analysis on aggregates, hashes or synthetic derivatives rather than plaintext records. Do not redistribute datasets, do not attempt reidentification beyond what the protocol authorises, and do not contact data subjects without approval. Publish the methodology and the aggregate statistics with the dataset described by provenance and date rather than shared, and state the selection bias inherent in which breaches become public.

Playbook: working Breach Intelligence 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 — Define the identity estate

Establish precisely which identifiers you are responsible for before matching anything. That means corporate email domains including legacy and acquired ones, service and shared accounts, executive and board personal aliases used for business, customer identifier formats, and any authentication identifiers such as employee numbers used across systems. Include suppliers who hold accounts on your platforms. A good output is a maintained identifier scope document with owners, because matching against an incomplete estate produces false assurance. Stop when identity, HR and business unit owners have each confirmed the domain and account list is complete, including domains only used for outbound marketing.

Phase 2 — Choose a lawful matching method

Decide how you will check exposure without acquiring stolen data. The preferred method is k-anonymity range matching, where a short hash prefix is submitted and the service returns the matching set, so the full identifier or password hash never leaves your control and you never receive other subjects data. Alternatives are a contracted provider operating under a data processing agreement with defined lawful basis. Record the decision and the legal basis. A good output is a documented matching architecture reviewed by privacy and legal counsel. Stop when the method is approved and the alternative of acquiring dumps has been formally ruled out.

Phase 3 — Establish dataset provenance

Before acting on any exposure claim, establish what the dataset actually is: which entity was breached, when, what fields it contains, whether it is a genuine single breach or a compilation of older material recirculated under a new name, and how the exposure service verified it. Compilations are routinely marketed as fresh breaches and drive wasted response. Record breach date, disclosure date and first circulation date separately. A good output is a provenance record per dataset with a confidence rating. Stop when you can state whether the exposure is new, recirculated or unverified, because that determines the whole response.

Phase 4 — Match and triage exposure

Run the matching process across the identity estate and triage results by what the exposure actually enables. A plaintext password for an account with single-factor remote access is an emergency; a decade-old salted hash for a decommissioned forum is not. Weight by credential recency, hash strength, whether the account still exists, whether the password pattern is likely reused, and the privilege attached. A good output is a ranked exposure list tied to specific accounts with an enabling-impact statement for each. Stop when every item is either actioned, accepted with a reason, or classified as historic and closed.

Phase 5 — Validate without unlawful testing

Confirm whether exposed credentials are live using only systems you control. Compare exposed password hashes against your own authentication store where technically possible, check for successful authentications from anomalous sources in your own logs, and look for session tokens still valid in your own platforms. Never test recovered credentials against a third party service, including services your staff use, because that is unauthorised access regardless of intent. A good output is a validated live-exposure subset supported by your own telemetry. Stop when the live set is established or the limits of internal visibility are documented.

Phase 6 — Contain the exposed accounts

Act on validated exposure immediately: force credential reset, revoke active sessions and refresh tokens, enrol or reassert multifactor authentication, and review recent activity on the account for signs of prior use. For privileged accounts, rotate any secrets the account could reach. Sequence containment so that the reset does not tip off an intruder already inside before you have visibility. A good output is a containment record per account showing what was rotated and when, plus the outcome of the activity review. Stop when every live-exposed account has been reset and reviewed, not merely reset.

Phase 7 — Hunt for prior exploitation

Assume exposed credentials may already have been used and hunt accordingly. Look back across authentication logs for successful logins from unusual geographies, impossible travel, new device registrations, mail rule creation, unusual delegation and forwarding, and access to sensitive repositories by accounts that had no business reason. Set the lookback to the earliest plausible circulation date, not the disclosure date. A good output is a documented hunt with the queries used, the period covered and either findings or a clean result with stated coverage. Stop when the hunt covers all systems the account could reach or the visibility gaps are recorded.

Phase 8 — Handle personal data lawfully

Where exposure involves customers, staff or third parties, hand the regulatory questions to privacy and legal counsel immediately, since notification duties run on statutory clocks measured in hours. Restrict who can see matched personal data, log every access, and set a retention period with automatic deletion. Do not retain a copy of a breach dataset for future convenience. A good output is a documented processing record naming the lawful basis, the minimisation applied and the deletion date. Stop when the retention decision is recorded and the data is either minimised to non-identifying form or scheduled for deletion.

Phase 9 — Notify and support affected people

Where individuals are affected, tell them clearly what was exposed, what it enables, what you have done and what they should do, in plain language and without minimising. Offer practical support such as guided password manager adoption and multifactor enrolment rather than generic advice. For staff in high-risk roles or high-risk jurisdictions, treat the notification as a duty of care conversation with follow-up. A good output is a notification that measurably changes recipient behaviour, tracked by reset and enrolment rates. Stop when affected people have been reached and the residual non-responders have been individually followed up.

Phase 10 — Feed the findings into controls

Convert exposure into structural change: block known-breached passwords at the point of setting, require phishing-resistant multifactor for privileged and remote access, reduce standing privilege, and stop using corporate addresses to register on low-value external services. Track whether repeat exposure of the same accounts falls. A good output is a specific control change traceable to a specific exposure finding, with a measured effect. Stop when the control change is live and measured, not when it is agreed.

Phase 11 — Run it continuously and review

Move to continuous monitoring so a new exposure raises a case within hours rather than at the next review. Maintain the identifier scope as domains and entities change, revisit provenance judgements when a dataset is reclassified, and review whether the response process is actually reducing time to reset. Record calibration: how often a flagged exposure turned out to be recirculated material. A good output is a running capability with measured detection to containment time and a falling false alarm rate. Stop tuning when analysts act on alerts rather than triaging them out of habit.

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	Aggregated index of breach exposure by email address and password hash, with documented breach descriptions and verification notes.	Primary lawful exposure check, including the hash-prefix range API that avoids disclosing the identifier being queried.
Mozilla Monitor	Registration	Consumer-facing breach notification service built on aggregated breach indexes with guided remediation advice.	Practical self-service option to recommend to staff and at-risk partners for their personal accounts.
Information Commissioner Office	Open	United Kingdom data protection regulator publishing breach reporting requirements, enforcement actions and guidance on personal data handling.	Defines notification duties and the lawful basis analysis required before processing breach datasets.
European Data Protection Board	Open	European coordinating body publishing guidelines on breach notification, lawful basis and data minimisation under the General Data Protection Regulation.	Governs how exposure data about European data subjects may be processed, retained and disclosed.
CISA	Open	United States cyber agency publishing guidance on credential compromise, identity controls and phishing-resistant authentication.	Supplies the control recommendations that convert exposure findings into durable authentication changes.
NCSC United Kingdom	Open	National technical authority publishing password policy, credential stuffing and account recovery guidance for organisations.	Anchors password and multifactor policy changes made in response to exposure to authoritative national guidance.
NIST digital identity guidelines	Open	Standards for authentication assurance including guidance on breached password screening and prohibited password lists.	Provides the standards basis for blocking known-exposed passwords at the point of credential setting.
Shadowserver	Registration	Non-profit reporting operation delivering free notifications of compromised hosts and credential-related exposure to verified network owners.	Independent notification channel that frequently surfaces credential-related compromise before internal detection does.
abuse.ch	Open	Operator of open threat data projects covering malware distribution, botnet command infrastructure and malicious URLs.	Identifies infostealer families and distribution infrastructure responsible for the credential harvesting behind many exposures.
VirusTotal	Registration	Multi-engine analysis platform with file, URL and behavioural reporting including infostealer sample analysis.	Characterises the malware responsible for credential theft when exposure appears to originate from device compromise.
MISP	Open	Open source platform for structured storage and controlled sharing of intelligence including breach and credential exposure objects.	Holds provenance records and exposure cases with access control and defined retention on personal data.
Internet Crime Complaint Center	Open	United States reporting channel and public reporting on cyber-enabled fraud including business email compromise driven by credential theft.	Provides the reporting route and loss context linking credential exposure to downstream fraud outcomes.
Europol	Open	European law enforcement agency publishing organised crime assessments and announcements of marketplace and infostealer disruptions.	Confirms takedowns and marketplace seizures that change the circulation status of a dataset.
OWASP	Open	Community publishing authentication, credential stuffing and session management guidance with testing methodology.	Guides the application-side controls that reduce the value of exposed credentials against your own services.

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 Breach Intelligence. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

k-anonymity range query clients — Submit a short hash prefix and match locally so the identifier never leaves your control. Limitation: only covers datasets the exposure service has ingested and verified.
Directory and identity provider audit tooling — Enumerates accounts, privilege and multifactor status to scope which exposures matter. Limitation: shadow accounts on unmanaged services stay invisible.
Breached password screening in authentication flows — Blocks known-exposed passwords at the point of setting rather than after compromise. Limitation: list currency varies and offline lists date quickly.
Authentication log analytics — Detects anomalous logins, impossible travel and token reuse indicating exposed credentials in use. Limitation: retention windows are often shorter than the exposure lookback needed.
Session and token revocation tooling — Invalidates live sessions and refresh tokens so a reset actually ends attacker access. Limitation: coverage across federated third party applications is usually incomplete.
Password manager deployment tooling — Removes reuse structurally, which is the only durable fix for cross-service exposure. Limitation: adoption depends on change management, not on the technology.
Hash cracking rigs used defensively — Test the strength of your own stored hashes against exposed candidate lists under authorisation. Limitation: legally and ethically restricted to your own credential store.
Case management with enforced retention — Holds exposure cases with access logging and automatic deletion dates for personal data. Limitation: only effective if deletion is actually enforced rather than configured.

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.

Threat Hunt — Runs saved hypotheses against the corpus and surfaces what matches, with the query preserved as a versioned artifact.
Auto-Collect Feeds — Pulls the registered feed set server-side on a schedule, recording per-feed status so a silently dead feed is visible.
Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
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:

Match by hash prefix, never by acquiring the dump. Range querying gives you the same answer without ever holding another persons stolen data, and it removes the entire legal and custodial problem rather than managing it.
Separate breach date, disclosure date and circulation date. Response urgency is driven by when the credentials began circulating, and lookback hunts anchored to the disclosure date routinely miss the window when the data was actually used.
Most alarming new mega-breaches are compilations. Check field structure, record overlap and known-sample matching before mobilising a response, because recirculated material produces expensive noise and erodes trust in the capability.
The finding is not exposure, it is enablement. Ask what the exposed credential unlocks today given your current authentication controls, because a plaintext password against phishing-resistant multifactor is a low-grade finding.
Never test a recovered credential against a service you do not own, including services your staff use. Intent is irrelevant to unauthorised access offences, and one such test can invalidate an entire investigation.
Infostealer output is a different category from database breach. It arrives fresh, includes session cookies that bypass multifactor entirely, and implies an infected device that still needs remediating after the reset.
Reset alone is not containment. Without session and refresh token revocation the intruder keeps working through an authenticated session while your report records the account as remediated.
Treat any retained breach dataset as a liability you now own. If it must exist, minimise it to non-identifying form, log every access and set an enforced deletion date before the first analyst opens it.

Measuring whether it is working

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

Median time from a credential exposure becoming known to completed containment, measured as reset plus session revocation plus activity review, not reset alone.
Proportion of exposure alerts that proved to be recirculated compilations rather than new breaches, which should fall as provenance assessment matures.
Percentage of privileged and remote-access accounts protected by phishing-resistant multifactor, which determines how much any exposure actually enables.
Repeat exposure rate for the same accounts across successive periods, indicating whether password reuse behaviour is genuinely changing.
Share of exposure cases where a lookback hunt was completed with documented coverage rather than assumed clean.
Number of breach datasets retained in identifiable form and the proportion past their scheduled deletion date, which should be zero.
Proportion of affected individuals who completed the recommended remediation after notification, rather than the proportion notified.

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

Recycled combolists inflate counts, as the same credentials are repackaged and resold for years and reported repeatedly as new
Treating a hit as proof of compromise; exposure of an old hashed password is not evidence that any account was accessed
Ignoring stealer logs because the credential is not in a named breach, when those are the freshest and most dangerous exposures
Resetting passwords without revoking sessions and refresh tokens, leaving the attacker existing authenticated session fully alive
Acquiring dumps directly from criminal venues, creating possession and data-protection liability out of proportion to the intelligence gained
Monitoring only corporate addresses, missing the personal accounts used as recovery addresses for corporate services

Legal and ethical considerations

Breach data is other people personal data and frequently the proceeds of crime. Purchasing or downloading dumps can amount to handling stolen data and makes you a controller under GDPR and equivalent regimes. Prefer licensed providers with documented lawful acquisition, or hash-matching services that never transmit plaintext. Minimise aggressively: store match results rather than full records, set retention limits and restrict access. Your own notification duties may be triggered when customer data appears. Never test recovered credentials against live systems without written authorisation.

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 Breach Intelligence, 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 7 data points, 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

Should we ever buy a breach dataset to check our exposure?

No. Purchase funds the criminal market, may constitute handling stolen data or an offence in itself, and in sanctioned contexts can breach financial sanctions. It also makes you the controller of a large volume of other peoples personal data with all the attendant obligations. Every legitimate question you have can be answered by hash-prefix matching against a reputable exposure service or through a licensed provider operating under a data processing agreement. If a specific dataset is central to an investigation, the correct route is law enforcement, who can obtain it lawfully under warrant with proper custody.

How do I tell a real new breach from a recirculated compilation?

Look at structure rather than headline claims. Check whether the field set is coherent for a single source system, whether email domains and account creation dates cluster in a plausible way, and whether a sample of records matches known older breaches. Genuine single-source breaches have consistent schema and a bounded date range; compilations show mixed schemas, wide date spread and heavy overlap with previously indexed datasets. Reputable exposure services publish verification notes and overlap statistics. If you cannot establish provenance, respond proportionately and label the assessment unverified rather than triggering a full incident.

What is the right lookback period for hunting prior use?

Anchor it to the earliest plausible circulation date, not the public disclosure date, because credentials often circulate privately for months or years before appearing publicly. If the breach date is known, hunt from there. If it is not, use the earliest evidence of circulation you can establish and state the assumption. The practical constraint is log retention, and the common finding is that retention is shorter than the required lookback. Document that gap explicitly rather than reporting a clean hunt, and use it to make the case for longer authentication log retention.

Are infostealer logs the same problem as a database breach?

No, and treating them the same is a serious error. Infostealer output comes from a compromised device and typically includes session cookies and tokens alongside credentials, which means a password reset does not end access, and multifactor may be bypassed entirely by session replay. It also implies the device itself is compromised and may still be. Response requires session and token revocation, device isolation and rebuild, and a review of everything the browser profile could reach. The exposure is also far fresher, which raises urgency substantially compared with an old database dump.

Can breach data be used as evidence?

Rarely on its own. A dataset obtained from a criminal venue has no chain of custody, unknown integrity and unknown completeness, and defence counsel will attack all three. It can lawfully serve as intelligence to direct an investigation. To become evidence, the underlying facts normally need to be re-established from an authoritative source, for example the breached organisation providing the relevant records under production order, or a device seized under warrant. Where breach data is itself the subject of the charge, custody starts from the seizure and must be documented from that point with hashes and continuity records.

How should we handle executive personal account exposure?

Carefully and consensually. Exposure of a personal account can create real organisational risk through password reuse, personal device access to corporate mail and targeted extortion. But the personal account is not yours to monitor. The defensible approach is to offer a voluntary service: explain the risk, offer a check the individual initiates, and provide practical support with password managers, multifactor and account recovery. Do not enrol personal identifiers into monitoring without informed consent, do not retain results in corporate systems without agreement, and route anything suggesting targeting to a protective security conversation rather than a ticket.

What retention period is appropriate for exposure findings?

As short as the purpose allows, and defined before you collect. Matched exposure records containing personal data should generally be minimised to a non-identifying case record once containment is complete, retaining the fact that account X was reset on date Y rather than the exposed credential. Statistical aggregates can be kept longer. Any full dataset should not be retained at all in normal corporate practice. Write the retention schedule into the processing record, enforce it with automated deletion, and audit compliance, because an indefinite exposure archive is one subject access request away from becoming a regulatory problem.

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:

The EU General Data Protection Regulation and the UK Data Protection Act 2018, which govern lawful basis, minimisation, retention and breach notification duties.
NIST SP 800-63 digital identity guidelines, which govern authentication assurance levels and the screening of credentials against known-exposed lists.
ISO/IEC 27035 on information security incident management, which governs the response process triggered by confirmed credential exposure.
ISO/IEC 27701 on privacy information management, which governs the controls applied when processing personal data in an exposure programme.
The Budapest Convention on Cybercrime, which governs cross-border preservation and cooperation where breach data supports a criminal investigation.
The UK Computer Misuse Act 1990 and equivalent legislation, which govern why testing recovered credentials against third party services is unlawful.
Payment Card Industry Data Security Standard, which governs handling and notification obligations where exposed data includes cardholder information.
Traffic Light Protocol 2.0, which governs onward sharing of exposure notifications between organisations and sharing communities.

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.

Have I Been Pwned breach index and range API — Have I Been Pwned. Aggregated breach exposure index supporting privacy-preserving hash-prefix queries
Personal data breach guidance — Information Commissioner Office. United Kingdom regulator guidance on breach assessment, notification and lawful processing
Guidelines on personal data breach notification — European Data Protection Board. European guidance on notification thresholds and processing of breach material
Digital identity guidelines — National Institute of Standards and Technology. Authentication assurance standards including breached password screening
Password and authentication guidance — UK National Cyber Security Centre. National guidance on credential policy, multifactor and account recovery
Identity and credential compromise guidance — Cybersecurity and Infrastructure Security Agency. Guidance on phishing-resistant authentication and credential compromise response
Internet Crime Report — Internet Crime Complaint Center. Annual reporting linking credential compromise to business email compromise losses
Daily compromised host reporting — Shadowserver Foundation. Free notification of compromised and exposed assets to verified network owners
Internet Organised Crime Threat Assessment — Europol. European assessment of credential markets, infostealer ecosystems and disruptions

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: monitors your domains and identities continuously with dated provenance and automatic containment triggers. Explore the platform, or browse the rest of the library by following any tag above.