The NE Estate

Introduction

Every reading, hunt and investigation in this course happens against one estate. It is fictional, it is consistent across all seven modules, and it is built so the answers you get are checkable rather than illustrative.

This section is the estate itself: what is in it, what the corpus behind it actually contains, and where its edges are. Knowing the edges matters more than knowing the inventory, because a query returning nothing is only informative if you know what should have been there.

You will finish able to work any exercise in this course against a concrete environment, and to say which parts of a real estate the corpus does and does not model.

Northgate Engineering is an 810-staff engineering firm running Microsoft 365 E5, with the identity, endpoint and SIEM stack that implies. Two sites carry most of it: Manchester as the main office and Birmingham as the secondary, with a small number of staff working from further afield.

The estate below is the first of those and the course spends its time on the second. Read it for the populations rather than the hostnames: which groups exist, which is small, and which sits at the edge.

Count the identity machines separately whenever you state a server total for this estate, and expect to have to explain why. Twelve general-purpose servers plus five identity machines is seventeen boxes, and the reason to split them is that a read-only controller and a certificate authority are not servers in the sense a capacity conversation means, while being exactly the machines a security conversation is about.

The split also survives the question it invites, which is whether it is a way of making a coverage number look better. It is the opposite: separating them makes the identity population visible as its own line rather than diluted into a total, and a line reading five machines with no endpoint telemetry is considerably harder to ignore than a percentage of seventeen.

The two web servers are the other detail worth marking now. They are the only internet-facing hosts in the estate, they run a different operating system from the rest of the Linux fleet, and they sit in their own network segment. Every one of those three properties makes them behave differently in a query, and all three are the kind of thing that gets forgotten in a hunt written for the general case.

The Birmingham machines carry a similar warning. A file server and a database replica sit at the second site, which means any hunt filtered by a Manchester network range or by a naming convention that assumes the primary site will quietly miss two hosts. Multi-site estates are the normal case and single-site queries are the normal mistake.

Neither of those is exotic. They are the two shapes almost every real estate has, which is why they are in this one: a small population that differs from the majority, and a remote site that is easy to filter out by accident.

The macOS population is the third. Around forty machines in an estate of 865 is under five per cent, which is small enough to be forgotten in a hunt and large enough to matter when one of them belongs to an engineer with access to source. Small populations are dangerous precisely because their absence from a result never looks wrong.

A useful habit follows from all three. When a hunt returns results, group by platform and by site before drawing a conclusion, even when the question has nothing to do with either. Two seconds of grouping tells you whether the answer came from the whole estate or from the majority population only, and it catches the case where a filter you did not think about excluded a fifth of the machines.

The same grouping is the fastest way to find a collection gap you were not looking for. A platform that contributes no rows to a query it should have contributed to is a coverage problem announcing itself, and the announcement only happens if you grouped.

Investigations in this course name people, because real ones do and because a hunt result is a list of accounts before it is anything else. Learning the six below is worth the two minutes: several exercises turn on knowing whose machine you are looking at, and a name that means nothing to you is a row you will skim past.

Six names recur through the course, and it is worth learning them by what they decide rather than by their titles.

The last row is the one to remember. A great deal of endpoint operations work needs somebody outside the security team to agree to it, and on this estate that is Phil. Validating a detection by executing a technique, collecting an artifact from a machine somebody is using, changing what the sensor records: all three are his to approve, and none of them is a security decision from where he sits.

That is not an obstacle to route around. It is the ordinary structure of the job, and the practitioners who get things done are the ones who arrive with the reason, the blast radius and the rollback already worked out.

The two analysts matter for a different reason. Most of what this course teaches will be executed by somebody at their level rather than by whoever designed it, so a detection they cannot action, a hunt they cannot repeat and a playbook they cannot follow at three in the morning are all failures regardless of how well reasoned they are. Writing for Tom and Priya rather than for yourself is a discipline, and it is the one that decides whether the work survives you leaving.

The estate is not only a description. There is a generated corpus of around 79,000 rows across 21 tables sitting behind it, which the queries in this course run against, so an exercise has an answer somebody can check rather than a plausible-looking output.

