0.3 The Hosts and the People

Introduction

An intrusion that starts on one machine rarely stays there. An attacker who gets a foothold on a workstation looks for a way to somewhere more useful, and the evidence of each step is left on the machine where the step happened.

The Northgate Engineering case crosses four Windows hosts. This lesson introduces each of them, the people who use them and the accounts those people hold, so that when a name or an address appears in a log you know whether it belongs there.

By the end of this lesson you can:

• Describe each of the four hosts, its role and the user it belongs to.
• Name every account in the case and the hosts it should and should not appear on.
• Identify an account in Windows evidence by its name, domain, SID and profile.
• State how the lab differs from the case and what that changes in the evidence you will see.

Windows records what happens on a machine on that machine. A program that runs on the finance workstation leaves its execution record on the finance workstation; a logon to the file server is recorded by the file server; a scheduled task created on the administrator's workstation lives in that workstation's task store.

No single machine holds the story of an attack that crossed several, so an investigation that collects one host can only answer questions about that host.

That is why the case is built across four hosts, and why the course teaches you to collect, process and read several collections the same way. The skill being practiced is not only reading an artifact; it is noticing when the answer to a question on one host lies on another.

An RDP logon recorded on the administrator's workstation names a source address. That address belongs to a host, and that host is where the next question is asked.

In practice, investigators often start with the host somebody reported and widen the collection as each artifact points somewhere new. The case gives you all four from the start so that you can practice following those pointers.

NGE-WS-114 is the workstation Laura Brennan uses in Accounts Payable. It is a standard Windows 11 machine, and Laura signs in with a standard user account, l.brennan, which cannot install software or change system settings. Her work is supplier payments, so documents arriving from outside the company are part of her day, which is exactly why a disguised supplier document is aimed at someone in her role.

Laura's machine is also typical of the hosts attackers target first: it belongs to someone whose job is to open what arrives, and it is ordinary enough that nobody watches it closely. The machine matters to the case because it is where the "broken PDF" was opened.

Whatever happened at that moment, any program that ran, any file that was created, any trace of the shortcut being opened, will be recorded here and nowhere else. You will collect it with gkape, KAPE's graphical front end, in the first of Module 2's collections, because a first responder in an office often has a single machine and a few minutes, and gkape is how many of them run KAPE.

A standard user account limits what a program it runs can do without elevation. Keep that in mind: whatever ran on WS-114 ran with Laura's rights unless it found a way to get more.

NGE-WS-031 is Kieran Ashworth's workstation in IT Operations. Kieran has two accounts, which is good practice in an IT team: k.ashworth, a standard account for email and everyday work, and adm.kashworth, an administrator account he is meant to use only for administration. Remote Desktop is enabled on this machine because administrators connect to it and from it to manage other systems.

This is where Tom Hale found the scheduled task and the NGUpdate service. Creating a scheduled task under the Microsoft folder or a service needs administrator rights, so whoever created them was working with an administrator's token on this machine.

That makes the question of which account, and from where, central to this host's evidence. You will collect it from the command line, which is how KAPE is run when the collection has to be repeated exactly or scripted.

Kieran's two accounts are a detail worth holding on to. If adm.kashworth appears somewhere Kieran would never use it, or at a time he was demonstrably elsewhere, that is a lead about the account, not about the man.

NGE-FS-01 is the engineering file server. Its Engineering share holds the design files: drawings, models, specifications and test reports for Northgate Engineering's projects. Engineers reach it over the network from their workstations, and administrators sign in to maintain it. Neither report mentions it.

In your lab, once you have played FS-01, the share and its forty seeded files sit on the VM's C: drive:

PS C:\> (Get-SmbShare -Name Engineering).Path
C:\Shares\Engineering
PS C:\> (Get-ChildItem C:\Shares\Engineering -File).Count
40

That silence is a reason to collect it, not a reason to leave it out. If the attacker's interest was the design files, this is where they would have gone, and the file system here is where staging, renaming, archiving and deletion would leave their traces.

In Northgate Engineering's estate FS-01 runs Windows Server 2022, and one Server default matters for the evidence: Prefetch, the execution record you will meet in Module 5, is off by default on Server. In your lab the file server is played by the Windows 11 VM, where Prefetch is on, and Module 5 shows you both.

The share is also where network evidence starts: an account opening it from another machine is recorded as a network logon on the server, with the address it came from.

