Workflow Automation in Digital Forensics

Introduction

Digital forensics studies the traces that computers leave when people and programs act on them. A disk records visible files and less visible residue, including file-system metadata, logs and execution traces. Anti-forensics is deliberate interference with those traces: it makes a disk harder to read by hiding, deleting, altering, or confusing the residue that an investigation would normally use. The goal of an investigator is to detect such attempts, and their job is to deal with disks whose current surface no longer gives a reliable account of its history.

Digital forensic analysis is used by institutions that investigate legal cases or security incidents at scale (public agencies, regulated firms, incident-response teams, insurers and private operators). Each result needs enough record to reconstruct the evidence path, identify the tools that produced each artifact and separate observed traces from proposed interpretations.¹

This article presents a prototype workflow for automated anti-forensic detection. Its contract-defined stages are local engineering terms for ordinary forensic controls: declared scope, documented collection, parser-backed examination, reviewable analysis, reporting artifacts and validation records. The prototype runs a scripted workflow and tests LLM assistance as bounded candidate-output gates.

For this experiment, the evidence source is synthetic. A generation pipeline builds a Windows VM, runs scenario playbooks that inject a known anti-forensic pattern, adds ordinary background activity and exports the guest disk as an evidence image. The scenario record stays outside the disk and enters only during evaluation, after the run has already produced findings.

The experiment is designed to test whether LLMs can replace or support traditional static approaches in forensic analysis, while preserving the records needed to assess the final findings. The prototype therefore splits typical forensic analysis tasks into contract-defined workflow stages and tests LLM proposal slots one at a time, allowing us to assess whether they add measurable value against the scripted reference run.

1. The Run Ledger

Digital forensic practice moves from evidence collection to examination, analysis and reporting.² The workflow starts from that conservative baseline. It defines the evidence objects to read and the analytical operations to run, then records them as a run profile. Collection extracts the declared disk artifacts into a run directory and records their provenance. Parser adapters turn raw tool outputs or direct artifact scans into normalised observations, so later checks reason over typed records instead of an unbounded disk surface.

Profile	Forensic question	Synthetic manipulations	Disk Artifacts	Operations
Q-DEL-01	Was deleted content used to conceal evidence?	Create target files, open them, delete them and leave user traces.	$MFT, $UsnJrnl, MRU records, shell links.	Collect, parse, compare active presence, correlate secondary traces.
Q-TIME-01	Was the disk timeline tampered with?	Alter selected NTFS timestamps after ordinary file activity.	NTFS timestamps, USN journal entries, $LogFile.	Collect, parse, compare timestamp families, build chronology.
Q-HIDE-01	Was data concealed outside the primary file surface?	Write hidden payloads into named streams with detectable content.	$MFT, named $DATA streams, collected stream content, YARA matches.	Collect, parse, enumerate named streams, scan content.
Q-LOG-01	Were Windows logs cleared or disrupted?	Clear or interrupt selected event logs after background activity.	Security EVTX, System EVTX, event record IDs, parser output.	Collect, parse, detect clearing events, check record sequences.

Sample set of run profiles, showing how forensic questions map to synthetic manipulations, disk artifacts and contract-defined operations.

A run profile is the executable form of a forensic question. It names the evidence source, artifact families, parser outputs, detector checks and generated artifacts the run may use. Once selected, the profile fixes the operation sequence over the evidence source. Each stage declares its inputs, tools, output schemas, checks and allowed state transitions.

The run ledger is the prototype’s audit-trail and provenance record. Every artifact points back to the run that produced it, with its origin operation, input set and hash attached. The ledger has two surfaces. An append-only event record preserves state changes (profile selection, collection, parser output, detector execution, model call, reviewer decision, scoring and reopening). Materialized views expose the same state for review (evidence index, findings ledger, interpretation brief, semantic interpretation and run packet). Together these surfaces show the route from collected evidence to findings, interpretation and evaluation.

2. Introducing Automation

The scripted workflow gives the evidence path a stable form. It does not remove the work around that path. A user still has to turn a case question into profile candidates, decide whether evidence must be generated or selected, inspect missing artifacts, distinguish a blocked run from a limited run and route findings into review. The prototype treats those moments as proposal slots, meaning human-reviewed gates where a model may draft one candidate output from a declared input package. The runner builds that package, the model drafts the candidate and the interface shows both together for review.

The profile-routing page turns the analyst question into a draft run profile with selectable generation entries, artifact reads, operations and boundary fields.

The model only enters at a proposal slot. When the run reaches that slot, the runner assembles the input package from the current ledger state. The model returns a candidate package, and the gate accepts, rejects, or revises it before the workflow advances. Evidence handling, state transitions and accepted run state stay with the scripted workflow. The audit trail records model calls as run events, which makes them comparable to the scripted reference run. The measurement asks whether automation makes repeated runs faster to coordinate, easier to compare and harder to misread while the evidence remains the object under examination.

3. Automation Layer Design

