Windows Forensic Analysis: Reconstruction From Records Nobody Asked For

Introduction

This course is about reconstructing what happened on a Windows system from the records that system kept without ever being asked to keep them. This first section is about why those records exist at all, because that explains most of what follows.

By the end of this section you will be able to say what separates this work from log review in a way that holds up when somebody asks, name the property of the operating system that makes reconstruction possible in the first place, explain why a single action produces several independent records rather than one, describe how a question gets answered from artifacts in a deliberate order rather than by searching everything, and state what a finding from this work actually looks like, which is narrower than most people expect.

The distinction that matters is that almost nothing in this course is a log. Logs are written on purpose by software that intended to record something, and most of what you will read here was written for performance reasons by software that was not thinking about you.

Forensic analysis on this platform is possible because Windows is built to be fast and convenient rather than to be forgettable. Making a program launch quickly the second time means remembering that it launched the first time, and that memory is where a great deal of this course lives.

Read the band at the bottom. None of those five was created to help an investigator, and that is precisely why they are useful: nothing about them was curated.

C:\> Import-Csv C:\out\prefetch.csv | Where {$_.ExecutableName -match "7Z"} |
      Select ExecutableName,RunCount,LastRun

ExecutableName      RunCount  LastRun
7Z.EXE-A41C82B4            1  2026-06-08 17:40:02

C:\> Import-Csv C:\out\Security-1102.csv | Measure-Object -Line
Lines : 1

  The security log was cleared at 17:52. The prefetch entry
  was written at 17:40 by a component that does not know
  the security log exists.

One execution record, on a machine whose security log was deliberately cleared.

One execution recorded by the Windows prefetcher, whose entire purpose is to make the next launch of that binary faster. Clearing the security event log did nothing to the prefetch file, because the Event Log service and the prefetcher are unrelated pieces of Windows.

There is a practical reason that reasoning matters more than a tool list on this platform specifically. Windows ships new components constantly and retires old ones, so any course that taught only what exists today would be teaching a snapshot. The Windows components in this course, from NTFS through the registry to SRUM, were chosen because they are stable across versions and because working out what each one records is a transferable exercise.

There is one more framing worth having before the detail, because it is what makes this discipline rather than a tool list. The artifacts change: formats are revised, components are retired, and a technique that worked on one Windows version fails on the next. What does not change is the reasoning, which is asking what a Windows component was built to do and deriving from that what its records can be trusted to say. That question works on an artifact nobody has documented yet.

There is a scope statement worth making at the very start, because it defines the course. This is about a Windows endpoint and what can be established from the machine itself. Server logs, network captures, cloud audit records and mobile devices are all real evidence and all outside this course, and where an endpoint cannot answer a question the course says so and names the source that can.

There is an audience point worth making before anything else, because this is the first section of the course. Nothing here assumes prior forensic experience, and every artifact named in this module is explained properly when the course reaches it. What this section is doing is establishing why the material exists, so that the modules that follow read as a system rather than as a list of file formats to memorize.

There is a second thing that record establishes which is easy to miss. The prefetch run count was one, so this was the first time Windows had seen that binary execute on this machine, and a first execution on the afternoon in question is a different fact from a program somebody uses daily.

There is a design reason behind that record worth understanding rather than memorizing. Windows watches which files a program needs during its first ten seconds and writes them into a prefetch file so it can fetch them in advance next time, which makes the second launch faster. The record exists to improve performance and it happens to be a dated list of every program that has run.

That independence is the property the whole course rests on. An action leaves marks in several Windows subsystems that do not coordinate with each other, so suppressing the prefetch record does nothing to the registry, and suppressing both does nothing to the NTFS change journal.

Two kinds of evidence get treated as one thing, and the difference decides what survives an attempt to remove it. Four things.

These two words get used interchangeably in practice and the distinction is worth holding because it predicts what will still be there. A Windows event log and a prefetch file are both files on an NTFS volume, and only the event log was written by something that knew it was creating a record.

The first row is not a criticism of logs, which are frequently better evidence than artifacts when they exist. A well-configured log answers a question directly, in a documented format, with a known retention period, and an examination that has one should use it. The point is that most machines do not have one covering the question being asked.

