UseOSINT/Skills

# Dig through data brokers

People-search sites resell a blend of public records, marketing data, and
self-reported data. They are fast, cheap lead generators and terrible evidence.
The one rule that matters: **a broker record is a lead, never a fact.** Confirm
every field you intend to use against the primary source the broker got it from —
and if you cannot identify that primary source, do not use the field.

## What these services actually are

Three input streams, blended and sold:

- **Public records** — property deeds, court filings, business registrations,
  voter files where public, professional licences, bankruptcy, marriage and

# Find anyone

Turn a name into a sourced profile of one specific human. The work is 20% finding
data and 80% proving the data belongs to your subject and not to someone with the
same name. Beginners collect first and disambiguate later; that is how you end up
with a confident, well-cited dossier describing two different people fused into
one. Bind the name to a second selector before you collect anything.

## Step 1 — Authorized scope

Write down, before searching: the subject, the objective, what is in bounds, what
is out of bounds, and which jurisdiction's law governs you and the subject. Read
[../../ETHICS.md](../../ETHICS.md).

# Find exposed servers

Internet-wide scanners already scanned your target. Querying their results is
passive — you never send a packet to the target, so nothing appears in their logs
and nothing is attributable to you. The cost is that every result is a claim about
a moment in the past, and the beginner's mistake is reading a banner as the
current state of a live host.

## Which platform first

| You hold | Reach for | Why |
|---|---|---|
| An IP | Shodan host lookup, or the free InternetDB endpoint | One request gives ports, hostnames, and CPEs |
| A netblock or ASN | Shodan `net:`/`asn:` with port faceting | Shows the shape of the estate before you look at individual hosts |

# Find hidden subdomains

The hosts an organization forgot about are the ones worth finding, and most of
them announced themselves the moment someone requested a TLS certificate.
Certificate Transparency turns that into a searchable, permanent, historical
index — free and completely passive. The beginner's mistake is treating a CT hit
as a live host: most of what you pull back does not resolve, and that is
information too, not noise.

## Which source first

| You hold | Start with | Why |
|---|---|---|
| An apex domain | crt.sh wildcard query | Broadest free coverage, includes long-dead names |

# Find leaks in the wild

This is where data surfaces before anything indexes it, and where most of what
you find is a recombination of things that leaked years ago. Two mistakes cost
people most: assuming a paste host's own search will find pastes, and reporting
a combolist as a breach. The first wastes a day; the second is a factual error
in a deliverable and it will be found.

## Where to start with what you're holding

| You have | Start with | Why |
|---|---|---|
| An email or username | A curated breach service first | Cheap, attributed, and answers most questions — `what-leaked-about-you` |
| A selector you think is circulating now | `site:` sweep of paste hosts, then a paste aggregator | Engines are shallow but free; aggregators reach what was never crawled |

# Find the original image

The goal is almost never "find a match". It is **find the earliest publication
and read its page**. A match tells you the image exists elsewhere; the earliest
page tells you the photographer, the date, the caption, and the names — which is
what you actually pivot on.

The beginner mistake: uploading the full frame to one engine, getting nothing,
and concluding the image is unindexed. Cropping to one distinctive object and
re-searching finds things full-frame search cannot.

## Pick your engine by what you are holding

| You have | Start with | Why |

# Follow the Crypto

Public chains are pseudonymous, not anonymous. Every transfer is permanently
visible to anyone; what's missing is the mapping from address to human. So the
whole game is attribution, and attribution almost always happens at an
off-ramp — the point where value converts to fiat through a service that
collected identity documents. Everything between the crime and the off-ramp is
just plumbing you have to follow.

The beginner error is treating a clustering heuristic's output as fact. "These
addresses belong to the same entity" is a probabilistic inference with known
failure modes, and commercial attribution labels are proprietary guesses you
cannot audit. Trace confidently; attribute carefully.

# Geolocate from pixels

Every photograph taken outdoors contains enough information to place it. The
constraint is never the image; it is your patience and your reference knowledge.

The beginner mistake is searching before inventorying. People see a mountain,
type "mountain with two peaks" into a search box, and get nothing. The method is
the opposite: extract every clue first, rank them by how much of the planet each
one eliminates, and only then start searching — because the clue that pins the
country is usually not the one your eye went to.

## Rank your clues before you search

Work down this list. Each row eliminates far more of the world than the one below

# Search operators

Operators turn a search box into a filter over a crawled index. The cost is that
you are querying somebody's *index*, not the web — coverage, freshness and
operator fidelity vary enormously between engines. The mistake beginners make is
assuming their query ran as typed. Google routinely drops, stems, and
synonym-expands your terms, so a zero-result dork and a silently-rewritten dork
look nothing alike but are equally useless.

## Which engine for which job

| You want | Go to | Why |
|---|---|---|
| Broad coverage of mainstream web | Google | Largest index, worst operator fidelity |

# Graph the network