When it comes to system design for this prototype, the first constraint is size. A forensic run contains a disk image, derived artifacts, intermediate checks, proposed findings, review decisions and scoring records. The model should not see that whole state at once. Filesystem metadata alone can exceed a prompt budget. In one local run, MFTECmd produced a 230 MB CSV over 467,724 source rows. A raw NTFS $MFT pass over 100,000 file-record segments averaged about 98 MiB before parser output. At that average, 100,000 retained observations would serialize to about 73.6 million JSON characters before other artifact families, citations, instructions, or generated text are included.

Long-context research adds a second constraint. A larger window does not guarantee reliable use of relevant material, especially when the relevant material sits away from the beginning or end of the prompt.³ Retrieval-augmented generation is a common pattern for this problem in the LLM literature. It retrieves selected external records, augments the prompt with those records and keeps retrieval, augmentation and generation as explicit pipeline stages for controlling what the model receives.⁴ Digital-forensics LLM work has begun to use the same control shape in narrower tasks. GenDFIR structures incident events as a knowledge base, retrieves relevant events for a prompt and has the model interpret that context for timeline analysis.⁵ This workflow implements retrieval as a bounded read package. The scripted runner retrieves the approved evidence subset, freezes it as the model input and records the package on the run ledger before the model call.

Forensic use adds another constraint. Errors and hallucinations can misdirect investigations, proprietary or cloud models can raise confidentiality problems, and court-facing use depends on source attribution, chain-of-custody, admissibility and validated tool behaviour.⁶ Each model call therefore remains a stage event. Each model step reads a declared projection of run state, writes a typed proposal back to the audit trail and leaves collection, parsing, detection, scoring and reviewer decisions with the workflow engine.

4. Experiment Design

The experiment compares two runs over the same evidence source. The reference run is a deterministic forensic workflow built from the ordinary forensic sequence of scope, collection, parsing, detector checks, findings, review and scoring. The comparison run keeps the same profiles, ledger schema, gates and scorer, but enables one LLM-based proposal step inside that sequence. The measurement asks what changes when one package is proposed by a model while evidence handling and scoring stay rule-based.

The planned proposal slots group scripted operations into reviewable workflow moves. A proposal slot may cover several scripted operations before it reaches a human review gate (profile proposal, retrieval planning, RAG retrieval, correlation, conflict checking, or finding proposal). At the gate, the slot returns one typed package to the next workflow stage. Gates are broader than individual functions. They align comparable run states over the same input, so the evaluation can measure what changes when one candidate-output gate is enabled with those controls fixed.

Comparison sketch for the scripted reference run and the same workflow with one LLM proposal slot enabled, with the same benchmark, ledger schema and scorer held across the gate sequence.

The diagram turns that comparison into a test harness. Both lanes run over the same evidence source. The upper lane is the scripted reference run. The lower lane enables one LLM proposal slot between shared gates and returns a typed package to the same next gate. The lower lane also keeps the evidence-access split visible. Context and policy define how evidence may be read, the evidence index exposes cited rows and hashes, and retrieval materializes a bounded read package before any proposal is written. The proposal slot can choose order, focus and prioritization inside those rules, but the output must return to the same package or findings-ledger shape.

Reading left to right, the shared gates are setup, scope, evidence, analysis, output and scoring. The orange dots are the comparison points where the run has to produce an approved package before the next stage can proceed. The control is narrow. Both lanes use the same inputs and gates, and only one LLM proposal slot changes.

5. Workflow Implementation

The implementation separates forensic execution from proposal generation. The workflow engine handles evidence access, collection, parsing, detector execution, scoring and artifact materialization. A scripted runner sits beside it. The runner reads the same contracts, chooses the stage order, checks cached stage outputs, assembles prompt packages and writes proposal events to the ledger.

A prompt package is a projection of run state, such as a selected profile, evidence index, evidence card, findings ledger, interpretation brief, or evaluation packet. The runner sends that package to the configured proposal-slot handler and records model calls, schema results, handoffs and failures as ledger events. The workflow engine keeps gate pauses and reviewer decisions. Profiles and schemas live together in the shared contract directory, so the engine and runner read the same contract before either writes state.

A CLI runner supplies the stage order. It chooses stages from the run profile, materializes the gate package for each stage and calls an LLM only when the configured stage is being tested as a proposal slot. The model receives a typed input package and returns a typed output package. The runner executes declared operations and advances the run. Initial smoke tests used Qwen2.5 Instruct served locally through Ollama.

Model calls are recorded as events with read sets, schemas and gate outcomes. The runner still owns tool execution, schema checks, gate pauses and event writing, so the workflow remains model-agnostic at the interface.

