Appendix D — Forensic Artifact Locations

Purpose. A keyboard-side cheat sheet of where the evidence lives — registry hives and keys, event logs, execution and USB artifacts, browser profiles, and the macOS/Linux equivalents — so you can go straight from "I need to prove X" to the exact path on the image. The chapters teach you what each artifact means; this appendix tells you where to find it.

This is a lookup table, not a tutorial. For how to interpret these artifacts, see Chapter 16 — Windows Forensics and Chapter 17 — macOS and Linux Forensics. For browser specifics, see Chapter 18 — Browser and Internet Forensics. For timestamps and timelines, see Chapter 21 — Timeline Analysis.

How to use this appendix (read first)

A few rules that apply to every path below. Internalize them once.

Work from the image, read-only. Every path here is written as it appears on a live system (with drive letters and ~). On an evidence image you reach the same file through your mounted/extracted copy — e.g. E:\evidence\C\Windows\System32\winevt\Logs\Security.evtx, or via fls/icat from a raw/E01. Never parse the live original when an image exists; the original is sacred (theme #2). Mount images read-only, or better, extract the artifact and hash it before you touch it.

Deleted ≠ destroyed — even here. These artifacts have their own slack, free lists, and deleted remnants. Deleted registry keys often survive in the hive's free cells and in the .LOG1/.LOG2 transaction logs (recover with yarp/RegRipper against a replayed hive). SQLite stores (browser History, macOS knowledgeC.db, Quarantine) keep deleted rows in page free-blocks and the freelist until VACUUM. .evtx records can be carved from unallocated space after a 1102 clear. Always ask not just "what is here?" but "what was here?"

The absence of a trace is a trace. Prefetch turned off, a Security.evtx that starts an hour ago, a $I` file with no matching `$R, a wtmp that disagrees with auth.log — gaps and inconsistencies are findings, not dead ends. See Chapter 30 — Anti-Forensics.

Mind the epoch. Different artifacts count time from different zero points (1601, 1904, 1970, 2001…). A 31-year or 369-year timeline error is the kind of thing opposing counsel loves. Use the Timestamp Epoch Quick Reference at the end of this appendix and verify per-column.

Versions drift. Microsoft and Apple move and rename things between builds; SSD/server defaults differ from desktop defaults. Treat every path as "as of recent Windows 10/11, current macOS, mainstream Linux." Confirm the artifact exists before you rely on it, and note the OS build in your report.

Notation: <u> = a user account name · <SID> = a security identifier (e.g. S-1-5-21-…-1001) · <AppID> = a Jump List application ID · <UUID>/<machine-id>/<random> = host- or profile-specific identifiers. On an offline SYSTEM hive there is no CurrentControlSet — use ControlSet001 (or read SYSTEM\Select\Current to learn which ControlSet was active).

Windows

Windows is the most artifact-rich platform you will examine: it records what ran, when, by whom, from which device, and where files came from, across the registry, dedicated logs, and a sprawl of caches. The map below mirrors Chapter 16.

Registry hives — on-disk location → mount point

The registry is not one file. It is a set of hive files that the running OS stitches into the HKLM / HKU / HKCU tree. On an image you parse the files, not the live tree.

Tool Tip. Always grab each hive's transaction logs alongside it — SAM.LOG1/.LOG2, SYSTEM.LOG1/.LOG2, NTUSER.DAT.LOG1/.LOG2, etc. A "dirty" hive must be replayed from its logs before parsing, and the logs themselves contain recently written (and recently deleted) keys. RegBack (C:\Windows\System32\config\RegBack\) historically held periodic hive backups, but it is empty by default since Windows 10 build 1803 — don't count on it.

Hive → tree mapping (offline)

  SAM          ─►  HKLM\SAM
  SECURITY     ─►  HKLM\SECURITY
  SYSTEM       ─►  HKLM\SYSTEM   (use ControlSet001; CurrentControlSet is runtime-only)
  SOFTWARE     ─►  HKLM\SOFTWARE
  NTUSER.DAT   ─►  HKU\<SID>     (HKCU for the interactive user)
  UsrClass.dat ─►  HKU\<SID>_Classes

Notable registry keys

Paths use the hive's file as the root to keep them image-friendly. Where a key lives under CurrentControlSet, substitute ControlSet001 offline.

USB and removable-device history

Limitation. Under USBSTOR, the instance ID is the device serial only if its second character is not &. A & means Windows generated the ID because the device reported no unique serial — it is not globally unique, so do not claim cross-machine identity for it. (See Chapter 16.)

Program execution and persistence

Why This Matters. Execution evidence is layered: Prefetch, UserAssist, and BAM indicate execution; Amcache and ShimCache indicate presence. No single key is proof — three that agree is a finding. State the distinction on the stand; do not call presence "execution."

Recent activity and shell usage (per-user — NTUSER.DAT / UsrClass.dat)

System configuration and accounts

Event logs (.evtx)

Folder: C:\Windows\System32\winevt\Logs\ · Format: binary XML (.evtx), magic ElfFile\x00. Parse with EvtxECmd, wevtutil, Get-WinEvent -Path …, or Python python-evtx.

Core logs

High-value specialized logs (same folder; %4 encodes the / in the channel name)

Key Security event IDs

Key System event IDs

Logon types (the LogonType field on 4624/4625)

War Story. A burst of 4625 (type 3 or 10) followed by a 4624 success is a brute force that worked. A lone 1102 is loud by itself: clearing the log is an action, the action is logged with who and when, and the silence afterward is the absence-of-a-trace trace.

Prefetch — "this program ran"

Folder: C:\Windows\Prefetch\ · Files: NAME-XXXXXXXX.pf (uppercased exe name + 8-hex path hash). On Win10/11 the body is MAM/Xpress-Huffman compressed — PECmd decompresses automatically.

• Holds run count, last 8 run times, and referenced files/directories (loaded DLLs, opened data files).
• Capacity: 128 entries (pre-Win8) → 1024 (Win8+).
• Often disabled on SSD-only systems and servers: SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters (EnablePrefetcher = 0). Absence ≠ "nothing ran."
• Boot tracing: C:\Windows\Prefetch\ReadyBoot\.

Amcache.hve — presence + SHA-1

File: C:\Windows\AppCompat\Programs\Amcache.hve (registry-format hive; grab .LOG1/.LOG2). Parse with AmcacheParser.

Limitation. Amcache proves a binary was present on the system, not that it executed. Pair it with Prefetch/UserAssist/BAM before you say "ran."

Other Windows stores (ESE and SQLite)

$Recycle.Bin — deleted via the GUI

Folder: C:\$Recycle.Bin\<SID>\ (XP used C:\RECYCLER\<SID>\INFO2). Parse with RBCmd.

Match $I` and `$R by their shared 6-character token. A $I` with **no** matching `$R means the content was purged but the deletion record survives — itself a finding.

LNK files and Jump Lists — "this file was opened, and where it lived"

Tool Tip. The <AppID> is a CRC of the application's path; use a published AppID list (or JLECmd) to map it back to the program. LNK targeting a drive letter with a volume serial that matches a USBSTOR device is how you prove a file lived on a USB stick that is no longer present.

Browser profiles (Windows)

Full schema and timestamp handling are in Chapter 18. Copy the -wal and -shm companions with any SQLite store — recent activity often lives only in the WAL.

NTFS file-system metafiles (root of each NTFS volume)

These are owned by Chapter 4 — File Systems and detailed in Appendix G, but list them here because they are artifact goldmines:

• $MFT` — every file's record (resident data, `$STANDARD_INFO and $FILE_NAME MAC times — the latter resists timestomping).
• $LogFile — NTFS transaction log (recent metadata changes).
• $Extend\$UsnJrnl:$J — the USN change journal: a rolling log of file create/delete/rename/write. Deleting it is itself suspicious.
• $Recycle.Bin`, `$Extend\$ObjId`, `$Extend\$Quota.

