0.2 Northgate's Tenant: the Case Every Hunt Runs On

Every hunt in this course runs on one organization: Northgate Engineering, a simulated engineering firm with offices in three English cities, a Microsoft 365 tenant, a Sentinel workspace and a month of security data.

This lesson is the case study. It introduces the organization, the team you join, the devices and services the data covers, the edge of the network, and the window, all read from the data itself rather than described from outside.

A case study matters for hunting more than for most security training, because hunting is local. An attacker's technique is the same everywhere; what it looks like in the data depends entirely on what is normal in the place being hunted.

A sign-in from an address outside the office means something different in a firm whose staff all work from the office and in one that is fully remote. A remote PowerShell session means something different where three administrators use it daily and where nobody does. Knowing the organization is the first half of every hunt.

The lesson reads the organization the way a new hunter would in their first week: who is here, who defends it, what machines exist, where people work from, and how far back the records go. Each answer comes from a query you can rerun, and the board at the end collects them as the reference the rest of the course uses.

Nothing in this lesson is a finding. The month contains intrusions, and the course uncovers them one by one in the modules that teach the techniques to find them. Here, every count is a count of ordinary activity, and the names that appear are names you will see again in context.

The directory snapshot, IdentityInfo, lists every account Northgate's Entra ID knows, with its department, job title and office. Grouped by department:

IdentityInfo
| summarize Accounts = count(), Cities = make_set(City) by Department
| order by Accounts desc

Nine departments appear, with the offices where each department's people sit:

Department              Accounts  Cities
----------------------  --------  ------------------------------
Engineering             15        Birmingham, Bristol, Mancheste
Finance                 13        Birmingham, Manchester
Sales                   13        Birmingham, Manchester
Information Technology  12        Birmingham, Manchester
Operations              12        Birmingham, Manchester
Marketing               11        Birmingham, Manchester
Risk & Compliance       9         Birmingham, Manchester
External                8         Manchester
Information Security    4         Manchester

97 accounts across 9 departments. 93 are member accounts belonging to people and 4 are service accounts that applications run as. Engineering is the largest department, as it should be in an engineering firm, and Finance, Sales, IT and Operations follow.

The External department holds the eight partner guests, consultants, auditors and engineers from other firms who work on Northgate's projects. Most of the firm is in Manchester, with smaller offices in Birmingham and Bristol.

The directory is also where a hunter checks whether an account belongs to a real person at all. An account that signs in but has no directory row, or a directory row with no department, is worth noticing in any tenant, because ordinary accounts are created through a process that fills those fields in. This lesson only counts; later modules use the lookup.

The directory snapshot has one property worth knowing from the start: it is a single snapshot, stamped at the very end of the window, so it shows the directory as it stood on 15 March rather than how it changed. 0.3 explains why that matters for how it is queried. For this lesson it is the list of who works here.

The partner guests are worth a note because the directory records them as members of an External department, while their sign-in names carry the #EXT# marker of an invited guest.

Step 4 finds them again in the sign-in log by that marker. It is the first example of a fact the course returns to often: two tables describe the same people in different terms, and a hunter learns which field to trust for which question.

The department list is also a map of what to expect in the data. Finance handles payments and invoices, so its mailboxes receive the lures that target money. Engineering handles drawings and project files, so its activity is heavy in SharePoint and in large file transfers.

IT holds the privileged accounts, so its sign-ins and remote sessions look unusual by design. A hunter who keeps this map in mind reads every result against the role of the account that produced it.

Job titles help in the same way, and the course uses them often. When a hunt returns an account, the first question is usually what that person does, and IdentityInfo answers it in one lookup. A systems administrator running remote commands is expected; a sales manager doing the same is a question.

Check coverage The organization is mapped. Check who defends it.

The hunting team sits in Information Security, and much of what a hunter sees in the data is done by IT. Both departments by job title:

IdentityInfo
| where Department in ("Information Security", "Information Technology")
| summarize Accounts = count(), Who = make_set(AccountName) by Department, JobTitle
| order by Department asc, Accounts desc

The two departments that run and defend the estate, by job title:

Department  JobTitle               Accounts  Who
----------  ---------------------  --------  --------------------------------
Security    L1 SOC Analyst         2         p.sharma, t.ashworth
Security    CISO                   1         r.okafor
Security    Security Architect     1         m.webb
IT          Systems Administrator  3         k.dhillon, s.mitchell, t.quinlan
IT          Network Engineer       3         a.fenwick, f.sowerby, r.mottram
IT          Service Desk Analyst   3         d.ogilvie, m.hargreaves, y.bevan
IT          Service Account        2         svc-backup, svc-sentinel
IT          IT Director            1         p.greaves

