GDE-050 |
Have I Been Pwned for OSINT | |||||||
Breach and credential exposure | ||||||||
September 2026 | ||||||||
01
What it is
Have I Been Pwned for OSINT is the practice of using Troy Hunt's free breach-notification service to confirm whether an email address has appeared in a known data breach, and treating that exposure as one corroborating signal in a wider identity investigation rather than as a standalone finding.
Have I Been Pwned (HIBP) aggregates data from publicly known breaches and lets anyone check a single email address for free, with no login required. It also runs Pwned Passwords, a k-anonymity password check that never receives the plaintext password, and separate lookups for pastes and infostealer malware logs. Domain-wide search is available after a one-time ownership verification.
Investigators use HIBP to confirm an address has a documented history of exposure, to date that exposure against other timeline evidence, and to flag which breach sources involve particularly sensitive categories of data. It answers a narrow question well: has this address appeared in a known breach, not whether an account is currently compromised.
| When to use this guide
|
02
How do you use Have I Been Pwned for OSINT?
Six steps from a free single-address check through to a verified domain-wide search.
The following resources are used across the steps below.
Have I Been Pwned (web): Free, no login. Single-address lookup returning every breach and paste the address appears in, with breach dates and the categories of data exposed.
Pwned Passwords: Free, no login or key. Checks a password against known-breached password hashes using k-anonymity; only a partial hash is ever sent, never the plaintext password.
HIBP API v3: Free and paid tiers. An API key is required for programmatic email search, domain search and stealer-log lookups. Most domain searches remain free after one-time verification; very high-volume domains fall into paid tiers.
| Before you begin Stop at the login. None of the lookups in this guide require logging into anything belonging to the subject. Pwned Passwords hashes any password client-side and sends only a short partial hash, so HIBP never receives the plaintext password at any point. Legal considerations. A breach listing shows historical exposure, not proof of a currently compromised account or wrongdoing by the address holder. Treat it as one corroborating signal, and handle any breach-derived personal data, especially from a sensitive-flagged breach, under the same lawful-basis and retention standard as any other personal data in the investigation. |
Enter the address at haveibeenpwned.com. Record every breach returned, its date, and the categories of data it exposed, such as passwords, phone numbers or physical addresses.
HIBP separates certain sensitive breach sources, such as those tied to dating or health services, behind an explicit opt-in on the web search. Treat a sensitive-flagged hit with additional care given its outsized privacy and reputational stakes.
The stealer log lookup surfaces infostealer malware captures, which are often far more recent than a historical breach and carry higher immediate risk. This lookup requires an API key.
Run the address through the Pastes search to surface any Pastebin-style dump referencing it outside HIBP's formal breach corpus.
Cross-check any hit against a live account-enumeration pass, since HIBP's breach corpus and a tool such as Holehe or Maigret answer different questions: one shows past exposure, the other shows current account registration.
For a domain rather than a single address, complete HIBP's one-time domain ownership verification, after which most domain searches remain free. Very high-volume domains require a paid API tier.
|
03
What are the pitfalls of using breach data?
Exposure history is not the same as current compromise, and absence from HIBP proves nothing.
Breach exposure mistaken for a currently compromised account: a password exposed in a 2019 breach may have been changed years ago, so a hit alone says nothing about the account's current state. Verifying check: cross-reference against a live account-enumeration check before treating an address as presently compromised.
Breach date mistaken for recent activity: HIBP's breach corpus spans well over a decade, and an old breach can read as significant if its date is not checked. Verifying check: note the breach date on every finding and weight older breaches accordingly.
Sensitive-category breach handled the same as an ordinary one: a hit against a dating or health-related breach source carries materially higher privacy stakes than a generic retailer breach. Verifying check: apply your organisation's stricter handling standard to any sensitive-flagged breach before using it further.
Absence from HIBP mistaken for a clean history: HIBP only contains breaches it has ingested and verified; a breach that has not been added, or one HIBP was never given, will not appear. Verifying check: treat a clean HIBP result as inconclusive, not as proof the address has never been exposed.
Chain of custody: a breach listing is time-sensitive; HIBP's corpus is periodically updated, and a result captured today may show more or fewer breaches on a later re-check.
Screenshot the breach list and its timestamp before citing it in an investigation file.
Record the name and date of each individual breach cited, not just the total count.
Do not retain any password hash or plaintext beyond what HIBP itself displays on screen.
Flag any sensitive-category breach explicitly in the record, so a later reviewer applies the correct handling standard.
04
Go deeper
Enumeration and email OSINT guides that pair with breach-history checks.
GUIDE · GDE-009
Email account enumeration: tools beyond Holehe
The live account-registration check that corroborates a breach-history finding.
GUIDE · GDE-005
Email OSINT: trace an address to accounts and infrastructure
The foundational email workflow breach-history checks fit into.
Evidentiary standard
Signal & Shadow operates to the LST-001 evidentiary standard. All claims are graded against the LST-001 v1.0.3 confidence tiers (Confirmed, Corroborated, Reported, Alleged) per the canonical voice and structural specification.
About Signal & Shadow
Signal & Shadow is an independent forensic investigation and methodology practice publishing tutorials, reference cards, and forensic dossiers for working practitioners. Founded by Derek Bowler.