// Orientation: what the estate looks like from the device table
DeviceInfo
| summarize arg_max(Timestamp, OSPlatform, DeviceType, MachineGroup) by DeviceName
| summarize Devices = count() by OSPlatform, DeviceType
| sort by Devices desc

Run that first. It is the same reading EO0.2 asked you to take on your own estate, against an environment where you already know the answer, which is the fastest way to learn what a correct result looks like before you have to judge an unfamiliar one.

Note what the query is doing with the device table, because the pattern recurs constantly. It reduces to one row per device with the latest state before counting anything, which is necessary because that table is a state snapshot rather than an event stream. Count its rows directly and you count heartbeats, and the number you get is large, plausible and meaningless.

Time is fixed rather than relative. The corpus is anchored at a specific instant, so a thirty-day lookback means thirty days back from that anchor rather than from today, and a query that returns nothing may be asking about a window the corpus does not cover rather than finding nothing.

That property is worth exploiting rather than merely tolerating. Because the anchor does not move, an exercise you work today returns the same rows as the same exercise worked next year, which means a wrong answer is genuinely a wrong answer rather than a consequence of the data having aged underneath you.

It also lets you practice a thing that is otherwise hard to practice, which is reading a result you already know to be complete. On a real estate an empty result is ambiguous, because you can never be certain the data was there to find. Here you can, so you can learn the difference between a query that found nothing and a query that asked wrongly, on a case where somebody can tell you which it was.

Carry that back deliberately. The instinct this builds, of asking what the data would have looked like if the answer were yes, is the single most transferable thing in this section.

Twenty-one tables is also worth registering as a number. The seven device tables from EO0.3 are the ones you will use most, and the remainder cover identity, mail, cloud application activity, alerts and the reference data that makes joins possible. An estate is not one stream, and the joins between those streams are where most real findings live.

Around 79,000 rows is small enough to be worth understanding as a property rather than a limitation. A real estate of this size produces that many process events before lunch, so the corpus is a curated sample rather than a recording: every row is there because it contributes to a chain or to the background the chains have to be found against. That makes it excellent for learning to read and useless for learning what volume feels like, and the second is a thing you can only get on a real estate.

The corpus is not only rows of ordinary activity. Four attack chains run through it, and knowing which tables each one touches is what stops you hunting for a chain in a table that could never hold it.

Four chains are woven into the corpus, each ending somewhere different, and between them they cover most of what an endpoint operator meets.

That split is the honest picture of the job. An endpoint operator who only reads endpoint tables will investigate the second half of half the intrusions they meet, arriving at a compromised workstation with no way to establish how the session that reached it was obtained.

It also explains an experience almost every endpoint analyst has had, which is being handed an incident that starts in the middle. The alert fires on execution, the investigation establishes what ran and where it went, and the question of how the adversary got there stays open because the answer lives in a table the endpoint operator never opened. That is not a knowledge gap so much as a habit of scope, and it costs a great deal in incident reviews.

The fourth chain is the one to work first if you work them out of order. Pre-encryption activity is dense, it is unambiguous once you know what to look for, and it is the case where the difference between finding it at the staging stage and finding it afterwards is the entire value of the function.

The password spray is the opposite and is worth working second for that reason. It is a chain where almost every individual event is unremarkable and the finding exists only in the aggregate, which is a different reading skill from following a process tree and one that a lot of endpoint practitioners never develop because their tables rarely demand it.

The mail-borne chain is the one that will feel outside your remit, and it is the one where an endpoint operator adds the most unexpected value. The endpoint holds the evidence of what the token was subsequently used to do, and the identity tables hold the evidence of how it was obtained, and nobody who reads only one of those two can describe the intrusion.

Work them in any order, and work all four before the capstone. Each teaches a different reading and the capstone assumes all four, which is deliberate: an operator who can follow a process tree and cannot read an aggregate is as limited as one who can do neither, they just fail on different days.

The exercise below is Northgate's device inventory as the platform reports it, against the roster above. The onboarding project closed at 96 per cent and nothing has been raised since.

