Windows Evidence Substrates: NTFS Metadata, Registry Hives, and Application Stores

Introduction

The first section of this module established why Windows keeps records nobody ever asked it to keep. This one is the map of where those records physically sit, which turns out to predict more about them than their names do.

By the end of this section you will be able to place any Windows artifact you meet into one of three substrates from its location alone, say what each substrate answers completely and what it is entirely silent about, explain why the substrate rather than the artifact decides how a record is collected, how long it survives and how much weight it carries, name the four categories of question Windows records nothing about whatsoever, and place an artifact this course never covered, which is the part of this section that will still be useful in five years.

The substrate matters more than the artifact name. Two records answering the same question behave completely differently if one is filesystem metadata and the other is an application's own file.

Windows evidence is almost always taught as a list of artifact names to learn. Grouping those artifacts by where they physically live is considerably more useful, because the substrate predicts how each one behaves under every condition that matters.

Read the band underneath. Collection, survival and who can modify a record are all properties of the substrate rather than of the artifact, so the first question about anything unfamiliar is which of the three it belongs to.

  SUBSTRATE      COLLECTED BY          WHO CAN MODIFY IT

  NTFS metadata  raw volume read       the filesystem driver, and
                                       an administrator with a
                                       raw handle

  Registry       hive file copy, or    any process with rights to
                 a raw read while      the key, which for a user
                 the machine runs      hive is that user

  Application    an ordinary file      the application, plus
                 copy of its own       anybody who can write to
                 directory             its directory

  Three substrates, three collection methods, three answers
  to who could have changed the record.

How each substrate is collected, and who is able to alter what it holds.

The right-hand column is the one that decides how much weight a record carries. A user can trivially edit files in their own application directories and cannot casually rewrite the change journal, which is why those two records are not equally strong evidence of the same fact.

Twelve artifacts from across the course, placed.

  ARTIFACT              SUBSTRATE      MODULE

  $MFT, $J, $LogFile    NTFS           1, 7, 8, 9
  $I30 directory index  NTFS           7
  Recycle Bin           NTFS + app     8
  SYSTEM, SOFTWARE      registry       4, 5
  NTUSER, USRCLASS      registry       3, 10
  Amcache               registry       2
  ShellBags             registry       3
  Prefetch              application     2
  SRUM                  application     2, 6
  Windows event logs    application     1, 3, 4, 5, 8
  Browser profiles      application    10
  Chat client stores    application    10

  One row is in two substrates. That is the exception
  rather than a fourth category.

The registry block in the middle is worth reading as a group rather than as five entries. Those hives are separate files collected together and they answer very different questions, with the machine hives covering configuration and the user hives covering what a person did, which is the split that makes attribution possible.

Every artifact this course teaches sits in one of the three, and the module column shows how the substrates distribute across the ten questions rather than clustering.

The distribution across the module column is worth a moment too. No substrate belongs to one module and no module draws on one substrate, which is the same argument the structure section made about artifact families arriving here from a different direction.

The event logs are the entry most people would place elsewhere. They feel like a system facility rather than an application store, and they are files in a directory written by a Windows service, which means they are collected, protected and destroyed exactly like any other application's store.

The Recycle Bin row is the interesting one. It is a directory on the volume containing files with their own metadata, plus an index the shell maintains, so it is genuinely both and the two halves survive different events.

The two halves of the registry, and how many user hives one machine carries.

C:\> reg query "HKLM\SYSTEM\CurrentControlSet\Control\ComputerName" 2>nul
  a machine hive: configuration, one per system

C:\> reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer" 2>nul
  a user hive: activity, one per account

C:\> Import-Csv C:\out\mft.csv | Where {$_.FileName -eq "NTUSER.DAT"} |
      Select ParentPath,FileSize
\Users\jdoe        18,874,368
\Users\p.sharma     4,194,304
\Users\svc_backup   1,048,576

  Three user hives on one machine. Three separate records
  of activity, and the sizes are not comparable by accident.

The service account in that list is the row worth pausing on. It has a user hive like any other account, so activity performed under it is recorded exactly the same way, and an examination that only enumerated human users would have missed a substrate copy entirely.

Two hive types answering two different questions, and three copies of the user one because three accounts have used this machine.

Counting the hives is also the fastest way to establish how many accounts have actually used a machine, which is a different number from how many are provisioned on it. A hive exists once an account has logged in and not before.

The sizes are worth reading rather than skipping. A user hive grows with activity, so an eighteen megabyte hive belongs to somebody who has used this machine heavily and a one megabyte one to an account that has barely touched it, which is a scoping fact available before any parsing.

There is a caution about the three-way split worth stating so it is used as a tool rather than believed as a law. It is a model, and models have edges: the Recycle Bin sits across two substrates, the search index is an application store that indexes the other two, and one or two artifacts move between categories across Windows versions. The value is in the questions it prompts rather than in the boxes being perfect.

There is a reason this section sits after the toolstack rather than before it. Tools are organized by artifact because that is how they were written, one per format, so the previous section's list is necessarily artifact-shaped. This one regroups the same ground by substrate, which is how an examiner should think about it even though it is not how the tooling is packaged.

