0.6 Ground Truth and Checking Your Work

Introduction

A real investigation has no answer key: you never learn for certain whether the timeline you built is what happened. This course does have one, because you planted the case yourself, and the lab pack writes down every step it carried out and when.

This lesson explains that ground-truth file, when to open it and when not to, and how the exercises are marked, so that you can check your own work honestly.

By the end of this lesson you can:

• Read a line of the ground-truth file and say what each field records.
• Explain when to open the ground truth during an exercise, and why not before.
• Compare an artifact time and an account with the ground truth, allowing for the artifacts that are written later.
• Mark an exercise against its acceptance criteria, and work out why a result differs from the model answer.

When you analyze a real machine, the evidence is all there is. You reconstruct what happened from what Windows recorded, and the quality of the reconstruction depends on how well you read the artifacts and how honestly you state their limits. Nobody tells you afterwards whether you were right. That is the condition the course prepares you for, and most of the time you will work under it.

But learning needs feedback, and a timeline you cannot check teaches you less than one you can. Because you run the case yourself, the course can tell you exactly what happened on each host: which step ran, when, under which account, and what it created.

That record is the ground truth, and it turns every exercise into one you can check against fact rather than against the course's reading of its own reference run.

The rest of this lesson is about using it in that order. A ground truth read too early becomes a list of answers, and the skill the course is teaching, finding the trace each action left, never gets practiced.

There is a second reason to wait. Ground truth is exact and evidence rarely is: an artifact may record a time to the second or only to the day, may survive or may have been overwritten, may say a program existed without saying it ran.

Working from the evidence first teaches you to say how sure you are and why. Reading the ground truth first teaches you to look for confirmation, which is the habit that makes real investigators overstate their findings.

Each host has its own ground-truth file, written by the lab pack as the run goes. The format is JSON Lines: one complete JSON object per line, one line per step, appended in the order the steps ran.

Every line has the same six fields, so you can read it by eye, open it in Timeline Explorer, or load it with a few lines of PowerShell. On WS-114, signed in as labadmin once the user activity has finished, the first line reads back like this:

PS C:\> $gt = 'C:\NGE-Lab\ground-truth\ground-truth-NGE-WS-114.jsonl'
PS C:\> Get-Content $gt -TotalCount 1 | ConvertFrom-Json | fl step, host, user, action

step   : 1.1
host   : NGE-WS-114
user   : labadmin
action : Renamed computer, created l.brennan, staged dllhost32.exe and update.dat

The record below is an example from step 1.8 on WS-114, where the user activity writes a text file naming adm.kashworth and then deletes it. In the file it is one line; here it is set out over several so it fits the page.

{
  "step": "1.8",
  "utc": "2026-11-03T14:22:41.318Z",
  "host": "NGE-WS-114",
  "user": "l.brennan",
  "action": "Wrote creds.txt naming adm.kashworth, then deleted it",
  "values": {
    "path": "C:\\Users\\Public\\Libraries\\creds.txt",
    "names": "adm.kashworth"
  }
}

Your file will hold the same step, host, user, action and values, and a different time, because the time is when you ran it. The backslashes in the path are doubled because that is how JSON writes a backslash inside a string; any JSON reader turns them back into single ones.

The values field is the useful part when an exercise turns on a detail. For the payload it records the file hashes; for the archive it records the path and hash; for the payload runs it records each run's number.

Because each line is a self-contained JSON object, PowerShell's ConvertFrom-Json reads one line at a time, and a one-line loop over Get-Content gives you the whole run as objects you can sort and filter. You will not need that in Module 0, but it is how you will line your timeline up against the ground truth in Module 9, when a check covers a whole host rather than one step.

The ground-truth files are written to C:\NGE-Lab\ground-truth on the VM, one per host. That folder sits outside every path the course's KAPE collections take, so the files never appear in your evidence.

This is deliberate: the collection holds only what Windows recorded, exactly as a real collection would, and the answer key stays separate from the material you analyze. On WS-114 the folder holds the host's file and the marker the lab pack writes when the user activity finishes:

PS C:\> (Get-ChildItem C:\NGE-Lab\ground-truth).Name
ground-truth-NGE-WS-114.jsonl
user-done-NGE-WS-114.txt

The consequence is the step from 0.5: when a host is finished, you copy its ground-truth file onto the evidence drive yourself, beside that host's collection, before you revert. A revert without that copy loses your record of when each step ran. You can still work the exercises, but every check that turns on time would have to fall back on the reference run's times, which are not yours.

Copy the file, do not move it, and do not open it as you copy it. A quick look at the file before you have analyzed a host spends the very thing that makes the exercise worth doing.

If you would rather not risk it, rename the copy on the evidence drive to something you will not open by accident, such as answers-NGE-WS-114.jsonl, and keep it in its own subfolder beside the collection. The name makes its purpose plain whenever you come across it, and the folder keeps it out of the way when you browse the collection.

