Skip to content

Module 04 — Windows Artifacts

Type 6 · Reconstruct — reconstruct attacker activity on a Windows host from EVTX-ATTACK-SAMPLES logs with chainsaw and registry-hive parsing, surfacing the authentication and execution events that show what ran. (Secondary: Tool-Build — grow the hive-parsing step into a reusable registry parser.) Go to the hands-on lab →

Last reviewed: 2026-06

Digital Forensics & IR — Windows leaves a detailed record of everything that ran — if you know where to look.

Difficulty: Intermediate  ·  Estimated time: ~5–7 hrs (study + lab)  ·  Prerequisites: Foundations

In 60 seconds

Windows was built for accountability, so it records what ran across many sources at once: event logs (EVTX), the registry, prefetch, Shimcache, Amcache. chainsaw parses EVTX without Windows and applies Sigma rules to surface suspicious logons (4624/4625), process creations (4688), and Kerberos activity (4768/4769). The key move is cross-corroboration: artifacts back each other up, so an attacker who clears one source (Event ID 1102 records the clearing itself) usually leaves the trail in another.

Why this matters

Windows is the dominant enterprise endpoint, and it is extraordinarily artifact-rich. Every program that runs leaves traces across event logs, the registry, prefetch files, the shellbag, and the timeline. An attacker who compromises a Windows host is operating in a recording studio: they may wipe the most obvious logs, but they can rarely erase all traces across all artifact sources simultaneously. The forensic investigator who knows all the sources — and which ones survive each anti-forensics technique — has a decisive advantage. This module maps the terrain.

The fastest way to internalize what those traces actually look like is to read real ones. EVTX-ATTACK-SAMPLES — Samir Bousseaden's widely-used public corpus — is a library of genuine Windows event-log (.evtx) files captured while real attack techniques were executed, filed by MITRE ATT&CK ID. It is the de-facto reference set the detection-engineering community tests Sigma rules against, precisely because the events are authentic rather than hand-crafted. Open the credential-access or lateral-movement samples and you see the exact 4624/4688/4769 records this module describes, in the messy form they take on a compromised host — not a clean textbook example. The lab bundles a small slice of this corpus.

Objective

Parse Windows Security event logs with chainsaw to surface authentication and execution events; extract key forensic data from a registry hive with Python's python-registry; and explain which artifacts survive common anti-forensics techniques like log clearing and prefetch deletion.

The core idea

Windows is designed for accountability — it was built for enterprise environments that need audit trails, and that design decision benefits the forensic investigator far more than it inconveniences the attacker. The registry is a structured database, not a log file: it's always-on, always-consistent, and resistant to partial corruption. The event log system (EVTX) is a structured binary format with embedded checksums and forward-recovery from incomplete writes. Prefetch is a performance optimization that happens to record the first 8 seconds of a program's I/O — which is exactly what an investigator needs to prove execution. These weren't designed to help investigators, but they do.

The mental model

Treat a Windows host as a recording studio with many independent microphones. No single artifact is the case; the case is built so that knocking out one source doesn't knock out the investigation — execution shows up in prefetch and Shimcache and Amcache and event 4688, each with a different durability against tampering.

The most important Windows forensic principle is that artifacts cross-corroborate each other, and that an attacker who clears one source usually leaves the clearing event itself in another source. A wevtutil cl Security command to clear event logs creates Event ID 1102 (log cleared) in the Security log — you can't clear the log without recording that you cleared it. Wiping prefetch requires either deleting the files (which leaves filesystem artifacts about the deletion) or using a specialized tool (which itself leaves an execution trace). The investigator's job is to build a case that doesn't rest on any single artifact source, so that knocking out one source doesn't knock out the investigation.

The gotcha

Registry timestamps record only a key's last write time — not creation or access. That's still useful for placing activity in time, but reading it as a creation date is a classic error that produces a wrong timeline. Know what each artifact actually records before you anchor a finding to it.

Event logs (EVTX) are the most commonly examined Windows artifact. The Security log is the richest: Event IDs 4624/4625 (logon success/failure), 4688 (process creation — gold for execution analysis), 4768/4769 (Kerberos ticket activity), 4720–4726 (account management), and 1102 (log cleared). The System and Application logs add hardware, service, and application events. chainsaw is a Rust-powered tool that parses EVTX files directly (no Windows needed), applies Sigma rules to surface suspicious events, and supports custom field queries. It is the forensic analyst's first pass over a log archive before hunting manually.

