Windows on-disk forensics #

NTFS metadata

NTFS stores not just files but a parallel set of metadata files prefixed with $ that live in the volume root (hidden). An image gives you these for free and they survive deletion of individual user files for a surprisingly long time. In practice you'll pull the triage set, parse $MFT first to answer "did this file exist?", then $UsnJrnl / $LogFile for "what happened to it?", then $I30 to recover filenames out of directory listings whose MFT entries have been reused.

Execution evidence (what ran, when, by whom)

"Execution evidence" is the body of Windows features that happen to leave timestamped proof a program ran. None of them was designed as a forensic log - they exist for performance (Prefetch), compatibility (Amcache, ShimCache), battery usage reporting (SRUM/BAM), UI personalization (UserAssist), or activity sync (ActivitiesCache). Each has different fidelity, different enablement defaults, and different retention. Rank them, corroborate across several, and account for where each one is wrong before you call something executed.

Shell & user activity

AI agent artifacts

AI coding agents and assistants run commands, read files and edit code as the user, so their transcripts are often the best execution log on the host - the prompt, every command, and the output the agent saw. The same files collect any secrets the agent read. Paths below are for Windows; ~ = %USERPROFILE%.

What to look for in the transcripts:

• Commands it ran - timeline every shell tool call next to EDR process events.
• Secrets it read - .env, cloud credential files, SSH keys, kube configs, browser profiles. What was read is in the transcript, so the transcript is now a copy of the secret.
• Where data went - web fetches, curl, git push to unfamiliar remotes, new MCP servers pointing at external URLs.
• Safety switches off - --dangerously-skip-permissions, --yolo, --trust-all-tools, broad allow rules, auto-approve. Check the settings file's mtime against the incident window.
• Instructions the user didn't write - prompt injection arrives in tool output (a web page, issue, README or MCP response). Read the tool results just before an odd action.
• Persistence - a planted CLAUDE.md, AGENTS.md, GEMINI.md, .cursor/rules, hook or MCP server re-runs the attacker's instructions every session.
• Agents driven by malware - the August 2025 Nx "s1ngularity" npm compromise ran claude, gemini and q with permission checks off to hunt for secrets. The parent is a package script, not a terminal, and there's no matching user prompt. Record agent and extension versions too: a poisoned Amazon Q VS Code release (1.84.0, July 2025) shipped a wipe prompt.

Inventory (then copy; take SQLite files with their -wal / -shm files, or close the app first - recent rows often live only in the WAL. Check that your KAPE / Velociraptor / UAC targets actually cover these folders):

$targets = '.claude','.claude.json','.codex','.gemini','.copilot','.continue','.cursor','.codeium','.kiro','.aws\amazonq','.ollama','.lmstudio',
  'AppData\Roaming\Claude','AppData\Roaming\Code\User','AppData\Roaming\Code\logs','AppData\Roaming\Cursor\User','AppData\Roaming\Cursor\logs',
  'AppData\Roaming\Windsurf\User','AppData\Roaming\Windsurf\logs','AppData\Local\Ollama','AppData\Local\Temp\qlog'
Get-ChildItem C:\Users -Directory -Force | ForEach-Object {
  foreach ($t in $targets) {
    $p = Join-Path $_.FullName $t
    if (Test-Path -LiteralPath $p) { Get-Item -LiteralPath $p -Force | Select-Object FullName, LastWriteTimeUtc }
  }
}
Get-ChildItem C:\ -Recurse -Force -Filter .aider.chat.history.md -ErrorAction SilentlyContinue | Select-Object FullName, LastWriteTimeUtc

Registry hives & where they live

Registry timestamps 101: every key has a LastWrite timestamp (FILETIME UTC, 100-ns precision) = last time that key or any of its values was modified. Values do not have their own timestamps - if you need per-value time, you must infer from LastWrite or from an external log. Hive files on disk have their own $SI MACB (first create, last reg write back to disk). Transaction logs (.LOG1, .LOG2) hold recent changes not yet written into the hive - always parse the main hive with its logs or you'll miss recent writes.

