VSI GLOBAL // ENTERPRISE ARCHITECTURE

OSINT-059-dark-web-investigation-and-attribution-report-collection

11 min read

[DIGITAL IDENTITY] - Collection Map

OSINT-059 Dark Web Investigation & Attribution Report - collection workspace. Central topic = the subject’s dark-web identity (handle / entity / incident). Branches are the data-point categories for the dark-web attribution mission. Drop each collected value as a child node; expand it with where it was found. Paste raw tool output into the node’s Notes. → feeds deliverable OSINT-059.

00 · Collection Plan - PIRs & EEIs

The questions this collection must answer + the essential elements of information (EEI) for each. Tick checkboxes as satisfied. → drives §3 Key Judgments, §4 PIRs, §13 Verified Findings, §17 Gaps.

PIR-1 - Handles / accounts: What dark-web identifiers does the subject operate?

  • EEI: primary dark-web handle(s) identified and documented
  • EEI: secondary / alias handles and cross-platform reuse confirmed
  • EEI: same-handle candidates identified and excluded (namesake check)
  • EEI: PGP key ID(s) and fingerprint(s) linked to handle(s)
  • EEI: wallet address(es) linked to handle(s) (route to OSINT-022 if full tracing needed)

PIR-2 - Venues: What dark-web forums, markets, and hidden services does the subject frequent?

  • EEI: primary marketplace / forum / hidden service with .onion URL documented
  • EEI: secondary venues and lurking presence noted
  • EEI: time window of observed presence for each venue
  • EEI: subject’s activity level per venue (active / occasional / historical)

PIR-3 - Activity: What illicit activity is the subject engaged in?

  • EEI: primary illicit activity type (credential trafficking / data sale / narcotics / fraud / malware / C2 / other)
  • EEI: listing or post evidence captured and preserved with hash
  • EEI: scale and recency of activity established
  • EEI: specific threat to client from subject’s activity assessed

PIR-4 - Attribution: Can the subject’s dark-web activity be tied to a real-world identity?

  • EEI: at least one strong attribution link (PGP key reuse / cross-platform handle / wallet clustering / registration data / self-disclosure / writing style / operational mistake)
  • EEI: contradictory / exculpatory evidence reviewed and documented
  • EEI: namesake / false-flag risk assessed
  • EEI: attribution confidence level determined (Confirmed / Probable / Possible / Unresolved)

PIR-5 - Network: What dark-web associations and threat-actor affiliations exist?

  • EEI: co-posting accounts and transactional counterparties identified
  • EEI: shared infrastructure or group affiliation indicators documented
  • EEI: known threat-actor group / criminal collective link assessed

Collection gaps / RFIs (running)

  • [open item] → route to [product / analyst / venue]
  • [open item]

01 · Identity Anchor

The bridge between the real-world subject and the dark-web identity being attributed. Both sides of the link must be established before attribution can be graded. → feeds §5 Subject Identification & Dark-Web Handles, §8 Attribution Analysis.

Real-world anchor (subject / entity / incident)

  • Subject legal name / entity name:
  • Triggering identifier (what brought them to attention):
  • Client-supplied selectors (emails / phones / usernames / wallet addresses):
  • Prior OSINT-055 or OSINT-058 findings in scope:

Dark-web anchor (primary identifier)

  • Primary handle:
    • Venue first seen:
    • Registration date (if visible):
    • Basis for anchoring to subject:
    • Confidence: [Confirmed / Probable / Possible / Unresolved]
    • Notes / tool output:
  • Attribution confidence (initial): [Confirmed / Probable / Possible / Unresolved]

02 · Selectors & Accounts

The full set of dark-web and cross-platform identifiers. Each selector block is clonable. → feeds §5 Subject Identification & Dark-Web Handles, §8 Attribution Analysis, Appendix A.

Dark-web handles / usernames

Cross-reference against clearnet usernames (idcrawl / sherlock / whatsmyname) to surface reuse.

  • [handle - e.g. d4rkpr0xy]
    • Venue(s) where found:
    • Clearnet reuse (platform + URL):
    • Linked email(s):
    • PGP key linked:
    • Wallet address(es) linked:
    • Other accounts reusing it:
    • Attribution confidence: [Confirmed / Probable / Possible / Unresolved]
    • Notes / tool output: ← sherlock, whatsmyname, idcrawl
  • [handle 2]