Read it against the reference block rather than on its own. The whole exercise is a comparison between two lists, and the findings are in what one contains and the other does not, which is invisible if you assess the inventory as a standalone document.

The identity machines are the finding that matters most and the one easiest to accept as normal. A separate team onboarding a separate population is an ordinary organizational arrangement, and its consequence is that every hunt in this course, run against that inventory, silently excludes the machines an intrusion is trying to reach.

Fixing it is rarely a technical problem. The machines are being managed, somebody is looking at them, and the gap is that their telemetry does not arrive where yours does. That is a conversation about routing rather than a project, and it is worth having early because every hunt you run before it is settled carries the same silent exclusion.

Ask what the arrangement is rather than assuming it is an oversight. Domain controllers are frequently onboarded differently on purpose, with a tighter change process and a separate approval chain, and there may be a good reason the telemetry lands elsewhere. The finding is not that somebody was careless; it is that the SOC's hunts do not cover them and nobody had noticed that consequence.

Until it is settled, state the exclusion in writing on every result. A hunt reported as covering the estate is wrong; the same hunt reported as covering 886 devices excluding the identity infrastructure is accurate, costs one clause, and makes the gap visible to everybody who reads the finding rather than only to you.

That habit is worth more than the fix in one respect. The gap will be closed eventually and a different one will open, because estates change, and a team that writes down what its results did not cover will notice the next one considerably faster.

EO0.4 said that asset criticality feeds incident prioritization and depends on the platform knowing which assets matter. Northgate is the ordinary case: almost nothing is classified, so that input contributes almost nothing.

There are four criticality tiers, from very high down to low, and three ways an asset acquires one. Predefined classifiers assign automatically against a catalog that already covers file servers, domain controllers and databases holding sensitive data. Custom rules let you write your own against real asset properties such as a tag, a role membership or a resource type. And an asset can be tagged by hand in the inventory. Where several rules apply to one asset, the highest level wins.

Northgate uses the third of those and only the third, which is why four file and print servers are classified and 882 devices are not. Enabling the automatic classifiers is the cheapest available improvement to queue quality on this estate, and it needs no rule writing at all.

There is a trap in the enthusiasm that follows, and it is worth naming before you go and classify things. Classifying only servers models about half of a real attack surface, because the identities and the cloud resources are assets too, and an intrusion frequently reaches a critical server through an account rather than through another server. A criticality map that stops at the machines is a map of where the damage lands rather than of how it is reached.

There is also a review step people skip. Automatic classification will flag assets it is confident about and leave others pending a human decision, and a pending queue nobody works is a classification program that stops halfway with the easy cases done. Check it on a cadence, because the assets that did not meet the automatic threshold are frequently the interesting ones: the unusual machine, the service account with more permission than its name suggests, the box somebody built for a project and never decommissioned.

The gap between those two is where this course spends most of its uncomfortable moments. Every empty result you get is empty with respect to the inventory, and the estate is what you are actually responsible for.

Building the second list is unglamorous and takes a few conversations rather than a tool. The management platform gives you one view, the directory gives you another, the network team can tell you what has an address, and the finance or procurement record knows what was bought. Four sources that disagree, reconciled once, produce a list nobody in the organization currently has, and the disagreements themselves are the findings.

Do it early on any estate and keep it. It is the artifact that lets you answer the only version of the coverage question that means anything, which is what proportion of the things we own are we watching.

Northgate's zero in the very high tier is the finding those four would surface here. Predefined classification would place both domain controllers there without anybody deciding anything, and it cannot, because those machines are absent from the inventory the classifier reads. Two gaps compounding: the population that is missing is also the population that would have been ranked highest.

The estate above is described. This is how you establish it for yourself, against data where you already know the answer.

One closing observation about why the estate is fictional at all. A real environment cannot be published, so a course built on one either shows you sanitized fragments or asks you to imagine. This one gives you every hostname, every account and every row, which means an exercise can have a right answer and you can be told when you have not found it. That is the whole reason for the construction, and it is why the roster above is worth a few minutes rather than a skim.

The next section separates the three activities this estate is worked with, which are constantly confused and need different things from it.