The Northgate Estate, and Why an Assistant Cannot Know It

Why a fixed estate

Most security training that involves AI stops at description. You read about a failure mode, you nod, and you never encounter one under conditions where you might miss it. That produces recognition without competence: you can define the six failure modes and you still approve the query.

Verification cannot be taught that way, because the skill is not knowing that generated output can be wrong. Everyone knows that already. The skill is catching it in a specific case where it is not obvious, and that requires a case, with data behind it, that you can interrogate.

So every exercise in this course runs against a single fixed environment: Northgate Engineering, an 810-person firm whose telemetry sits behind the query surface on these pages. When a module shows you a generated query, you run it. Real rows come back. When the finding tells you the query was wrong, you can prove that for yourself by changing one clause and running it again.

What Northgate is

An engineering firm with two UK offices, running a Microsoft-centered stack with some Linux infrastructure behind it.

Staff	810
Endpoints	865
Servers	12, of which 6 RHEL and 2 Ubuntu web
Identity	Entra ID, M365 E5
Detection	Defender XDR, Microsoft Sentinel
Network	Palo Alto PA-3220 perimeter, Squid proxy
Offices	Manchester (10.0.1.x), Bristol

The names recur across the course, and it is worth knowing a few before you meet them in an exercise. Rachel Okafor is the CISO. Tom Ashworth and Priya Sharma work the SOC queue. Marcus Webb is the security architect. Phil Greaves is IT Director and holds a Global Administrator account, which is why he appears in more incidents than he would like.

The estate is fictional and the telemetry is not arbitrary. It was generated by simulating activity, which means the ordinary traffic behaves like ordinary traffic: people sign in from the office on weekdays, service accounts run on schedules, and a few things are broken in the way real estates are always slightly broken.

The tables you will use

The corpus holds 21 tables and roughly 79,000 rows. This course uses a handful of them heavily and the rest occasionally.

Identity, which is where most of the verification exercises live because sign-in data is where the subtle field errors are:

• SigninLogs: interactive sign-ins, with ResultType, IPAddress, AppDisplayName, ConditionalAccessStatus and AuthenticationRequirement
• AADNonInteractiveUserSignInLogs: the token refreshes and background authentications that a query filtered to SigninLogs will silently miss
• AuditLogs: directory changes: role assignments, method registrations, application consent
• IdentityLogonEvents: on-premises domain authentication, Kerberos and NTLM

Endpoint, from Defender:

• DeviceProcessEvents: process creation with command lines and parent process
• DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, DeviceLogonEvents, DeviceEvents

Email and cloud: EmailEvents, OfficeActivity, CloudAppEvents.

Alerts: SecurityAlert, AlertEvidence, SecurityIncident.

Four intrusions, and why they matter here

Four attack chains run through the corpus. They matter to this course for a specific reason: a generated query that fails silently is only dangerous if there was something to find, and these are the something.

Adversary-in-the-middle phishing. A proxy captures a session token from c.richardson@ne.com; the attacker uses it from outside the estate. The sign-in satisfies MFA because the token already carries the claim, which means a query looking for failed authentication finds nothing.

Password spray. 193.32.162.89 makes 21 attempts across 20 accounts, one each, so no account locks and no per-account threshold fires. A query grouped by user shows one failure per user and looks like ordinary noise.

Endpoint compromise and credential theft. NE-LEWIS-LT and NE-THOMPSON-LT are dumped with comsvcs.dll MiniDump, a signed Microsoft binary. Antivirus has nothing to say about it and neither does a query looking for unusual executables.

Ransomware pre-encryption. Shadow copy deletion and backup interference before any encryption occurs, which is the window in which the incident is still preventable.

Alongside these sits a separate brute force against r.scott@ne.com: 84 attempts from a single Lithuanian address on the night of 2 March, of which 83 failed and one succeeded at 22:55:12. That single success is the row that most of the query exercises in this course are built around, because it is easy to write a query that runs, returns rows, and does not contain it.

The noise is the point

An estate containing only attacks would teach nothing. Every query would find the intrusion and every verification would pass.

The corpus is mostly ordinary. Hundreds of people signing in from the office, service accounts running on schedule, developers running PowerShell for legitimate reasons, someone in finance downloading eleven files in an afternoon because that is what their job involves.

That ordinary activity is what makes verification a skill rather than a formality:

• A query that accidentally selects successes still returns plenty of rows, because there are plenty of successes
• A time window one day off still finds failures, because there are always a few failures
• A rule matching PowerShell execution fires constantly, because PowerShell runs constantly

In every case the wrong query produces a confident, populated, plausible answer. That is precisely the condition this course exists to train you for, and it cannot be reproduced in a dataset that contains only the attack.

What "normal" looks like here, and why you need it