A list of thirty selectors and a graph of thirty selectors contain identical
information, and only one of them lets you see that two clusters share a node.
That is the entire justification: humans do not detect shared elements across
rows, and detect them instantly in a layout. The beginner mistake is treating
the graph as an output — a picture drawn at the end for the report. It is the
case's working memory, built from the first pivot, and the report is generated
from it.

## Decide the schema before the second node

Everything useful downstream — deduplication, centrality, querying, the report
table — depends on decisions made in the first ten minutes. Two rules:

# 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](../../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

# Investigate anything

The front door. Everything downstream is faster than the thinking that should
precede it, which is why most bad investigations are not collection failures —
they are framing failures. You can run forty tools against a name and produce a
confident dossier on the wrong person. The work here is deciding what question
you are answering, what would count as an answer, and what would prove you
wrong.

## Core vocabulary

Used across every skill in this repo, defined only here.

- **Selector** — one identifiable data point: name, handle, email, phone,

# Investigate without getting made

Collection is bidirectional. Most investigators are burned not by a clever
adversary but by a platform doing exactly what it advertises: telling the
subject who looked at their profile, suggesting the investigator to the subject
as someone they may know, or marking a story as viewed. The default failure is
not a leaked IP address. It is being logged into a real account.

## Threat-model first

OPSEC effort should be proportionate. Answer three questions before you spend a
day building infrastructure — or before you decide you need none.

1. **Who might notice?** A dormant shell company, a moderately technical

# Is this photo real

Verification order is the whole skill: **provenance first, pixels last.** Finding the
earliest copy and reading its caption settles more cases than every forensic filter
combined, and it produces evidence you can show someone. Pixel forensics produces a
colourful heatmap and an argument.

The beginner mistake is running error level analysis on a downloaded JPEG and announcing
the image is fake. The second is looking for deepfakes: the overwhelming majority of
deceptive media is **real footage with a false caption** — right pixels, wrong war,
wrong year, wrong country.

## Triage: what question are you actually answering

# Pattern of Life from Socials

Pattern-of-life analysis turns scattered public posts into a model of where
someone is, when, and with whom. It is the most abusable technique in this
repo: the same method produces a due-diligence report and a stalking dossier.
The difference is authorization and scope, not tradecraft. The beginner error
is collecting posts instead of analysing them — screenshots of a feed are not
intelligence. Work four layers: account metadata, network, content, temporal
behaviour. The first and last are the two everyone skips, and the two the
subject can't curate.

## Step 1 — Authorized scope

Read [../../ETHICS.md](../../ETHICS.md), then write down before opening a

# Read deleted pages

Archives work because removal is a decision made after publication. The
beginner's mistake is treating the Wayback Machine as a website you browse: the
calendar UI shows one page at a time, while the CDX API enumerates every URL the
archive ever saw under a host, including paths nobody remembers.

## Which archive first

| Situation | Go to | Why |
|---|---|---|
| A URL that 404s now | Wayback, then archive.today | Different corpora, different removal pressure |
| "What did this site say before X" | Wayback CDX with `collapse=digest` | Gives the dates content changed, not every capture |
| A JS-heavy page or a social post | archive.today | Captures the rendered DOM; Wayback often replays an empty shell |

# Recon a domain passively

Turn one domain into a defensible map of an organization's internet-facing estate
plus the owner behind it. The techniques live in other skills; what this workflow
contributes is the **order**, the **inventory**, and the **stopping rule**. Two
failure modes to avoid from the start: enumerating for hours and producing 400
hostnames with no attribution, dates or priority, which is not a map; and drifting
active without noticing, because one probe "just to check if it's up" ends the
passive claim. Decide the passive boundary before step 2, not during it.

## Ordering logic

Each stage feeds the next, and the sequence is cheapest-and-quietest first:

# Secrets in file metadata

The fastest lead in an investigation is often already inside the file: GPS to six
decimal places, a camera serial that ties four "unrelated" images to one body, a
document author who is a real employee, a template path containing a corporate
share name.

Two things beginners get wrong. Absent metadata is not suspicious — it is the
normal state of anything that passed through a social platform. And present
metadata is not proof: every tag is a **claim written by whatever software touched
the file last**, and all of it is editable with one command.

## Where to look first, given what you have

# Secrets in git history

A repository is three intelligence products: a list of humans with real email
addresses, a map of the organisation's infrastructure, and a credential store
nobody meant to publish. The costly mistake is scanning the working tree.
Secrets deleted from HEAD stay in history forever, and commits deleted from a
branch stay reachable through the fork network — scan only what is checked out
and you are searching the one place the secret was definitely removed from.

## What you're holding, and where to start

| You have | Start with | Why |
|---|---|---|
| An organisation name | Public org members, then their personal repos | Corporate repos are reviewed; personal ones are not |

# Track Planes and Ships

Aircraft and ships announce themselves over the air, and volunteers with cheap
receivers write it all down. That gives you movement history for most civil
traffic and, through registries, a path to ownership. The cost: the data is
self-reported by the vehicle, so it is exactly as truthful as its operator
chooses. The beginner error is chasing the wrong identifier — tail numbers,
callsigns, vessel names and MMSIs all change, while ICAO hex codes and IMO
numbers largely don't. Resolve to the durable identifier first and everything
downstream survives a rename.