NGE-DC-01 is the domain controller. In Northgate Engineering's estate, every account is a domain account, and every time one is used to sign in anywhere, the domain controller is asked to verify it. That makes the domain controller's Security log the one place where the logons of every host meet: which account asked for access, to which machine, from which address, and whether it succeeded.

A domain controller is collected differently from a workstation. You rarely take its whole file system; you take its event logs and registry, because those hold what an investigation needs from it and the rest is the directory itself.

In your lab there is no domain controller, because a Windows 11 VM cannot be one, so the course shows you a domain controller collection and its output in Modules 2 and 7, and the exercises that use it are answered from the page.

When you reach Module 7 you will see how a logon on the administrator's workstation and a request recorded on the domain controller describe the same event from two sides.

Which account did something decides where the evidence of it is kept, and that is worth understanding before you open any collection. Every Windows account has its own registry hive, NTUSER.DAT, in its profile folder, plus a second per-user hive, UsrClass.dat.

Settings and activity that belong to a user, such as the programs that start when that user signs in, the folders they opened in Explorer and the documents they used recently, are written there. Settings that belong to the machine, such as services, system-wide scheduled tasks and installed drivers, are written to the machine's own hives under C:\Windows\System32\config, and changing them needs administrator rights.

That split tells you something before you have read a single value. A Run value in a user's hive is evidence about that user's sessions and was created by something running as that user. A service is evidence about the machine and was created by something running with administrator rights.

On WS-031, Tom Hale found both kinds of object: a scheduled task in the system task store and a service in the machine's configuration. Whoever made them had an administrator's token, and if a per-user Run value turns up as well, its hive names the account.

Windows also limits an administrator's own rights until they ask for more. When an administrator signs in, User Account Control gives their programs a standard token by default, and a program has to be elevated, usually through a consent prompt, to use full administrator rights.

In practice this means an administrator account doing administrator things leaves traces of elevation, and a standard account cannot create a service at all without first finding a way to an administrator's credentials.

You will see this split again in Module 6, where the same persistence technique is read from a user's hive on one host and from the machine's configuration on another.

Remote Desktop is enabled on NGE-WS-031 because IT administrators connect to their workstations and from them to the systems they manage. An RDP connection is a full interactive session on the target machine, started from another one.

The target records it as a remote interactive logon, with the account that signed in and the address the connection came from, and if it is the account's first session on that host, Windows creates a profile folder for it.

On WS-031 in your lab, the lab pack puts adm.kashworth in the Remote Desktop Users group, and the account's first Remote Desktop session creates its profile and hive:

PS C:\> (Get-LocalGroupMember -SID S-1-5-32-555).Name
NGE-WS-031\adm.kashworth
PS C:\> Test-Path C:\Users\adm.kashworth\NTUSER.DAT
True

That makes RDP evidence on WS-031 one of the most direct ways to connect the two reports. If an account signed in to WS-031 over Remote Desktop, the logon records will name the source address, and the address will belong to one of the hosts on the map.

The session itself also leaves traces in the account's hive and in Windows' own Remote Desktop logs, which Module 7 reads. And because an RDP session is interactive, anything done in it, opening folders, running tools, creating tasks, is recorded as that account's activity on that host.

In your lab you will make that connection yourself: when you play WS-031, you connect to the VM from your own computer over Remote Desktop with the case account. The records Windows writes are the real ones, which is the reason the lab is built that way rather than simulating the session.

Keep the RDP setting itself in mind too. Whether Remote Desktop was enabled, and since when, is a registry value, and an attacker who needs RDP and finds it disabled will often turn it on.

Four people matter to the case, and their accounts are the names you will see throughout the evidence. Priya Raman and Tom Hale are not users of the case hosts; they appear in the case as the person who commissioned the investigation and the person who found the task. Laura Brennan and Kieran Ashworth are the users of the two workstations.

An investigator builds an expectation for each account: where it should be used, at what times, for what. Laura's account belongs on WS-114 during working hours. Kieran's standard account belongs on WS-031. His admin account belongs on the hosts he administers, including the file server, and should appear on WS-031 when he sits down to do admin work.

The value of the expectation is that it makes the unexpected visible. An admin account signing in to a workstation from a finance clerk's machine is not something any of these people would normally do.

None of this is an accusation. Accounts are used by whoever holds their credentials, and a credential can be stolen. The evidence establishes which account did what; who was behind the keyboard is a separate question, and often one the evidence cannot settle alone.

Windows records an account in several forms, and recognizing all of them is part of reading every artifact in the course. A logon record names the account and its domain. The registry and many file system records carry the account's security identifier, its SID, rather than its name.