Windows triage collection (illustrative)

# Read-only artifact pull from a mounted image (E:) into a case folder.
# Illustrative — never run against an original; hash everything you copy.
$src = "E:\C"; $out = "D:\case-2026-014\artifacts"
$paths = @(
  "Windows\System32\config\SAM","Windows\System32\config\SYSTEM",
  "Windows\System32\config\SOFTWARE","Windows\System32\config\SECURITY",
  "Windows\System32\winevt\Logs",            # all .evtx
  "Windows\Prefetch",                         # *.pf
  "Windows\AppCompat\Programs\Amcache.hve",
  "Windows\System32\sru\SRUDB.dat",
  "Windows\INF\setupapi.dev.log"
)
foreach ($p in $paths) { robocopy "$src\$p" "$out\$p" /E /COPY:DAT /R:0 /XJ | Out-Null }
# Per-user: NTUSER.DAT, UsrClass.dat, Recent\, browser profiles  (loop C:\Users\*)
Get-ChildItem "$out" -Recurse -File | Get-FileHash -Algorithm SHA256 |
  Export-Csv "$out\_hashes.csv" -NoTypeInformation

Tool Tip. In practice you do this with KAPE targets (see Chapter 15 — Live Response and Triage) and Eric Zimmerman's tools (RECmd, PECmd, AmcacheParser, EvtxECmd, JLECmd, RBCmd, SRUMECmd) — see Appendix C — Tool Reference. The script shows what to grab; KAPE does it faster and with logging.

