investigate-without-getting-made

Investigator OPSEC — threat-model who might notice you, control your attribution surface across IP, ASN, browser and TLS fingerprint, timing and logged-in…

INSTALLATION
npx skills add https://github.com/useosint/osint-skills --skill investigate-without-getting-made
Run in your project or agent environment. Adjust flags if your CLI version differs.

SKILL.md

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.

  • Who might notice? A dormant shell company, a moderately technical

individual, a criminal group running monitored infrastructure, or a state

service. Their capability sets the bar.

  • What would they see? Passive collection: a line in a server log. A

logged-in visit: your name. An interaction: your persona and its history.

  • What is the consequence? Nothing, or evidence destroyed and accounts gone

dark, or the investigation attributed to your organisation and disclosed, or

physical risk to you or a source.

SituationProportionate posture
Registries, archives, CT logs, court recordsNormal browser, no persona. You are one of thousands.
Viewing a target's public websiteClean browser profile, commercial VPN, no logged-in sessions.
Any logged-in platform view of a targetPersona account, dedicated profile, and check the platform's viewer-notification behaviour first.
Target operates monitored infrastructure or is technically capableDedicated VM, non-datacentre egress, no reused fingerprint, timing discipline.
Organised crime, harassment risk, physical safety in playEverything above plus compartmented hardware, and a colleague who knows what you're doing.

Over-engineering costs too: a locked-down setup gets CAPTCHA'd, rate-limited and

blocked, so you collect less, and unusual configurations are themselves

distinctive. Blend in where blending in is the goal. And before working out how

to view something safely, check whether an archive already holds it

(read-deleted-pages) — a snapshot tells the target nothing.

Your attribution surface

What a site or platform can learn from a visit:

SurfaceWhat it gives away
IP and ASNThe network, not the address, is the tell: a datacentre ASN says "VPN or scraper", a corporate ASN says your employer's name — the worst outcome, and common, because people forget the office network is an identifier
Browser fingerprintUser-agent, window geometry, fonts, canvas and WebGL rendering, hardware concurrency, timezone — often unique and, crucially, stable across sessions and IPs, so it links your visits to each other when nothing else does
TLS fingerprintThe client hello (cipher suites, extensions, ordering) identifies your client independently of anything the browser exposes; it is why a tool behind a proxy is trivially separable from a real browser — the headers say Chrome and the handshake does not
Language and localeAccept-Language, timezone offset, units. An English-locale browser reading a regional-language site from a third-country datacentre IP is memorable
TimingActivity only in one country's working hours, gaps on its holidays, bursts on the hour. Timing survives every other control you apply
Link previewsPasting a target URL into chat, a ticket, or a doc makes that platform fetch it; the fetch hits the target's server and correlates with your other activity. Disable previews or defang URLs

Logged-in accounts are the big one. Authentication converts an anonymous

request into an identified one, and the leaks are features: profile-view

notifications and viewer lists, story and video view lists, "people you may

know" suggestions driven by contact-list and interaction graphs, read receipts,

follower and list notifications, mutual-connection displays. Some fire with no

action beyond loading a page.

Per-surface checks, what each platform category exposes, and the settings that

do and don't help: reference/attribution-surface.md.

Separation is absolute

Research identity and real identity never touch. Not "mostly" — one crossing

links them permanently, and it is not reversible once a platform has correlated

it. The specific leaks, roughly in order of how often they burn people:

  • A real phone number for SMS verification. The strongest cross-platform

identifier there is; platforms link accounts on it internally and use it to

power contact-based suggestions. One verification links the persona to you

forever, including retroactively.

  • A recovery email that is yours — or one that is another persona's, which

links the personas to each other.

  • A payment method. Any card, wallet, or subscription, including the VPN.
  • A reused password, which surfaces in a future breach and clusters your

accounts for anyone who buys the dump — see what-leaked-about-you.

  • A synced browser profile, carrying history, autofill, and saved passwords

into the research environment. Personal cookies and sessions do the rest.

  • An avatar that reverse-searches back to you — or to anyone

