EvilTrace

EvilTrace is an autonomous DFIR operator that runs forensic tools, validates evidence, and produces traceable incident reports with confidence-labeled findings.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for EvilTrace

Inspiration

Most AI security demos sound confident even when the evidence is weak. In real DFIR work, that is dangerous. EvilTrace was built from the opposite idea: an incident-response agent should inspect real forensic artifacts, preserve an evidence trail, separate confirmed facts from hypotheses, and produce a report another analyst can audit.

The project was inspired by FIND EVIL-style forensic workflows using SANS SIFT, Protocol SIFT, Volatility, recovered Windows event logs, and structured incident reporting. The goal was not to build a generic cybersecurity chatbot. The goal was to build a defensive DFIR operator that can help an analyst move faster without inventing unsupported compromise claims.

What it does

EvilTrace is an evidence-backed DFIR triage agent prototype. It reads saved forensic-tool outputs, builds a case ledger, assigns confidence labels, and generates both human-readable and machine-readable incident reports.

For the packaged ROCBA case, EvilTrace analyzed a Windows memory image and memory-recovered validation artifacts. The strongest lead was RDP/TermService activity around 2020-11-16 02:31-02:36 UTC.

The system produced:

  • a source evidence ledger with hashes and artifact IDs;
  • saved Volatility output review;
  • recovered EVTX validation summaries;
  • a deterministic evidence-engine Markdown report;
  • a machine-readable JSON findings file;
  • a polished final incident report with timeline, findings, limitations, and next validation steps.

The key result is conservative and evidence-led:

  • Confirmed: RDP/TermService listener/activity around the focus window.
  • Confirmed: TerminalServices EVTX corroboration for RDP-Tcp activity.
  • Confirmed: MRC.exe process/file recovery near the same window.
  • Hypothesis: malfind memory-code candidates.
  • Not confirmed: malicious authenticated RDP compromise.

That last point matters. EvilTrace does not inflate RDP activity into attacker attribution without Security/session log proof.

How we built it

The workflow was built around one forensic case first instead of trying to ingest every available dataset.

  1. The background case material was extracted and summarized.
  2. Raw evidence was kept separate from derived artifacts.
  3. SHA256 hashes and exact file sizes were recorded in docs/evidence-ledger.md.
  4. The memory image was extracted and analyzed with Volatility 3.
  5. First-pass process, command-line, network, service, handle, malfind, psxview, and user-context artifacts were saved.
  6. The strongest lead — RDP/TermService activity — was validated with scoped follow-up artifacts and recovered EVTX parsing.
  7. A deterministic evidence engine generated Markdown and JSON findings from the saved outputs.
  8. A final report was produced with confidence labels and evidence references.

The agent/reporting logic is designed around guardrails:

  • raw evidence stays isolated;
  • derived artifacts are ledgered;
  • every claim maps to evidence references;
  • findings are labeled Confirmed, Likely, Hypothesis, or Rejected;
  • unsupported claims are explicitly limited instead of silently promoted.

Challenges we ran into

The biggest challenge was avoiding overclaiming. Memory forensics can produce strong leads, but not every lead proves compromise. For example, RDP/3389 network rows and TerminalServices records confirmed activity, but recovered memory-backed Security.evtx did not contain exact-window authentication rows such as 4624, 4625, or 4776. EvilTrace had to preserve that distinction.

Another challenge was working with large forensic artifacts safely. The memory archive expanded into a much larger raw image, so the workflow needed clear separation between raw evidence, extracted artifacts, notes, generated reports, and submission-safe files.

Parsing tool output was also handled carefully. Volatility outputs can include warnings, progress lines, and noisy rows, so the evidence engine avoids blind parsing and keeps uncertain signals like malfind candidates as hypotheses unless corroborated.

Accomplishments that we're proud of

The strongest accomplishment is that EvilTrace produced a defensible incident report instead of a flashy but unsupported story.

It confirmed what the evidence supported:

  • 124 RDP/3389 network rows;
  • 4 established RDP rows;
  • 281 exact-window TerminalServices RDP-Tcp records;
  • confirmed MRC.exe process/file recovery;
  • machine-readable and human-readable reports.

At the same time, it refused to claim what was not proven. That is the behavior we want from AI in defensive incident response.

What we learned

We learned that autonomy in DFIR is only useful when it is paired with evidence discipline. An agent should not just summarize outputs. It should preserve provenance, show counts, cite files, classify uncertainty, and make it easy for another analyst to reproduce or challenge the conclusion.

We also learned that conservative reporting can be a strength. Saying “confirmed RDP activity, but not confirmed malicious authenticated RDP compromise” is more useful than making a dramatic but unsupported claim.

What's next for EvilTrace

The next step is to connect EvilTrace to a fuller disk/event-log validation pipeline. Complete Security.evtx, TerminalServices logs, Prefetch, Amcache, Shimcache, SRUM, and user profile artifacts would allow stronger session attribution.

Future improvements include:

  • MCP/tool integration for controlled forensic command execution;
  • a safer allowlisted DFIR command runner;
  • automatic evidence-ledger updates;
  • richer timeline correlation;
  • selected VAD dumping and YARA/strings validation;
  • a web or notebook interface for analyst review;
  • support for additional forensic cases beyond ROCBA.

EvilTrace is built for controlled autonomy: move faster, but never outrun the evidence.


## Built with

```text
Python 3.11, Volatility 3, python-evtx, py7zr, JSON, Markdown, SANS SIFT-style DFIR workflow, Windows Event Logs, memory forensics, evidence ledger, WSL/Linux, Git, deterministic report generation

Built With

  • deterministic
  • evidence-ledger
  • git
  • json
  • markdown
  • memory-forensics
  • py7zr
  • python-3.11
  • python-evtx
  • report
  • sans-sift-style-dfir-workflow
  • volatility-3
  • windows-event-logs
  • wsl/linux
Share this project:

Updates