0.2 The Incident as Reported

Introduction

Every investigation starts from what somebody noticed, and what somebody noticed is rarely the beginning of what happened.

This course follows one intrusion at Northgate Engineering from the first report to the final investigation report, and this lesson is where you meet it: as two short notes, written two days apart by people who did not know they were describing the same attack. Your job, from here to Module 10, is to find out what those notes leave out.

By the end of this lesson you can:

• State what the two reports establish and what they leave open.
• Separate an observation in a report from a conclusion someone drew from it.
• Name the five questions the investigation must answer and who set them.
• Explain why the investigator collects before anything on the hosts is changed.

An investigation does not start with evidence. It starts with a report: a ticket, a phone call, an alert, an engineer who noticed something wrong. Reports are written by people doing other jobs, in the language of those jobs, and they mix what was seen with what the writer concluded from it.

The first skill of an investigator is to read a report for what it actually establishes, so that every later step is aimed at what is unknown rather than at confirming what somebody guessed.

That reading matters because the report decides where you look first. A report that says "PDF will not open" points at a document. A report that says "unknown scheduled task" points at persistence. Neither says "intrusion", and neither writer had any reason to connect their note to the other's. The connection, if there is one, is in the evidence.

In this course you are the investigator Northgate Engineering's IT Security Manager assigns to the case. You do not start with a suspicion; you start with two notes and a set of questions, and you work to answers you can defend.

Northgate Engineering is an engineering company in Birmingham, in the UK, with 810 staff and 865 endpoints. It has the teams you would expect: Finance pays suppliers, IT Operations runs the estate, and Engineering produces the design files the company exists to make.

Those design files live on an engineering file server, and they are the most valuable thing on the network: the drawings and models customers pay for, and that a competitor would pay for too.

Nothing about the company is unusual, which is the point. The intrusion in this course uses nothing exotic: a disguised shortcut, a saved credential, Remote Desktop, built-in Windows tools.

That is how most real intrusions look, and it is why the evidence that reveals them is the ordinary evidence every Windows machine keeps: the file system, program execution records, the registry, the event logs and the traces of what a user did.

The value of the design files shapes the investigation from the start. If an attacker was on this network, the question that matters most to the business is the fourth: did the drawings leave, which ones, and how. Everything else in the investigation is in service of answering that one with confidence.

You will meet the hosts and the people involved in detail in the next lesson. For now, the shape is enough: a finance workstation, an IT administrator's workstation, an engineering file server and a domain controller, all Windows, all on one internal network.

On the morning of Wednesday 11 March 2026, Laura Brennan, a clerk in Accounts Payable, raised a ticket with the service desk. A supplier had sent her a remittance advice, she had clicked it the day before, and nothing had happened. The service desk asked her to request a new copy, recorded the cause as user error and closed the ticket.

Read the ticket for what it establishes. A file Laura believed was a PDF was opened on NGE-WS-114 on Tuesday 10 March, in the morning, and nothing visible happened. That is all.

"User error" is a conclusion the service desk drew without looking at the file or the machine, and it is the kind of conclusion that closes a ticket and also closes the only early chance to catch an intrusion.

Note also what the ticket does not say: what the file was called, where it came from, whether anything else ran. Those are questions for the machine. Laura's memory of a click a day earlier is useful for when to look; it is not a record of what happened.

The next morning, Thursday 12 March, Tom Hale in IT Operations was patching NGE-WS-031, the workstation Kieran Ashworth uses for his administrator work. He noticed a scheduled task he did not recognize, \Microsoft\Windows\NGHelper\Sync, and a service called NGUpdate. Neither is part of Northgate Engineering's build. Tom changed nothing, stopped patching that machine and raised it with IT Security.

Tom's note is a better report than the ticket, and the reason is what he did not do.

He did not delete the task, disable the service or reboot the machine to finish patching. Each of those would have changed the evidence: deleting the task removes the file you would read, disabling the service writes new registry and event log entries over the old, and a reboot clears what was only in memory. He observed, recorded and escalated.

What the note establishes is narrow. Two objects exist on WS-031 that should not. It does not establish who created them, when, how, or whether they ran. A task in a folder named after Microsoft is a common way to hide persistence, but that is a hypothesis to test, not a finding.