Collect the logs with the hive: every hive has .LOG1 / .LOG2 transaction logs beside it (e.g. SYSTEM.LOG1) holding recent writes not yet flushed - parse hive + logs together. C:\Windows\System32\config\RegBack\ held automatic backups until Windows 10 1803; since then the files are still there but 0 KB unless EnablePeriodicBackup=1 was set under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager. Older copies of hives may also sit in Volume Shadow Copies.

Event logs - high-value IDs

EVTX timestamps: every record has System/TimeCreated/@SystemTime in ISO-8601 UTC (100-ns FILETIME precision in the binary, serialized as ISO text in XML). The EventRecordID is a monotonically-increasing serial you should pair with the timestamp when sequencing events across a cleared/rotated log. Logs rotate when the file hits the max size set in the channel properties, default 20 MB for Security on Win10+. Record log size + oldest timestamp per channel at collection; a 20 MB Security log with only 2 days of events on a busy DC may mean the real evidence has already rolled.

Logon types (4624)

Sysmon event IDs

Sysmon (Sysinternals System Monitor) is a driver and service that writes detailed process, file, registry, network and WMI activity to Microsoft-Windows-Sysmon/Operational (%SystemRoot%\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx). It only exists if the client installed it, and it only logs what its XML config includes - with no config it records little beyond process creation, so check the config (sysmon -c) before you read an absence as "didn't happen". Every event carries UtcTime (when the activity happened, UTC) as well as the record's TimeCreated.

Persistence - the long tail

Windows exposes dozens of "ASEPs" (Autostart Extensibility Points): mechanisms Windows checks at boot, logon, or specific process start that an attacker can hijack to re-run their code. The sophistication curve runs from Run keys (any user, any malware, instantly spotted) up through signed-code validation hijacks (nation-state tier, hard to see without integrity scanning). Your job is to enumerate every ASEP, then compare each entry's binary and signer against what should be there. Sysinternals Autoruns and PersistenceSniper (Federico Lagrasta) are the standard sweeps; KAPE's RegistryHives + ASEP module + SharpUp cover the collected-image case; on live hosts at scale, Velociraptor's Windows.Sys.StartupItems and Windows.Persistence.PermanentWMIEvents do the same sweep.

Classic autoruns (loud, easy, still common)

• Run / RunOnce keys - The simplest autostart. Any value under HKLM\Software\Microsoft\Windows\CurrentVersion\Run (system-wide, requires admin) or HKCU\…\Run (per-user, no privs needed) is launched by Explorer at logon; the data is the command line. RunOnce is deleted after it executes once; RunOnceEx processes its sections in order, synchronously. Also check the WOW6432Node variants on 64-bit systems. Trivial for commodity malware to drop - infostealers (Lumma, RedLine) love it. Hunt: every unknown binary; verify Authenticode signatures.
• Startup folder - Any .lnk, .exe, or script dropped in %AppData%\Microsoft\Windows\Start Menu\Programs\Startup (per-user) or %ProgramData%\…\Startup (all-users) is executed at user logon. Often overlooked because it's "not registry." Parse LNK targets with LECmd.
• Scheduled tasks - The Task Scheduler stores each task as an XML in C:\Windows\System32\Tasks\ (mirror in registry under Software\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree). Tasks can trigger on boot, logon, idle, event ID, or interval, and run as SYSTEM / NETWORK SERVICE / any user whose creds the task was created with. Attackers like them for durability (survive reboot) and masquerade (name a task MicrosoftEdgeUpdate). Watch for tasks with no author, hidden flag, UNC-path actions, or BASE64-encoded PowerShell. Audit via schtasks /query /fo list /v, Get-ScheduledTask, EID 4698 (created), 4702 (updated), 106/140 in Microsoft-Windows-TaskScheduler/Operational.
• Services - Each entry under HKLM\SYSTEM\CurrentControlSet\Services\<svc> has ImagePath (exe), Start (0=boot driver, 1=system, 2=auto, 3=manual, 4=disabled), Type (kernel vs user), and optionally ServiceDll (for shared-process svchost services, under Parameters). Attackers either install a new service (classic Impacket/PsExec: random 4-letter service name, random 8-char binary, Type=0x10, Start=3) or hijack an existing one (overwrite ServiceDll of an unused service). Event IDs 7045 (install) and 4697 are your tells. Compare live service list to a known-good baseline.