The second row is the one that sets expectations for the whole course. A prefetch file answers what the prefetcher cared about, which is which files a binary needed at startup, and it is silent on who ran it. No single Windows artifact tells a story.

The third row is the practical consequence and it explains why anti-forensics is difficult rather than easy. Somebody removing evidence of an action has to know that prefetch, Amcache, ShellBags, UserAssist, the change journal and SRUM each recorded part of it, and that list is long, undocumented and different on every Windows version.

The fourth row is why the work is technical rather than procedural. Microsoft documents almost none of these formats, and prefetch, ShellBags and Amcache are understood because researchers reverse-engineered them across Windows versions.

A single act touching a Windows system leaves marks in several places at once, and the reason is that NTFS, the registry and the Windows service layer were each solving their own problem.

C:\> Import-Csv C:\out\mft.csv | Where {$_.FileName -eq "svc.exe"} |
      Select SI_Created
2026-06-08 17:38:02

C:\> Import-Csv C:\out\j.csv | Where {$_.FileName -eq "svc.exe"} |
      Select -First 1 Timestamp,Reason
2026-06-08 17:38:02.114   FILE_CREATE

C:\> Import-Csv C:\out\amcache.csv | Where {$_.Name -eq "svc.exe"} |
      Select SHA1,IsOsComponent
SHA1 : 8814a41c82b4d5e04c1f8a92b6d70389e5c14b0a
IsOsComponent : False

The same file described by three components that do not talk to each other.

Three records of one file from the NTFS master file table that indexes the volume, the change journal that logs every modification to it, and the Amcache hive that exists so Windows application compatibility checks are faster. Each was written by a different part of the system for a different reason.

Five artifacts, why each one exists, and what it incidentally records.

  ARTIFACT      EXISTS BECAUSE                    HAPPENS TO RECORD
  -----------   ------------------------------   --------------------
  Prefetch      launching a program twice         every program that
                should be faster the second       has run, and when
                time

  Amcache       compatibility checks should       every binary seen,
                not rescan every binary           with its hash

  SRUM          users want to see which apps      per-app data volume
                drain battery and data            and process time

  ShellBags     a folder should reopen with       every folder browsed,
                the view you last left it in      including deleted ones

  UserAssist    the start menu should list        per-account launch
                what you actually use             counts and times

That table is also the shape of the whole syllabus. Each of the ten modules takes a group of these, establishes what the component was built to do, and derives from that what its records can and cannot answer.

Read the middle column first. Not one of those five was built for an investigator, and every entry in the right-hand column is an accident of the design in the middle one.

The right-hand column also explains why these artifacts have limits that feel arbitrary. A record kept for performance is kept only as long as performance needs it, so prefetch caps at a fixed number of files, UserAssist counters reset, and Amcache entries age out on schedules Microsoft never documented.

The fourth row is the clearest example of the pattern. Remembering how you like a folder displayed requires the registry to remember that the folder existed, which means the ShellBag outlives the folder, and a directory deleted months ago is still listed there.

A registry key that outlived the folder it describes.

C:\> Import-Csv C:\out\shellbags.csv | Where {$_.AbsolutePath -match "Q2-restricted"} |
      Select AbsolutePath,LastInteracted

AbsolutePath                                    LastInteracted
C:\Users\jdoe\Documents\Q2-restricted          2026-06-08 17:36:44

C:\> Import-Csv C:\out\mft.csv |
      Where {$_.FileName -eq "Q2-restricted"} | Select InUse
InUse : False

  The registry remembers how jdoe liked that folder displayed.
  NTFS says the folder is gone.

Windows kept a record of a folder in order to reopen it the way the user left it, and that record survived the folder being deleted because the registry and NTFS are unrelated stores.

This is the whole principle in two commands. Nobody built ShellBags to prove a directory existed, and they do it anyway, which is what the rest of the course is made of.

There is a counting trap in that independence that arrives later in the course and is worth flagging now. The master file table and the change journal both describe NTFS metadata, so they are not as independent as the count of three suggests, and establishing which artifacts genuinely have separate origins is a piece of work in itself.

There is a consequence of that separation that shapes how findings get built. Because NTFS, the registry and the compatibility layer do not consult each other, agreement between them is meaningful: three artifacts saying the same thing is three Windows mechanisms independently arriving at it, rather than one fact copied three times.

