Evidence

What an evidence item holds

An evidence item is one thing under examination: a laptop, a disk image, an email account. Each carries the fields its type defines, plus the records that make it usable as evidence.

• Ownership. The legal owner, the person who was using it, and whoever currently holds it.
• Storage location. A shelf in an evidence locker, or a path on a file server.
• Chain of custody. Who had it and when, as a verifiable record.
• Investigation status. Where the item has reached in your workflow.
• Runbooks. Procedural checklists for handling it.
• Flags, files and notes. Triage tags, encrypted attachments, and analysis findings.

Physical and digital items work the same way. The difference is what you put in the storage location field, and which type you choose.

Evidence types

The type decides which fields an item has. DFIRe ships 26 of them, and each defines its own metadata, its icon, and any runbooks that attach on creation.

Group	Types
Devices	Laptop, Workstation, Server, Mobile Phone, Tablet, Hard Drive Internal, Hard Drive External, Flash Media, SIM Card, Network Device, Drone / UAV, Paper Documents
Digital artifacts	Disk Image, Memory Image (RAM), Virtual Machine, Network Capture (PCAP), Log File, Malware Sample, Database, File, Cloud Resource
Accounts and identities	User Account, E-Mail Account, Email Message, Cryptocurrency Wallet
Catch-all	Other, for anything the list does not cover

To see exactly which fields a type carries, or to change them, open Settings → Evidence Types. Administrators can edit the shipped types and add their own. See Evidence types.

Parent and child items

Items nest, which is how you record where an artifact came from. A laptop holds a hard drive, the hard drive yields a disk image, a phone holds a SIM card, a server yields a memory image.

An item has one parent, and the hierarchy runs one way. An item cannot go underneath one of its own children, however deep the chain. DFIRe refuses a move that would fold the hierarchy back on itself, and says why.

Adding an item

Open a case, go to the Evidence tab, and choose Add Evidence. The case header has the same button.

1. Pick the type

   This decides which fields the rest of the form offers.

2. Name it and place it

   Give it a descriptive label, set a parent item if it came out of something else, and record the storage location.

3. Record who it belongs to

   Set the legal owner and the primary user. You can pick existing legal entities or create one without leaving the form.

4. Fill in the type's own fields

   Serial numbers, hashes, whatever that type defines.

5. Add the item

   DFIRe opens its detail view.

Import on the case Evidence tab bulk-loads items from a CSV file, and previews which rows it will create or update before writing anything.

The item view

The sidebar carries the item's identity: type, name, location, legal owner, primary user, and the current custodian taken from the latest custody entry. Below those sit its place in the hierarchy, its flags, and its type-specific fields. A progress bar summarizes how far its runbooks have got.

Alongside it sit the working tabs. Notes takes analysis findings in Markdown. Runbooks holds the procedural checklists, with the ones from the evidence type attached on creation and others added by hand. Custody holds the chain. Files takes acquisition logs, exported artifacts and screenshots. History shows the full audit trail for the item, including its custody transfers, uploads and notes.

Investigation status

Each item moves through a workflow you control. Click the status badge on the item to change it. The shipped workflow follows the standard forensic process:

Status	Meaning
Identification	Potential evidence spotted.
Acquisition	Seized, imaged or otherwise secured.
Processing	Indexing, hashing and extraction.
Analysis	Review and correlation.
Reporting	Findings written up.
Archived/Returned	Returned to its owner or stored long term.
Finalized	Handling complete, nothing further needed.

Administrators can rename, reorder, add and remove these steps under Settings → Evidence Workflow. See Workflows.

Flags

Flags are colour-coded triage tags. DFIRe ships ten, and administrators manage them under Settings → Triage Flags.

Flag	Meaning
Evidence	Holds something relevant to the case.
No evidence	Examined, nothing relevant found.
Malware	Contains malware.
Illegal content	Contains illegal content.
Broken	Device damaged or file corrupted.
Return	Give it back to the owner.
Do not return	Keep it.
Reimage OS	The device still needs wiping.
OS Reimaged	The device has been wiped.
Personal	Personal property rather than company equipment.

Owner, user and custodian

Three different questions, three different fields.

• The legal owner owns the item, which decides where it goes back to.
• The primary user had it in daily use, which is often who you need to interview.
• The custodian holds it right now. You never set this directly. DFIRe derives it from the most recent custody entry.

Owners and users are legal entities: people, organizations, agencies and teams, kept in the Entities directory in the top navigation. See Legal entities.

Files on an item

