Writing a Cyber Incident Timeline for Darknet Fraud Reports

Start with chat logs and disappearing messages. Then grab email headers. Wallet addresses and transaction hashes come last. A screenshot without the underlying data proves almost nothing to a bank, an exchange, or a reporting body. Platforms strip metadata.

Do not wait. A phishing mirror can vanish in hours. A stolen session token may remain valid for a day or two. A chat platform can delete a thread after a takedown or an exit scam. Your first action is not to report. Freeze the proof while it still exists.

Continue with the section overview or a closely related question:

• Payments and evidence
• Should I contact the scammer again?
• What evidence should a cybercrime victim save?

Work through this sequence. Export the full chat log first, timestamps, sender IDs, and any off-platform pressure to move, before the impersonator account disappears. Second, save the raw email headers for every message from a fake support ticket or advance-fee demand. Third, copy the wallet address you sent funds to, and the transaction hash. Fourth, capture the phishing mirror URL and the page source before the host takes it down. Fifth, record the time you noticed a clipboard hijacker or info-stealer, and what the pasted address looked like versus what you copied.

Volatility works against you. A hosted phishing page may live for only a few hours after detection. A chat moderator can delete a thread in seconds. A wallet drain on one chain can be chain-hopped to another within minutes. If you preserve the wallet address first and the chat log second, you may lose the one artifact that proves how you got the address. Reverse the instinct.

Why Screenshots Fail Alone

A screenshot is a picture of text, not the text itself. It has no header data, no sender IP, no timestamp beyond what the image file may carry, and many platforms strip that on upload. For an IC3 report or Action Fraud intake, investigators need the actual message, the actual email header, the actual transaction hash. Admissibility depends on whether the artifact can be verified independently, not on whether you have a clear image of it. Save the raw data and keep the screenshot as a secondary reference.

For an IC3 report or Action Fraud filing, each timeline entry needs five fields. Date and time in UTC. The event, written as a plain statement: "Received message from account posing as vendor support." The artifact, named and located: "Telegram export, chat ID saved as CSV." The platform or service, because a credential stuffing attempt on one exchange is not the same proof as a session token theft on another. The loss or exposure, stated as what was taken, not what you feel: "Advance-fee payment of the requested amount, transaction hash on file."

Do not use the timeline to argue. Do not write "obviously a scam" or "I knew it was fake." Reporting bodies want the sequence, not the interpretation. A log that reads like a server access log, one line per event, moves faster than one that reads like a diary.

If you cannot pin an exact time, use a range and say why. "Between 14:00 and 16:00 UTC, device showed malware loader behavior after opening a file." That is better than an invented timestamp. A wrong time can damage the whole report because it breaks the chain of custody logic an investigator follows.

A fraud evidence log is not a narrative. It is a numbered list of dated entries, oldest first, where each line names the event, the artifact, and the actor if known. Start with first contact. If the first contact was an impersonator account on a forum, name the forum, the username, the exact message time, and what the person claimed to be. If the first contact was a phishing mirror you clicked, record where the link came from and what the page asked for.

Then add every subsequent event. Each advance-fee demand gets its own entry. Each time you paid, each wallet address you used, each time you contacted support and got either a real reply or a fake support ticket. Include the recovery scam attempt if one happened after the loss. That is a separate crime and often more provable than the first one. A scam event sequence that ends at the loss misses the second fraud.

Work backwards when you write it. Most victims remember the loss first and the early contact last. But the log must read forward, because that is how a financial investigator traces the money and an IC3 analyst clusters the wallet address reuse. Build the forward sequence from your backward notes.

Contact Stage

Record the platform, the username, the exact text of the first message, and any off-platform pressure. Impersonators move to encrypted chat because it leaves less metadata for you to preserve. If someone asks you to move from a forum to a private messenger, that is a scam event sequence marker in itself. Write it down.

Payment Stage

Record the wallet address, the amount, the time, and the transaction hash. Write the address down before you paste it, then compare what you pasted to what you copied. A clipboard hijacker changes the address at paste time, and the only way to catch it is to look at the destination address in your wallet software before you sign. If you notice a mismatch, stop. Do not send. Record both addresses and both hashes.

Loss Stage

Record what disappeared. Funds from a wallet. Access to an account after a SIM swap. A service login after session token theft. Name the service and the time you lost access. If the loss followed a credential stuffing attack on another platform, note that too, because credential reuse rate is what turns one breach into many takeovers.

Volatility is the enemy of every fraud report. A chat log can vanish in minutes. A phishing mirror can go down in hours. A hosted page used for a credential harvest may be replaced by the phishing kit author before you finish reading it. Your timeline is only as good as the artifacts you preserved before they disappeared. That means the first hour after you realize something is wrong is not for reporting. It is for exporting, saving, and copying.

Admissibility follows from how you preserve. A raw email header is admissible. A screenshot of a Gmail inbox is weak. A transaction hash on a block explorer is verifiable. A screenshot of a wallet balance is not. When an investigator asks for the chain of custody, they are asking whether the artifact you submitted is the same one you saw. If you altered a file, renamed it, or cropped a screenshot, say so. Do not edit the raw export.

For darknet fraud, the most durable artifacts are the wallet addresses and transaction hashes. They outlive websites, chat accounts, and phishing domains. Wallet address reuse across incidents is how clustering works, and a transaction hash is how an exchange can freeze funds if the attacker cashes out through a compliant platform. Preserve those even if you lost the chat log.