There is a reason those three exist separately rather than as one record. NTFS needs the master file table to find files, needs the change journal so indexers and backup software can watch for changes without rescanning the volume, and Windows needs Amcache to remember binaries so compatibility checks are quick. Three different problems produced three different stores.

The Amcache entry carries a SHA1 hash, which neither the master file table nor the change journal does. That is the pattern to expect throughout: each artifact answers something the others cannot, and the answer to a real question is usually assembled from several.

An investigation is not a search across everything the machine holds. It is a question that selects which artifacts are relevant, answered in an order that narrows the ground with each step.

  QUESTION: did this account run an archiving tool on 8 June?

  1. Execution artifacts       did anything of that kind run
     -> prefetch, amcache, shimcache, userassist

  2. Filesystem artifacts      what did it touch
     -> $MFT, $J, and the directory it worked in

  3. Attribution artifacts     which account, from where
     -> userassist is per-user, and the logon records

  4. Corroboration             does an unrelated source agree
     -> SRUM for the process, and network usage for volume

C:\> Import-Csv C:\out\userassist.csv | Where {$_.ProgramName -match "7z"} |
      Select UserName,RunCount,LastExecuted
NORTHGATE\jdoe    1    2026-06-08 17:40:02

One question broken into four steps, then the step that names an account.

The order is deliberate. Establishing that something ran, from prefetch and Amcache, comes before establishing what it touched in the master file table, and both come before attributing it to an account from UserAssist, because each step narrows what the next one has to examine.

There is a case where the order legitimately inverts and it is worth knowing. Where an alert or a report supplies a specific filename, account or time, that is the question already narrowed for you and the master file table is the right first stop, and starting from it is correct rather than lazy. What the sequence protects against is starting from a search when nothing has narrowed the ground.

There is a discipline in that ordering that is easy to abandon under pressure. The tempting first move is to search for the filename somebody mentioned, which skips straight to the middle of the sequence and produces a result with no context around it, and rebuilding that context afterwards costs more than doing the steps in order.

There is a structure to these four steps that recurs through every module of this course. Execution artifacts, then NTFS, then registry attribution, then corroboration is the order the ten modules themselves follow, so the sequence here is a preview of the syllabus rather than only a method for one question.

There is a reason the question comes before the artifacts rather than after them. A workstation carries hundreds of thousands of artifact records, and examining them without a question produces a description of a computer rather than an answer, which is the commonest way an examination consumes a week and establishes nothing.

The last step is the one people skip. A finding resting on prefetch alone is a finding resting on one Windows component behaving as you expect, and this course asks for a second artifact throughout.

A finding from this work is a narrower sentence than most people want to write. Four things.

These four are the structure every finding in this course follows, and they are worth reading now rather than discovering in the reporting module. The habit is easier to build from the first artifact than to retrofit at the end of an examination.

The first row is narrower than most people write. A prefetch entry establishes that a binary executed and says nothing about who ran it or why, and the temptation is to write the interesting sentence rather than the supported one.

The third row will feel pedantic until the first time it matters. A shared workstation, a Windows service account, a session left logged in and an account whose password was known to somebody else all produce UserAssist and logon records naming an account that a person did not operate.

The fourth row is the habit this course builds throughout. Every module ends by asking what the evidence does not establish, because that question is where examinations are won and lost.

The user who stated they never ran the tool.

  THE POSITION: no application logging, no agent installed,
                security event log cleared at 17:52.

C:\> Import-Csv C:\out\prefetch.csv | Where {$_.ExecutableName -match "7Z"} |
      Select RunCount,LastRun
1    2026-06-08 17:40:02

C:\> Import-Csv C:\out\userassist.csv | Where {$_.ProgramName -match "7z"} |
      Select UserName,LastExecuted
NORTHGATE\jdoe    2026-06-08 17:40:02

C:\> Import-Csv C:\out\amcache.csv | Where {$_.Name -eq "7z.exe"} |
      Select SHA1
8814a41c82b4d5e04c1f8a92b6d70389e5c14b0a

C:\> Import-Csv C:\out\SrumEcmd_AppResourceUseInfo.csv |
      Where {$_.ExeInfo -match "7z"} | Select BytesRead
BytesRead : 641,204,880

The position as stated, then four components that were never told to record anything.