(find-the-original-image). A cropped personal photo, a friend's photo, and a

stock image all fail, for different reasons. Strip upload metadata too

(secrets-in-file-metadata).

  • Style and habits. A distinctive phrasing, a recurring typo, fixed hours.
  • Contact-list upload. Granting an app contacts access, on a phone that has

ever held your real contacts, hands the platform the graph that links

everything.

Personas

Build one only when observation genuinely requires an account, and read the ToS

section below first. A brand-new empty account is both useless and conspicuous: it can't see much and

it looks exactly like what it is, so it gets blocked, challenged, or banned at

the moment you need it. Personas need plausible history and age, so create them

well before the case that needs them and let them accumulate ordinary activity.

Maintain a small stable rather than one per investigation.

Coherence is the whole game: name, locale, language, timezone, posting hours,

interests, and connections all agreeing with each other and with the platform's

demographics. A persona claiming a city while posting on that city's night

schedule is a contradiction a human notices instantly.

Step-by-step build, identifier sourcing, ageing schedule, and the maintenance

routine: reference/persona-runbook.md.

Hard limit, regardless of mandate: personas are for observation — not for

eliciting private information, inducing anyone to act, or gaining entry to

closed systems or groups on a false pretext you have no authorization to make.

Network egress

OptionGood forBad for
Commercial VPNHiding your ASN and rough location from ordinary sites; the common defaultAnything that blocks datacentre ranges; anything where "obvious VPN" is itself a signal; trusting the provider
Residential / mobile proxyAppearing as an ordinary consumer connection; reaching services that block datacentresCost, variable reliability, and a serious sourcing problem — see below
TorStrong anonymity against network observers; accessing onion servicesPersona accounts (exit nodes are a published list, so expect blocks, CAPTCHAs, and account security challenges); anything needing session stability or geographic plausibility
Your own VPSControl and stabilityBeing a datacentre IP that traces to a billing identity, which is often worse than a VPN

Tor is the strongest tool here and the wrong one most of the time: exit

addresses are publicly enumerable, so a monitored target sees "someone using Tor

looked at this" — more attention-getting than an ordinary visit — and platforms

treat Tor logins as high-risk, triggering the verification challenges that kill

a persona.

Residential proxies deserve a specific warning: many pools are assembled from

consumer devices enrolled through bundled SDKs whose users did not meaningfully

consent, and your traffic exits through a stranger's home connection — an

ethical problem and potentially a legal one for both of you. Know how your

provider sources its pool, or don't use one.

Verify whatever you choose: check the exit address and its ASN, confirm DNS

resolves through the tunnel, and block WebRTC, which reveals addresses

independently of it.

Environment and compartmentation

One case, one environment. A dedicated VM per case is the clean answer; a

dedicated browser profile is the minimum. Containerised tab isolation separates

cookies but not fingerprint — a convenience, not a boundary. Across setups: no

personal accounts ever signed in; snapshot clean and roll back between cases;

keep notes and downloads in the case's encrypted store; never open a target's

document or PDF in an environment that can reach your real identity.

Compartmentation means a persona used on case A is never used on case B. Two

targets who compare notes — and targets in one ecosystem do — reconstruct your

operation from the overlap. Same for numbers, emails, proxies, and avatars.

Never authenticate to anything belonging to the target. Not their portal,

not their wifi, not a login with credentials found in breach data, not a

"forgot password" flow to confirm an account exists. That is the line between

open-source research and unauthorized access, and it does not move because the

password was easy to find.

Where this goes wrong

  • The logged-in slip. A colleague sends a link, you click it in your normal

browser, and the target has your name. The most common burn by a distance.

Defang shared URLs and make the research browser visually distinct.

  • The privacy setting that isn't. Anonymous-browsing modes stop the name

reaching the target, but the platform still has it, the setting can revert,

and some notifications aren't covered. They reduce exposure, not remove it.

  • Contact-graph suggestions. You never visited the profile, yet they're

suggested to you and you to them, because your device or persona touched a

