Saving Cybercrime Evidence for a Darknet Scam Victim

Save the raw, unaltered digital record before you do anything else. Preserve full message headers, chat logs, transaction IDs, wallet addresses, and a chronological timeline immediately. Screenshots alone are insufficient because they strip metadata and can be altered. Original digital files or full headers are needed for any investigation. Evidence decays quickly, and panic often drives victims to delete the very material that could help authorities later.

Begin with messages and logs because they vanish fastest. Many chat platforms automatically delete messages after a set period, and phishing domains can disappear within 48 to 72 hours. Transaction IDs and wallet addresses sit on immutable blockchains and will persist, but the conversation that proves intent will not. Preserve in this order: volatile chat data first, durable blockchain records second.

Continue with the section overview or a closely related question:

• Payments and evidence
• How should an incident timeline be written?
• How should suspicious messages be preserved?

Export Conversations Before They Disappear

Start with the volatile items. Export the entire chat or message thread before the impersonator deletes it or the platform removes the account. Most messaging services offer an export function that saves the conversation as a JSON or HTML file, which retains timestamps and sender identifiers. Do not copy and paste the text into a document. Use the native export tool. If the platform lacks an export option, record a screen capture video that scrolls through the entire thread. Video is still far weaker than a raw export.

Capture Full Message Headers

Next, capture the full email or message headers. Headers contain the routing information, server IP addresses, and authentication results that investigators need to trace the source. In webmail clients, the option is usually called "Show Original" or "View Source." Copy the entire block of text, which will include lines like "Received: from" and "ARC-Authentication-Results." Save it as a .eml or .txt file without any formatting changes. A forwarded message strips these headers, so forwarding an email to report it destroys the most valuable data.

Record Transactions and Addresses

Third, record every transaction ID and wallet address involved. A transaction ID is a long hexadecimal string that uniquely identifies a payment on the blockchain. It proves that funds moved and links the victim's wallet to the recipient's. Write down the exact addresses, including any that appeared as "poisoned" lookalike addresses in the clipboard. Clipboard hijackers often swap addresses silently. Comparing the address you intended to use with the one in the confirmed transaction is the only way to spot the attack. The checklist is complete when you have raw message data, headers, transaction records, and a written timeline with timestamps in UTC.

Copy the transaction ID directly from the wallet or blockchain explorer and store it in a plain text file. The transaction ID is not the wallet address. It is the unique hash that appears in the wallet's transaction history after a transfer completes. This hash allows any investigator to view the transfer on a public block explorer without needing access to the victim's wallet. Do not store the ID only as a screenshot. A screenshot can be altered, and the text cannot be searched or copied without manual transcription, which introduces errors.

Wallet addresses and transaction IDs are the most durable evidence available. Even after a phishing domain is taken down and a messaging account is deleted, the blockchain record remains. An investigator can cluster a scam address across multiple reports and trace funds through chain-hopping attempts, though mixers and non-cooperative exchanges often halt attribution. Save the addresses in a separate file and note the exact time of each transaction. The timestamp links the payment to the conversation in the timeline. Without it, a prosecutor cannot prove the victim sent funds in response to a specific fraudulent message. This link is what turns a blockchain entry into admissible evidence.

Log Every Contact From the First Message

Start from the first contact. Record the date and time, the platform where it occurred, and the username or display name of the impersonator. Note whether the contact was unsolicited or followed a legitimate support request. Impersonators often reply to real support tickets faster than the genuine team, making the response speed itself a piece of evidence. Log every subsequent interaction, including any demands for advance fees, off-platform contact pressure, or requests to install software.

Document Every Payment Demand

The timeline must include every payment request, every wallet address shown, and every confirmation message. For an advance-fee scam, document the escalating demands. The first fee is often small and plausibly described as an escrow release, a shipping insurance, or a verification deposit. The second and third fees grow larger, each promised as the final requirement. The number of demands before a victim stops paying is a key metric for investigators. A timeline that shows five separate fee demands over three days is far more useful than a single complaint that says "they kept asking for money."

Capture Phishing URLs Exactly

Record any phishing URLs or domains exactly as they appeared, not as the page looked. A phishing mirror uses a lookalike domain that may differ from the real service by one character. Capturing the raw URL preserves that distinction. If the victim clicked a link and entered credentials, note the time and whether the page prompted for a two-factor code. A phishing kit that captures session tokens can bypass two-factor authentication entirely. That detail changes the threat classification from credential theft to session token theft. The timeline is the spine of the evidence package. Without it, even preserved messages lack context.