Four records of one execution, agreeing on the second, produced by the Windows prefetcher, the UserAssist registry key, the Amcache hive and the SRUM database. Clearing the security event log removed one source and had no effect on any of those four.

The same evidence written twice, once supported and once not.

  THE SUPPORTED SENTENCE
    7z.exe executed once on NGE-WKS-4471 at 17:40:02 on
    8 June 2026 under the security context NORTHGATE\jdoe.
    Prefetch (RunCount, LastRun), UserAssist (UserName,
    LastExecuted), Amcache (SHA1), SRUM (BytesRead).

  THE SENTENCE PEOPLE WRITE
    jdoe used 7-Zip to archive the pricing documents before
    exfiltrating them.

  The second adds: a person, a purpose, a set of files,
  and an outcome. The artifacts support none of the four.

Neither version is dishonest, which is what makes this worth a block rather than a warning. The second is what the examiner believed, and it may well be correct, and the difference is that the first is what the evidence establishes while the second is what somebody concluded from it. Reports fail when those two are written as one sentence.

The first version names its sources field by field, which is what lets somebody else check it. The second reads better and every additional word in it is unsupported.

The machine name in the first version is doing quiet work too. Everything these Windows artifacts establish is about one endpoint, so naming the machine keeps the claim where the evidence is rather than letting it become a statement about an account across an estate.

Four things were added rather than one, which is how this happens: a person for an account, a purpose for an execution, a set of files for a tool, and an outcome for all of it. Each felt reasonable on its own.

The limits written out alongside the findings, which is where every module ends.

  What the four artifacts DO establish
    a binary ran, once, at a time, on this machine
    under a named security context
    with a known hash

  What they do NOT establish, and what would
    who was at the keyboard        logon records, door
                                   badge, camera
    what it archived               the filesystem journal
                                   for that minute
    where the archive went         network usage, the
                                   proxy, the firewall
    whether anybody asked          nothing on this endpoint

Four established against four not is roughly the ratio to expect, which is worth knowing at the start of a course rather than discovering at the end of a case. An examination that answers half the questions put to it and is precise about which half is doing well.

The right-hand column is the part worth copying as a habit. Naming where an unanswered question would be answered turns a limitation into an instruction for whoever picks the work up.

The last row has no source on this endpoint at all, and saying so is the honest answer rather than a gap in the examination. Some questions are not answerable from a machine and a report that pretends otherwise is the one that fails.

There is a reason the four were chosen from different parts of the system rather than four execution artifacts. Four records of the same kind would be four readings of one mechanism, and the corroboration is worth something precisely because a fault or an omission in one of these has no effect on the other three.

There is a limit worth stating even in this worked read. Four artifacts agreeing establishes that the tool ran on this machine at that time under that account, and none of them establishes why or on whose instruction, which are questions this evidence does not reach.

There is a fifth source in that list worth pointing out because it is the least expected. Network usage is recorded per application by a component that exists to show users which programs use their battery and data, and it happens to record how much data each program moved.

The account name appears in only one of the four, which is worth noticing this early. Three of them establish that the tool ran on this machine and one establishes which security context ran it, and the distinction between those two statements runs through the whole course.

Forensic analysis on this platform works because Windows is built to be fast and convenient rather than forgettable. Making a program launch quickly means remembering that it launched before, and making software installation quick means keeping a cache of what has been installed. None of those records was created for an investigator, which is exactly what makes them valuable: nothing about them was curated, and nothing about them was written with the possibility of being read later in mind.

That is what separates this from log analysis. A log was written to be read, by somebody who decided its contents, its format and its retention, so its gaps are policy. An artifact is a side effect that records what one component of the operating system needed for its own purposes, which is frequently more specific than a log and occasionally far less complete. Logs are centralized and artifacts are scattered, so clearing a log is one operation against one place while removing the artifact trail of a single action means finding several stores maintained by components that do not coordinate with each other.

The work is a question that selects artifacts rather than a search across everything, answered in an order that narrows: whether something ran, then what it touched, then which account, then whether an unrelated source agrees. And the findings are narrower than people expect. An execution record establishes that a binary ran and says nothing about who ran it or why. Artifacts record security contexts rather than people. Every finding names the artifact and the field it came from so somebody else can check it, and says what would overturn it, which is what makes it something a reader can evaluate rather than something they have to accept.