Before going further, take the ticket apart the way you will take apart every report and every artifact in this course. Each line is either something the writer saw or did, or something the writer concluded. Observations are evidence of what the writer saw; conclusions are evidence only of what the writer thought, and they carry the writer's assumptions with them.

Two lines in the ticket are conclusions: that the file was a PDF, and that the cause was user error. Laura believed the file was a PDF because it looked like one, and the service desk concluded user error because a PDF that will not open usually is. Both conclusions may be wrong, and the first is exactly what a disguised file is designed to make a user conclude.

Tom's note, by contrast, is almost all observation; his one judgment, "neither is ours", is the kind an IT engineer is well placed to make about his own build.

You will do the same with tool output later in the course. A parser's column called "Executed" is a conclusion the parser drew from a flag; whether the flag means what the column name says is something you check, not something you assume.

A report also tells you where to look first, and turning it into a list of evidence is the first practical step of any investigation. The ticket names a host, a rough time and an action: a file opened on WS-114 on the morning of 10 March.

That points at the file itself if it still exists, at the record of where it came from, at any program that ran when it was opened, and at the trace a user leaves when they open something from a folder.

Tom's note names a host and two objects.

That points at the task's definition and the service's configuration, at the event log entries written when each was created, and at who was signed in to WS-031 when that happened. Neither report mentions the file server or the domain controller, which is exactly why they belong on the list: an investigator who only looks where the reports point finds only what the reports already suspected.

The modules teach how to collect and read each item. What matters now is the habit: every report becomes a list of the evidence that would confirm it, contradict it, or explain it, on every host it could plausibly involve.

That list becomes the first draft of your investigation plan, which you will write properly in the 0.7 exercise.

The file was opened on Tuesday morning. The ticket was closed on Wednesday. The task was noticed on Thursday. By the time Priya Raman opened the investigation, two days had passed since the first event, and on a working network two days is long enough for some evidence to be gone.

Windows overwrites its event logs when they reach their size limit, oldest records first, and a busy server can roll a log in hours. Anything that existed only in memory was lost at the first reboot. Each ordinary day of work adds new records that sit on top of the old.

Not every source decays at the same rate. Files and registry entries usually survive until something deliberately changes them. Program execution records keep a limited history per program.

Event logs are the most fragile because they are size-limited, and the logs that matter most on a server, such as Security, are often the busiest. That is why the investigation collects promptly and why it records, for each source, how far back it actually reaches.

In the lab the gap is minutes, not days, but the habit transfers. When you collect a host in Module 2, you will record the oldest record in each log you collected, because an answer to question five is only as good as the evidence still there to support it.

The decay also explains a pattern you will see in the case: the hosts where the attacker spent least time can hold the clearest records, simply because less happened on them afterwards.

Put the two notes side by side and a question appears that neither writer asked: are they connected? One concerns a finance clerk's workstation and a file that did nothing; the other an administrator's workstation and objects that should not exist. They are two days and one department apart. In a real investigation the honest answer at this point is that nobody knows.

It would be easy to assume a link and work backwards from it. That is the mistake to avoid: an investigator who decides the story first reads every artifact as confirmation and misses the one that contradicts it. Treat the connection as a question with three possible answers: connected, unrelated, or one of them is not malicious at all.

Each of the three answers predicts different evidence. If the reports are connected, something on WS-114 should lead to WS-031: an account, a network connection, a file. If they are unrelated, the trails will not meet. If the task turns out to be an IT tool somebody installed and forgot to record, its creation will sit inside a normal change, made by a normal account, at a normal time.

Module 9 is where you test the connection properly, by laying the evidence from every host on one timeline. Before that, each module reads one kind of evidence and asks what it says about each host on its own terms.

Holding three answers open is easier if you write them down as hypotheses, each with the evidence that would support it and the evidence that would rule it out.

A hypothesis written that way is a plan for the next step; a hypothesis held in your head tends to become a belief. Investigators who write their hypotheses down change their minds faster, because the evidence that would refute a hypothesis is on the page before they start looking.

# Working hypotheses, 12 March  (case notes, E:\Cases\notes.md)

H1  One intrusion: the file on WS-114 led to the task and service on WS-031.
    Supports: an account or connection from WS-114 appearing on WS-031.
    Rules out: no shared account, host or time between the two.
