Hunt a handle
Handle reuse is the cheapest strong link in OSINT: one string, checked in
minutes, potentially tying a dozen platforms to one person. It is also the most
over-trusted. Enumerators do not verify identity — they perform HTTP existence
checks — and a hit list is a list of candidates, nothing more. The mistake
that ruins these investigations is pasting the tool's output into the report.
Enumeration is the cheap half; confirmation is the work.
Step 1 — Authorized scope
Read ../../ETHICS.md and write down, before any query:
subject, objective, in-bounds selectors, out-of-bounds actions (logging in,
contacting, requesting follows), and the governing jurisdiction. Handle hunting
drifts easily — one run hands you thirty new platforms, and it is trivial to end
up profiling an uninvolved person who shares the string.
Done when scope is written down and you can name what would put you out of
bounds.
Step 2 — Pick your enumerator
| Holding | Reach for | Why |
|---|
| One handle, need breadth fast | | Largest quick sweep, existence only |
| One handle, need profile content | | Parses the page: display name, bio, IDs, links, sometimes country and creation date |
| Need to see why a hit fired | WhatsMyName data | Every check is a declared URI plus a match rule you can read |
| A handle on one known platform | Manual visit | Nothing beats reading the actual profile |
bash
sherlock jdoe_92 --timeout 10 --csv
maigret jdoe_92 --html
maigret is the higher-value tool for correlation because it returns fields,
not booleans. A display name, avatar URL, self-declared location, numeric user
ID and an "also known as" list give you material to test the next platform
against. Sherlock gives you a URL and a claim.
WhatsMyName is a detection list, not a scanner: a JSON file of site entries,
each with a URI template and explicit match criteria (an expected HTTP status
and an expected string in the body, plus the equivalent for "missing"). Read the
entry for any site you doubt — it tells you exactly what the tool considered
proof. Many wrappers and web front-ends consume the same list, so a hit in three
different tools is often one rule firing three times, not three independent
confirmations.
Done when every candidate is recorded with platform, URL, the tool that
found it, and live/dead status.
Step 3 — Generate variants
The handle you were given is one point in a person's naming habit. Recover the
habit and you find the accounts the first sweep missed.
- Separator swaps: , , ,
- Truncations and initials: , , ,
- Number suffixes: birth year, birth year two-digit, , ,
- Leetspeak and character substitution: ,
- Email local part as handle, and handle as email local part
- Gamer-tag morphology: prefixes, , clan tags, doubled letters
Full pattern list: reference/variant-patterns.md.
Two inference directions matter. Handle → name:
suggests a
first-initial-lastname pattern and a 1992 birth year, which is a hypothesis to
test, not a finding. Name → handle: if you already have a real name, generate
the handles that name would plausibly produce and enumerate those too — it often
outperforms starting from a handle someone gave you.
Done when the variant set is enumerated and the ones that produced hits are
folded back into Step 2.
Step 4 — Confirm, or reject
For each candidate, look for evidence that survives a skeptical reader.
Strong:
- Same avatar. Verify with — a match to a stock photo
or a third party's picture is a rejection, not a confirmation.
- Byte-identical or near-identical bio text, especially with a typo or an unusual
phrasing carried across.
- A self-declared cross-link: the profile links the other profile. Best evidence
available short of an admission.
- A contact selector present on both (same email, same personal domain).
Moderate:
- Account creation dates clustering in a narrow window across platforms — people
sign up for things in bursts.
- Follower/following overlap with the same distinctive small accounts.
- Writing style: idiom, punctuation habits, timezone of posting.
Weak on its own: the handle matching. That is the thing you are testing, not
evidence for it.
Platforms exposing a
numeric user ID are disproportionately useful. Where
IDs are issued in registration order, the ID bounds an account's creation date
even when the profile hides it. GitHub's
https://api.github.com/users/<login>
returns a numeric
and
;
Discord's snowflake IDs encode a creation timestamp directly. Per-platform
detail:
reference/platform-leakage.md.
Done when every candidate is graded confirmed, probable, or rejected, each
with its evidence written next to it.
Where this goes wrong
Existence checks are HTTP heuristics. Every one of these produces a false
positive:
- Soft 404s. The site returns 200 with a "user not found" page. If the match
rule keys on status code, everything exists.
- Catch-all profile pages. Some platforms render a generic shell for any
string and only 404 on the API.
- Rate-limit and CAPTCHA interstitials. A challenge page is a 200 with body
content, so it can satisfy both the "found" and "missing" rules — and once you
are rate-limited, results for the rest of the run are garbage. Re-run failures
separately rather than trusting a single sweep.
- Reserved, squatted, and impersonation accounts. Registered, real, not your
subject.
- Stale entries. Sites change their 404 behaviour and detection lists lag.
Absence of a hit is not absence of an account.
The deeper problem is collision. Common handles belong to many unrelated people,
and a short or dictionary-word handle across ten platforms is ten people far
more often than one. Confidence should scale with the handle's distinctiveness:
a rare invented string is itself weak-to-moderate evidence,
is none.
Do not resolve ambiguity by logging in, messaging, or requesting a follow. That
is interaction, out of scope by default, and it tells the subject you exist —
see
investigate-without-getting-made
.
Confidence grading
- Confirmed — an avatar match verified through
plus one other strong item, or a self-declared cross-link between the two
profiles, or a shared contact selector.
- Probable — distinctive handle plus one moderate item (creation-date
cluster, follower overlap, consistent style) and no contradicting evidence.
- Unconfirmed — the handle matches and nothing else does. Report it as an
enumeration hit, not as the subject's account.
- Rejected — content, language, timeline, or avatar provenance contradicts
the subject. Record rejections; they stop the next analyst redoing the work.
Worked example
Given
. Sherlock returns 14 hits. maigret returns 9 with content,
including a code-hosting profile with display name "A. Okonkwo", a photography
site with the same avatar, and a forum with an empty shell profile.
The forum hit is discarded first: fetching a deliberately absurd handle on the
same forum also returns 200 with an identical empty page. Catch-all, not an
account.
The avatar on the photography site reverse-searches (via
) to the same image on the code-hosting profile and
nowhere else — good. The code-hosting API gives a numeric ID and a creation date
in the same month as the photography account's stated join date. Two moderate
items plus an avatar match: confirmed for both.
A microblog hit with the same handle posts in a different language about
unrelated subjects, on an account predating the others by six years. Different
person, same string — rejected, and stated explicitly, because it is the first
thing a reviewer will find.
Pivots
| New selector | Skill |
|---|
| Display name / real name | |
| Exposed or inferred email | |
| Phone number on a profile | |
| Avatar or posted photos | , |
| Photos with location context | |
| Code-hosting handle | |
| Personal domain in a bio | |
| Handle in credential dumps | |
| Full posting history on a confirmed account | pattern-of-life-from-socials
|
| The account map itself | |
Legal and ToS notes
Automated enumeration hits platforms with scripted requests, which most terms of
service prohibit regardless of the data being public. Keep concurrency low, do
not defeat CAPTCHAs, and stop when a platform signals refusal. In the EU and UK,
assembling scattered public accounts into a profile of a living person is
processing personal data and needs a lawful basis and data minimisation.
Step 5 — Report
Run
. Give the platform/URL/confidence/evidence table,
list rejections with reasons, and lead with the real-name and contact selectors
the handles produced.
Done when every candidate in the table carries a grade and a source, and no
enumeration hit appears without one.