Information Security is four people: a CISO, a security architect and two L1 SOC analysts who work the alert queue 0.1 measured. You join them as the hunter. IT is larger: an IT director, 3 systems administrators, network engineers, service desk analysts and the service accounts IT runs.

A hunter's place in a team this size is specific. The L1 analysts close alerts; the architect designs controls; the CISO decides priorities and answers to the business. The hunter's output feeds all three: findings to the analysts as incidents, gaps to the architect as design changes, and measures of what hunting found and could not see to the CISO. Module 9 is about producing each of those well.

The team's size explains its habits. Two analysts working a queue of hundreds of alerts a month have little time for anything else, which is why most hunting falls to you.

The administrators matter in a different way: much of what looks unusual in endpoint and identity data, remote sessions, privileged sign-ins, configuration changes, is their ordinary work. A hunter who knows who the administrators are can separate their routine from anything that imitates it, and Module 9 shows how much of a hunt's result that separation explains.

The security team's own accounts appear in the data too, and the course treats them like any other. A security analyst who clicks a phishing link in a training exercise, or an architect who signs in from an unusual place while traveling, produces the same rows as anyone else.

A hunter does not exempt their own team from a hunt; they read the rows with the same care and know a little more about the likely explanations.

Widen The people are known. Widen to the machines they use.

Defender for Endpoint reports four kinds of activity from each device it covers: processes, network connections, logons and file changes. Grouping the devices by kind, and counting how many report all four:

let start = datetime(2026-02-13 12:00);
let stop = datetime(2026-03-15 12:00);
union
    (DeviceProcessEvents | where Timestamp >= start and Timestamp < stop
        | summarize by DeviceName | extend Table = "process"),
    (DeviceNetworkEvents | where Timestamp >= start and Timestamp < stop
        | summarize by DeviceName | extend Table = "network"),
    (DeviceLogonEvents | where Timestamp >= start and Timestamp < stop
        | summarize by DeviceName | extend Table = "logon"),
    (DeviceFileEvents | where Timestamp >= start and Timestamp < stop
        | summarize by DeviceName | extend Table = "file")
| summarize Tables = dcount(Table) by DeviceName
| extend Kind = case(DeviceName endswith "-LT", "Laptop",
    DeviceName endswith "-WS", "Workstation",
    DeviceName startswith "WEB-", "Web server", "Server")
| summarize Devices = count(), AllFour = countif(Tables == 4) by Kind
| order by Devices desc

The endpoint devices by kind, with how many report all four tables:

Kind         Devices  AllFour
-----------  -------  -------
Laptop       15       15
Server       6        0
Web server   2        0
Workstation  1        0

24 devices report endpoint activity. 15 are staff laptops, named for their user, with 15 reporting all four tables; one is a desktop workstation. The rest are servers, and the servers tell a different story: few of them report all four tables, because the sensor coverage on Northgate's servers is partial. Module 3 measures exactly what each server reports, and that measurement shapes every hunt that touches a server.

The servers are also seen through the Sentinel workspace, which collects other feeds:

let start = datetime(2026-02-13 12:00);
let stop = datetime(2026-03-15 12:00);
union
    (Syslog | where TimeGenerated >= start and TimeGenerated < stop
        | summarize Rows = count(), Sources = dcount(Computer)
        | extend Feed = "Linux Syslog"),
    (SecurityEvent | where TimeGenerated >= start and TimeGenerated < stop
        | summarize Rows = count(), Sources = dcount(Computer)
        | extend Feed = "Windows Security events"),
    (CommonSecurityLog | where TimeGenerated >= start and TimeGenerated < stop
        | summarize Rows = count(), Sources = dcount(Computer)
        | extend Feed = "Firewall")
| project Feed, Rows, Sources

Three other feeds reach the workspace, each with its rows and the number of machines sending it:

Feed                     Rows  Sources
-----------------------  ----  -------
Linux Syslog             5244  8
Windows Security events  1109  12
Firewall                 2060  1

8 Linux servers send Syslog, the domain controllers and a few Windows servers send Security events, and one firewall, FW-NGE-MCR-01, sends its traffic and threat logs. A server that reports no processes to Defender may still send Syslog or Security events, so a hunt that finds nothing in one table about a server should ask the others before concluding anything.

The naming tells you a lot before any query. Laptops are named NE- and the user's surname, so a laptop result names its owner. Servers are named SRV-NGE- with the site and role, MCR for Manchester and BRS for Bristol, and APP, DB or MON for what they do. Web servers are WEB-NGE-.

A convention like this is a gift to a hunter, because a device name in a result already says what kind of machine it is and roughly who should be using it. Not every tenant has one, and part of learning a new environment is learning whatever convention it has.