Email addresses (dark-web registrations / contact)

→ check breach/paste appearances and account discovery alongside handle attribution.

  • [email - e.g. user@protonmail.com]
    • Venue / registration context:
    • Breach / paste appearances:
    • Account discovery (linked platforms):
    • Where found (source + URL):
    • Attribution confidence: [Confirmed / Probable / Possible / Unresolved]
    • Notes / tool output: ← holehe, h8mail, hunter.io, haveibeenpwned
  • [email 2]

PGP keys

  • [key ID / fingerprint - e.g. 0xABCD1234]
    • Keyserver found on:
    • UID(s) on key:
    • Cross-venue reuse:
    • Creation / expiry date:
    • Signed / web-of-trust links:
    • Attribution confidence: [Confirmed / Probable / Possible / Unresolved]
    • Notes / tool output: ← keys.openpgp.org, Mailvelope lookup
  • [key 2]

Cryptocurrency wallet addresses

Full on-chain tracing routes to OSINT-022; record identifiers here for attribution linkage only.

  • [wallet address - e.g. 1A1zP1…]
    • Chain / coin:
    • Venue / listing context found:
    • Clustering / co-spend links noted:
    • Exchange deposit detected:
    • Attribution confidence: [Confirmed / Probable / Possible / Unresolved]
    • Notes / tool output: ← blockchain.com, etherscan, breadcrumbs.app, arkham
  • [wallet 2]

Phone numbers (dark-web contact)

  • [number - e.g. +1 555-0199 / Telegram ID]
    • Context found:
    • Type (Telegram / Signal / VoIP / other):
    • Linked accounts:
    • Attribution confidence: [Confirmed / Probable / Possible / Unresolved]
    • Notes / tool output:
  • [number 2]

03 · Credential & Breach Exposure

Background breach exposure context - distinguishes the subject as actor from subject as victim. Credential exposure feeds attribution (do leaked passwords reappear on dark-web registrations?). → feeds §10 Illicit Activity & Threat Indicators (if subject is trafficking their own or others’ data), §8 Attribution (if leaked passwords or usernames confirm cross-platform link).

