· ~3 min read
A Windows 11 forensics case, and an AI agent for triage
A course forensics case on an encrypted Windows 11 VM: handling the evidence, mapping the findings to MITRE ATT&CK, and what an LLM agent can and cannot do for triage.
Goal
The case for the Digital Forensics course of my MSc was a Windows 11 Enterprise virtual machine and a memory capture, on which an intrusion had been simulated for the course. The task was to reach the evidence without damaging it, reconstruct a timeline, map the findings to MITRE ATT&CK, and recommend remediation. Alongside the manual analysis, I built an AI agent to see how much of the correlation work a language model can take off an analyst.
This post stays at a high level: the method, the tooling and the lessons, not a replay of the intrusion.
Method
- Encrypted evidence. The disk was protected by BitLocker with its key sealed in a virtual TPM, so access had to go through the VM's own environment before any offline analysis.
- Read-only analysis. The disk was attached on a separate Linux analysis machine and mounted read-only, and the relevant artefacts were copied out for analysis.
- Seven sources, one timeline. Memory, Windows event logs, registry hives, Prefetch, PowerShell history, browser history and network indicators were normalised into a single JSON timeline, so events from different sources could be lined up by time.
- ATT&CK mapping. Each finding was tied to a technique ID and to the artefact that proves it. The point of the mapping is the second column: a technique without its evidence is an opinion.
The AI triage agent
| Part | Role |
|---|---|
| FastAPI backend | Receives the timeline JSON, validates it, and exposes endpoints to upload, classify, analyse and report |
| Gemini Flash model (google-genai SDK) | Correlates the events, suggests ATT&CK IDs, severity and indicators, in structured output |
| Streamlit dashboard | Risk gauge, filtering by attack stage, and the generated hardening suggestions |
The model's large context window meant the whole timeline (105 shell commands and 377 collected files) fit in one request, so it could correlate across sources without the data being cut.
Recommendations
The hardening advice was the standard set for this class of incident: remove every persistence mechanism found and verify it is gone, protect credentials in memory (LSA protection and Credential Guard), require Network Level Authentication and keep RDP behind a VPN or jump host, restrict PowerShell through application control, and keep script block and command-line process logging enabled so the next investigation has evidence to work with.
What I learned
- Decrypting in place changes the evidence. Removing the encryption from the volume itself writes to it. Next time I would image first, record a SHA-256 of the image, and unlock a working copy with the recovery key, leaving the original untouched. The block device should also be attached read-only, not just the filesystem.
- Chain of custody means hash values on paper. Saying the evidence was handled carefully is not the same as listing the hashes of the image and of every extracted artefact, so that anyone can re-check them.
- The LLM is a triage assistant, not a witness. Its risk score is an opinion; every claim it makes has to trace back to an artefact. It was fast at grouping events and suggesting technique IDs, and it still needed checking.
- Sending evidence to a cloud API is a decision in itself. Forensic data is often confidential. That is why my follow-up project ran the model locally.
A course forensics case for the MSc in Cybersecurity & Data Science at the University of Piraeus; the intrusion was simulated in a lab VM.
Want the configs or code from this lab, or have a question? Email me at kostaspapas1023@gmail.com