Ermittlungen und rechtlicher Rahmen · Lektion 1 von 5
What crypto forensics is
10 Min. Lesezeit
Diese Lektion ist noch nicht auf Deutsch verfügbar und wird daher auf Englisch angezeigt.
Every crypto investigation produces links and numbers, but only some of them can carry weight in a courtroom, a freezing application or an insolvency claim. Crypto forensics is the discipline of reaching findings about digital-asset flows, holdings and control in a way that another qualified person can check, repeat and challenge. Each finding rests on data that someone retrieved, decoded and interpreted; an examiner who cannot say which node produced the data, which software decoded it and whose labels were applied cannot defend the finding. This lesson sets out what makes work forensic, which cases it serves, who does it, and what each layer of blockchain data adds.
Analytic work and forensic work
The same blockchain data supports two kinds of work. Analytic work answers questions fast enough to act: which exchange received a deposit, how exposed a customer is to a mixer, whether a wallet is still active. It tolerates working assumptions, uses whatever tool is quickest and is judged by whether it was useful. Forensic work answers questions to an evidential standard: the finding rests on preserved source data, is reached by a stated method, is recorded so that it can be re-performed and is expressed with its limits. It is judged by whether it survives scrutiny by an opposing expert and by the court.
| Analytic work | Forensic work | |
|---|---|---|
| Purpose | Leads, risk scores, intelligence | Evidence for a decision by a court or competent authority |
| Standard | Useful and timely | Reproducible, documented, defensible |
| Sources | Tool output, labels, dashboards | Preserved raw data; tool output only as a pointer |
| Method | Often the tool's default | Stated, justified, validated |
| Uncertainty | Often left out | Graded and reported for each finding |
| Records | Optional notes | Contemporaneous notes, hashes, custody log |
| Audience | Colleagues and managers | Prosecutors, defense, the court, the other party |
Most cases start as analytic work and become forensic when a decision with legal consequences depends on them. The trap is carrying analytic shortcuts, such as an unverified label or an undocumented tracing rule, into evidence. Good units treat every case as potentially forensic from intake, because rebuilding provenance afterward is slow and sometimes impossible.
Reproducible, documented, defensible
Three tests separate a forensic finding from an opinion.
Reproducible. Another examiner, given the same sources and method, reaches the same result. On a public blockchain this is unusually achievable: every txid, block and amount can be fetched again from an independent node. What is not automatically reproducible is the interpretation layered on top: a clustering heuristic, a third-party label, a tracing method. ISO/IEC 27037 names repeatability (same method, same environment, same result) and reproducibility (same method, different tools or conditions, same result) alongside auditability and justifiability as qualities that digital evidence handling should have.
Documented. Every step is recorded as it happens: what was queried, from which source, with which tool version, at what time in UTC, and what came back. If the record does not show a step, a reviewer must assume it did not happen as described. Lesson 8.3 covers the mechanics.
Defensible. The method fits the question, its known weaknesses are stated, alternatives were considered and the conclusion goes no further than the evidence. A defensible finding anticipates the questions a defense expert will ask (Lesson 8.4).
A useful habit is to separate three layers in every statement:
- observation: what the chain or a record shows;
- inference: what the examiner concludes from it, and by which method;
- assumption: what is taken as given, such as a label being accurate.
What crypto forensics investigates
The techniques are shared, but each case type has typical starting points (seeds), questions and end points.
| Case type | Typical seed | Typical questions | Where it usually ends |
|---|---|---|---|
| Fraud and scams | Victim's payment txids | Where did the funds go; who controls the receiving wallets | Exchange accounts, freezes, victim recovery |
| Ransomware | Ransom address from the note or negotiation | Who received the payment; affiliate splits; cash-out | Seizure of unspent funds, attribution of infrastructure |
| Thefts and hacks | Exploit transaction, drained addresses | Dispersal through bridges and mixers; laundering path | Freezes by issuers and exchanges, recovery |
| Darknet markets | Market wallets from seized servers | Vendor, buyer and operator flows | Identification of operators and users |
| Sanctions evasion | Designated addresses or entities | Who deals with them; nested services | Blocking, enforcement, further designations |
| Terrorist financing | Donation addresses from campaigns | Collectors, intermediaries, end users | Disruption, often of small amounts |
| Insolvency and civil asset tracing | Company wallets, customer claims | What existed, where it went, who holds it now | Recovery for creditors, civil orders |
Public cases show the range. After the 2021 Colonial Pipeline ransomware attack, investigators traced the 75 BTC ransom and recovered about 63.7 BTC held at one address. In the Bitfinex 2016 hack, investigators followed about 119,754 stolen BTC over several years and in 2022 recovered more than 94,000 BTC after decrypting a file in an online storage account that held private keys. In both, the trace was only part of the case: the rest was legal process, device and cloud evidence, and documentation that made the findings usable.
Roles in a crypto investigation
| Role | Main question | Typical output | Main duty |
|---|---|---|---|
| Investigator | What happened, who is responsible, what can be recovered | Case strategy, legal requests, interviews | Lawful and fair conduct of the case |
| Forensic examiner | What do the preserved data show | Examination notes, findings, evidence packages | Sound method and evidence integrity |
| Analyst | What patterns and leads exist | Intelligence products, link charts, leads | Accuracy and grading of sources |
| Expert witness | What opinion can be given within expertise | Expert report, testimony | Independence and duty to the court |
Incident responders in exchanges and protocols often do the first hours of work after a theft. Their notes and exports become evidence later, so they need the same discipline. A court-appointed expert works for the court rather than for either party.
In small units one person may hold several roles, which is workable if every output records which role produced it. An intelligence product may rely on sensitive sources and is not written for court; pasting one into an evidential statement is a common reason findings are excluded or given little weight.
Where blockchain data comes from
Blockchain data comes in three layers, each built on the one below.
| Layer | What it contains | Example | Who produces it |
|---|---|---|---|
| Raw node data | Bytes and fields exactly as the protocol defines them | A serialized Bitcoin transaction in hex; an Ethereum log with topics and a data field | Any node that validates the chain |
| Decoded data | Raw fields parsed into readable structures | Inputs and outputs with addresses and amounts; a log decoded as Transfer(from, to, value) | Parsers, ETL pipelines, explorers |
| Enriched or labeled data | Decoded data joined with outside information | "Exchange hot wallet", USD value at the time, cluster ID, risk score | Analytics vendors, researchers, your own team |
Raw node data is the ground truth: every honest full node on the same chain returns the same bytes for the same block hash. Decoded data is only as reliable as the decoder, which must know the script type or the contract's interface (its ABI). Enriched data adds judgment: prices from a chosen market, labels from a chosen source, clusters from chosen heuristics. The higher the layer, the more useful the data and the more assumptions it carries.
Nodes, providers, explorers and warehouses
What a full node can answer depends on what it keeps. Bitcoin Core needs the optional transaction index (txindex=1) to look up any confirmed transaction by txid and has no address index, so address histories need a separate indexer (open-source examples include Electrs, Fulcrum and Esplora). A default Ethereum full node holds state (balances, contract storage) only for recent blocks, roughly the latest 128 under Geth's default path-based storage; historical balances and most tracing of old transactions need an archive node. Since July 2025 the major Ethereum execution clients also support partial history expiry under EIP-4444, letting a node drop pre-Merge (before September 2022) bodies and receipts while keeping every header. Lesson 2.1 covers node APIs.
RPC providers run nodes for you, and you inherit their configuration, rate limits and errors. A block explorer is right for a first look and wrong to rely on alone: its methods are rarely documented, its labels are applied retroactively to old transactions, and explorers disagree on derived figures such as internal transactions and token balances. A data warehouse (a columnar database of indexed chain data) answers questions about many transactions, but is only as good as the ETL that filled it. A sound workflow uses an explorer for orientation, a warehouse for scale and a node to verify the specific transactions a finding depends on (Lesson 2.7).
A worked example: one payment, two kinds of answer
A victim reports a 3.0 ETH payment to a fake investment platform. An analyst opens a tracing tool and writes: "Funds went to Exchange K." That is a lead. The forensic version reads:
Finding F-03
- Observation: txid
0x9c1e…44ab(block 19,204,124, 2024-02-11 10:06:59 UTC) moved 3.0 ETH from the victim's address0x5D0f…a1C2to0xA1b2…9F. - Observation:
0xA1b2…9Fsent 2.98 ETH to0x77cd…e310in txid0x41b0…7d2e(block 19,204,160).0x77cd…e310later swept its balance to0xE3f9…08B1. - Inference:
0x77cd…e310is a deposit address of Exchange K. Basis: the sweep to0xE3f9…08B1, which two independent sources label as an Exchange K hot wallet (snapshots S-07 and S-08). - Assumption: the labels in S-07 and S-08 are accurate.
- Grade: observations A, recorded on chain (re-verified on own node, 2024-03-02); deposit-address attribution C, a single indicator (the sweep) resting on third-party labels, rising to B if Exchange K's records confirm it.
Anyone can re-check the observations from the chain. The inference names its basis, the assumption is stated rather than hidden, and the grade line says what would change the conclusion: records from the exchange (Lesson 3.2 develops grading).
The data definition matters just as much. Asked how much ETH 0xA1b2…9F received in February 2024, an explorer's transaction list and a warehouse query on the transactions table both total 41.20 ETH, while a query that adds internal calls from the traces table totals 53.70 ETH. None is wrong. The first two count only top-level transactions with the address in the to field; the extra 12.50 ETH arrived through contract calls (a withdrawal from a smart-contract wallet) visible only in traces. Including wrapped ETH, a token visible only in event logs, would give another answer; counting reverted calls, which traces record but which moved nothing, a wrong one. "53.70 ETH received as native value in blocks X to Y, including successful internal transfers and excluding WETH" is an answer another examiner can reproduce.
Reproducibility habits
What breaks reproducibility is rarely the raw layer, which does not change once final. It is everything around it:
- Moving targets. "Latest" changes every few seconds. Anchor every query to a block height and record that block's hash.
- Unrecorded sources. Note the node or provider, the client and its version, and the dataset and table version.
- Unrecorded transformations. Keep the exact query or script, including filters and unit conversions.
- Mutable labels. Record each label's source and the date you read it; labels get revised.
- Unfinalized data. Recent blocks can be replaced (Lesson 2.1).
A finding that rests on "the explorer said so last Tuesday" cannot be checked; one that rests on a named block hash, a saved query and a recorded client version can be checked by anyone with a node. Lesson 2.6 turns these habits into a provenance record.
Exam focus: expect to tell analytic from forensic work, to recognize the evidential standard as reproducible, documented and defensible, and to know the ISO/IEC 27037 qualities (repeatability, reproducibility, auditability, justifiability). Be ready to sort statements into observation, inference and assumption, match case types to seeds and end points, distinguish the roles, and explain why intelligence products stay out of evidential statements. On data: the three layers and their assumptions, txindex and the missing address index, archive nodes for historical state, EIP-4444, why native, internal and token transfers give different totals, and anchoring queries to a block height and hash.