Logon / UI-shell hijacks (DLL-level, higher stealth)

• Winlogon Shell / Userinit - HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell defaults to explorer.exe; appending another binary (comma-separated) runs that too at logon. Userinit defaults to userinit.exe, and is called by Winlogon before Shell - same pattern. GinaDLL is legacy (pre-Vista) but still occasionally seen on old images.
• AppInit DLLs - HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs. Any DLL listed here is loaded into every process that links user32.dll (nearly all GUI processes). Must be enabled via LoadAppInit_DLLs=1 and (post-Vista) signed. Ignored entirely when Secure Boot is on (Windows 8+), so it matters mainly on legacy-BIOS or Secure-Boot-off hosts.
• AppCertDLLs - HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCertDlls. Loaded into any process that calls CreateProcess*. Broader reach than AppInit; even sneakier because it's not in the usual "Autoruns" chase list.
• LSA Security / Notification Packages / Authentication Packages - Values under HKLM\SYSTEM\CurrentControlSet\Control\Lsa (Security Packages, Notification Packages, Authentication Packages). The LSA loads these DLLs in the LSASS process at boot. Perfect for credential harvesting (classic Mimikatz "SSP" trick registering mimilib.dll). An unknown SSP is a very high-signal detection.
• Netsh helper DLLs - Under HKLM\SOFTWARE\Microsoft\Netsh. Loaded whenever netsh.exe runs, which happens frequently (scripts, GPOs, update processes). Attackers register a malicious helper so their code runs whenever a netsh is spawned.
• Explorer shell extensions / ShellIconOverlayIdentifiers / context-menu handlers - DLLs registered under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers and various COM-handler keys get loaded into Explorer at logon. Rare but used by advanced actors to live inside a trusted process.

Image hijacks (make a legitimate binary load your code)

• Image File Execution Options (IFEO) debugger hijack - HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<target.exe>\Debugger. Set to a path and Windows will launch that instead of the target, passing the target's command line as an argument. Originally a legit debugging feature. Classic abuse: hijack sethc.exe (sticky keys) with cmd.exe for an unauth SYSTEM shell at the lock screen; hijack a scheduled binary your victim's AV calls daily. Also abused via GlobalFlag=0x200 under this key, which turns on SilentProcessExit monitoring (configured under its own key - see below).
• SilentProcessExit - HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\<target.exe> with ReportingMode (0x1 = launch MonitorProcess, 0x2 = write a dump, 0x4 = notify), MonitorProcess=<attacker.exe> and DumpType=2 (full memory), plus GlobalFlag=0x200 under the target's IFEO key. When the target is terminated, Windows launches the monitor and / or writes the dump (default folder %TEMP%\Silent Process Exit, or LocalDumpFolder) and logs it in the Application log with source Process Exit Monitor. Classic use: set target=lsass.exe, have the monitor collect the dump, SYSTEM-level credential harvesting with no third-party driver. Often seen in post-exploitation playbooks.
• COM hijacking - Every COM class is identified by a GUID; the implementing DLL is registered under HKLM\Software\Classes\CLSID\{GUID}\InprocServer32 (system) or HKCU\Software\Classes\CLSID\{GUID}\InprocServer32 (per-user, takes precedence over HKLM for that user). Attackers point the per-user key at a malicious DLL; whenever any process in that user's context instantiates that CLSID, the malicious DLL loads. TreatAs adds another indirection - class A is "treated as" class B - letting the attacker intercept otherwise-protected system CLSIDs. Scheduled tasks that invoke COM, Explorer, Office - all are triggers. Use OleViewDotNet, or Autoruns to enumerate.
• DLL search-order hijacking / sideloading / phantom DLL - Windows looks for a DLL in a specific search order: the loading .exe's directory first, then System32, PATH, etc. Drop a malicious DLL named like a dependency next to a signed binary (sideloading), or in a dir earlier in PATH, and the signed binary loads your code. Phantom DLL is when the binary tries to load a DLL that doesn't normally exist on disk - the attacker provides it. Lots of threat actors rely on this (e.g., signed vendor utilities and outdated Microsoft binaries shipped alongside a malicious DLL). Procmon on the CreateFile Not Found operations is the classic hunt.
• Print Processors / Port Monitors - DLLs registered under HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\…\Print Processors and …\Monitors are loaded by the Print Spooler (spoolsv.exe, runs as SYSTEM). This is the PrintNightmare lineage (CVE-2021-34527) and seen in the wild with Winnti's PipeMon and Gelsemium (MITRE T1547.012) as stealthy SYSTEM persistence.
• AppPaths - HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\<name.exe> maps a short name to a full path; start name or ShellExecute name dereferences through here. Overwrite an entry to redirect a common invocation.

