0.5 Running the Case

Introduction

The evidence you analyze in this course comes from a case you plant yourself. The lab pack is a set of PowerShell scripts that turn the course VM into each of Northgate Engineering's three Windows hosts in turn, carrying out the intrusion on each so that the artifacts are real: written by Windows, in the places Windows writes them.

This lesson explains how the runs work, what you do during each, and why they happen when they do. You will play the hosts in Module 2.

By the end of this lesson you can:

• Describe what the lab pack does and which script you run for each part of a host.
• Explain when each host is played and why it is collected before the VM is reverted.
• Carry out each host's run, including the parts that happen in a case user's session.
• State how your evidence will differ from the course's reference output, and where the lab differs from the case.

The lab pack is four PowerShell scripts and two asset files in a single download. One script plants a host, one carries out the steps that must happen inside a case user's own session, one holds the names and helpers the other two share, and one removes the case if you have no snapshot to revert to.

The assets are the decoy remittance PDF Laura Brennan opens and the archive later copied to removable media.

Listed from the evidence drive, the pack holds seven files:

PS C:\> (Get-ChildItem E:\kape-ez-tools-lab-pack -Recurse -File).Name
Deploy-Case.ps1
Invoke-UserActivity.ps1
NGE-Case.common.ps1
README.md
Reset-Case.ps1
Q1_designs.tar
Remittance_Advice_0310.pdf

Nothing in the pack is malware. The attacker's tools in the case are copies of programs that ship with Windows, renamed: the shortcut launches a renamed cmd.exe, the payload is a renamed whoami.exe, and the archiver on the file server is a renamed tar.exe.

That is how the case stays harmless while producing the same evidence a real intrusion would: a program running from an unusual folder under an unusual name is exactly what the execution artifacts in Module 5 record.

You can read every line of the scripts before you run them, and you should. They are written to be read, with a comment on each step naming the case timeline step it carries out, so the script is also a record of what happened on each host.

When a later lesson asks why a particular record exists, the answer is always a step you can find in the script and in the case timeline. Reading the script is not cheating: an investigator never has the attacker's script, but a student who knows what was done can concentrate on learning where each action left its trace, which is the skill the course is teaching.

You play the hosts in Module 2's exercise, not now. The reason is the snapshot cycle from 0.4: one VM plays three hosts by reverting to clean between them, and reverting throws away everything on the VM's disk. Each host therefore has to be collected with KAPE before the VM is reverted for the next one, and KAPE is installed in Module 1 and taught in Module 2.

So the order through the start of the course is fixed. In this module you get the pack onto the evidence drive and learn what the runs do. In Module 1 you install KAPE and the EZ Tools onto the evidence drive.

In Module 2's exercise you play WS-114 and collect it with gkape, KAPE's graphical front end, then revert and play WS-031 and collect it from the command line, then revert and do the same for FS-01. From Module 3 onward you work from those three collections.

After Module 2 you only need the VM again if a collection turns out to be incomplete, in which case you revert, play that host again and collect it again. Keep the three collections and their ground-truth files together on the evidence drive for the whole course, one folder per host.

Every exercise from Module 3 to the capstone report reads them, and losing one means replaying that host, which costs an hour or two and gives you a collection with different times from the one your earlier notes describe.

Download the pack on your own computer, then copy it onto the evidence drive, so the VM can reach it after every revert. If your evidence drive is a shared folder, extract the pack into it from your computer.

If it is a second virtual disk, copy the pack in once, by a host-to-guest copy or a temporary shared folder, then put the setting back the way 0.4 left it. Either way the pack lives on the evidence drive, not the VM's own disk, so a revert does not remove it.

When Deploy-Case runs, it copies the pack to C:\NGE-Lab\pack inside the VM, because the scripts that run in a case user's session need it at a path every account can reach. That copy is on the VM's own disk and disappears with the revert, which is intended: each host starts with a fresh copy taken from the evidence drive.

