Dark-Web Forensics Investigation Guide

1Start Here: Task, Authority, and Scope Core

The dark web is not a synonym for crime. It is a loose label for services that are not reached through ordinary public-web discovery and may require an overlay network or purpose-built client. Such services support legitimate privacy, journalism, research, and protected communication as well as harmful activity. A forensic question should therefore concern evidence and conduct, not the mere use of anonymity technology.

Begin with a case-supplied artifact: for example, a saved page, screenshot, URL supplied by an authorized requester, browser record from an approved endpoint collection, or transaction identifier already present in the case file. Translate the request into a question that can be answered with evidence:

• What was observed, on which evidence surface, and at what recorded time?
• Can the observation be preserved with enough context for another reviewer to understand it?
• Which parts are direct facts, and which depend on interpretation or corroboration?
• What would change the conclusion or require renewed authority?

Avoid starting with “find everything about this actor.” That request is unbounded and encourages identity claims before the evidence model is clear. A defensible scope names the requester, authority, question, supplied lead, permitted evidence surfaces, time window, collection limits, retention rule, and stop conditions.

2Tor and Onion Evidence: What Changes, What Does Not Core

Tor Browser routes browser traffic through the Tor network and is configured to reduce common forms of tracking. An onion service uses a self-authenticating onion address and establishes a connection within Tor rather than publishing an ordinary server location. Those properties change the network path and the meaning of an address; they do not make every session, endpoint, operator, or captured artifact unknowable [8][9].

The practical question is not “Did Tor reveal the person?” It is “Which authorized evidence surface produced this observation, and what can that surface support?” A saved page can establish captured content and context. An endpoint artifact may establish that a browser process or profile contained a record. Network telemetry may establish that an endpoint communicated with Tor infrastructure during a time window. None of those facts, by itself, establishes who controlled a remote service or why a person used it.

3Authorization and Stop Conditions Core

Authority is a continuing condition, not a sentence copied into the intake form. A valid plan tells the examiner what may be observed, collected, stored, shared, and retained. Reassess authority whenever the evidence, environment, tool, requested action, or affected people change. The Berkeley Protocol similarly treats legal, ethical, security, and psychosocial risk as part of investigation method rather than an afterthought [10].

4Investigation Lifecycle and Decision Gates Core

Treat the work as a controlled loop. Intake fixes the question and authority. Planning converts that question into evidence targets and stopping rules. Acquisition and preservation create a reviewable record. Analysis tests claims against alternatives. Review challenges the method and language before reporting and retention close the case. Current NIST incident-response guidance places evidence gathering inside a broader risk and response process rather than treating forensics as a disconnected specialty [1].

5Collection Plan and Controlled Environment Core

Write the collection plan before opening or importing the supplied lead. The plan should be short enough to use during the work and specific enough for another examiner to challenge later. At minimum, record:

• Question and authority: who requested the work, the permitted purpose, and the approved time window.
• Evidence targets: the supplied artifact and the minimum additional context needed to answer the question.
• Environment: approved workstation or virtual environment, network controls, storage path, and time source.
• Tools: name, version, configuration, output format, known limitations, and validation appropriate to the task.
• Activity record: start and stop times, examiner actions, errors, redirects, unexpected events, and decisions.
• Stops and escalation: the exact conditions from Section 3 and the person or channel that owns each decision.

Isolation is not a magic property. It is a set of controls whose purpose must be clear: preventing contamination, limiting uncontrolled content, separating case data, and producing attributable logs. A virtual machine can help with separation, but snapshots, shared folders, clipboard paths, host logging, DNS behavior, and time synchronization still need to be understood. Use organization-approved controls rather than inventing a laboratory architecture during a case.

Tool presence is not tool assurance. Record what a tool actually did and validate the capability relevant to the collection. NIST's Computer Forensics Tool Testing program distinguishes supported functionality and repeatable testing from product reputation [7]. If a capture tool omits redirects, response headers, failure states, or timing information, that limitation belongs in the evidence record.

6Preserve Web Evidence and Provenance Core