Fileless / event-driven (hardest to see)

• WMI event subscriptions - Three WMI classes form the trigger: __EventFilter (a WQL query that fires on an event - a timer, a logon, a process start), __EventConsumer (what to do: CommandLineEventConsumer runs a cmd, ActiveScriptEventConsumer runs a script, LogFileEventConsumer writes to a file), and __FilterToConsumerBinding (wires them together). All stored in C:\Windows\System32\wbem\Repository\OBJECTS.DATA. No file in Run, no scheduled task, no service - the trigger lives inside WMI. Classic APT tradecraft (APT29, Turla, FIN7). Hunt via Get-WmiObject -Namespace root\subscription -Class __EventFilter/__EventConsumer/__FilterToConsumerBinding, EID 5861 (consumer-to-filter binding activity), Autoruns -WMI, WMI-Monitor, PyWMIPersistenceFinder.
• Office test persistence - HKCU\Software\Microsoft\Office test\Special\Perf - any DLL path under this undocumented key is loaded into every Office process (Word, Excel, Outlook) on launch. No prompt, no macro, no document. Pure registry trigger. If a user opens Outlook once a day, the DLL runs once a day. Patched by Microsoft's attention eventually, but still works on many fleets.
• SIP / Trust Provider hijacking - Windows validates signed binaries by looking up a "Subject Interface Package" DLL (one per signature format: PE, Cabinet, MSI, Catalog). Entries live under HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg\<OID> and …\CryptSIPDllVerifyIndirectData\<OID>, plus Trust Provider entries under …\Providers\Trust\FinalPolicy. Replace a SIP DLL with a wrapper that always returns "signature valid" and every signed-code check on the system (incl. sigcheck, Defender signature verifications) lies to you. Full write-up by Matt Graeber ("Subverting Trust in Windows"). Advanced-actor persistence that doubles as defense evasion.
• Boot execution (BootExecute) - HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute is a REG_MULTI_SZ of native-mode programs run during boot before Win32 subsystem starts (default: autocheck autochk *). Prepending a malicious native-mode binary gives earliest-possible-execution persistence. Rare but used.
• BITS jobs - Background Intelligent Transfer Service (bitsadmin.exe / Start-BitsTransfer) can schedule a download that executes a command on completion (SetNotifyCmdLine). The job can be set to retry indefinitely across reboots. Jobs live in %ALLUSERSPROFILE%\Microsoft\Network\Downloader\qmgr*.dat or (newer) qmgr.db. Hunt: bitsadmin /list /allusers /verbose, BitsParser (FireEye), Microsoft-Windows-Bits-Client/Operational EID 59/60.

User-level / GPO / less-common but seen