The registry is a hierarchical key-value store that encodes almost everything about a Windows system's configuration and user activity. The forensically important hives are SYSTEM (boot configuration, device history, network interfaces), SOFTWARE (installed applications, run keys), SECURITY (policy, cached credentials), and per-user NTUSER.DAT (MRU lists, typed paths, shellbags, run keys, autorun persistence). Registry timestamps only record the last write time of a key — not creation or access — which limits timestamp analysis but is still useful for placing activity in time. python-registry reads raw hive files without needing a Windows OS, making it suitable for offline forensic analysis.

Persistence and execution artifacts deserve special attention because they answer the investigator's core question: "what ran, and how did it get there?" Persistence lives predominantly in run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run, scheduled tasks in SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache), services (SYSTEM\CurrentControlSet\Services), and startup folders. Execution evidence comes from prefetch (C:\Windows\Prefetch\MALWARE.EXE-XXXXXXXX.pf — proves the file ran, when, and how many times), the Shimcache (SYSTEM hive, AppCompatCache key — records executable metadata even if prefetch is disabled), and Amcache (C:\Windows\appcompat\Programs\Amcache.hve — SHA1 hash of the binary, proving the specific file that ran). These sources survive each other's deletion in different ways, which is why experienced investigators check all of them.

Go deeper: the execution-artifact trio

Three sources answer "what ran, when, how often?" with different survivability. Prefetch (C:\Windows\Prefetch\*.pf) proves a file ran, when, and the run count. Shimcache (SYSTEM hive, AppCompatCache) records executable metadata even if prefetch is disabled. Amcache (Amcache.hve) carries the SHA1 of the binary — proving the specific file that ran. An attacker who clears one rarely clears all three, which is exactly why you check each.

AI caveat

A model excels at explaining unfamiliar Event IDs ("what is 4769 failure code 0x12?") and drafting registry-parsing scripts from a key description — but it cannot read your EVTX or hive files, and it will invent specific event details. Draft and interpret with it; verify every finding against the raw event.

Learn (~4 hrs)

Event logs (~1.5 hrs) - chainsaw — GitHub README and usage guide — read "Hunt Mode" and the Sigma rule integration; this is the tool you'll use in the lab. - Windows Security Event Log Reference (Microsoft) — the canonical reference for Security event IDs. Focus on 4624, 4625, 4688, 4768, and 1102. - EVTX-ATTACK-SAMPLES (sbousseaden) — a curated repo of real attack-shaped EVTX files organized by ATT&CK technique; the lab bundles a small slice of these.

Registry forensics (~1.5 hrs) - python-registry — GitHub — the library's README and examples; understand the Registry, RegistryKey, and RegistryValue classes. - Windows Registry Forensics — Eric Zimmerman's tool docs — the "Registry Explorer / RECmd" section explains the forensically important keys; focus on NTUSER.DAT MRU lists and run keys. - SANS FOR508 Registry Cheat Sheet — one-page reference of the most forensically relevant keys; keep it open during the lab.

Execution artifacts (~1 hr) - Amcache and Shimcache — SANS — white paper on the two execution history artifacts that survive prefetch deletion; understand what each records (file hash vs. metadata).

Key concepts

  • EVTX is a structured binary format; chainsaw parses it without Windows and applies Sigma rules.
  • Key Security event IDs: 4624 (logon), 4625 (failed logon), 4688 (process creation), 4768/4769 (Kerberos), 1102 (log cleared).
  • Registry timestamps record last write time only; forensically important hives include NTUSER.DAT, SYSTEM, SOFTWARE.
  • Persistence: run keys, scheduled tasks, services, startup folders.
  • Execution artifacts: prefetch (ran, when, how many times), Shimcache (metadata even without prefetch), Amcache (SHA1 of binary).
  • Artifacts cross-corroborate: clearing one source usually leaves evidence in another.
  • Anti-forensics moves (log clearing, prefetch deletion) are themselves recorded somewhere else.
  • EVTX-ATTACK-SAMPLES is the public corpus of real, ATT&CK-tagged Windows event logs to practice against — authentic events, not hand-crafted ones.

AI acceleration

AI excels at explaining unfamiliar Event IDs ("what does Event 4769 with failure code 0x12 mean?") and drafting registry parsing scripts from a description of the key structure. Where it falls short: it cannot read your EVTX or hive files, and it will invent specific event details. Use it to draft the parsing logic and to interpret output you've already collected — then verify every finding against the raw event data.

Check yourself

  • An attacker ran wevtutil cl Security to wipe the Security log. Why is that not the dead end they hoped, and what survives it?
  • Prefetch was disabled on the host. Which two artifacts still let you prove a specific binary executed, and what does each contribute?
  • A registry key's timestamp shows last night. Why is "the key was created last night" an unsafe conclusion?

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).