People and company OSINT, done carefully

People OSINT maps the humans and accounts around a target: usernames, work emails, public profiles, and whether an address shows up in a known breach. It is the most privacy-sensitive part of recon, so the rule comes first. You collect what the scope needs about accounts tied to your target, you do not build dossiers on private individuals, and breach data is handled as the sensitive record it is.

#Usernames across platforms

A handle reused across sites links accounts. sherlock checks one username against hundreds of platforms.

sherlock exampledev --timeout 5 --print-found

maigret does the same across more sites and tags, and can write a report folder.

maigret exampledev --folderoutput ./maigret-out

A hit means the name exists on that platform, not that it is the same person. Confirm by the account content before you link two handles to one human.

#Email discovery and validation

Work emails usually follow a pattern such as first.last at the domain. theHarvester collects addresses tied to a domain from public sources.

theHarvester -d example.com -b bing,crtsh -f example-emails

holehe checks which sites already have an account registered to an address, without sending the person anything.

holehe [email protected] --only-used

Keep this to addresses on your scope's domain or ones the program told you are in scope. An address outside that is someone's personal account, and it is not yours to probe.

#Breach-notification sources

A breach-notification service tells you whether an address appeared in a known data breach, which matters for exposure, not for logging in. Have I Been Pwned is the standard source and has an API.

curl -s -H "hibp-api-key: $HIBP_KEY" \
  "https://haveibeenpwned.com/api/v3/breachedaccount/[email protected]"

A hit lists the breaches an address was in. It does not give you passwords, and you should not seek them. The finding is that the address was exposed in a named breach, and that belongs in a report so the owner can force a reset. Treat the list itself as sensitive, because a record that an address was breached is still personal data, so it stays encrypted and out of any shared screenshot.

#Let the chat structure, not snoop

The NotHoly chat has no access to any of these services; it structures what you already gathered.

Here are usernames, emails and breach names for accounts in
my scope. Build a table: account, platforms confirmed, domain,
breach exposure, confidence. Mark anything that is a guess.

Use it to turn scattered findings into one table with a confidence column, which stops you from stating a guess as a fact. It will not and cannot pull more data on a person.

#Scope and privacy

This is where OSINT touches real lives, so three limits keep it clean. Collect only accounts tied to the target in scope, not an employee's private life. Store breach data encrypted, share it only through the program's channel, and delete it when the engagement ends. Never use a breached password or a found email to log in anywhere, and when you are unsure whether something is in scope, leave it out.

#Frequently asked questions

#Can I look up a specific employee's accounts?

Only when the person's work identity is in scope and the purpose is the engagement, not curiosity. A personal account outside work is their private data, so stay off it.

#Does checking an email against a breach service tell the person?

No. The query goes to the breach service, not the mailbox. holehe and sherlock likewise query third-party sites, not the target, but the data they return is still about a person, so handle it with care.

Accounts and people fill in the human layer. Next, learn image and location work in image and geolocation OSINT basics. Back to search-engine dorking that works.