forensic_workflow/
|-- contracts/
|   `-- ...
|-- workflow_engine/
|   `-- ...
|-- proposal_steps/
|   |-- prompts/
|   |   |-- rank_profiles.md
|   |   |-- propose_collection_plan.md
|   |   |-- check_coverage.md
|   |   |-- assemble_evidence_packet.md
|   |   |-- propose_annotation_sidecar.md
|   |   |-- interpret_findings.md
|   |   `-- propose_review_action.md
|   `-- schemas/
|       `-- ...
|-- scripted_runner/
|   |-- materialize_package.py
|   |-- run_stage.py
|   |-- call_llm.py
|   |-- schema_check.py
|   |-- gate_pause.py
|   `-- event_writer.py
|-- run_ledger/
|   `-- ...
`-- evals/
    `-- ...

Implementation sketch separating contract-defined execution, scripted proposal-slot handlers, runner controls and run-ledger outputs.

The workflow can also generate a compact run packet beside the forensic artifacts. This is local vocabulary for a review package assembled from case documentation, provenance, tool-output metadata and audit-trail records. It joins run identity, evidence basis, model calls, workflow-state transitions, reviewer gates and reopening conditions, so a reviewer can inspect the path without re-running the whole pipeline.

The audit-stream page expands a run event and exports a model-call trace for review.

Across the evaluation design, the seven LLM proposal slots share the same interface shape. Each slot has a bounded read set, a typed output and a human gate. The semantic interpretation slot is the richest example because it turns findings into reviewable explanatory claims with cited support, challenge, limits and review status.

6. Semantic Interpretation

Semantic interpretation is local vocabulary for a bounded explanation proposal over completed findings. The workflow has produced findings, but those findings still need to become a reviewable account: the reviewer needs to see what the finding supports, which benign alternatives remain open and which next observation would separate competing hypotheses. Semantic interpretation produces that account from completed findings and their citations.

For this semantic step, the model receives interpretation_brief.v1, a compact projection built from findings, evidence cards, hypothesis context and public run checks. In contrast, it does not receive raw disk material, retrieval controls, collection scope, scenario-generation records, or evaluation records.

The interpretation step confines the model to that brief and asks for a proposal over existing findings. The model may organize the findings into a bounded hypothesis, attach citations, state benign alternatives and identify one observation that would separate competing explanations. It does not add evidence, change detector output, or decide the case claim.

The output is semantic_interpretation.v1. It contains a review hypothesis, cited supporting observations, benign alternatives, limits and one next discriminating observation. Interpretation becomes a typed operation over the audit trail. The reviewer sees the output as a cited proposal attached to the brief that produced it.

Semantic interpretation is also where evidence statements become explanatory claims. The run should not treat observations, model sentences, reviewer decisions and benchmark scores as the same kind of statement. Each claim carries provenance (actor, stage, read set and gate) and state (proposition, support, challenge and status). In that frame, knows(actor, proposition) is shorthand for what a declared actor may assert from a declared read set at a declared stage.⁷ Recent four-valued epistemic logic supplies a conceptual analogue for this prototype. Evidence can be absent, one-sided, or conflicting without becoming a final fact. The run records that state before review or scoring changes it.⁸

Semantic interpretation tests the proposal-slot interface where findings become an explanation. The comparison asks whether the LLM proposal makes support, conflicts and next observations easier to review while collection, detector output and scoring stay unchanged.

The findings page lets a reviewer inspect a cited finding and ask the model to check its evidence path before escalation.

The contract is small enough to test directly.

Contract element	Semantic interpretation step
Input package	interpretation_brief.v1, built from findings, evidence cards, hypothesis context and public run checks.
Excluded material	Raw disk material, retrieval controls, collection scope, scenario-generation records and evaluation records.
LLM operation	Draft a cited interpretation over existing findings.
Output package	semantic_interpretation.v1, containing a hypothesis, citations, alternatives, limits and one next observation.
Gate	Reviewer accepts, rejects, or asks for another proposal.
Replay	The same input package can be reused with another prompt or model without re-running earlier stages.

Semantic interpretation as one contract-defined LLM proposal slot.

The scripted reference run produces findings. The LLM receives one cached package from that run, writes one proposal package and returns control to the workflow.

Conclusion

This article has presented our initial design considerations, before moving towards implementation and experimental steps. The envisioned prototype treats automated anti-forensic detection as a measured comparison between a deterministic forensic workflow and an LLM-based proposal flow. The scripted reference run makes that comparison repeatable by producing stage outputs from a synthetic or real forensic image. An LLM proposal slot can then be enabled at one stage. It uses the package emitted by the previous gate and returns a typed package to the next one.

The evaluation stays small because the expensive evidence work sits outside the slot comparison. A cached stage output can be replayed against another prompt, model, or proposal slot without regenerating the disk image or rerunning the whole analysis pipeline. The remaining measurement is slot-level: it asks which proposal slot improves coordination, interpretation, or review, and which only adds cost, risk, or scoring error.

Footnotes

1. ISO/IEC 27037, NIST SP 800-86 and SWGDE minimum requirements for testing tools. ↩

2. NIST SP 800-86 and NIST Computer Forensics Tool Testing. ↩

3. Liu et al., 2024. ↩

4. Lewis et al., 2020 and Gao et al., 2024. ↩

5. Loumachi, Ghanem and Ferrag, 2025. ↩

6. Cherif et al., DFIR-Metric, 2025, Sharma et al., 2025 and Al-Khateeb et al., 2019. ↩

7. Halpern and Moses, 1990. ↩

8. Santos, 2020. ↩