Attach acquisition logs, exported artifacts, analysis output and screenshots. Uploads over 8 MB go up in chunks, and a general attachment can reach 4 GB. Photographs for the item's gallery are capped at 32 MB.

DFIRe encrypts Secure-tier files before they leave the application server. The key comes from the tenant key, the key of the case or item they belong to, and a salt of their own. See Storage for the tiers, the size limits and the proxy settings large uploads need.

An ordinary user cannot move an uploaded attachment to a different case or item. A Secure-tier case attachment can be linked once to an item in the same case, and its description stays editable.

Very large forensic images are better handled by the Direct Storage tier, or kept on dedicated storage with the item's storage location field pointing at them.

Chain of custody

The chain records who held an item and when. It matters most for physical evidence, and it is optional: many items, such as log files and memory images, never need one. The custodian field reads "No record" until the first entry exists.

Transfer types

Type	When to use it
Intake	The item is entering or re-entering custody. Every chain starts with one. A second intake is accepted only after a release, to record re-acquisition.
Transfer	The item moves from one custodian to another. The "from" party must be the current custodian.
Correction	An earlier entry was wrong. This fixes the chain without deleting anything, and requires a note explaining it.
Released	The item leaves custody, returned to its owner or sent for destruction. The "from" party must be the current custodian.

To record one, open the item's Custody tab and choose Record Custody Transfer. Pick the type, set the parties, which can be legal entities or DFIRe users, and record the time and location. Submitting updates the item's storage location.

Entry order

Entries are listed by the transfer time you recorded, which is how a chain of custody reads. Each also shows the position it was added in. Those two orders match unless someone recorded a handover after the fact, so an entry numbered out of step with its position is one that was backdated. A backdated entry goes on the end of the chain and does not rewrite what came before it.

Tamper detection

Every entry carries a SHA-256 hash over its own contents, meaning the parties, times, location, purpose, condition and notes, together with the hash of the entry before it. Change anything in a recorded entry and its hash changes, along with every hash after it, so the alteration shows instead of passing silently. The Custody tab recomputes the whole chain each time you open it and says whether it still matches.

The parties on an entry are the ones recorded at the time, which is what the hash covers. Renaming a legal entity or a user account later changes neither what a past entry displays nor whether it verifies.

Entries written before this feature was installed were hashed during the upgrade. Their chain therefore attests to what they contained at that moment rather than when they were first written. From that point on, the chain shows that nothing has changed.

DFIRe offers no way to edit or delete a custody entry, so the hashes guard against changes made directly to the database. Two limits are worth knowing.

• Entries removed from the end of a chain leave a shorter chain that still verifies. Catching that needs a copy of an earlier chain hash, which the printed receipt and the downloaded JSON both give you.
• The hashes show that a record has not changed since it was written. They say nothing about whether the handover it describes actually happened.

Handovers reach the audit log with their hash attached, so on an installation that forwards audit records, each chain hash leaves the installation as it was recorded. Entries created by a case import are covered by the import's own audit record rather than one each.

Custody records still follow your retention policy. Deleting a case removes its evidence and custody records with it. The chain guarantees that the records you hold are the ones that were written, not that records are kept forever.

Importing a case from another installation

A chain names the people and organizations that held the evidence, as that installation knew them. Those identities do not travel. An account with the same name on two installations is not the same person, and matching them by name would assert that somebody took custody of evidence they never handled.

So a case exported from a different installation imports its evidence items without their chains, and the import reports which items were affected. A case this installation exported itself imports normally, including after restoring a backup onto a new host.

Verifying a chain yourself

Download JSON in the Custody tab exports the chain with each entry's exact hashed contents beside its hash. Run verify_custody_chain.py against that file. It needs only Python 3, with no DFIRe access, credentials or network. It recomputes every hash, checks that each entry links to the one before it, and prints the chain hash.

Administrators can check every chain on the server at once with verify_custody_chains, which reports the first failing entry per item and exits non-zero if any chain fails.

Printable receipt

Print in the Custody tab opens a clean, print-ready page with the item's details and its complete chain, noting that the electronic record in DFIRe is the authoritative one.

The receipt prints each entry's hash and the chain hash, which is what lets you detect entries removed from the end later. To check one, find the entry number on the sheet and confirm that entry still has the same hash in DFIRe. A chain that has grown since is expected and leaves the earlier hashes untouched. A chain now shorter than the sheet, or with a different hash at that number, has been altered.

Building out the hierarchy

Add Related Evidence on an item creates a new item already linked as its parent or child. It saves going back to the case view, for example when you create a disk image directly from the hard drive it came off.