Open the ground truth when a model answer tells you to, and at no other point in an exercise. The model answer will say which of your findings to compare with which step: for example, the time you established for the payload's first run against the step that launched it. That is the moment the ground truth is useful, because you already have your own answer to check.

There is one other legitimate use. During Module 2, if you lose track of where a run has reached, the last line of the file shows the most recent step that completed, which tells you what the script will do when you run it next. That is checking the run, not the investigation, and it gives nothing away.

Using it as a checklist is the failure to avoid. It tells you what was done; it does not tell you where Windows recorded it or which artifact would show it, and those are what the course is teaching.

If you find yourself wanting to look because you are stuck, go back to the lesson the exercise draws on instead. Each exercise is built from the module's lessons, and the artifact you need is one of the ones those lessons taught. Being stuck and then finding the record yourself is worth far more than being told where it is.

Every student's evidence differs in its timestamps and identifiers, so a model answer cannot say "the payload first ran at 14:22:41." What it can say is what the scripts guarantee: which file exists and where, which registry value holds what, how many times a program ran, which event came before which, which account did it. Those are the same in everyone's run, and they are what the model answers check.

Where a question turns on time, the model answer says how to check your answer against your own ground truth instead. The reference run's output is still shown, because seeing the shape of correct output, its columns, its rows, where the important value sits, is how you recognize your own. Just never copy a time or an identifier from it into an answer about your evidence.

If an exercise asks for a time and you give the reference run's, the answer is wrong even if it matches the page, because it is not what your evidence shows. The same applies to identifiers.

Your adm.kashworth has its own SID on each host, your file system its own entry numbers, your USB stick or virtual disk its own serial number. An answer quoting the reference run's values describes a machine you have never examined.

Comparing a time from an artifact with the ground truth is not always a matter of matching to the second. Some artifacts record the moment of the action: a file the step created has file system timestamps within a second or two of the step's time, and an event the step caused is logged as it happens.

Others are written later by design, and their times describe the writing, not the action. The reference case shows all three kinds for one program. Its inventory scan ran at 23:02 that night, so its Amcache time is hours after the run rather than the few minutes you will see in the lab.

The clearest cases are the two from 0.5. Amcache entries are made when the inventory scan runs, which in the lab is a few minutes after the activity, and ShimCache is written to the registry at the restart. So an Amcache time later than the program's run is expected, and teaches you something about the artifact.

ShimCache's earlier time is not an exception, because it is the file's own modified time, carried over from the copy of whoami.exe it was made from, and not a record of anything the step did.

An artifact time that does claim to record the action, and is earlier than the step, is different: that should not happen, and when it does, it is a finding, as the back-dated archive on FS-01 is in Module 4. Scale matters too.

A difference of a second or two between the ground truth and a file system time is the gap between PowerShell recording the step and Windows completing it. A difference of minutes for an artifact that should be immediate means you have the wrong record, or the step ran more than once.

Always compare in UTC. The ground truth is in UTC; some tools and views show local time, and a one-hour difference is far more often a time zone than an error.

The ground truth's user field shows which account each step ran under, and it separates two kinds of activity you will meet throughout the evidence. Steps carried out in a case user's session show that user: l.brennan for the WS-114 activity, adm.kashworth for the WS-031 activity.

Steps carried out by Deploy-Case itself show your own account, because you ran the script. Read the user field from every line of the WS-114 file and both kinds appear:

PS C:\> $gt = 'C:\NGE-Lab\ground-truth\ground-truth-NGE-WS-114.jsonl'
PS C:\> (Get-Content $gt | ConvertFrom-Json).user | Sort-Object -Unique
l.brennan
labadmin

The same split runs through the collections. Your account appears as the administrator who signed in, ran the scripts and ran KAPE, and that activity belongs to the lab, not to the intruder.

Recognizing it and setting it aside, with a sentence saying so, is the same discipline as setting aside a responder's activity on a real machine. The one exception is FS-01, where the script uses adm.kashworth's credentials to reach the share, so that access is the case's even though your account started it.

The ground truth makes this easy to confirm: if a step's user field shows your account, the action belongs to the lab's setup, unless the model answer says otherwise. In your own investigations this distinction never comes so cleanly.

Responders sign in, run tools and copy files, and their activity sits in the same logs as the intruder's. Learning to account for your own account here, where you know exactly what it did, is practice for accounting for a colleague's on a real host, where you will have to ask.

The ground truth records what the script did. It does not record what Windows wrote as a result: it lists no artifacts, no registry paths, no event IDs, no Prefetch file names.

A line saying a shortcut was launched through the shell does not tell you that the launch created a shortcut in the Recent folder, updated a registry value, wrote a Prefetch file and added a jump list entry. Finding those is the investigation.