Evidence Type	What It Proves	Preservation Priority	Admissibility Weakness
Raw chat export	Intent, impersonation, fee demands	Highest: delete risk within hours	None if exported natively
Full email headers	Server origin, routing path, authentication	High: headers are lost on forward	Requires technical interpretation
Transaction ID and wallet address	Fund movement, recipient clustering	Medium: blockchain is durable	Chain-hopping can obscure destination
Phishing URL or domain	Impersonation method, kit deployment	High: domains disappear in days	Takedown removes the live page
Screenshot	Visual confirmation of a page or message	Low: insufficient alone	Strips metadata, alterable, unsearchable

Screenshots are the most common mistake victims make when preserving evidence. A screenshot captures only what was visible on the screen at one moment. It does not contain the underlying data that proves authenticity. Message metadata, including the sender's unique identifier, the server timestamp, and the message edit history, is absent. An investigator cannot verify that a screenshot was not edited because the file lacks cryptographic signatures. Courts routinely treat screenshots as weak corroboration, not primary evidence, because they are so easy to fabricate.

Platforms strip metadata aggressively. When a user downloads an image from a chat app, the original EXIF data is often removed. A screenshot of a conversation does not prove the conversation occurred on that platform at that time. A screenshot of a wallet address does not prove a transaction was sent. The gap between what a victim thinks is proof and what an investigator can use is wide. Victims assume screenshots are enough for law enforcement. Real-world investigations need metadata, full headers, wallet addresses, and preserved logs. The original digital files are the only records that carry the weight required for evidence admissibility.

File With Your National Agency

Reporting jurisdiction determines which agency can act on a darknet scam report. A victim in the United States files with the IC3, the primary federal intake for internet fraud. A victim in the United Kingdom files with Action Fraud, the national reporting gateway. In Canada, the Canadian Anti-Fraud Centre is the central body. In Australia, ReportCyber via the Australian Cyber Security Centre handles public reports. Each agency triages cases by loss amount, evidence quality, and whether the report matches an existing pattern. A single report of a small loss is unlikely to drive an immediate investigation. The same report combined with fifty others that share a wallet address can trigger action.

Report Anyway, Even If Recovery Is Unlikely

Official report impact is often overstated in public messaging. Reporting portals imply individual reports drive action. Real-world impact depends on loss size, jurisdiction, and whether the report matches an existing pattern. Triage systems prioritize aggregate harm over single complaints. Victims should report anyway. Aggregate data from the IC3 and Action Fraud shapes policy, secures funding, and helps blockchain analytics firms like Chainalysis and CipherTrace map scam infrastructure. A victim who does not report removes their data point from the public record entirely. Victim shame suppresses the reporting rate, which keeps darknet-adjacent fraud out of official statistics and skews public understanding.

A recovery scam is a secondary fraud that targets victims after the initial loss. Fraudsters monitor forums, social media, and even official complaint threads for people who have just lost funds. They then reach out with promises to recover the money using blockchain tracing, legal threats, or insider contacts. The distinguishing feature is the upfront fee demand. A legitimate recovery assistance effort does not charge before any action is taken and never guarantees results. A recovery scammer demands payment first, often in cryptocurrency, and then disappears or escalates with further fees.

Recovery scams are especially dangerous because they exploit desperation. A victim who has just lost funds is emotionally vulnerable and more likely to grasp at a promise of recovery. The scammer often uses the same impersonation tactics as the original fraudster, posing as a cybersecurity firm, a law enforcement affiliate, or a "white hat" hacker. Any cold outreach offering to recover darknet-related losses is a scam. Block the account, report it to the platform, and add the contact to the evidence timeline. The existence of a victim population guarantees a secondary fraud population offering recovery, and falling for both is tragically common.

Session Token Theft and SIM Swaps

Two-factor authentication does not stop all account takeovers. Session token theft bypasses passwords and two-factor entirely. An info-stealer infection silently collects saved credentials, cookies, and session data. If an attacker steals an active session token, they can act as the logged-in user without triggering a login alert or a two-factor prompt. The session remains valid until it expires or the user logs out, which can be hours or days. SIM swap attacks bypass two-factor by intercepting one-time codes at the mobile carrier level. The attacker socially engineers a phone company employee into porting the victim's number to a new SIM, then receives all text message codes.

Phishing Kits Capture Codes in Real Time

Phishing kits also defeat two-factor by capturing the code in real time. A victim enters their password on a phishing mirror, then enters the one-time code when prompted. The attacker relays both to the real service and establishes a session. The victim sees an error or a redirect and assumes a glitch, while the attacker now controls the account. Over-reliance on two-factor is a failure mode that security marketing encourages. Services imply two-factor stops account takeover. Real-world attacks using SIM swap, session-token theft, and phishing that captures one-time codes bypass it. Treat two-factor as a layered control, not a single one.