Username and Email OSINT: Sherlock, Holehe, and Breach Pivots
people pick one handle at nineteen and ride it into the grave. the same username on github, reddit, keybase and a crypto forum is not four people, it is one person who hates coming up with names. that laziness is the backbone of username and email osint, and it is how an investigator maps an actor’s footprint without sending a single phishing email.
step 1: enumerate accounts from a username (sherlock)
sherlock (and maigret, which goes deeper) checks a username against hundreds of sites and reports where it exists. it is the fastest way to turn one handle into a footprint.
the value is not the list, it is what the profiles then leak: a github with a real name in the commit email, a reddit history that reveals a city and a job, a keybase that ties the handle to a pgp key and other accounts. sherlock finds the doors; you still have to read what is behind them. false positives happen, so verify each hit rather than trusting the green plus.
step 2: check an email without touching the target (holehe)
holehe asks a clever question: for a given email, which sites say “this address already has an account”? it uses password-reset and registration flows to detect existence without logging in, bruteforcing, or alerting the owner.
this maps an email’s surface: a target who uses the same address on spotify, github and imgur gives you three more profiles to pivot into. critically, holehe is non-intrusive by design, which is what keeps it on the right side of the line. you are reading public existence signals, not trying doors.
step 3: correlate breach data (carefully)
breach data is the force multiplier and the ethical minefield. correlating an email against known breach corpora can reveal reused usernames, linked alternate emails, and (unfortunately) old passwords that reveal a person’s naming habits. the legitimate use is understanding exposure and linking identifiers in an authorized investigation.
for defenders, the cleanest and most defensible tool is have i been pwned: check whether your org’s addresses appear in breaches and force resets. for deeper correlation, tools like h8mail work against local corpora, but handling breach dumps carries real legal and privacy obligations. do not go collect leaked databases for fun. use hibp for exposure, and treat raw breach data as something you only touch with authorization and a reason.
the pivot chain
- username -> sherlock/maigret -> list of platforms
- read each profile for real name, location, linked accounts, emails
- email -> holehe -> more platforms (non-intrusive)
- email -> hibp for exposure; authorized breach correlation to link identifiers
- loop: new username or email found restarts the chain
what defenders can do
- map your own exposure: run these against your org’s handles and addresses to see what an attacker sees. that executive who reuses a personal handle on a crypto forum is a spear-phishing map.
- enforce hygiene: unique usernames and emails per context break the reuse pivot. password managers make this painless.
- monitor breaches: hibp domain monitoring plus forced resets closes the credential-stuffing door.
- threat-model your vips: the people with the most reuse are often the most targeted. prioritize them.
sloth take
the whole discipline runs on the fact that humans reuse one handle and one email across their entire adult life. sherlock finds the doors, holehe checks which ones exist without knocking, breach data connects the person behind them. point it at your own org to find what leaks before an attacker does, and keep it pointed there.
sources
- Sherlock and Maigret username enumeration projects
- Holehe email account-existence checker
- Have I Been Pwned (haveibeenpwned.com) for breach exposure
- h8mail for authorized local breach correlation
- Lab artifacts generated on-box 2026-10-17 (synthetic identifiers and terminal captures)