There is an ordering claim in this section that is worth making explicit, because it inverts how most material is written. The artifact name is the least useful thing to know about a record and it is what every list leads with. Where it lives, what wrote it and who can change it are all more predictive, and all three are answerable before you know what the artifact is called.

There is a fourth thing the substrate predicts that the table does not show, and it is the one that matters in court. Records written only by privileged components carry more weight than records any user process could have produced, and that difference is a substrate property rather than an artifact property.

There is a reason the first column is worth memorizing before any artifact name. A collection that captured all three substrates properly can be worked for years, and one that missed a substrate cannot be repaired afterwards however good the analysis is, so this table is really a checklist for the acquisition module.

The middle column is why the first module spends its time on collection. Three substrates need three approaches, and a collection that copied files without a raw read has captured one of the three properly.

Each substrate is complete about the thing it was built for and blind everywhere else. Four things.

The first row is worth pairing with what it cannot do, because people over-read it constantly. Filesystem metadata establishes that a file existed and when its timestamps changed, and it does not establish who changed them or which process was responsible, so a finding that names an account on the strength of filesystem evidence alone has gone past what the substrate holds. It is the only substrate that reliably attaches activity to an account, and attribution is a question almost every case asks.

The fourth row is the boundary of the whole discipline rather than a limitation of one substrate. Every artifact records an act, none records a reason, and an examiner who is clear about that at the start avoids being drawn into a claim the evidence was never going to support.

The third row is the trade the course keeps returning to. The most informative evidence is the least stable, so an application store is where you find what was actually said and also where an update can remove the format you relied on.

An event that erases one substrate very frequently leaves another completely untouched, which is what makes knowing three categories worth more than memorizing thirty artifact names.

  EVENT                    NTFS      REGISTRY   APPLICATION

  file deleted             record    unaffected  entry may
                           persists              persist

  application uninstalled  unaffected keys often  store usually
                                     remain       removed

  user profile deleted     record    hive gone    store gone
                           persists

  volume defragmented      journal   unaffected  unaffected
                           entries
                           churn

  Nothing in this table erases all three.

Four destructive events, and what each does to the three substrates.

No row in that table is blank across all three. Each event is decisive for one or two substrates and irrelevant to the others, which is the structural reason evidence survives attempts to remove it.

One real question, split into what the machine holds and what it does not.

  "did she read the report before she resigned?"

  WHAT WINDOWS RECORDS         WHAT IT DOES NOT

  the file existed             that it was read
  it was opened by an app      how long it was on screen
  a folder was browsed         whether anybody looked
  a shortcut was created       what was understood

  The honest finding: the document was opened under her
  account at 17:37:02, and no artifact establishes that
  its contents were read.

There is an auditing exception worth naming so the claim is precise rather than absolute. Windows can be configured to audit file access, and where somebody has turned that on for a specific folder the event log does record reads. It is off by default, it is rare on workstations, and checking whether it was enabled costs one query and occasionally changes an entire case.

There is a category of application that does record reading, which is worth knowing before this reads as too absolute. Document viewers, mail clients and some editors keep their own recent-items and last-position records, so the answer can exist in the application substrate even though the operating system never wrote it.

That question arrives on almost every insider case in some form, and it is worth having the answer ready before it does. The word in it that does the damage is read, because the machine has no concept of reading at all.

Opened and read are different acts and only one of them touches the machine. An application recorded that a document was opened and nothing anywhere recorded that a human being looked at it.

The word accessed is the one to avoid in a report, and it is worth naming here rather than in the reporting module. It reads as though it covers both opened and read, it is defensible against neither precisely, and it is the word an examiner reaches for when they want the stronger claim without making it.

The left-hand column is not weak evidence either, which is worth saying so the section does not read as discouraging. Four independent facts about one document under one account inside a minute is a substantial finding, and it is only disappointing next to a question nobody could have answered.

The honest finding at the bottom is the one to practice writing. It answers the question that was asked, states what the artifacts support, and names the gap rather than closing it with a word like accessed that quietly spans both.

There is a general principle underneath this table that is worth more than the four rows. Evidence survives because the three substrates are maintained by parties with different interests: the filesystem driver, the operating system's configuration store, and a vendor's application. No single act reaches all three because no single party controls all three.

The second and third rows are the pair worth comparing. Removing an application takes its store and usually leaves its registry keys behind, while removing a profile takes the user hive and the stores together, so the two events destroy overlapping but different evidence.

The first row is the one that carries most of this course, and it is the reason deleted-file work is productive rather than hopeless. A deleted file leaves its filesystem record behind, frequently leaves registry traces of having been browsed or opened, and may leave an application entry, so deletion is the event that destroys the least of the three.

The last row is the one people underestimate. Defragmentation is not an anti-forensic act and it churns filesystem metadata heavily, so a routine maintenance task can damage the substrate that would have answered the question while leaving the other two intact.