Breach appearances (subject as potential victim or actor)

  • [breach / paste - e.g. Collection #1, 2019-01]
    • Selector exposed:
    • Data fields (email / password hash / plaintext / phone / address):
    • Source grade:
    • Significance (victim profile vs. actor reuse):
    • Notes / tool output: ← haveibeenpwned, dehashed, intelx.io, leakcheck
  • [breach 2]

Credential reuse across dark-web accounts (attribution pivot)

  • [credential pattern - e.g. password variant observed in two venues]
    • Venues matched:
    • Confidence this links accounts to same operator: [H/M/L]
    • Notes:

Data-broker / stealer-log exposure

  • [stealer-log / data-broker entry]
    • Source:
    • Data content:
    • Relevance:
    • Notes / tool output: ← intelx.io, flare.io, Hudson Rock Cavalier

04 · Dark-Web Presence

The heart of the collection. One block per venue / platform where the subject appears. Capture: handle used, activity type, content themes, time window, .onion URL (if safe to record). → feeds §6 Venue & Platform Mapping, §7 Activity & Communications Analysis, Appendix B.

Forum / community presence

Clone per forum. Passive observation only - no account creation, no engagement.

  • [forum - e.g. RaidForums mirror / BreachForums / XSS / Exploit.in]
    • .onion / clearnet URL:
    • Handle used:
    • Join / first-post date:
    • Last active date:
    • Activity level: [Active / Occasional / Historical / Single post]
    • Post count / reputation score:
    • Topics / sub-forums active in:
    • Notable posts / threads (by date):
    • Source grade:
    • Notes / captured content (hashed):
  • [forum 2]

Marketplace listings / vendor presence

Clone per marketplace.

  • [marketplace - e.g. AlphaBay successor / dark0de / vendor shop]
    • .onion URL:
    • Vendor handle:
    • Listings observed (category / price / quantity):
    • Feedback / reputation metrics:
    • PGP key posted:
    • Wallet address(es) in listings:
    • Time window of observed activity:
    • Source grade:
    • Notes / captured content (hashed):
  • [marketplace 2]

Paste sites / leak sites / hidden service mentions

Clone per paste / mention.

  • [paste site / leak site - e.g. Pastebin, ghostbin, ransomware leak blog]
    • URL (captured):
    • Handle / attributed to subject:
    • Content summary:
    • Date posted:
    • Source grade:
    • Notes:
  • [paste 2]

Chat platforms (dark-web adjacent)

  • [platform - e.g. Telegram channel / IRC / Matrix / XMPP]
    • Channel / server:
    • Handle used:
    • Content observed:
    • Time window:
    • Notes / tool output:

05 · Digital Footprint & PII Exposure

Clearnet footprint that provides attribution anchors linking dark-web identity to real-world subject. → feeds §8 Attribution Analysis (cross-platform handle reuse, self-disclosure, metadata); §10 Illicit Activity (if subject is selling client PII or targeting client infrastructure).

Clearnet social media (attribution-pivot accounts)

Clone per platform. Focus on handles / metadata that bridge dark-web to real-world identity.

  • [platform - e.g. GitHub / Twitter-X / Reddit / Telegram public / HackerNews]
    • Handle / URL:
    • Attribution confidence (links to dark-web identity): [Confirmed / Probable / Possible]
    • Key content (writing style, references to dark-web activity):
    • Account status: [Active / Dormant / Deleted]
    • Notes / tool output: ← sherlock, whatsmyname, idcrawl
  • [platform 2]

Technical / developer footprint

  • [GitHub / GitLab / SourceForge repo or commit]
    • Username:
    • Email in commits:
    • Code / tools of relevance:
    • Attribution link to dark-web handle:
    • Notes:

Data-broker / public-record PII

  • [data-broker / people-search entry]
    • Fields available:
    • Accuracy / currency:
    • Attribution link:
    • Notes / tool output: ← Spokeo, BeenVerified, PeopleFinders, Intelius

Image / media (avatar / profile picture reverse)

  • [image ref]
    • Reverse-image match (platform + URL):
    • Metadata (EXIF / geotag):
    • Attribution link:
    • Notes:

06 · Infrastructure

The technical infrastructure operated by or associated with the subject. → feeds §6 Venue & Platform Mapping (subject-operated hidden services), §8 Attribution Analysis (shared infrastructure pivot), §11 OPSEC Assessment.

Domains and hidden services operated by subject

Clone per domain / .onion.

  • [domain / .onion - e.g. subjectshop.onion]
    • Registrant / WHOIS (clearnet):
    • Hosting / IP / ASN:
    • SSL cert / SAN (crt.sh):
    • Associated email(s) in registration:
    • Linked identifiers:
    • Status: [Active / Offline / Seized]
    • Notes / tool output: ← whois, crt.sh, Shodan, SecurityTrails, RiskIQ
  • [domain 2]

IP addresses (inferred or observed)

  • [IP - e.g. exit-node IP seen in registration, forum login leak]
    • ASN / hosting provider:
    • Geolocation (coarse):
    • Context of exposure (OPSEC mistake vs. Tor exit):
    • Attribution confidence: [H/M/L]
    • Notes / tool output: ← Shodan, Censys, AbuseIPDB
  • [IP 2]

Malware / C2 infrastructure (if applicable)

  • [C2 domain / IP / malware hash]
    • Malware family:
    • Observed in:
    • Link to subject:
    • TI source:
    • Notes / tool output: ← VirusTotal, Any.run, MalwareBazaar, ThreatFox

Shared infrastructure pivot (clusters with associates)

  • [infrastructure element - e.g. shared hosting account, certificate reuse]
    • Shared with (associated handle / entity):
    • Basis for clustering:
    • Notes:

07 · Attack Surface & Vulnerabilities

The subject’s OPSEC weaknesses and attribution-enabling mistakes - the inverse of §11 OPSEC Assessment. → feeds §11 Operational Security (OPSEC) Assessment, §15 ACH, §17 Gaps.

OPSEC mistakes observed

  • [mistake - e.g. reused username on clearnet, real email in PGP UID, IP leak in forum post]
    • Venue / context:
    • Date observed:
    • Attribution value (pivots to what):
    • Notes:

Counter-OPSEC / anti-forensic measures observed

  • [measure - e.g. Tor-only access, PGP-signed comms, separate per-venue handles]
    • Consistency of measure across venues:
    • Assessment of effectiveness:

VPN / Tor / proxy usage indicators

  • [indicator - e.g. Tor exit IP in forum login, VPN ASN in registration record]
    • Source:
    • OPSEC implication:

OPSEC posture assessment (working)

  • Overall posture: [Low / Moderate / High]
  • Strongest OPSEC element:
  • Most significant weakness:
  • Implication for further collection:

08 · Attribution & Threat Actors

The full attribution evidence chain mapped here; the Key Judgment KJ-1 (subject operates handle) and KJ-2 (subject engaged in activity) are supported by nodes in this branch. → feeds §8 Attribution Analysis, §9 Network & Affiliation Mapping, §15 ACH, §16 Key Assumptions.

Attribution evidence chain

Each evidence item is an independent link. Collect at least two independent streams before upgrading to Probable.

  • [evidence item - e.g. PGP key reuse across venues]
    • Evidence type: [PGP key reuse / cross-platform handle / wallet clustering / registration data / self-disclosure / writing style / metadata / OPSEC mistake / other]
    • Detail:
    • Strength: [Strong / Moderate / Weak]
    • Source grade:
    • Notes:
  • [evidence item 2]

ACH hypotheses (working)

  • H1 Subject genuinely operates the handles - evidence for / against: /
  • H2 Misattribution (namesake / false flag) - evidence for / against: /
  • H3 Shared account (multiple users) - evidence for / against: /
  • H4 Compromised identity / planted evidence - evidence for / against: /
  • Most consistent hypothesis (working):

Network associates / co-actors

Clone per associate. → feeds §9 Network & Affiliation Mapping.

  • [associate handle - e.g. c0mprom1sed]
    • Venue(s) of connection:
    • Nature of connection: [Co-poster / transaction partner / forum interaction / shared infrastructure / group affiliation]
    • Known real-world link (if any):
    • Confidence: [H/M/L]
    • Source grade:
    • Notes:
  • [associate 2]

Threat-actor group / criminal network affiliation

  • [group / collective - e.g. Lapsus$ / Killnet / specific marketplace org]
    • Indicators of affiliation:
    • Confidence: [H/M/L]
    • TI references:
    • Notes:

Writing style & linguistic markers

  • Primary language:
  • Distinctive patterns (idioms, typos, punctuation habits, vocabulary):
  • Cross-venue consistency:
  • Tool/approach: [JGAAP / manual stylometric notes]
  • Attribution value:

99 · Collection Admin

Working register - audit trail behind the deliverable. Not itself a deliverable section.

Source register

Every material datum traceable to a graded source (Admiralty A–F / 1–6).

  • [S-1 - source]
    • Type: [Forum post / marketplace listing / hidden service / PGP key / wallet transaction / chat log / paste / data-broker / TI feed / other]
    • Reliability (A–F):
    • Credibility (1–6):
    • Date accessed:
    • Capture method (screenshot / hash / archive):
  • [S-2]

Evidence archive

  • [EV-1 - capture ref]
    • File hash (SHA-256):
    • Original URL / .onion:
    • Timestamp of capture:
    • Preservation method: [Screenshot / HTTrack / archive.org / IPFS / local]
    • Chain-of-custody note:
  • [EV-2]

Open gaps / RFIs / verification pending

  • [item - e.g. PGP key fingerprint not confirmed against keyserver]
  • [item - e.g. wallet clustering not completed - route to OSINT-022]
  • [item - e.g. associate handle unresolved]

Assumptions log (feeds §16 Key Assumptions Check)

  • A-1 Handles not shared / single operator assumed: [basis / confidence]
  • A-2 Dark-web content not tampered / planted: [basis / confidence]
  • A-3 OPSEC posture consistent across venues: [basis / confidence]
  • A-4 No law-enforcement / intelligence operation running the account: [basis / confidence]

Graph View