A screenshot shows appearance. It usually does not preserve the full response, embedded resources, headers, redirect path, request errors, or the conditions under which the page rendered. Preserve content and context as a package: the captured object, machine-readable metadata, a human-readable activity record, integrity values, and the relationship among them. SWGDE's current collection guidance emphasizes documentation, integrity, and minimizing alteration throughout evidence handling [3]. Older NIST and IETF guidance remains useful for integrating forensic work with incident response and reasoning about collection order, but neither source replaces current procedure [17][18].

SWGDE also publishes guidance specifically for acquiring online content [6]. This page uses its preservation, documentation, volatility, and method-review principles. It intentionally does not reproduce the document's covert-access, profile-presentation, or origin-obfuscation material; those operational choices require separate authority, policy, risk, and competence controls.

The following record is deliberately synthetic. The .invalid name cannot be a live onion-service destination, and the values teach record structure rather than a collection command.

{
  "case_id": "DWFI-EXERCISE-01",
  "item_id": "WEB-0007",
  "parent_item": "TIP-0002",
  "source_locator": "case-example.onion.invalid",
  "authority_reference": "training-scope-A",
  "capture_started": "2026-07-27T14:05:18-04:00",
  "capture_ended": "2026-07-27T14:05:41-04:00",
  "result": "case-supplied saved response imported; no live access",
  "content_file": "WEB-0007-response.bin",
  "content_type_reported": "text/html",
  "sha256": "SYNTHETIC-NOT-A-DIGEST",
  "tool": {
    "name": "approved-import-workflow",
    "version": "training-example",
    "limitations": ["no server-side metadata", "no remote time source"]
  },
  "examiner_note": "Record supports content-at-import only; operator identity is not established."
}

Read the record from the bottom up: the limitation constrains the finding, the method defines the evidence surface, the timestamps define the local activity window, and the item and parent identifiers preserve lineage. The digest can later detect a byte change; it does not prove that the content was accurate, original, or controlled by a particular person. Digital artifacts and tool behavior change quickly, so every method statement should remain tied to the observed version and conditions [2].

7Analyze Claims Without Overclaiming Core

Analysis begins after the evidence surfaces and limitations are known. Start with the smallest direct observation. Assess the source and method. State the inference needed to answer the case question. Then ask what else could explain the same record and what independent evidence would discriminate among those explanations. ICD 203 formalizes comparable habits: source description, uncertainty, alternatives, relevance, and clear separation of underlying information from analytic judgment [12].

8Package, Report, Review, and Retain Core

A useful evidence package lets a skeptical reviewer move from the finding back to the exact observation, method, and limitation. Keep originals or authoritative captures separate from derived items. Give every derivative—render, extracted text, translation, normalized record, timeline entry, or chart—its own identifier and parent relationship. Current SWGDE acquisition and examination guidance emphasizes documentation, competent method selection, preservation of source material, and reviewable results [4][5]. SWGDE's foundational report-writing requirements also remain a useful content checklist, subject to current organizational requirements [19].

A concise report normally includes:

• requester, authority, scope, case question, and material stop decisions;
• evidence received and acquired, with stable item identifiers;
• environment, tools, versions, relevant settings, and known limitations;
• methods applied and any deviations, failures, missing data, or clock uncertainty;
• findings that distinguish direct observations from inference and confidence;
• alternative explanations considered and the evidence that supports or weakens them;
• privacy, handling, disclosure, and retention limits appropriate to the audience.

Peer review should try to break the finding. Can the reviewer locate the source item? Does the cited record support the sentence? Is a timestamp being treated as more precise than its clock permits? Did two “independent” sources actually copy the same origin? Would a less dramatic explanation fit? Resolve those questions before distribution.

9Synthetic Practice Scenarios Core

These exercises use fictional, non-routable identifiers. They practice decisions and reporting, not live exploration.

Scenario A · The saved listing

An authorized fraud team supplies a screenshot and saved HTML file from a prior tip. It asks whether the material advertises a specific stolen dataset. The saved page names a dataset and uses an alias already present in the case, but the screenshot contains no visible time and the HTML has no server-side metadata.

