Getting Started with Windows Forensics

Windows forensics is the practice of reconstructing what happened on a Windows system from the traces it leaves behind. Ransomware, insider data theft, a compromised admin account or a single suspicious logon: in every case, the operating system has recorded far more than the attacker or the user realises. This guide is the on-ramp to the whole site. It covers the investigative mindset, what to collect and in which order, the major evidence areas (each with a link to its dedicated guide), the free toolset professionals use, and a practical plan for the first 48 hours of a case.

What Windows forensics is

At its core, forensics is disciplined reconstruction. You collect evidence, preserve its integrity, analyse it, and present conclusions that another examiner could reproduce from the same data. Windows is a rich target because it records program execution, file and folder access, USB insertions, network connections, logons and persistence mechanisms across dozens of registry hives, event logs, databases and file-system structures. Most of these records exist for performance or compatibility reasons, not for security, which is exactly why attackers overlook them.

DFIR (Digital Forensics and Incident Response) blends two goals that sometimes pull in opposite directions. Incident response wants answers fast so the business can contain and recover. Forensics wants evidence handled carefully so conclusions hold up. A good practitioner does both: move quickly, but never in a way that destroys evidence or makes a finding impossible to defend later.

The DFIR mindset

A few habits separate solid investigations from guesswork.

Work from hypotheses

Start from the question you have been asked ("did the attacker reach the finance server?") and turn it into testable hypotheses ("an interactive logon from the compromised workstation to FIN-SRV01 happened between 1 and 3 June"). Then look for artifacts that would confirm or refute each one. Deciding what happened and hunting for confirmation is how innocent explanations get missed.

Correlate, never trust a single artifact

One data point is a lead. Three independent artifacts pointing in the same direction is evidence. A Prefetch entry, an Amcache SHA-1 and a Security event 4688 for the same binary tell a far stronger story than any one of them. Independence matters: two parsers reading the same registry value are one source, not two.

Respect the order of volatility

Capture the most fragile evidence first. The order of volatility, formalised in RFC 3227, runs roughly:

1. CPU registers and cache
2. Memory: running processes, network connections, the kernel's view of the system
3. Temporary state: network routing, ARP cache, logged-on sessions
4. Disk: file system, registry, event logs
5. Remote logs and monitoring data (SIEM, EDR, firewall)
6. Backups and archival media

This is why a memory capture comes before any shutdown. A live RAM image can reveal injected code, decrypted payloads and active network connections that never touched the disk.

Document everything

Record hashes, timestamps, tool versions, exact commands and who handled what. Maintain a chain of custody for every piece of evidence. Your notes are part of the evidence: if you cannot explain how you reached a conclusion, it will not survive a challenge.

Think in UTC

Windows stores most timestamps as FILETIME values in UTC, but some artifacts, tools and log exports use local time. Confirm the system time zone from the SYSTEM hive (ControlSet00x\Control\TimeZoneInformation), normalise to UTC during analysis, and state the time zone in your report. See UTC and local time for the traps.

What to collect

You rarely have time to take everything, and you rarely need to. Decide based on the questions and the legal context.