number or address in their contact graph.

  • Verification challenge mid-case. Ageing and stable egress reduce it;

nothing eliminates it. Plan for the account to die at the worst moment.

  • Metadata in your own outputs. Screenshots and reports carrying your

username, hostname, or internal paths, sent to a client.

  • Correlating your own personas. Same avatar generator, same bio template,

same three interests, made in one afternoon from one exit IP. Platforms

cluster on exactly this.

  • Assuming passive means invisible. One request in a server log is nothing;

a distinctive pattern across a hundred is a signature. And scanners and API

clients carry their own TLS and header fingerprints, with some logging your

queries server-side — know what egresses where.

Grading your exposure

After any collection action, grade what the target could know.

  • Clean — nothing reached target-controlled infrastructure: third-party

archives, registries, and logs only.

  • Anonymous contact — the target's servers logged a request carrying no

identity beyond an IP you control and a common fingerprint.

  • Pseudonymous contact — the target can see a persona: a viewer entry, a

follow, a notification. Recoverable if the persona is clean and compartmented.

  • Attributed — a real identity, employer ASN, or cross-linked selector

reached the target. Stop, record what was exposed and when, and tell the case

owner; a concealed burn becomes a burn the other side discovers first.

Log exposure events as they happen, with timestamps. Reconstructing them after a

case goes wrong is guesswork, and the client will ask.

Worked example

Objective: is a supplier's named director active in an industry forum? Subject

is a small business owner, not technically sophisticated, but the forum is niche

and members notice new accounts.

Posture: commercial VPN, dedicated browser profile, an existing aged persona

from the stable — not a new one, because the forum's member list shows join

dates.

The dead end that matters: the forum blocks the VPN's ranges outright. Instead

of escalating tooling, the archive route (read-deleted-pages) yields cached

thread pages containing most of what was needed, with no contact at all. Graded

clean.

One question still needs a live profile page. The persona logs in from a

consumer connection rather than the VPN, in the forum's working hours, views the

profile, and leaves. The forum has no "who viewed" feature, so exposure is

graded anonymous contact — with a note that the administrator can still read

access logs.

Not done: a professional-network profile view of the same person, because that

platform notifies. The question it would have answered went into the report's

gaps section instead. A tipped-off subject costs more than an unanswered

secondary question.

Pivots

OPSEC is a precondition, not a producer of selectors. Run it before

pattern-of-life-from-socials, hunt-a-handle, find-leaks-in-the-wild, and

any interactive step in find-anyone or x-ray-a-company. Check avatars with

find-the-original-image, strip uploads with secrets-in-file-metadata, prefer

read-deleted-pages to live visits, and log exposure events so

write-the-intel-brief can state what the subject may know.

Legal and ToS notes

Say this plainly: fake accounts violate most platforms' terms of service.

Accurate-information requirements are near-universal, the accounts get banned,

and the ban can take your collection with it. Terms breach is generally a

contract matter rather than a crime, but the boundary between breaching terms

and unauthorized access is jurisdiction-specific and has been litigated both

ways. Decide with counsel whether your mandate covers it, and record it.

Impersonating a real, identifiable person is a far more serious matter than

an invented persona — a number of jurisdictions criminalise online impersonation

specifically (California Penal Code § 528.5 is one example), and it exposes you

to defamation and civil claims. Impersonating a **law-enforcement officer,

government official, or lawyer** is a criminal offence in its own right in many

places, including under US federal law, and no investigative mandate covers it.

Also: a persona is personal data processing under GDPR-style regimes when used

to collect on living people, and the persona's own conduct is attributable to

your organisation. See ../../ETHICS.md. If you cannot justify

the persona in writing, do not create it.

BrowserAct

Let your agent run on any real-world website

Bypass CAPTCHA & anti-bot for free. Start local, scale to cloud.

Explore BrowserAct Skills →

Stop writing automation&scrapers

Install the CLI. Run your first Skill in 30 seconds. Scale when you're ready.

Start free
free · no credit card