Attribution and OSINT · Lesson 2 of 5
Attribution sources and their reliability
8 min read
Every attribution in a forensic report rests on a source, and the defense will ask about each one: where did this label come from, when was it true, who checked it, and could it have been copied from somewhere else? Sources range from records a service produced under legal process to an unexplained tag on a public explorer. This lesson sets out the main families of attribution source, their typical reliability, and a method for grading, dating and reconciling them, building on the label sources described in the IDFE-BA lesson Attribution and labeling.
Source families at a glance
| Source | What it gives | Reliability | How to verify | Main risks |
|---|---|---|---|---|
| Self-published addresses | An entity's own reserve, donation or contract addresses | High for the listed addresses, on the date published | Archive the list; confirm the domain is the entity's | Stale lists; fake lists from impersonators |
| Authority releases | Addresses in indictments, seizure notices, sanctions listings, advisories | High for the named addresses | Archive; cite issuer and date | The attribution is the authority's; extensions are yours |
| Service and issuer records | Account assignment, KYC, deposit and withdrawal logs, ledgers | High as records; identity only as submitted | Hash on receipt; reconcile with the chain | Wrong period or account; KYC names the holder, not the actor |
| Seized databases | Server data from takedowns of markets, mixers or services | High once validated | Custody record; test rows on-chain | Schema, time zones, test data, unfunded addresses |
| Victim and incident disclosures | Attacker addresses in post-mortems and victim reports | High for the incident addresses | Check against the incident transactions | Early lists corrected later |
| Commercial labels | Vendor attributions inside analytics tools | Variable; rarely explained | Record the version; ask the basis | Opaque method, undated, versions change |
| Community labels | Explorer tags, open datasets, user scam reports | Low to moderate | Trace to the origin | Circular copying, malicious reports |
| Leaked data | Breached customer databases, dumps | Unknown | Re-establish through a lawful source | Legality, authenticity, data protection |
The table is a starting point. A self-published list on an impersonating domain is worthless; a community label that you trace to a court filing is strong. Grade the specific item, not the family.
Records from services and issuers
Exchanges, custodians and stablecoin issuers hold the records that bridge the service and account-holder layers (see the lesson From address to entity to person). Records produced in answer to legal process are usually the strongest attribution source in a case, but they still need examination:
- Authenticate the production: who produced it, through which channel, with what covering declaration, and the hash of each file on receipt (see the lesson Hashing, logging and chain of custody).
- Check scope: do the period, account and asset match the request?
- Reconcile with the chain: every deposit and withdrawal in the records should match a transaction you can verify on a node, with the same amount and a plausible time. Mismatches reveal internal transfers, off-chain ledger moves or errors (see the lesson Exchange and cloud accounts as evidence).
- Remember what KYC is: the documents a customer submitted, verified to the service's standard at the time.
A stablecoin issuer can also confirm that it froze an address and when; its records of the freeze are primary.
Seized databases
Takedowns of darknet markets, custodial mixers and illicit exchanges often yield server images containing user accounts, deposit addresses and internal transfer logs. Such data can attribute thousands of addresses at once and is often shared among authorities through police cooperation channels (see the lesson Custodial mixers).
Treat a seized database as evidence with its own provenance. The examiner who relies on it needs the seizing authority's chain of custody, the hash of the image, and an understanding of the schema: which column holds the deposit address, which time zone the timestamps use, whether rows include test accounts, cancelled orders or addresses generated but never used. A deposit address generated for a user but never funded proves nothing about value. Validate a sample of rows against the chain before relying on the rest.
Leaked data: legal and ethical limits
Breached customer databases and other dumps circulate on forums and are sometimes offered to investigators. They are tempting because they can link addresses or emails to names. They are also hazardous:
- Legality: possessing or processing stolen personal data may itself be unlawful, and rules differ widely between jurisdictions. Use requires a clear legal basis and a written organizational policy, decided by legal advisers, not by the examiner.
- Authenticity: dumps are often recompiled, merged with older breaches or partly fabricated.
- Data protection: the data concerns many uninvolved people. Proportionality and minimization apply (see the IDFE-BA lesson Data protection, ethics and responsible disclosure).
- Disclosure and fairness: material that cannot be disclosed or authenticated can undermine a case.
Where use is permitted at all, a leaked record is at most an intelligence lead, graded at the bottom of the scale, and the fact must be re-established through a lawful source, typically a request to the service whose data leaked.
Commercial and community labels
Analytics tools carry large proprietary label sets. They are often well researched, but the method behind an individual label is rarely visible, and labels change between versions without notice. For forensic use:
- Record the tool, version, label text, category and the date and time it was viewed, and capture the screen or export (see the lesson Tooling, reproducibility and validation).
- Ask the basis for any label a finding depends on: test transaction, public release, records, heuristic extension.
- Corroborate decision-critical labels independently, for example with a test deposit of your own, a self-published list or the service's confirmation.
Community labels, such as explorer public tags, open datasets and user-submitted scam reports, have no warranty at all. Scam reports can be filed maliciously against innocent addresses. Use them to generate hypotheses, then trace each to its origin; copies of one origin count once (the IDFE-BA lesson Attribution and labeling calls this circular reporting).
Grading source and information separately
Intelligence practice grades two things independently: how reliable the source is, and how credible the specific item of information is. The NATO "Admiralty" system uses letters A to F for source reliability (from completely reliable to cannot be judged) and numbers 1 to 6 for information credibility (from confirmed by other sources to cannot be judged). Many law-enforcement bodies, Europol among them, use a four-by-four version: sources A, B, C or X (cannot be assessed) and information 1 to 4, from information whose accuracy is not in doubt to information the source does not know personally and that cannot be corroborated.
The two-axis approach suits attribution well. A reliable source can pass on an item it did not know first-hand; an unknown forum user can post an address that the chain then corroborates. An illustrative 6x6 mapping:
| Item | Source | Information | Why |
|---|---|---|---|
| Exchange production assigns deposit address to account | A | 1 | Primary record, reconciled with the chain |
| Vendor label "Exchange K", basis not stated | B | 3 | Usually reliable source; item not independently confirmed |
| Forum post claims an address belongs to a scam | F | 3 | Unknown poster; address activity fits the claim |
| Address from a leaked dump linked to an email | F | 6 | Provenance and authenticity unknowable |
Record both codes with every label in the case's attribution log, alongside the confidence grade of the link (see the lesson From address to entity to person).
Verifying, dating and reconciling labels
Every label is true for a period. A practical verification routine:
- Trace to origin. Find the first publication or record, not the copy you saw.
- Preserve and date it. Archive the page or record with URL, UTC capture time and hash (see the lesson OSINT methodology).
- Check the activity window. Does the address's on-chain activity fit the claimed role in that period? An address labeled as an exchange hot wallet that stopped moving in 2021 says nothing about 2026 deposits.
- Check behavior. Does the address behave like the category: sweeps for deposits, large fan-out for hot wallets, contract code for a bridge?
- Seek a second, independent source for any label a finding depends on.
When sources disagree, do not average them:
| Conflict | Usual resolution |
|---|---|
| Authority release versus vendor label | Report the authority's attribution as theirs; note the vendor label and ask its basis |
| Service records versus any label | Records govern for that service's own addresses, once reconciled with the chain |
| Two vendor labels naming different entities | Treat as a possible false cluster merge; re-examine the cluster links |
| Recent label versus older label | Check whether the address changed hands or role; both may be right for their periods |
Keep the losing label in the log with the reason it was set aside. Disagreements between sources are exactly what defense experts look for, and showing that you found and resolved them is stronger than appearing never to have noticed (see the lesson Disclosure and defense scrutiny).
Exam focus: the main source families, their strengths and risks, and how each is verified; authenticating, scoping and reconciling service records; validating seized databases (provenance, schema, time zones, unfunded addresses); legal, authenticity and data protection limits on leaked data, and re-establishing facts through lawful sources; recording and asking the basis of commercial labels; circular reporting; two-axis grading of source and information (the NATO Admiralty 6x6 and the law-enforcement 4x4 versions); dating labels against activity windows; resolving conflicts between sources and keeping the reasons.