Verification requires a baseline, and a baseline is not a fact you can look up. It is a set of expectations you build by looking at the estate when nothing is wrong. Four are worth acquiring now, because exercises later depend on them.

Where sign-ins come from. Almost everything originates in 10.0.1.x, the Manchester office range. Bristol has its own range. Anything outside those is either a genuine remote worker, a partner VPN egress, or an intrusion, and telling them apart is a question about the account rather than about the address.

When service accounts run. The estate's svc- accounts authenticate to SRV-NGE-MCR hosts on schedules. Thirty-three of thirty-six service account logons go to servers. The three that do not are the whole of one exercise later in this course.

What failure rates look like. A handful of failed sign-ins a day is ordinary: people mistype passwords. A query that returns "some failures" has told you almost nothing, which is why the brute force is identified by its shape, one address against one account eighty-four times, rather than by its existence.

How much noise PowerShell makes. Seventeen hosts run it, constantly, for entirely legitimate reasons. Any detection idea that starts with "alert on PowerShell" dies on contact with this estate, and Module 4 uses exactly that to show what a generated rule fails to account for.

A note on how the corpus was built

The telemetry is generated rather than captured, and the way it was generated matters for what you can conclude from it.

Ordinary activity was simulated: users with roles, working patterns, devices and habits, producing the volume and rhythm a real estate produces. The attacks were then run through that activity as chains, so the malicious events sit inside the noise in the right proportion rather than being appended to it.

The practical consequence is that absence is meaningful here. If a query finds nothing, the reason is either that the thing did not happen or that you looked in the wrong place, and both are real answers. The corpus is not a puzzle where every query is supposed to return something interesting, and treating it as one will cost you a finding.

The same log line, twice

Here is a single event, presented without comment.

2026-03-12T22:08:47Z  svc-sql  NE-LEWIS-LT  Network  Ntlm  Success

Ask an assistant what it means and you will get an accurate reading: a service account named svc-sql authenticated to a host called NE-LEWIS-LT over the network using NTLM, and it succeeded. Every word of that is correct.

Now the same line read by someone who knows Northgate. svc-sql is a database service account. NE-LEWIS-LT is a laptop. Service accounts in this estate authenticate to SRV-NGE-MCR servers, thirty-three times out of thirty-six. NTLM rather than Kerberos is the older protocol and this estate uses it for legacy applications on servers, not for laptops. And svc-sql appears exactly once in thirty days of logon history, which is this line.

The first reading is a translation of the record. The second is a finding. The gap between them is not intelligence, effort or prompting. It is that the second reader has seen the other thirty-five logons and the first has not.

Four kinds of context

It helps to separate them, because they differ in whether they can be supplied.

Stated facts. The estate has 810 staff, two offices, an M365 E5 tenant, a Palo Alto perimeter. Writeable, short, easily supplied.

Conventions. Hosts are named SITE-FUNCTION-NN. Service accounts are prefixed svc-. Office ranges are 10.0.1.x and Bristol's equivalent. Writeable with a little effort, and genuinely useful when supplied.

Distributions. How often service accounts touch laptops. What a normal daily failure count looks like. How many files finance downloads at month end. Not writeable, because they are not facts you hold as sentences. You hold them as expectations, and you discover you hold them when something violates one.

Exceptions and history. That svc-legacyerp authenticates without MFA because of an application nobody has rewritten, that a partner's VPN egress looks foreign every Tuesday, that the alert on this host last month turned out to be a misconfigured backup agent. Partly writeable and never complete, because the list is generated by events rather than by design.

The first two can be given to an assistant. The second two are where the findings are, and they are the two that resist being written down.

What you can actually supply

Supplying the writeable half is worth doing and it produces a real improvement. Three things carry most of the value.

The naming conventions, because they let an assistant read a hostname as structured rather than as a string. Told that SRV- means server and NE-SURNAME-LT means a user laptop, a response about the line above becomes noticeably more useful, because the shape of the anomaly becomes visible from the names alone.

The address ranges, because internal and external is the most common distinction in security reasoning and it is entirely estate-specific.

The schema, meaning which tables exist and what they hold. This is the single highest-value thing to supply for query generation, because it directly attacks failure modes 1 and 4: a model told that IdentityLogonEvents holds domain authentication and DeviceLogonEvents holds endpoint logons is much less likely to query the wrong one.

Running your first query

Confirm the mechanism before an exercise depends on it. The block below is editable and runs against the live corpus.

SigninLogs
| where IPAddress == "45.83.64.117"
| summarize Attempts = count() by ResultType
| sort by Attempts desc

You should get three rows: 50126 with 58, 50053 with 25, and 0 with 1. Wrong password, account locked, and one success.

Look at that last row before moving on. One row out of 84. It is the entire finding, it sits at the bottom of a sorted result, and every exercise in Module 3 is a variation on a query that returns something reasonable while excluding it.