• Group Policy preferences (GPP) - SYSVOL-stored XML containing scheduled tasks, startup scripts, services, logon scripts. If an attacker has write access to \\<dc>\SYSVOL, they can push persistence to every joined machine. Watch for recent writes to Policies\{GUID}\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml and friends.
• Logon / startup scripts - HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\Scripts (and …\Group Policy\State\…\Scripts), local Group Policy script references under %SystemRoot%\System32\GroupPolicy\{User,Machine}\Scripts\{Startup,Logon,Shutdown,Logoff}.
• Explorer DelegateExecute / Protocol handlers / URL handlers - Registering a protocol handler (HKCR\<scheme>\shell\open\command) runs your binary when a user clicks a scheme://… URL. Also hijacked for drive-by execution.
• Screensaver - HKCU\Control Panel\Desktop\SCRNSAVE.EXE - the .scr is just a renamed PE. Idle-time execution. Niche but real.
• Accessibility backdoor - Replace sethc.exe, utilman.exe, osk.exe, magnify.exe, narrator.exe or hijack them with IFEO. All are reachable from the pre-logon screen; abuse yields SYSTEM shell without authentication. Classic physical-access / stolen-image technique.

Credential theft - artifacts and detection

Modern Windows stores credentials in a half-dozen locations. On a domain controller, the master store is NTDS.dit (an ESE database holding every object in Active Directory, including password hashes). On a workstation, the LSASS process holds whatever creds have been used since boot - NT hashes, Kerberos TGTs, cleartext passwords (for logon types that need them), and DPAPI master keys. On disk you'll find the SAM hive (local account hashes) and the SECURITY hive (LSA secrets, cached domain creds). The attacker's goal is almost always to get hashes they can crack or pass, or TGTs they can replay. Your job as DFIR is to answer "did they get it, and if so, what did they do with it after?"

• LSASS dumping - categorize techniques, not just tools: comsvcs.dll MiniDump via rundll32, procdump -ma, Dumpert (direct syscall), nanodump, Taskmgr right-click, MiniDumpWriteDump through PPL bypass. Detect via Sysmon EID 10 to lsass with suspicious GrantedAccess masks (0x1010, 0x1410, 0x1438).
• LSA Protection (PPL) and Credential Guard raise the bar; bypasses exist for PPL (e.g. vulnerable or signed drivers). Credential Guard moves secrets into the isolated LsaIso.exe process, so LSASS dumps on those hosts won't contain NT hashes or TGTs for protected accounts.
• SAM/SECURITY offline - grab via reg save, VSS, raw NTFS read.
• NTDS.dit - DC extraction via ntdsutil ifm, VSS, DCSync.
• DCSync - detect via 4662 w/ replication GUID above; monitor replication rights (DS-Replication-Get-Changes-All).
• Kerberos abuse - Kerberoasting (TGS-REP RC4), AS-REP Roasting (accounts with pre-auth disabled), Golden/Silver tickets, S4U2Self/S4U2Proxy (constrained/RBCD).
• Shadow Credentials - attacker writes msDS-KeyCredentialLink to request PKINIT auth.
• Zerologon (CVE-2020-1472), PetitPotam, PrinterBug → NTLM relay to AD CS → AD CS abuse (ESC1-ESC16 as catalogued since Certified Pre-Owned).
• DPAPI - %AppData%\Microsoft\Protect\<SID>\<MasterKey>; chromium cookie DPAPI v10/v20 wrapped w/ app-bound key; infostealer workflow.

Lateral movement - what each pivot leaves behind

Every lateral-movement vector produces traces on both hosts - a client-side artifact on the source (what the attacker used to pivot) and a server-side artifact on the target (the authentication, the service install, the file created). Always correlate both sides: a 4624 Type 3 on the target with no matching outbound logon on the putative source means the real source is somewhere else and you haven't fully scoped yet.

Anti-forensics & cover-up

• wevtutil cl, Clear-EventLog → Security EID 1102 (Security log) / System EID 104 (any other log)
• Volume Shadow Copy deletion (vssadmin delete shadows, wmic shadowcopy delete, vssadmin resize shadowstorage), ransomware signature; detect on the command line (4688 / Sysmon 1). VSS EID 8224 is only the service's idle shutdown, not a deletion indicator
• Timestomping (SI vs FN divergence)
• cipher /w, fsutil usn deletejournal, sdelete
• Clearing MRU keys, UserAssist deletion
• Disabling Defender / tamper protection (Defender Operational EID 5001 real-time protection disabled, 5007 configuration changed)