Device artifacts and wallet recovery · Lesson 2 of 5
Search and seizure of crypto at the scene
7 min read
A search in a crypto case has two clocks running at once. One is the ordinary evidential clock: preserve devices and data so that findings can be defended later. The other is the asset clock: anyone else who holds a copy of a seed phrase can move the funds within minutes, wherever they are. This lesson covers how to plan the search, make live and dead-box decisions, handle hardware wallets and seed backups, seek access lawfully and document the scene so that both clocks are respected.
Planning before entry
Most scene failures are planning failures. Before entry, the team should know what it expects to find, what it is authorized to do, and who decides when the unexpected happens.
| Planning item | Questions to settle |
|---|---|
| Intelligence | Which wallets, exchanges and chains does the subject use? Do provider records, on-chain analysis or OSINT suggest hardware wallets, a full node or large holdings? |
| Authority | Does the warrant or order cover digital devices, data stored on them, data reachable from them, and the seizure or transfer of crypto-assets? Is separate authority needed for cloud data or data held abroad (see the lesson Legal authority and international cooperation)? |
| People | Is a digital evidence specialist present for live decisions? Who is the crypto specialist? Who can authorize a transfer of funds at the scene? |
| Kit | Cameras, RF-shielded bags or enclosures, external power banks, write blockers, tamper-evident bags, a clean examiner laptop, and an agency-controlled wallet prepared in advance |
| Timing | Can searches of co-suspects be simultaneous? Should freeze requests to exchanges be ready to send at entry (see the lesson Freezing and seizure options)? |
The agency wallet and the transfer procedure belong in the plan, not in an improvisation at the kitchen table; the lesson Securing seized crypto-assets covers how they are set up.
Live versus dead-box decisions
A dead-box acquisition examines a device that is powered off. A live acquisition captures data from a running system. The choice follows the order of volatility set out in RFC 3227, Guidelines for Evidence Collection and Archiving: collect the most short-lived data first, such as memory, network state and running processes, before data on disk. In crypto cases the volatile data can be decisive, because a running wallet may hold decrypted keys in memory and full-disk encryption may make the powered-off disk unreadable.
| Device state on entry | General action |
|---|---|
| Computer powered off | Leave it off; seize for dead-box imaging |
| Computer on and unlocked, wallet or exchange open | Prevent sleep or lock; photograph and film the screen; a trained examiner considers memory capture and live acquisition before shutdown |
| Computer on and locked | Do not guess passwords; photograph the screen; consider memory capture; record encryption indicators |
| Phone on | Keep it on and powered; isolate it from all networks in an RF-shielded enclosure; record whether it is locked |
| Phone off | Leave it off; isolate and seize |
| Hardware wallet | Do not power on, connect or enter PINs; seize with cables, box and any papers |
Two notes for mobile devices come from SWGDE's Best Practices for Mobile Device Evidence Collection & Preservation, Handling, and Acquisition (version 2.0, 2025). Airplane mode may leave Wi-Fi or Bluetooth active, so confirm isolation or use shielding. And a reboot can move a phone from the after first unlock (AFU) state to before first unlock (BFU), in which much more data is encrypted and may become unrecoverable, so stable external power matters.
Every live action changes the system. ISO/IEC 27037 accepts this where it is justified, provided the examiner minimizes changes and records each action with its time and reason. A live action log is therefore mandatory, not optional.
Volatile data that matters in crypto cases
When a system is running, the following can be lost at shutdown or lock:
- Memory: decrypted wallet keys or seeds held by running wallet software, passwords, clipboard contents (often an address that was just copied).
- Open sessions: exchange accounts logged in, browser-extension wallets unlocked, webmail showing exchange notifications.
- Screen state: balances, addresses and transaction histories displayed by an open wallet.
- Network state: connections to wallet servers, node peers, remote desktops or other machines the subject controls.
- Two-factor codes in authenticator apps on an unlocked phone.
Documenting what an open wallet displays, by photography or screen recording, is very different from operating it. The examiner records what is shown; any transfer of funds happens only under the plan and the authority, with the controls described below.
A public example shows why planning around live state matters. In the 2013 Silk Road arrest, investigators arranged the arrest so that the operator's laptop was taken while open and logged in, preserving access to data that encryption would otherwise have protected.
Hardware wallets and seed backups
A hardware wallet is designed to resist exactly what a curious searcher might try. Many devices wipe themselves after a small number of wrong PIN entries, so nobody at the scene should attempt a PIN, including one written on a note nearby; record the note and seize it. Seize the device with its cable, box and any recovery card.
The device is often less important than its seed backup, because the backup restores the wallet without the device. Search for it as described in the lesson Wallets on seized devices. When one is found:
- photograph it in place with an agency camera, never a personal phone;
- classify the photos as key material and restrict who can view them;
- seal the backup in a tamper-evident bag without transcribing it at the scene unless the plan requires an immediate transfer;
- log the find, the seal number and every person who saw the words.
Anyone who sees a seed phrase could later move the funds, so limiting exposure protects both the assets and the officers from later allegations.
Seeking access under lawful authority
People at the scene may provide PINs, passwords, passphrases or the location of backups. Whether a person can be required to provide them, and what protection against self-incrimination applies, differs between jurisdictions; the team should know the applicable rule before entry. Whatever the rule, three practices are common to good investigations:
- Record exactly what was asked, what was said and what was provided, with times.
- Do not let the subject operate a device. A user can enter a duress PIN, trigger a wipe, or open a decoy wallet with a different passphrase while appearing to cooperate.
- Verify, do not trust. A passphrase that opens a wallet with a small balance does not prove there is no other passphrase-protected wallet behind the same words.
Questions about accounts, exchanges and other devices are as useful as passwords: an answer naming an exchange can be turned into a freeze request within minutes.
Securing funds and documenting the scene
Possession of a seed phrase does not make the funds safe, because an associate may hold a copy. Where the authority covers it and the plan provides for it, funds are moved promptly to an agency-controlled wallet under dual control, with a test transaction, as described in the lesson Securing seized crypto-assets. Balances held at custodial services are protected by immediate freeze or preservation requests instead.
Scene documentation ties everything together: photos and video before anything is moved, a sketch, the item log, and the live action log. Each live action is recorded in the same structured way:
{
"case": "CASE-0417",
"action_id": "LA-006",
"time_utc": "2026-03-14T07:18:40Z",
"device": "CASE-0417-I-003 laptop, on, unlocked",
"action": "Screen video of open desktop wallet; no clicks on send or settings",
"reason": "Displayed balances and addresses lost at lock or shutdown",
"performed_by": "Examiner 1",
"witness": "Examiner 2",
"output": "VID_0009.mp4, SHA-256 3c7e…b1d9",
"system_changes": "Mouse moved to prevent sleep"
}
The record identifies the device and its state, what was done and deliberately not done, why the action was necessary, who performed and witnessed it, the output file with its hash, and the changes the action made to the system. A defense expert reviewing it later can see that the live step was justified and controlled. Hashing and custody of the outputs continue as described in the lesson Hashing, logging and chain of custody.
Exam focus: the two clocks (evidence preservation and asset movement) and the planning items that serve them, including authority scope, specialists, kit and a pre-prepared agency wallet; live vs dead-box decisions and the order of volatility (RFC 3227); mobile isolation, external power and AFU vs BFU; volatile data relevant to crypto (memory, open sessions, screens, clipboard, two-factor codes); never entering PINs on a hardware wallet; treating seed backups and their photos as key material; recording and verifying access information without letting the subject operate devices; prompt transfer to an agency wallet under dual control, recorded in the live action log.