A user's profile folder, created the first time the account signs in interactively or over Remote Desktop, sits under C:\Users with the account's name, and holds that account's own registry hive.

In Northgate Engineering's estate these accounts are domain accounts, so a record shows NORTHGATE\adm.kashworth and the SID is the same on every host.

In your lab each host is a standalone VM, so the script creates the accounts as local accounts with the same names: where a record shows the account's domain, your lab shows the computer name, and the SID differs from host to host. Matching an account across your three collections is therefore done by name in the lab, and by SID in a real domain.

The profile folder is itself evidence. Its creation time on a host is the first interactive or RDP logon of that account there, which is often a better answer to "when did this account first appear on this machine" than any log that has since rolled over.

Your lab reproduces the case on one Windows 11 virtual machine, which plays each host in turn. That keeps the lab within what most people can run, and it changes three things you need to keep in mind.

The accounts are local rather than domain accounts. The file server is a Windows 11 VM with a share rather than a Server 2022 machine. And the hosts are played one after another from a clean snapshot, not all at the same time.

None of those differences changes the tools, the artifacts or the way you read them. A Prefetch file is a Prefetch file; an RDP logon creates the same records.

What changes is a handful of details: the account's domain, one Server default, and the fact that times across your three collections follow the order you ran them rather than the case calendar. Module 9 deals with that last point directly when you build the cross-host timeline.

The course always says when something you see in your lab differs from what the case's own evidence shows, and why.

Four machines mean four clocks, and every answer to the fifth question depends on reading times correctly across them. Northgate Engineering is in Birmingham, which in March 2026 is on UTC until the clocks go forward on 29 March.

Domain members take their time from the domain controller, so in a healthy domain the four hosts agree to within a second or two, and a host whose clock has drifted is itself something to note.

PS C:\> $uk = [TimeZoneInfo]::FindSystemTimeZoneById('GMT Standard Time')
PS C:\> [TimeZoneInfo]::ConvertTimeToUtc('2026-03-10 09:12', $uk).ToString('u')
2026-03-10 09:12:00Z
PS C:\> [TimeZoneInfo]::ConvertTimeToUtc('2026-03-30 09:12', $uk).ToString('u')
2026-03-30 08:12:00Z
PS C:\> $uk.IsDaylightSavingTime('2026-03-30 09:12')
True

Windows artifacts do not all record time the same way. Most store times in UTC internally, as a count of 100-nanosecond intervals since 1601, and a tool converts them for display; a few record local time, and some tools display local time by default.

The course works in UTC throughout, and the EZ Tools write UTC by default, which is what keeps four hosts' records comparable. Module 1 covers timestamp formats in detail; here the point is simply to decide the time basis before you compare anything.

In your lab the VM's clock is whatever your computer's is, and your three runs happen on the day you do them, not on 10 March 2026. Your times will therefore differ from the case calendar and from the course's reference output. What stays the same is the order of events within each host and the gaps between them, which is what the exercises check.

The ground-truth file each lab run writes, introduced in 0.6, records every step in UTC for exactly this reason.

Putting the hosts and the evidence types together gives the shape of the investigation. Each collection holds several kinds of evidence, and each kind appears in several collections. That is what lets one artifact be checked against another: the execution of a program on WS-114 can be checked against the file it created there, and the RDP logon on WS-031 against the authentication recorded on the domain controller.

The map also tells you why the modules are ordered as they are. The file system and execution come first because they establish what existed and what ran. The registry and event logs come next because they say how it persisted and who did it.

User activity comes last among the artifacts because it ties actions to a person's session. By the time you build the timeline in Module 9, every host will have been read from several angles.

In the lab you collect the hosts in a fixed order: WS-114, then WS-031, then FS-01. That order follows the reports rather than the attack: you start where the first event was reported, move to where the second was found, and then to the host neither report named.

On a real network you would often collect in parallel, or start with whichever host is most at risk of losing evidence, but the reasoning about what each collection is for stays the same, and so does the habit of recording when each one was taken.

Keep the map beside your notes. When an artifact names a host, check it against the map and ask what that host's collection could add.

Practice

Two pieces of practice. The first is an inventory of the accounts, groups and profiles on the four hosts. Use it to work out where each account could act and where its actions will be recorded.

The second builds, in your notes, the picture an experienced investigator would have in their head on day one.

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 case: the hosts, people and accounts as set out in this lesson and the last. The lab pack arrives in 0.5.