A triage collection grabs the high-value files (registry hives, event logs, $MFT, $UsnJrnl, Prefetch, Amcache, SRUM, browser databases, user folders' LNK and Jump Lists) in minutes, and it also pulls locked files through raw NTFS access. For full images, attach the source through a write blocker, produce an E01 or raw image, and hash it straight away.

# Verify an image hash against the acquisition log
Get-FileHash -Algorithm SHA256 .\evidence.E01

# KAPE triage of a live host into a VHDX container
.\kape.exe --tsource C: --tdest D:\triage\HOST01 --target !SANS_Triage --vhdx HOST01 --vss

The --vss switch also collects from Volume Shadow Copies, which often hold older versions of hives and logs that the attacker cleaned. For the details of targets, modules, remote collection and preserving collections, read acquisition and triage with KAPE and Velociraptor.

The major evidence areas

Every artifact on this site belongs to one or more of these areas. Each has its own guide.

Registry

The registry is a set of hive files (SYSTEM, SOFTWARE, SAM, SECURITY, NTUSER.DAT, UsrClass.dat) that record configuration, user activity and execution. Key last write times help date changes. Start with Windows registry forensics.

Event logs

.evtx files under C:\Windows\System32\winevt\Logs record logons, service installs, process creation (if audited), PowerShell and much more. Knowing the key event IDs is essential. See Windows event log forensics.

Evidence of execution

Did the program actually run, or did it merely exist on disk? Prefetch, Amcache, ShimCache, BAM, UserAssist, SRUM and others answer with very different levels of certainty. The evidence of execution guide compares them side by side.

NTFS and the file system

The Master File Table, the USN journal and $LogFile record file creation, renames and deletions, often long after the file is gone. Read NTFS forensics: $MFT, USN and $LogFile.

User activity

ShellBags, LNK files, Jump Lists and MRU keys show which folders and files a user opened, including on removable and network drives. See user activity: ShellBags, LNK and Jump Lists.

Persistence

Run keys, services, scheduled tasks and WMI subscriptions are how an attacker survives a reboot. Hunting Windows persistence walks through each mechanism and how to spot the malicious entry among hundreds of legitimate ones.

Lateral movement

RDP, PsExec, WMI and WinRM leave traces on both the source and the destination host. Lateral movement forensics maps which artifacts appear where.

USB and external devices

The registry, setupapi.dev.log and event logs record which devices were connected, when, and by whom. See USB device forensics.

Memory

RAM shows what was running at acquisition time: processes, injected code, network connections, command lines. Windows memory forensics with Volatility covers acquisition and the core plugins.

Anti-forensics

Log clearing, timestomping, secure deletion and disabled logging leave their own traces. Detecting Windows anti-forensics explains what to look for.

Timelines

A super timeline puts all of the above in one chronological view. Building a super timeline with Plaso shows how to build and filter one.

The free toolset

You can run a complete investigation without a commercial licence.

# Download or update every EZ Tool (.NET 6+ builds)
.\Get-ZimmermanTools.ps1 -Dest C:\Tools\EZ -NetVersion 6

# Parse a KAPE collection with the EZ Tools module set
.\kape.exe --msource D:\triage\HOST01 --mdest D:\parsed\HOST01 --module !EZParser

# First look at a memory image with Volatility 3
vol -f HOST01.raw windows.info
vol -f HOST01.raw windows.pstree
vol -f HOST01.raw windows.netscan
vol -f HOST01.raw windows.cmdline

The browser parsers are ideal when you have one file and one question, such as a .pf from an email attachment. For whole-host processing, the command-line tools remain the reference, and the results are easier to reproduce.

A first-48-hours workflow

Hours 0 to 4: scope and preserve

1. Agree on the questions, the scope and the legal constraints. Start the case notes now.
2. Identify affected hosts from alerts, EDR and SIEM data. Ask the network team to preserve firewall, proxy, VPN and DNS logs before they roll over.
3. For each running, possibly compromised host: capture memory first, then run a triage collection. Contain (network isolation through the EDR is ideal) rather than power off.
4. Hash everything you collect and log it in the chain of custody.

Hours 4 to 12: triage and anchor

1. Parse the collections with KAPE modules or EZ Tools.
2. Look for an anchor: one confirmed malicious event with a timestamp (an alert, a suspicious logon 4624 type 10, a new service 7045, a known-bad binary in Amcache).
3. Check the usual suspects: execution artifacts, persistence locations, RDP and remote logons, PowerShell logs.

Hours 12 to 36: expand from the anchor

1. Build a timeline around the anchor, a few hours either side, then widen.
2. Pivot on every new indicator: user accounts, source IPs, file names, hashes, service names. Sweep other hosts for them with Velociraptor hunts.
3. Track findings in a simple table: time (UTC), host, artifact, event, source file, confidence.

Hours 36 to 48: consolidate

1. Test each hypothesis explicitly: confirmed, refuted or unresolved, and why.
2. Decide what needs a full disk image or deeper analysis.
3. Write an interim report: what is known, what is suspected, what is still unknown, and the next steps.

Pitfalls

• Powering off first. Pulling the plug before capturing memory destroys volatile evidence and can flush or lose unsaved registry data.
• Running tools from the suspect disk. Run collectors from external media or a network share, and write output elsewhere.
• Confusing presence with execution. A ShimCache or Amcache entry proves a file was seen, not necessarily that it ran.
• Mixing time zones. A one- or two-hour offset between sources silently reorders events.
• Forgetting shadow copies and memory. Deleted logs and older hives often survive in VSS; recent ShimCache entries live only in RAM until shutdown.
• Letting logs expire. Event logs roll over by size, and cloud and network logs by retention. Preserve them on day one.
• Single-artifact conclusions. If only one source supports a finding, say so in the report.

Checklist to take away

• Questions and scope written down, case notes started
• Remote logs preservation requested
• Memory captured on live hosts before any shutdown
• Triage collection (with VSS) on every host in scope, hashed and logged
• Collections parsed, system time zone confirmed, analysis in UTC
• At least one anchor event identified and timelined
• Every conclusion backed by two or more independent artifacts
• Interim report with confirmed, refuted and open hypotheses

Keep the Windows artifacts cheat sheet at hand: it lists every artifact on this site with its location, what it proves and how to collect it. To practise, image a test VM, run a benign program, and try to prove when it executed using the next guide on evidence of execution.