Do not unblock or change the scripts to make them run. The command in the next section runs them as they are, and a script you have edited no longer produces the evidence the course's reference output and model answers describe.

Every run starts the same way. Sign in to the VM with your own account, open PowerShell as administrator, change to the pack's folder on the evidence drive and run Deploy-Case.ps1 with the host you are playing. The script checks that it is running as administrator and on a virtual machine, and stops if either is not true.

PS E:\kape-ez-tools-lab-pack> powershell -ExecutionPolicy Bypass -File .\Deploy-Case.ps1 -CaseHost NGE-WS-114

=== Next ===
  The VM restarts now as NGE-WS-114.
  After it restarts, sign in as l.brennan (password NGE-Lab-2026!).
  In that session open PowerShell (not as administrator) and run:
    powershell -ExecutionPolicy Bypass `
      -File C:\NGE-Lab\pack\Invoke-UserActivity.ps1 -CaseHost NGE-WS-114

The -ExecutionPolicy Bypass on the command line lets this one PowerShell process run the unsigned script without changing the machine's execution policy, which a case host would not have changed.

The -CaseHost parameter takes one of the three host names, and the script tells you what to do next in a block headed Next at the end of each stage. Read that block every time before the VM restarts: it is the only place the script tells you what it expects of you before the next stage.

If you miss the message, run the same command again after the restart. The script works out where it stopped and repeats the instructions for that stage.

The stage you are on is also recorded in the ground-truth file as each step completes, so if you lose track entirely, the last line of that file tells you which step ran most recently. You can open it to check progress without spoiling anything, because it records what the script did rather than what the investigation should conclude.

Each host takes several stages, with a restart between most of them, because some of the evidence is only written at a restart and some of the activity has to happen in a different account's session. You do not choose the stage. After each restart you run exactly the same Deploy-Case command again, and the script carries on from where it stopped.

After the first stage on WS-114 and its restart, the state file holds the stage the run has reached:

PS C:\> Get-Content C:\NGE-Lab\state-NGE-WS-114.txt
1

The script keeps track with a small state file for each host in C:\NGE-Lab. That is also how it protects the snapshot cycle.

If you start a run for one host on a VM that has already played another, it finds the other host's state file and refuses, with a message telling you to revert to the clean snapshot first. Two hosts' evidence on one disk would make every exercise that reads that collection unreliable.

If a stage is waiting on something you have not done yet, such as the user activity, it says so and stops without changing anything, so running the command early does no harm.

The first run plays Laura Brennan's finance workstation. The first stage renames the VM to NGE-WS-114, creates her account, makes sure Prefetch is recording, places the attacker's files and restarts. You then sign in as l.brennan and run Invoke-UserActivity.ps1 in her session, in an ordinary PowerShell window, not as administrator, because a standard user's actions are what the case needs.

PS E:\kape-ez-tools-lab-pack> powershell -ExecutionPolicy Bypass -File .\Deploy-Case.ps1 -CaseHost NGE-WS-114

PS C:\Users\l.brennan> powershell -ExecutionPolicy Bypass -File C:\NGE-Lab\pack\Invoke-UserActivity.ps1 -CaseHost NGE-WS-114

PS E:\kape-ez-tools-lab-pack> powershell -ExecutionPolicy Bypass -File .\Deploy-Case.ps1 -CaseHost NGE-WS-114

The user activity is where the intrusion happens. It creates her Downloads\Supplier folder with the remittance shortcut and decoy PDF, marked as downloaded from the internet, opens the folder in Explorer, launches the shortcut the way a double-click would, runs the payload twice more, then writes and deletes the inert credentials note.

When it finishes you sign out, sign back in with your own account and run Deploy-Case again, which runs the inventory scan and restarts. One more run of the command after that tells you the host is planted.

The script tells you to collect this host with gkape. That is the first part of Module 2's exercise. Do not sign in as l.brennan again after the user activity has finished. Each sign-in adds logon events and profile activity to her account, and the model answers describe one interactive session, the one in which she opened the remittance.

If you sign in again by mistake, the evidence is still usable, but your logon counts will not match and you should note why.

The second run plays Kieran Ashworth's IT administrator workstation, and it is the one where you do the most. Revert to clean first. The first stage renames the VM, creates k.ashworth and adm.kashworth, enables Remote Desktop and sets up the Engineering share the intruder browses.

After the restart you connect to the VM over Remote Desktop from your own computer, signing in as adm.kashworth, because the case's intruder reached this host over RDP with that account.

PS E:\kape-ez-tools-lab-pack> powershell -ExecutionPolicy Bypass -File .\Deploy-Case.ps1 -CaseHost NGE-WS-031

PS C:\Users\you> mstsc /v:<VM address>

PS C:\Windows\system32> powershell -ExecutionPolicy Bypass -File C:\NGE-Lab\pack\Invoke-UserActivity.ps1 -CaseHost NGE-WS-031

PS E:\kape-ez-tools-lab-pack> powershell -ExecutionPolicy Bypass -File .\Deploy-Case.ps1 -CaseHost NGE-WS-031

That connection is what makes the remote access evidence real: the logon records, the RDP session events, the profile created at the first remote session.

Inside the RDP session you run the user activity as administrator, which plants the Run value, the scheduled task and the service, browses the share, and copies the archive to removable media. If you have a USB stick, pass it through to the VM before that step; if not, the script uses a virtual disk instead.

When the activity finishes, sign out of the RDP session, sign in at the VM with your own account and run Deploy-Case twice more, once before and once after its restart. If the Remote Desktop connection fails, the cause is almost always the network from 0.4: your computer cannot reach the VM's address.

Check it from your computer before suspecting the script, which has already enabled Remote Desktop and allowed adm.kashworth to use it. Do not connect from inside the VM to itself as a shortcut, because a connection that never leaves the machine does not produce the evidence the case describes.

The third run plays the engineering file server, and you do the least. Revert to clean again. The first stage renames the VM, creates adm.kashworth, creates and seeds the Engineering share with the design files, turns on share auditing and restarts. When you run the command again, the script carries out the whole of the intruder's work on the server in one stage.

The first stage ends by telling you what comes next, as every stage does:

PS E:\kape-ez-tools-lab-pack> powershell -ExecutionPolicy Bypass -File .\Deploy-Case.ps1 -CaseHost NGE-FS-01

=== Next ===
  The VM restarts now as NGE-FS-01.
  Sign in with your own admin account and run this command again.

That stage maps the share with adm.kashworth's credentials, drops the renamed archiver into C:\Windows\Temp, copies twelve design files into a staging folder and renames them, archives them, deletes the staging folder, sets the archive's timestamps back, and clears the Windows PowerShell event log.

You do not sign in as a case user at any point, because on the file server the intruder never had an interactive session: everything arrived over the network with a stolen account.

After the inventory scan and a final restart, the script tells you to collect the host from the command line. That is the last collection of Module 2's exercise.

The restarts are not housekeeping. Two of the execution artifacts the course examines are not written at the moment a program runs. Amcache is populated by the Microsoft Compatibility Appraiser, a scheduled task that inventories programs on the machine, and on a real host it runs on its own schedule. ShimCache entries are held in memory and written to the SYSTEM hive when Windows shuts down.

So at the end of each host's activity the script runs the Appraiser itself and then restarts, which writes ShimCache. Without those two steps, a collection taken straight after the activity would be missing entries an investigator would find on a real machine that had been running for a while.

The restarts also make the computer rename take effect, and a case user's first sign-in creates the profile that holds their own registry hive.

This timing is itself evidence, and Module 5 teaches it: an entry's time in one of these artifacts can describe when it was written rather than when the program ran.

The script creates the case's accounts on each host as local accounts. In the case they are accounts in the NORTHGATE domain; in your lab there is no domain, so each host gets its own local copy of the accounts it needs. That is why adm.kashworth on WS-031 and adm.kashworth on FS-01 in your evidence have different security identifiers, which 0.3 explained.

On WS-031, both of Kieran Ashworth's accounts exist with the names and full names the case gives them:

PS C:\> Get-LocalUser -Name k.ashworth, adm.kashworth | Format-Table Name, FullName

Name          FullName
----          --------
k.ashworth    Kieran Ashworth
adm.kashworth Kieran Ashworth (admin)

Every case account has the same lab password, printed by the script when you need it. It exists so you can sign in and connect over RDP as the case users, and it should never be used anywhere outside the course VM. Your own account, the one you installed Windows with, stays on each host alongside the case accounts and is the one you run Deploy-Case and KAPE from.

You will see your own account in the collections too, as the administrator who ran the scripts and the collection. That is expected, and 0.6 explains how to tell it apart from the case. Choosing a plain name for your own account at installation pays off here.

An account called labadmin or student is easy to set aside when you read a list of profiles or logons; an account named after you puts your name in every finding you write, which is the problem 0.4 set out to avoid.

The course shows expected output from a reference run of the same scripts on clean VMs. Your output will match it in structure and differ in detail. Every timestamp is the time you ran the step, every SID is generated by your VM, and file system details such as entry numbers and volume serials depend on your disk.

The exercises are written around what does not differ: which files, keys, tasks, services and accounts exist, how many times a program ran, which event came before which. Where a question turns on time, the model answer tells you to check your own run's times in the ground-truth file the script writes.

There is also one ordering difference to keep in mind. In your lab the hosts happen in the order you play them, WS-114, then WS-031, then FS-01, while in the case the archive on FS-01 was made before it was copied to USB on WS-031.

Module 9, which builds one timeline across the hosts, comes back to that ordering difference and how to read it.

A lab built from one Windows 11 VM cannot reproduce every detail of a company network, and the course says where it does not rather than pretend. There are four places, and each lesson affected states the difference where it matters.

On WS-031 the Engineering share is on the VM itself, named to look like the file server, so browsing it writes a genuine network path into the ShellBags while the server-side session records exist only in the case.

FS-01 runs on Windows 11 rather than Windows Server, which matters for Prefetch: Windows 11 normally records it, Server has it off by default, and the script makes sure it is on for the hosts that need it. Removable media evidence from a virtual disk lacks some of the records a real USB stick leaves. And the domain controller is not built at all.

None of these changes what the exercises ask. They change which records you will find in your own collections, and the lessons name the records each time. Treat these limits the way you would treat the limits of any real collection.

Investigators rarely get every artifact they want: a log has rolled over, a machine was rebuilt, a disk was encrypted. Stating plainly what the evidence cannot show, and why, is part of writing a finding that holds up, and Module 9 makes that a habit.

When the script says a host is planted, three things happen in a fixed order. Collect the host with KAPE to the evidence drive, as Module 2's exercise describes. Copy the ground-truth file for that host from C:\NGE-Lab\ground-truth onto the evidence drive beside the collection. Then revert the VM to the clean snapshot.

The order matters because the revert is irreversible. If you revert before collecting, the host's evidence is gone and the run has to be done again. If you revert before copying the ground-truth file, you lose your own record of when each step happened, which several exercises rely on.

The ground-truth folder is deliberately outside the paths the course's KAPE collections take, so it never appears in your evidence, which is why it has to be copied separately.

0.6 explains what is in the ground-truth file and when to open it.

Practice

Get the lab pack ready for Module 2.

Check your understanding

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

Resources

The lab pack's README.md and the comment help in Deploy-Case.ps1 (Get-Help .\Deploy-Case.ps1 -Full) describe the same runs in brief.