how to check if an employee's email is in a breach dump

how to check if an employee's email is in a breach dump

TL;DR

Do not paste employee addresses into random breach-checker websites. Use Have I Been Pwned's k-anonymity API: hash the address with SHA-1 locally, send only the first 5 characters of the hash, and check whether the full hash appears in the returned list. The service never sees the address. For ongoing coverage, subscribe your company domain to breach notifications. A hit means force a password reset, check for reuse, and turn on MFA, not panic.

how to check if an employee's email is in a breach dump

Use this when

• Screening during onboarding or a security review, with consent
• A major breach is announced and you need to check exposure
• Building an employee exposure monitoring process
• An employee asks whether their work address has been breached

Not for this skill when

• You want to download or search raw breach dumps yourself (do not)
• You are checking someone's address without a legitimate reason and consent
• You need password-specific checking (different endpoint, same service)

Steps

1. Check one address with the k-anonymity API

addr="[the address]"
prefix=$(echo -n "$addr" | sha1sum | cut -c1-5)
curl -s "https://api.haveibeenpwned.com/range/$prefix" -A "company-breach-check" | grep -i "$(echo -n "$addr" | sha1sum | cut -c6-40 | tr 'a-f' 'A-F')"

Expected: either a line like SUFFIX:COUNT meaning the address appears in that many breaches, or no output meaning no known breach. Only the 5-character hash prefix leaves your machine, so the full address is never exposed to the service.

2. Identify which breaches are involved

The range response gives counts, not breach names. For a confirmed hit, look up the address on the service's website (with the employee's knowledge) or use the authenticated API to get the breach names and dates. Knowing it was a 2019 forum breach versus a 2026 credential-stuffing dump changes how urgently you act.

3. Set up domain-level monitoring for ongoing coverage

curl -s "https://haveibeenpwned.com/api/v3/breaches" | python3 -c "import json,sys; [print(b['Name'], b['BreachDate']) for b in json.load(sys.stdin)[:5]]"

Expected: the most recent breaches in the dataset. Subscribe your company domain to the domain search feature (it requires proving you control the domain) so you get notified when new breaches affect any address on it, instead of checking one by one forever.

4. Act on a hit

Force a password reset for that account, ask about password reuse on other services, enable MFA if it is not on, and review recent login activity for anything odd. Then log it:

echo "[the address] | breach hit | reset forced | $(date -u +%F)" | tee -a breach-response-log.txt

Expected: one line in the response log. The log matters because the same address will come up again and you do not want to start from zero next time.

Variant: onboarding screening

With documented consent, check new hires' work addresses during onboarding and require MFA from day one for any hits. Make it a standard step, not a suspicion-driven one.

Variant: the whole domain lights up after a big breach

Prioritize privileged and externally-facing accounts first, then work down the list. A company-wide forced reset is disruptive, so sequence it: admins and finance today, everyone else this week, with clear communication about why.

Variant: paste dumps

Separately check the paste endpoints for addresses appearing in pastebin-style dumps, which often surface before the breach itself is confirmed. Same k-anonymity approach.

Why this happens

Breach dumps circulate for years and get combined into credential-stuffing lists. An address breached in 2019 is still being tried against logins today, especially when people reuse passwords. Checking exposure is not about the old breach, it is about whether that old breach still hands attackers a working key to something current.

Edge cases and pitfalls

• No hit does not mean safe, only not in known dumps. Keep MFA on regardless.
• The k-anonymity API covers addresses. Checking passwords uses a separate endpoint with the same hash-prefix idea.
• Do not build a habit of checking addresses you have no business checking. Document consent and purpose for employee checks.
• Hash the address exactly as-is. Case and whitespace differences change the hash and give false negatives.
• Rate limits apply to the API. Batch sensibly and cache results.
• A hit on a shared or role address needs a different response than a personal one. Figure out who actually uses it before forcing resets.

Tool notes: Have I Been Pwned's free range API needs no key. Domain search and the full breached-account API need a key and domain verification.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2yGro2fpqZRRaTqcyDHnXw