Orientation is as much about knowing what will not be there as what will, and four whole categories of question have no Windows artifact behind them at all.

  QUESTION                          RECORDED?   WHERE IT LIVES

  was this file read                 no*        *unless the app
                                                kept its own record

  what was in a file before it       no         backups, versions,
  was overwritten                               the search index

  what was sent over the network     no         proxy, firewall,
                                                the far end

  why any of it happened             no         interviews, email,
                                                other people

  The first is the one people assume is recorded.

Four questions with no Windows artifact behind them, and where each answer actually lives.

The first row surprises people every time. Windows does not record file reads, so opening a document and doing nothing else frequently leaves no operating system trace, and what looks like evidence of reading is usually an application recording it for its own convenience.

The second and third rows are worth reading as routing rather than as absence. Neither says the question is unanswerable; both say the answer is not on this endpoint, which is the sentence a report should carry rather than silence.

The last row is worth saying plainly at the start of a forensics course. Every technique here establishes what happened on a machine, and no artifact anywhere records a reason, so a question about motive is not a forensic question however it is phrased.

Windows ships components faster than anybody documents them, so placing an unfamiliar artifact is the skill that lasts. Four things.

These four questions are the whole method and they work on artifacts nobody has written about yet, which is why this card closes the section rather than a list of artifacts to memorize. Each is answerable from the artifact itself with no documentation at all.

The first row is answerable in seconds and settles more than it looks. A file inside the volume's own structures, a value inside a hive, and a file in a program's directory are three visibly different things, and almost every artifact declares which it is by its location alone.

The second row is the transferable part and the one worth practicing. Windows ships new components constantly, and asking what a new one was built for predicts its evidential value before anybody has published a parser for it.

A worked example of the four is useful. Take a folder Windows created that you have never examined: it lives in a program's directory, so it is an application store; it exists to cache something for speed; the application and the user can both write to it; and it will go when the application does. That is its evidential profile established in four sentences and no research.

The fourth row is four questions rather than one and they rarely share an answer. Surviving a file's deletion, an application's removal, a profile's deletion and a reboot are independent properties, and an artifact can be durable against three of them and destroyed by the fourth.

The third row is what turns a record into a finding of a particular strength. Evidence that only a privileged component could have produced is worth more than evidence a user could have written, and knowing which you have is a substrate question.

The document that is gone, from an application that was removed, on a volume that was defragmented.

  QUESTION: was Q2-pricing.xlsx opened on this machine?

  APPLICATION SUBSTRATE   the spreadsheet application was
                          uninstalled; its recent-files store
                          went with it
                          -> nothing

  NTFS SUBSTRATE          the file was deleted and the volume
                          defragmented afterwards; journal
                          entries for that period have churned
                          -> nothing usable

  REGISTRY SUBSTRATE      unaffected by all three events

C:\> Import-Csv C:\out\shellbags.csv | Where {$_.AbsolutePath -match "Q2"} |
      Select AbsolutePath,LastInteracted
C:\Users\jdoe\Documents\Q2-restricted   2026-06-08 17:36:44

C:\> Import-Csv C:\out\usrclass-recentdocs.csv |
      Where {$_.TargetName -eq "Q2-pricing.xlsx"} | Select OpenedOn
2026-06-08 17:37:02

The same question put to each substrate in turn, then the one that answered.

Two of the three substrates were destroyed by unrelated events and the third was not touched by any of them. The registry recorded both that the folder was browsed and that the document was opened, under a named account.

The order in that block is the order worth working in. Checking the application substrate first is natural because it is the richest, and checking it first on this case would have produced nothing and stopped an examiner who had no map of the alternatives.

That is the argument for the three-substrate map in a single case. An examiner who thinks in artifact names asks whether a particular parser will help; an examiner who thinks in substrates asks which of three places is still intact, and gets to the answer faster.

Windows evidence is usually taught as a list of artifact names, and grouping it by where the records physically live is more useful, because the substrate predicts how each one behaves. Filesystem metadata is the volume's own bookkeeping and answers what existed, when it changed, in what order and what is gone, while saying nothing about contents or about which program was responsible. Registry hives hold configuration and per-account activity, which makes them the only substrate that reliably attaches an action to an account. Application files hold content and communication, and are simultaneously the richest of the three and the most fragile, because they belong to vendors who change them without notice.

The substrate decides three things the artifact name does not. It decides how a record is collected, because a raw volume read, a hive copy and an ordinary file copy are three different operations. It decides who could have altered the record, which is what separates evidence only a privileged component could have written from evidence a user could have edited. And it decides what survives which event: a deleted file, an uninstalled application, a removed profile and a defragmentation each destroy one or two substrates and leave the others intact, which is the structural reason evidence outlives attempts to remove it.

Four categories of question have no Windows artifact behind them at all. File reads are not recorded, so what looks like evidence of reading is almost always an application keeping its own convenience record. Previous contents of an overwritten file are gone unless a backup, a version or the search index holds them. Network payloads live on the proxy and at the far end rather than on the endpoint. And nothing anywhere records why something happened, which means a question about motive is not a forensic question however it is phrased. Knowing those four at the start of the course is what stops an examination looking for something that was never written down.