1. Scope: examine the supplied files; do not attempt to revisit, contact, register, purchase, or authenticate.
2. Preservation: assign parent and child item IDs, preserve original bytes, calculate integrity values, and record import time separately from claimed publication time.
3. Analysis: state that the saved content contains the name and alias; test whether the files independently establish when or by whom the content was published.
4. Bounded finding: “The supplied files contain an advertisement using alias X and dataset label Y. They do not independently establish remote publication time, service control, possession of the dataset, or operator identity.”

Scenario B · The transaction reference

An incident-response team supplies an extortion message, a cryptocurrency address, and a transaction identifier. It asks whether the transaction record is consistent with a payment during the incident window.

1. Scope: preserve and examine supplied records and publicly observable transaction data only; no wallet access, key use, asset movement, or seizure action.
2. Preservation: keep the message, address string, transaction identifier, retrieved public record, retrieval context, and time-source notes as separate linked items.
3. Analysis: compare amount, network, and recorded time while documenting confirmation state, clock assumptions, exchange-rate source, and alternative explanations.
4. Bounded finding: “The public transaction record is consistent with value moving to the supplied address during the incident window. The record alone does not establish who controlled the address or why the transfer occurred.”

References and Source Notes

Sources are grouped by role so publication age is not mistaken for authority. Current procedural and project documentation leads the workflow. Analytic and exchange standards support the advanced modules. Older material remains useful as foundational context. Dynamic legal and policy sources are issue-awareness references and require current, jurisdiction-specific review. Source status was reviewed 2026-07-27.

Current procedural and technical authorities

1. [1] NIST SP 800-61 Rev. 3 (2025). Incident Response Recommendations and Considerations for Cybersecurity Risk Management. Current incident-response integration; supersedes Rev. 2.
2. [2] NISTIR 8354 (2022). Digital Investigation Techniques: A NIST Scientific Foundation Review. Scientific foundations, limitations, and rapid artifact change.
3. [3] SWGDE 18-F-002-2.0 (final, 2025). Best Practices for Digital Evidence Collection. Verify publication status and issue date in addition to the version label.
4. [4] SWGDE 17-F-002-2.1 (2025). Best Practices for Computer Forensic Acquisitions.
5. [5] SWGDE 18-F-001-2.0 (2025). Best Practices for Computer Forensic Examinations.
6. [6] SWGDE 21-F-001-1.1 (2024). Best Practices for Acquiring Online Content. Used here for preservation, documentation, volatility, and method review; covert-access and origin-obfuscation material is outside this guide's scope.
7. [7] NIST. Computer Forensics Tool Testing Program. Tool-capability testing and public test resources.
8. [8] Tor Project. About Tor Browser.
9. [9] Tor Project. Onion Services Properties.
10. [10] OHCHR and UC Berkeley Human Rights Center. Berkeley Protocol on Digital Open Source Investigations.
11. [11] SWGDE 23-F-006-1.1 (final, 2024). Tech Notes on Cryptocurrency. Recognition, triage, and collection; seizure and transfer are outside its scope.

Analytic and exchange standards

12. [12] Office of the Director of National Intelligence. ICD 203: Analytic Standards. 2015 directive with 2022 technical amendment.
13. [13] OASIS (2021). STIX 2.1.
14. [14] OASIS (2021). TAXII 2.1.
15. [15] FIRST. Traffic Light Protocol 2.0.
16. [16] MITRE. ATT&CK knowledge base. Behavior normalization, not actor identification.

Foundational context

17. [17] NIST SP 800-86 (2006). Guide to Integrating Forensic Techniques into Incident Response. Foundational background; not the sole modern procedural authority.
18. [18] RFC 3227 / BCP 55 (2002). Guidelines for Evidence Collection and Archiving. Foundational collection and order-of-volatility context.
19. [19] SWGDE 18-Q-002-1.0 (2018). Requirements for Report Writing in Digital and Multimedia Forensics. Foundational report-content guidance; current status should be rechecked for maintained use.

Dynamic and jurisdictional context

20. [20] Financial Action Task Force (2020). Virtual Assets Red Flag Indicators. Contextual risk indicators, not proof of identity or conduct.
21. [21] U.S. Treasury Office of Foreign Assets Control. Sanctions Related to Significant Malicious Cyber-Enabled Activities. Dynamic U.S.-jurisdictional context; use current qualified review.