It also says nothing about everything else that happened on the machine. Windows does a great deal on its own: updates, Defender scans, maintenance tasks, the inventory scan. The lab adds its own activity, from your sign-ins to the restarts, and KAPE leaves traces of its own collection.

None of that is in the ground truth and all of it is in the evidence, which is realistic: every real collection is mostly ordinary activity with the incident somewhere inside it.

The reference run has the same kinds of noise at different times, so do not expect your collection's unrelated rows to match the page. Learning to recognize ordinary activity quickly is a large part of getting fast at this work.

By the end of the course you should be able to look at a list of Prefetch files or scheduled tasks on a Windows 11 machine and see at once which belong to Windows and which do not, and the noise in your own collections is where you learn that.

Each module ends with an exercise, and each exercise is marked against acceptance criteria rather than a single right answer. The criteria say what a complete answer does: names the artifact, gives the evidence, states the time in UTC, says what the evidence cannot show. You mark each one against your own answer as Met, Partly or Not met.

As you mark each criterion, the page shows how the model answer meets it and where answers most often fall short. When every criterion is marked, the model answer opens.

The order is deliberate: you judge your own work first, against the standard, before seeing anyone else's. Reading the model first and then marking turns the criteria into a comparison with the model rather than a judgment of your own reasoning.

The model answer is not the only acceptable answer. An answer that meets every criterion by a different route is a good answer. Investigators often reach the same finding from different artifacts: one shows a program ran from Prefetch, another from Amcache, a third from an event log.

Where the criteria allow it, the feedback says which other routes would also have met them, so you can see how the evidence overlaps and which route is strongest when you can only take one.

The marking is for you, and it only helps if it is strict. A criterion half met is Partly, not Met. A conclusion that happens to be right but is not supported by evidence you can point to is Partly at best, because in a real report an unsupported conclusion is a liability, however accurate it turns out to be.

Partly and Not met are useful marks, not failures. They point to exactly what to go back to: the artifact you did not check, the time you did not convert, the limit you did not state.

The habit you are building is the one a reviewer applies to a real report, asking of each finding what supports it and what would change it, and applying it to your own work first is how you get good at it.

Keep your marks in your case notes. By Module 10 they show which kinds of evidence you read confidently and which you still need to check twice.

Sometimes your answer will differ from the model's and you will be sure it is right. Before deciding the model is wrong, work through four places a difference can come from, in order, because the first three are far more common than the fourth.

Most differences are in the reading: the wrong output file, a column misread, a time left in local time. The next most common is processing: a module that failed or skipped an artifact, which its log will say. Then the run: a step that did not complete, ran twice or ran out of order, which the ground truth shows.

Only when all three check out is the difference likely to be Windows behaving differently on your build, and that is worth noting, because it is exactly the kind of variation real investigators have to account for.

If you do find a genuine difference in how Windows recorded something, write it down with the build number. It is a finding about the artifact, and those are worth more than any single answer.

Investigators keep notes as they work, because a finding not written down with its evidence is one you will have to establish again when you write the report. The course asks the same of you. Keep a notes file for each host on the evidence drive, and add to it in every exercise: what you found, where, when and how sure you are.

# NGE-WS-114  (E:\Cases\NGE-WS-114\notes.md)

## F1  ngsync.exe ran three times from C:\Users\Public\Libraries
Evidence:    PECmd, the NGSYNC.EXE Prefetch file, run times 1 to 3
             (output in E:\Cases\NGE-WS-114\processed)
Time:        first run 2026-03-10 09:13:00 UTC, from Prefetch
Confidence:  high; Amcache and SRUM agree that it existed and ran
Gaps:        Prefetch does not record who ran it; SRUM puts it under l.brennan,
             so check her session

The notes are not a formality. Module 9 builds a single timeline across the hosts from them, and Module 10's capstone is a report on the whole intrusion written from them. A finding recorded with its artifact, tool, output file and time can go straight into either; a finding recorded as "the payload ran three times" sends you back to the evidence to find out how you knew.

Record gaps too. What you could not establish, and why, belongs in the report as much as what you could.

Practice

Two pieces of practice. The first is the comparison a model answer will send you to make: the reference run's ground truth for WS-114 beside eleven artifact times from its collection. Decide which times record the action, which are written later by design, and which are not the case at all.

The second sets up the notes you will keep for the rest of the course.

Check your understanding

Answer each question before you read on. Every option explains itself once you choose it, the wrong ones too.

Files this lesson draws on

The ground-truth format is defined in the lab pack's NGE-Case.common.ps1 (the Write-GT function), and each step it records is described in Deploy-Case.ps1 and Invoke-UserActivity.ps1. All three are in the lab pack on your evidence drive.