macOS

There is no registry on a Mac. The equivalents are property lists (plists), SQLite databases, and structured binary logs scattered mostly under ~/Library/ and /Library/. (/var is a symlink to /private/var; paths below use the short form.) See Chapter 17. The single biggest rookie error is treating macOS like Windows — learn its map on its own terms.

System and unified logs

Live tools: log show / log collect (with --predicate). Offline: Mandiant UnifiedLogReader, mac_apt.

File-system and metadata activity

Activity timeline databases

Limitation. macOS forgets fast. The Unified Log retains days to weeks, not months, and high-volume entries roll quickly. Acquire promptly and capture volatile state live where you can. (theme #5)

Key plists (configuration, persistence, identity)

Tool Tip. plists come in XML and binary form. Convert/inspect with plutil -convert xml1 -o - file.plist or plutil -p file.plist. Parse the whole Mac at once with mac_apt (APFS, Spotlight, FSEvents, Unified Log, knowledgeC, Quarantine, plist, Safari plugins).

Time Machine and APFS snapshots

Why This Matters. Enumerate snapshots before you carve. Why reconstruct from fragments what an hourly snapshot holds whole? Mount the snapshot read-only (APFS-Fuse / mount_apfs -s) and diff against the live volume to prove deletion windows.

User-data SQLite stores

Browsers (macOS)

macOS collection one-liner (illustrative)

# From a mounted, read-only image volume at /Volumes/EVID — copy, then hash.
mac_apt.py -i /Volumes/EVID -o ~/case/mac_out ALL      # broad plugin sweep
# Targeted grabs (paths relative to the mounted volume root):
#   private/var/db/diagnostics  +  private/var/db/uuidtext   (Unified Log: BOTH)
#   .fseventsd                                               (FSEvents)
#   .Spotlight-V100/Store-V2                                 (Spotlight)
#   Users/<u>/Library/Application Support/Knowledge/knowledgeC.db
#   Users/<u>/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2
shasum -a 256 ~/case/mac_out/*  > ~/case/mac_out/_hashes.txt

Linux

Linux gives you redundant records on purpose — the same SSH login lands in auth.log, in wtmp (via last), and in the systemd journal. When they agree, your finding is bulletproof; when one is edited and the others are not, the disagreement is the evidence. Paths follow mainstream distros; note the Debian/Ubuntu vs. RHEL/CentOS/Fedora split. See Chapter 17.

/var/log — text logs

Binary login records (decode with the right tool)

Tool Tip. Each record is a fixed-size utmp struct (384 bytes on 64-bit glibc: type, PID, terminal, 32-byte user, 256-byte host, timestamp). Because they are binary, they are harder to edit cleanly than text logs — a wtmp that disagrees with auth.log is a tampering indicator. The full struct layout is in Appendix G.

systemd journal

Path: /var/log/journal/<machine-id>/*.journal (persistent) · /run/log/journal/ (volatile RAM-only — capture live). Files begin with magic LPKSHHRH.

# Read the journal straight from a MOUNTED IMAGE, offline, with structured filters.
journalctl --file ./var/log/journal/<machine-id>/system.journal \
           -u ssh.service --since "2026-06-20 00:00" -o verbose
journalctl -D ./var/log/journal/<machine-id> --list-boots

Captures process executions, service starts/stops, authentication (ingests the same PAM events as auth.log), and kernel messages, with microsecond timestamps. Optional Forward Secure Sealing (FSS) makes it tamper-evident.

Shell history and per-user activity

Scheduled execution (cron, systemd timers)

Persistence, accounts, and system identity

ext4 / file-system layer

The inode table, extents, and the ext4 journal (a "second chance" at the block map for recently deleted files) are owned by Chapter 4 and detailed in Appendix G. Recover deleted files with extundelete/ext4magic or carve (photorec, foremost — Appendix H).

Timestamp epoch quick reference (cross-OS)

The single most error-prone step in artifact analysis. Always confirm which epoch a column uses before you build a timeline (Chapter 21).

Why This Matters. Forget the +978,307,200 on a Mac column and your timeline is off by 31 years; treat a FILETIME as Unix and you are off by 369 years. These are the errors opposing counsel exhibits to the jury. Convert deliberately, label every timestamp with its source and time zone, and normalize everything to UTC in your master timeline.

Artifact-to-question matrix (start here)

Work backward from the question you must answer to the artifacts that answer it. Corroborate across at least two independent sources before you state a finding.

Caveats and cross-references

Legal Note. Knowing where an artifact lives is not authority to collect it. Scope your acquisition to the warrant or consent that authorizes it (Chapter 25 — The Legal Framework), and document every artifact's source path, acquisition method, and hash in your chain of custody.

Limitation. Encryption changes this map. On a BitLocker/FileVault/LUKS volume, none of these paths are reachable until the volume is unlocked — see Chapter 29 — Encrypted Device Forensics. Cloud-synced artifacts (browser history, files, mail) may live partly or wholly server-side — see Chapter 31 — Cloud Forensics. Mobile layouts differ entirely — see Chapter 24 — Mobile Device Forensics.

Related references in this book:

• Appendix A — File Signatures Reference: magic numbers for carving the files these artifacts point to.
• Appendix B — Python Forensics Toolkit: scripts to parse timestamps, registry, and SQLite stores.
• Appendix C — Tool Reference: the parsers named above (RECmd, PECmd, EvtxECmd, mac_apt, plaso…).
• Appendix G — File System Reference: NTFS MFT, ext4 inode, APFS, and the utmp struct.
• Appendix H — Command-Line Reference: fls/icat, xxd, exiftool, journalctl, last/lastb, and friends.
• Glossary: every term used above, chapter-cross-referenced.

Recovery vs. Forensics. The same path serves both disciplines, with different priorities. A recovery tech reads $Recycle.Bin, browser caches, and snapshots to restore what the user lost, fast. An examiner reads the identical artifacts to prove who did what, when — admissibly: image first, hash, work the copy, document the source path of every artifact, and normalize every timestamp to UTC. Know which job you are doing before you touch the keys.