Dark Web Research Methodology

Obtain Written Authorization

Every dark web investigation requires documented authorization from a person with authority to grant it. For corporate threat intelligence work, this is typically the CISO or legal counsel. For academic research, this is the Institutional Review Board (IRB). Document:

• Research objective and scope definition
• Specific techniques and tools permitted
• Data handling requirements and retention policy
• Legal boundary conditions (e.g., no purchases, no account registration on criminal sites)
• Authorized researchers by name and role
• Escalation procedure if illegal content or active criminal activity is encountered

Define Research Scope

A clearly defined scope prevents scope creep, ensures legal compliance, and makes research results actionable. Define:

• Target: Specific threat actor group, vulnerability, sector threat landscape, or credential exposure assessment
• Time horizon: Are you researching current activity, historical patterns, or building ongoing monitoring?
• Data types: Which types of dark web data are in scope? (Forums, marketplaces, leak sites, infrastructure)
• Reporting requirements: Who receives the intelligence and in what format?
• Duration: Define the research window and review checkpoints

Establish an Isolated Research Environment

Never conduct dark web research from your primary work machine, home computer, or any system connected to production networks. The research environment must be compartmentalized from all personal and organizational identity. Recommended configurations by investigation sensitivity:

• Standard research: Dedicated research VM running Whonix on an isolated physical host, connected to a research-only VLAN with no route to internal resources
• Sensitive investigations: TAILS OS on dedicated USB media, booted on air-gapped or isolated hardware — no persistent storage between sessions
• Extended research campaigns: Whonix on Qubes OS for maximum compartmentalization between concurrent investigations

Critical controls for any research environment:

• No personal accounts, email, or social media from the research environment
• No copy-paste between research and personal/production environments without sanitization
• MAC address randomization enabled
• All DNS resolving through TOR to prevent DNS leaks
• WebRTC disabled in browser (TOR Browser handles this by default)
• JavaScript disabled for initial site assessment, enable only if necessary

Build a Research Persona (If Required)

Some investigations require researcher interaction with dark web communities — forum registration, monitored account activity, or direct engagement. If persona creation is within the authorized scope:

• Generate a persona with no connection to your real identity — use a dedicated operational email account created through TOR
• Use a consistent backstory appropriate to the forum culture — implausible personas are quickly identified and banned
• Never use real details, real photos, or real biographical information
• Compartmentalize personas: one persona per investigation, never reuse across different targets
• Document persona credentials in an encrypted store — if a persona is burned, it must be fully documented before abandonment
• Legal review required: active engagement (as opposed to passive monitoring) may cross legal boundaries in some jurisdictions

Systematic Discovery

Use dark web search engines in a structured sequence to build a comprehensive map of relevant dark web infrastructure before diving into specific sites:

1. Ahmia first: Begin with filtered results to scope the ecosystem without exposure to unfiltered content. Document all relevant .onion addresses found.
2. Specialized directories second: Tor.link and Onion.live for categorized discovery — particularly useful for identifying active services in specific categories (forums, markets, ransomware sites).
3. Unfiltered engines last: Only with explicit authorization, use HayStack or Torch for comprehensive coverage that filtered engines may miss. Ensure TAILS/Whonix isolation before proceeding.

Document each .onion address discovered with: date/time found, source (which search engine or directory), category, initial assessment, and priority for deeper investigation. This documentation forms the chain of custody for any intelligence produced.

Credential Exposure Assessment

If credential exposure is within research scope, follow a tiered approach:

• Tier 1 — HIBP: Free, safe, and legally clear. Domain Search API covers all corporate email addresses against publicly known breaches.
• Tier 2 — DeHashed/Snusbase: Deeper coverage with multiple query types. Requires subscription and access control. Log all queries with analyst ID and justification.
• Tier 3 — Dark web forum monitoring: Monitor active credential trading forums for organizational domain mentions. Requires dedicated monitoring infrastructure and legal review.

Correlate all found credentials against Active Directory to identify currently active accounts that need immediate password resets regardless of whether unauthorized use has been detected.

Evidence Collection and Chain of Custody

All intelligence collected during dark web research must be documented with chain-of-custody standards equivalent to legal evidence — dark web intelligence may be used in criminal investigations or civil litigation. For each piece of evidence collected:

• Screenshot with timestamp (system clock synchronized to NTP) and URL visible
• Hash (SHA-256) of all screenshot files at time of capture
• Analyst name, date/time, and research task reference for each collection event
• Store evidence in an encrypted, access-controlled repository with immutable audit log
• If illegal content is inadvertently encountered: stop, document the encounter without additional collection, escalate to legal counsel per the pre-defined escalation procedure

Threat Intelligence Enrichment

Raw dark web data becomes actionable intelligence through enrichment — correlating findings with additional sources to build complete threat pictures. Use Mitaka or manual enrichment to:

• Cross-reference IOCs (IPs, domains, hashes) against VirusTotal, Shodan, and SIEM historical data
• Map threat actor TTPs to MITRE ATT&CK framework entries for consistent communication with defenders
• Identify infrastructure overlaps between newly discovered threat actor tools and known indicators
• Correlate breach data findings with authentication logs to identify likely unauthorized access attempts
• Pivot from .onion addresses to associated clearnet infrastructure using passive DNS and certificate transparency logs

Intelligence Report Structure

Intelligence reports from dark web research should follow a structured format that enables non-researchers to understand findings and act on recommendations:

• Executive summary: One-page summary of key findings and recommended immediate actions
• Scope and methodology: Authorized scope, research period, tools and techniques used
• Findings by priority: Critical (immediate action required), High, Medium, Informational
• Evidence appendix: Screenshots, hashes, and collection timestamps for all supporting evidence
• IOC appendix: Structured IOC list in STIX/TAXII or CSV format suitable for SIEM import
• Recommendations: Specific, actionable remediation steps with ownership assignments