Widen The machines are mapped. Widen to how people reach the tenant: where they sign in from.

Every interactive sign-in to the tenant is in SigninLogs, with the address it came from. Microsoft's reference describes the column as "The IP address of the client from where the sign-in occurred." Splitting staff from partner guests:

SigninLogs
| where TimeGenerated >= datetime(2026-02-13 12:00)
    and TimeGenerated < datetime(2026-03-15 12:00)
| extend Account = iff(UserPrincipalName has "#EXT#", "Partner guest",
    "Northgate account")
| summarize SignIns = count(), Accounts = dcount(UserPrincipalName),
    FromOffice = countif(IPAddress startswith "203.0.113.") by Account

Staff and partner sign-ins over the month, with how many of each came from the office:

Account            SignIns  Accounts  FromOffice
-----------------  -------  --------  ----------
Northgate account  7804     93        7328
Partner guest      258      8         0

94% of staff sign-ins came from 203.0.113.0/24, Northgate's office range. That number is the first baseline in the course and one of the most useful: in a firm where most sign-ins come from the office, a sign-in from elsewhere is worth a second look, while in a remote-first firm it would be routine. Partner guests never sign in from the office range, because they sign in from their own companies.

The office range carries a caution as well as a baseline. Because most sign-ins come from it, a sign-in from the office range is weak evidence that the person was in the office: a device on the corporate network, a VPN that egresses through the office, or an attacker who has reached an internal machine would all present the same address.

The baseline makes outside sign-ins stand out; it does not make inside ones trustworthy.

Microsoft's reference describes the DeviceDetail column as information "such as deviceId, OS, and browser", and it adds a second baseline alongside the address. Whether a sign-in used MFA and a managed device is the other half of the pattern, and 0.4 measures both.

The guests come from four partner organizations:

SigninLogs
| where TimeGenerated >= datetime(2026-02-13 12:00)
    and TimeGenerated < datetime(2026-03-15 12:00)
| where UserPrincipalName has "#EXT#"
| extend Partner = tostring(split(split(UserPrincipalName, "#EXT#")[0], "_")[1])
| summarize Accounts = dcount(UserPrincipalName), SignIns = count() by Partner
| order by Accounts desc

Four partner firms appear, each with a few guest accounts and their sign-ins over the month:

Partner               Accounts  SignIns
--------------------  --------  -------
harlowmarine.co.uk    3         95
krauss-structural.de  2         87
penroseaudit.com      2         55
northviewfab.co.uk    1         21

A marine engineering firm, a structural engineering firm, an audit firm and a fabrication supplier: the organizations an engineering firm shares documents with. Their guests sign in from their own networks, so their addresses vary, and Module 1 reads one of their off-hours sign-ins to show how a hunter decides what is ordinary for a guest.

Partner access is one of the places hunting in a real tenant spends real time, and the course gives it the same care.

Guests use their own companies' devices and networks, so their sign-ins cannot be held to the office baseline, and a hunter has to build a separate baseline for each partner: when they usually sign in, from what kind of address, to which resources. Module 1 makes the first such baseline, and later modules return to partner activity wherever a hunt touches it.

Sign-ins are only one way into the tenant, and the board lists the others. Mail arrives from outside and is recorded in EmailEvents; files are shared in and out through SharePoint and OneDrive and audited in OfficeActivity; the firewall records traffic to the web servers that face the internet.

A hunter thinking about how an attacker could get in considers each of these doors, and each has its own table and its own baseline.

Of the doors, the firewall is the least visible from the identity side and the most important for the servers. Traffic to Northgate's internet-facing web servers passes through it, and its threat logs record what it judged suspicious.

Nothing in the sign-in logs would show an attack that never involved a sign-in, which is why the course keeps the firewall in its data and why a hunt that starts from an account sometimes has to finish at the edge.

Check coverage People, devices and access are known. Check the last thing every hunt depends on: how far the records reach in each table.

The course's window is thirty days, 13 February 12:00 to 15 March 12:00 UTC, and every query uses it. Not every feed fills it. The main tables, with their first and last rows inside the window:

let start = datetime(2026-02-13 12:00);
let stop = datetime(2026-03-15 12:00);
union
    (SigninLogs | where TimeGenerated >= start and TimeGenerated < stop
        | project At = TimeGenerated, Table = "SigninLogs"),
    (OfficeActivity | where TimeGenerated >= start and TimeGenerated < stop
        | project At = TimeGenerated, Table = "OfficeActivity"),
    (EmailEvents | where Timestamp >= start and Timestamp < stop
        | project At = Timestamp, Table = "EmailEvents"),
    (DeviceProcessEvents | where Timestamp >= start and Timestamp < stop
        | project At = Timestamp, Table = "DeviceProcessEvents"),
    (IdentityLogonEvents | where Timestamp >= start and Timestamp < stop
        | project At = Timestamp, Table = "IdentityLogonEvents"),
    (SecurityEvent | where TimeGenerated >= start and TimeGenerated < stop
        | project At = TimeGenerated, Table = "SecurityEvent"),
    (Syslog | where TimeGenerated >= start and TimeGenerated < stop
        | project At = TimeGenerated, Table = "Syslog"),
    (CommonSecurityLog | where TimeGenerated >= start and TimeGenerated < stop
        | project At = TimeGenerated, Table = "CommonSecurityLog")
| summarize Rows = count(), Days = dcount(startofday(At)),
    Earliest = min(At), Latest = max(At) by Table
| order by Earliest asc

The main tables and how much of the window each one actually fills:

Table                Rows   Days  Earliest     Latest
-------------------  -----  ----  -----------  -----------
OfficeActivity       15960  31    02-13 12:00  03-15 10:41
SigninLogs           8062   31    02-13 12:00  03-15 11:57
EmailEvents          15188  31    02-13 12:02  03-15 11:50
DeviceProcessEvents  9394   30    02-13 12:02  03-15 11:08
CommonSecurityLog    2060   31    02-13 12:02  03-15 11:59
IdentityLogonEvents  2523   31    02-13 12:03  03-15 11:57
Syslog               5244   31    02-13 12:03  03-15 11:58
SecurityEvent        1109   28    02-16 03:12  03-15 11:55

The Days column is as informative as the dates, and it is quicker to read. A table that holds rows on every day of the window records something that happens continuously, sign-ins, mail, firewall traffic.

A table with rows on fewer days either records something that does not happen every day or started late, and the Earliest column says which. A hunter reading a gap in a daily count first checks whether the table normally has rows on that day.

Most tables start within the first hours of the window and run to its last day. The domain controllers' Security events start later, on 16 February, so a hunt over the first days of the window has no domain controller events to read. Microsoft notes that advanced hunting holds "up to 30 days" of Defender data; the course's window is that month, and the lab's now is its end.

Two things follow for every hunt in the course. First, a query that reaches back before a table's first row returns nothing for that period, and the silence is about the feed, not the activity; a hunt over the domain controllers in the first days of the window has to say so.

Second, the window's end is the lab's present. Anything the course describes as happening "now" happens at 15 March 12:00, and anything after it is outside the data.

The half-open window has a practical edge as well. The directory snapshot from step 1 is stamped exactly at 15 March 12:00, the window's excluded end, so a query that applies the window to IdentityInfo returns no rows at all.

That is why this lesson queried it without one, and 0.3 shows the effect directly. It is a small example of a large habit: know how each table is stamped before trusting a filter on it.

The board below collects what this lesson read. It is the reference the course uses: when a later lesson says "the office range" or "the administrators" or "the window", this is what it means.

The board has two halves for a reason. What the data covers is the list of places a hunt can look. What it does not cover is the list of places a hunt cannot, and every finding in the course is bounded by it.

A hunt that finds nothing on a server reporting only logons has not cleared that server of anything except unusual logons, and the board is where a reader checks that.

The limits are ordinary ones, the kind every real tenant has. Sensors are deployed unevenly, some feeds are connected later than others, and anything outside the tenant, a partner's laptop or an employee's phone, is visible only where it touches Northgate's services. Naming them up front is what lets the course's hunts state their bounds precisely instead of hedging every conclusion.

The record closes the case study. Explained means the organization is described and nothing in the description needs action.

The record's next steps point to the next two lessons, and that is how every record in the course works: it ends by saying what the hunt hands on. Here it hands on a description, and 0.3 and 0.4 build on it, first by naming the tables properly and then by running a hunt that turns one line of this description, the office-range baseline, into a measured fact.

The case study is short on drama by design. A hunter who starts from a description of normal can see an anomaly when it appears; one who starts from a list of known incidents sees only those incidents. The modules that follow return to this description constantly, and Module 10's capstone report refers back to it as the environment every finding is bounded by.

Step 3 counted devices by kind and by how many endpoint tables each reports. Build the per-device view and find the servers that report only one table.

Write down the servers that report fewest tables. Then write which kind of hunt would be blind to each.

The check gives you the main tables and their first and last rows. Decide what each tells a hunter about coverage.

Resources

Publishers revise these pages; where a page and this lesson disagree, the page is newer.

• Proactively hunt for threats with advanced hunting in Microsoft Defender XDR (Microsoft Learn)
• SigninLogs table reference (Microsoft Learn)