H2  Two unrelated events.
    Supports: different accounts and tools on each host.
    Rules out: any shared account, file or connection.
H3  The task and service are an administrator's unrecorded change.
    Supports: created by a known admin during a recorded change.
    Rules out: created at an odd time, by an unexpected account.
H4  The file was benign.
    Supports: no program ran when it was opened.
    Rules out: execution records at the time of the click.

Each row names something you can look for in a specific place. That is the test of a useful hypothesis: it points at evidence. "The attacker was sophisticated" points at nothing and cannot be tested.

"The task on WS-031 was created by an account that logged on from WS-114" points at the task's creation record, the logon records on WS-031 and the account's activity on WS-114, and any one of them could prove it wrong.

The list will change. Some rows will be ruled out in Module 6 or 7, new ones will appear when an artifact shows something nobody expected, and by Module 9 one account of events will be left standing with the evidence for each step.

Keep the list with your notes and date each change, because the order in which you ruled things out is part of how you justify the answer.

A hypothesis ruled out is a result, not a waste of time. The report will say what was checked and excluded as well as what was found.

At 09:30 on Thursday 12 March, Priya Raman, Northgate Engineering's IT Security Manager, opened an investigation and assigned it to you. She set five questions. They are your terms of reference: the questions your final report must answer, and the test of whether the investigation is finished.

Each question is written so it can be answered from evidence. "How did the attacker get in" asks for a mechanism and a host, not a theory. "Which accounts" asks for names and places. "What did they do" asks for actions and the traces they left.

"Did data leave" asks for a yes or a no, and what and how if yes. "When, and how sure" asks for times and for a confidence, which is the question most reports answer worst.

Notice that the fifth question applies to the other four. Every answer you give needs a time and a confidence, and a confidence needs a reason: which artifacts support it, and whether any contradict it.

Your role is to establish what happened, from the evidence, and to report it to Priya Raman in terms she can act on. That shapes what you do and what you leave to others. You decide what to collect and how. You process and analyze it.

You state your findings with the evidence for each and the limits of each. You do not clean the machines, reset the passwords or tell Kieran Ashworth what to do with his account; those are response actions, and they are decided by the people who own them, ideally informed by what you find.

The order matters. Collection comes before any response action touches a host, because response changes the evidence. Disabling the NGUpdate service is the right thing to do eventually; doing it before the service's configuration and its event log entries are collected loses part of the answer to question three.

In the lab this is literal. You will plant each host's activity, collect it with KAPE, and only then revert the machine. The same discipline applies on a real network, where the pressure to "just fix it" is much greater.

The role also means keeping a record of your own work. From the first collection to the last finding, an investigator writes down what they did, when, with which tool and version, and what it produced: where each collection came from and its hash, which parser read it, which filter turned thousands of rows into the ten that matter.

That record is how somebody else, or you in three months, can repeat a step and get the same result. It is also how a finding survives challenge, because a conclusion nobody can retrace is an opinion. In this course the record starts in Module 1 with the collection's hashes and grows module by module until it becomes the methodology section of the Module 10 report.

The course is built around those five questions. Modules 1 to 3 give you the method and the tools to collect and process evidence properly. Modules 4 to 8 each read one kind of Windows evidence, and each moves several questions forward.

Module 9 combines everything on one timeline, which is where the connection between the reports gets tested. Module 10 writes the answers into the report Priya Raman asked for.

The pattern in the grid is deliberate. No question is answered by one module, because no question is answered well by one artifact.

Execution evidence says a program ran; the event logs say which account was logged on; the file system says what the program created; user activity says how it was launched. An answer that rests on one source is a lead. An answer that rests on two that agree is a finding.

Keep the grid in mind as you work through the modules. At the end of each, ask which of the five answers it moved, and what is still missing.

Practice

Two pieces of practice. The first is the service desk's week, exported on 12 March: most of it is ordinary traffic. Find the entries that are the incident, and separate what each reporter saw from what somebody concluded.

The second starts your own notes the way a real investigation starts: with what you were told, separated from what you were not.

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 two reports and the terms of reference, as set out in this lesson. Nothing to download yet; the lab pack arrives in 0.5.