## Triage: which identifier do you have?

| You have | Resolve to | Why |

# useOSINT

Router for investigation work. Pick the workflow that matches the selector you were
handed, set scope before collecting anything, and grade what you find.

## Sources

Your knowledge of breach corpora, data-broker coverage, registry endpoints and platform
APIs may be outdated. **Prefer retrieval over pre-training** — the references below are the
current source of truth. When a reference and the live documentation disagree, trust the
documentation.

| Source | Use for | URL |
|---|---|---|

# What an email reveals

An email address is usually the highest-value selector in an investigation: it
carries a name, a domain, an account history, and a breach footprint. The
beginner error is trying to prove the address exists. Existence is the least
interesting thing about it, it is the hardest thing to establish passively, and
the techniques that establish it are the ones that expose you. Work the
structure and the footprint first; treat validation as a bonus.

Never send mail to the subject as a research technique.

## Step 1 — Authorized scope

Read [../../ETHICS.md](../../ETHICS.md). Write down subject, objective,

# What leaked about you

Breach data answers a question nothing else answers cheaply: which services did
this identity actually use. That service list is almost always worth more to an
investigator than the credentials in the record — and the credentials are the
part you must never touch. Using a leaked password is unauthorized access, no
matter how public the dump was.

## What a record actually contains, and what matters

A breach record is a row from a service's user table. Typical fields: email,
username, a password hash (or plaintext, in bad cases), registration date, last
login, IP address at signup, display name, date of birth, physical address,
security questions, and whatever the service happened to collect.

# Where was this taken

Input: an image or video file, or a URL to one. Output: a location with a confidence
radius, a time window, an authenticity assessment, and the evidence chain for each.

This workflow orchestrates. The technique detail lives in `secrets-in-file-metadata`,
`find-the-original-image`, `geolocate-from-pixels` and `is-this-photo-real` — run
those, don't reimplement them here.

The order matters more than anything else in this file. Metadata before analysis,
because analysis destroys metadata. Provenance before geolocation, because the
original's caption often *is* the location. Authenticity checks before you commit,
because geolocating a composite gives you a confident answer to the wrong question.

# Who owns this domain

Registration data tells you who bought the name; DNS tells you who runs the
service. They are frequently different parties, and conflating them is the
mistake that wrecks attribution. Everything here is passive except where flagged
— but note that `dig` aimed at the target's own nameservers lands in the
target's query logs, so resolve through a public recursive resolver or passive
DNS when you care about being quiet.

## Which source first

| You hold | Reach for | Why |
|---|---|---|
| A domain, nothing else | RDAP, then registrar WHOIS | Structured, gives dates + registrar + status in one hit |

# Who really owns it

Registries turn a brand into a legal entity with a number, dates, addresses, and
named people. The thing nobody tells you first: **registry structure varies
enormously by jurisdiction, and that variance is the entire game.** One country
publishes full accounts, share registers, and directors' birth dates for free.
Its neighbour publishes a name and a status code and charges for the rest. Your
research strategy is not "look up the company" — it is "work out what this
jurisdiction lets me see, then plan around the gap".

Second thing: search by **company number**, not name. The number is issued once
and persists through renames, mergers, and dissolution. The name does not.

## Triage

# Whose number is this

A phone number is a strong selector: expensive to acquire, hard to change, and
used as an account-recovery anchor almost everywhere. It is also the selector
investigators get most wrong, because the metadata everyone quotes — the carrier
— is frequently stale, and because a large share of numbers now belong to
software rather than to a SIM in someone's pocket. Do not call or text the
subject; that is contact, not research.

## Step 1 — Authorized scope

Read [../../ETHICS.md](../../ETHICS.md). Write down subject, objective,
in-bounds selectors, out-of-bounds actions, and the governing jurisdiction —
which matters more here than in most skills, because reverse phone lookup is

# Write the intel brief

The report is the only part of the investigation anyone else sees, so it is the
only part that can be wrong in public. The failure that destroys credibility
isn't a missed source — it's a sentence that reads as fact and is actually an
inference. "The account is operated from Lisbon" versus "posting times cluster
in UTC+0/+1, consistent with Iberian working hours." One survives cross-
examination.

## Step 1 — Sort every claim into observation, inference, or assessment

Three categories, never blurred, ideally visually distinct in the text.

- **Observation** — what you saw, with source and timestamp. "The registry

# X-ray a company

Take a brand, a website, or an invoice and produce a defensible picture of who you
are actually dealing with. Four layers — legal entity, people, infrastructure,
reputation and risk — worked in that order. Skipping the first ruins everything
after it: the trading name on the contract, the brand on the website, and the
entity liable in court are routinely three different things, and every later
finding attaches to the wrong one if you assume they match.

## Step 1 — Authorized scope

Write the target, the decision the work supports, the risk areas in scope, the
jurisdictions involved, and what is out of bounds. Read
[../../ETHICS.md](../../ETHICS.md). Corporate research on public filings is