0.2 Northgate's Domain

Introduction

Every lesson in this course happens in one place: corp.ne.com, the Active Directory domain of Northgate Engineering, an engineering company of about 800 people with offices in Manchester and Birmingham. The attacks are attacks on this domain, the evidence is this domain's, and the fixes are made here.

This lesson is the map. It names the controllers, the four machines and two groups that make up tier 0, the certificate authority, the server that copies identities to the cloud, the other forest Northgate trusts, and the people whose accounts run it all. You will meet each again in the module that defends it, and knowing where it sits makes those lessons shorter to read.

The tree is the domain from the top down. A forest is the outer boundary of Active Directory, and Northgate's holds one domain with the same name. The domain is divided into sites by network, which tells clients which controller is nearest. Under the sites are the machines this course treats as tier 0, marked red: the two writable controllers, the certificate authority and the Entra Connect server.

Outside the forest are two connections that matter as much as anything inside it: a trust to Calder Fabrication's forest, and a sync to Microsoft Entra ID. The PowerShell output in this lesson is read from the course's evidence files, which record the domain as it stood on 15 March, and the queries run on the corpus month that ends that day.

A forest is the security boundary of Active Directory: everything inside it shares a schema, a configuration and a set of administrators who can reach every domain in it. Northgate's forest holds a single domain, which is the simplest shape and still the most common in a business of this size. The two commands an administrator runs first, from Phil Greaves's admin workstation:

PS C:\> Get-ADForest | Format-List Name, ForestMode, Domains, Sites, UPNSuffixes, SchemaMaster
>> Get-ADDomain | Format-List DNSRoot, NetBIOSName, DomainMode, DomainSID, PDCEmulator
Name         : corp.ne.com
ForestMode   : Windows2016Forest
Domains      : {corp.ne.com}
Sites        : {Manchester-HQ, Birmingham-Branch}
UPNSuffixes  : {ne.com}
SchemaMaster : NE-DC01.corp.ne.com


DNSRoot     : corp.ne.com
NetBIOSName : NE
DomainMode  : Windows2016Domain
DomainSID   : S-1-5-21-3623811015-3361044348-30300820
PDCEmulator : NE-DC01.corp.ne.com

Each line is a fact a later module depends on. ForestMode and DomainMode, the functional levels, are Windows Server 2016, and Microsoft's functional levels reference explains why: Windows Server 2019 and 2022 added no level of their own and use 2016's, and the 2025 level allows only 2025 controllers, so 2016 is the highest level a forest with 2022 and 2025 controllers can run at.

The two sites carry Northgate's two offices. UPNSuffixes holds ne.com, which is why people sign in as n.ellery@ne.com rather than with the internal name corp.ne.com. The domain SID is the prefix of every account's SID, so S-1-5-21-3623811015-3361044348-30300820 followed by a number is a Northgate account wherever you see it in an event.

The last two lines name roles. The schema master is the one controller allowed to change the schema, and the PDC emulator is the controller that takes password changes first and acts as the domain's time source. Both are NE-DC01, which holds all five operations master roles.

That concentration is normal for a domain this size, and it makes NE-DC01 the controller whose loss hurts most. It also means many authoritative events, such as an account lockout, are written on NE-DC01 whichever controller the user first reached, which is why so many of the course's queries end up reading NE-DC01's log.

Sites matter for the same practical reason. When a computer looks for a controller, it asks DNS for controllers registered in its own site first, so a laptop at Manchester normally signs in through NE-DC01 or NE-DC02 and a desktop at Birmingham through the branch controller.

That routing decides which controller's log holds a given person's sign-ins. An investigator who reads only one controller sees only the clients that happened to reach it, and an attacker who can choose which controller to talk to can choose which log records them.

Northgate keeps an inventory of its controllers in a spreadsheet on the IT share, the way most businesses do, and it is the list the IT team works from:

PS C:\> Import-Csv \\corp.ne.com\IT\Inventory\dc-inventory.csv | Format-Table Name, Site, Role, Owner, Notes -AutoSize
Name      Site              Role                         Owner          Notes
----      ----              ----                         -----          -----
NE-DC01   Manchester-HQ     Writable DC (all FSMO roles) Infrastructure 
NE-DC02   Manchester-HQ     Writable DC                  Infrastructure Windows Server 2025
NE-RODC01 Birmingham-Branch Read-only DC                 Infrastructure Branch office

Three controllers. Two at Manchester take changes, and one at Birmingham is read-only. The read-only controller is a deliberate choice for a branch office: Microsoft designed the type for sites with few users and weaker physical security, and by default it stores no user or computer passwords at all, apart from its own account and its own krbtgt, caching others only when the password replication policy allows.

If someone walks out of the Birmingham office with the server, they have far less than a copy of Manchester's. What each controller is:

NE-DC02 is the one to remember. Windows Server 2025 brought features to the directory that no other Northgate controller has, among them delegated managed service accounts, and a feature that exists in a domain is a feature an attacker can misuse there.

Several lessons later in the course depend on which controller runs which version. The inventory is also a claim, and a list a team keeps by hand can fall behind the domain it describes. Lesson 1.5 compares this list with what the directory itself says, and the course leaves that comparison to it.

Tier 0 is the name for every account, group and machine that can control the domain, directly or in one step. The term comes from Microsoft's administrative tier model, which its current guidance keeps as a useful model inside a wider enterprise access model where tier 0 has become the control plane.

The test is simple: if an attacker controls this thing, do they control the domain? For a domain controller the answer is yes by definition. For the two administrative groups it is yes because their members can do anything. Northgate's members, as Module 1 found them:

PS C:\> "Domain Admins", "Enterprise Admins" | ForEach-Object { $g = $_; Get-ADGroupMember $g |
>>     Select-Object @{ n = "Group"; e = { $g } }, Name } | Format-Table -AutoSize
Group             Name
-----             ----
Domain Admins     Administrator
Domain Admins     a-pgreaves
Enterprise Admins Administrator

Two people's worth of accounts: the built-in Administrator in both groups, and Phil Greaves's admin account in Domain Admins. Enterprise Admins has forest-wide rights, which in a single-domain forest adds little to Domain Admins and is held by Administrator alone. The groups are the obvious part of tier 0. The less obvious part is the machines that are not controllers but are just as powerful:

The certificate authority is tier 0 because a certificate it issues for sign-in is accepted by the controllers as proof of who someone is, so whoever controls the CA, or a template on it, can issue a certificate that signs in as an administrator.

The Entra Connect server is tier 0 because Microsoft says so in its own prerequisites: it must be treated as a tier 0 component, hardened as a control plane asset, with administrative access restricted to domain administrators or tightly controlled groups. Its account can ask a controller for every password hash, as section 5 shows.

Anything that can change one of these four, a backup of a controller, a group policy that applies to them, an account that can reset an administrator's password, is tier 0 too, and finding all of those is a large part of Modules 5, 11 and 14.

Active Directory Certificate Services is the Windows role that issues and manages certificates for users, computers and services. Northgate runs one certificate authority, NE-Issuing-CA, on NE-ADCS01 at 10.0.1.12.

Microsoft's overview lists what its certificates are for, including smart card sign-in, TLS for web servers and digital signatures, and it describes how the CA fills certificates from what the directory already knows about the requester, with Group Policy deciding which users and machines may get which kinds.

That integration is what makes the CA useful, and it is what makes it dangerous, because a certificate whose subject the CA fills in wrongly is an identity the controllers will accept. The CA's own Security log records each certificate it issues as event 4887, and the corpus holds a month of them:

SecurityEvent
| where EventID == 4887
| summarize Issued = count() by Computer, Week = startofweek(TimeGenerated)
| sort by Week asc

One computer and four weeks, between 38 and 50 certificates a week, 174 in all. That is a working CA serving machines and people with ordinary certificates, and a steady weekly rate is itself a baseline: a week with ten times the issuance, or a certificate for an account that never asks for one, stands out against it.

The corpus records which template each certificate came from and who asked, which is what Module 18 reads when it examines templates that let the requester choose the name in the certificate, and certificates issued for one person to another.

For now the point is where the CA sits: it is not a controller and holds no copy of the directory, yet it can produce proof of identity the controllers trust.

One property makes that proof unusually durable. A certificate is valid until it expires or is revoked, and resetting the password of the account it names does not touch it. A user certificate issued for a year keeps signing that account in for a year, whatever happens to the password in between.

For ordinary staff that is the point of certificates. For an attacker it means a certificate issued to them is a way back in that survives the password resets an incident response usually starts with, which is why Module 22 hunts for certificates as persistence and Module 21's response plan includes revoking them.

Northgate's people sign in to Microsoft 365 with the same password they use at their desks, and Entra Connect is what makes that true. It runs on SRV-NGE-MCR-AAD01 and copies accounts from corp.ne.com to Northgate's Microsoft Entra ID tenant, with password hash synchronization.

Microsoft documents how the hashes are fetched: every two minutes the agent requests stored password hashes from a controller over the same replication protocol, MS-DRSR, that controllers use with each other, and its connector account needs the Replicate Directory Changes and Replicate Directory Changes All permissions to do it. As messages:

Northgate's connector account is MSOL_6c3b1d2e9f40, the name Entra Connect gives it at installation, and its replication requests are written on NE-DC01 as 4662, an operation on an object. Counted over the month:

SecurityEvent
| where EventID == 4662 and SubjectUserName startswith "MSOL_"
| summarize Requests = count(), Days = dcount(bin(TimeGenerated, 1d)), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SubjectUserName, Computer

708 requests on every one of the 30 days, from the first hour of the corpus to its last, all on NE-DC01. That steadiness is the account's signature. It is a legitimate replicator, and that is exactly the problem a defender faces: the rights that let it work are the same rights an attacker uses to copy every password in the domain, which Module 1 calls DCSync.

A rule that watches for replication by anything that is not a controller has to name this account as an exception, and an exception for an account this powerful only holds while the server it runs on is protected like a controller. Module 1 writes that rule and decides what the exception rests on.

The sync also joins the two directories' fates. A password set in corp.ne.com reaches Entra ID within minutes, so a password an attacker steals or sets on premises signs in to Microsoft 365 as well, mail and files included, without the attacker touching the cloud. And whoever controls the Entra Connect server controls what it writes to the tenant.

A compromise of corp.ne.com is therefore rarely contained to corp.ne.com, and the course's response modules treat the cloud side as part of the same incident rather than a separate one.

Northgate acquired Calder Fabrication, a supplier, and kept Calder's own forest while the two are consolidated. A trust joins them, so Calder's staff can use Northgate resources with their own accounts and the reverse. A forest trust links two forests so authentication requests can pass between them, and Microsoft's description of a two-way trust is that requests can pass in both directions. Northgate's, as Get-ADTrust reads it:

PS C:\> Get-ADTrust -Filter * | Format-List Name, Direction, ForestTransitive, IntraForest, TrustType, UsesAESKeys
Name             : corp.calder.example
Direction        : BiDirectional
ForestTransitive : True
IntraForest      : False
TrustType        : Uplevel
UsesAESKeys      : True

BiDirectional and ForestTransitive: Calder's forest trusts Northgate's, Northgate's trusts Calder's, and the trust covers every domain in each forest. IntraForest is false because Calder is a separate forest with its own administrators, whom Northgate does not employ and whose security it does not run.

UsesAESKeys is the encryption the trust's own Kerberos traffic uses. What a trust does not say in these lines is how much of Northgate a Calder account can reach once it is trusted, which is set by another property and is Module 17's question.

The general point stands without it: a trust widens the set of people who can authenticate to corp.ne.com to include everyone Calder's administrators let in, and a compromise of Calder's forest is a starting point inside Northgate's.

Trusts like this one are common after an acquisition, because merging two forests is slow and the business needs people to work together the week the deal closes. They are risky for the same reason. Northgate's team did not build Calder's forest, does not know who administers it or how well, and receives none of its logs.

The trust is a decision to accept Calder's sign-ins as genuine, and every weakness in Calder's forest becomes a question for Northgate. Module 17 reads the trust's settings, the authentication that crosses it in the corpus, and what narrowing it would change.

A domain is run by a small number of people, and a good domain gives each of them two accounts: a day account for mail and the web, and an admin account used only for administration, from a machine kept for it. Northgate follows the convention by name, with an a- prefix on every admin account. The corpus's directory list holds 102 accounts, and sorted by what they are for:

Eighty-five staff accounts are the people who sign in to do their jobs, plus the services and the managed accounts that run software. The few in red are the ones whose misuse reaches furthest: three admin accounts, two help desk accounts that can reset other people's passwords, and krbtgt, whose key signs every Kerberos ticket and which nobody signs in as. Who they belong to:

The ticket counts come from one query on the month, and they say something about how each account is used:

SecurityEvent
| where EventID == 4768 and Status == "0x0"
| where TargetUserName startswith "a-"
| summarize TGTs = count(), LastSeen = max(TimeGenerated) by TargetUserName
| sort by TargetUserName asc

Admin accounts that sign in eight or nine times a month are being used for administration and nothing else, which is what the convention asks for, and a single TGT for a-psharma in the whole month is an account that is almost never used.

Rare use is good for exposure and bad for detection, because there is no habit to compare an unusual sign-in against. Each of these accounts comes back in the course: a-pgreaves's sign-ins in Module 1, the help desk's reach over other accounts in Module 5, a-mwebb's sessions in Module 6.

Treat the list as a cast rather than a set of suspects. Most of what they do in the month is their job.

The reason for two accounts each is exposure. When anyone signs in to a Windows machine, that machine holds material derived from their credentials for as long as the session lasts, and anyone who controls the machine can take it.

If Phil Greaves read his mail as a-pgreaves, every laptop and server he signed in to would hold a Domain Admin's credentials, and an attacker on any one of them would be one step from the domain. A separate admin account, used only on machines kept for administration, keeps that material off the places attackers land first. Module 6 is about what happens when the rule is broken.

Every question this course asks about corp.ne.com is one of two kinds, and knowing which kind decides where you look:

The PowerShell in this lesson answered the first kind: who is in a group, how a trust is set. The queries answered the second: what the CA issued, what Entra Connect asked for, how often the admins signed in. An investigation needs both, and the course's lessons move between them constantly. This exercise is the second kind. Write the query in the editor and run it:

Both writable controllers serve nearly every account, so watching one controller is watching about two thirds of the domain. That is a fact about collection as much as about Kerberos, and it is the first of several in this course where what you can see depends on which logs reach the place you are looking.

Put the two kinds together and a question gets an answer. The PowerShell in section 3 says a-pgreaves is a Domain Admin; the query in section 7 says his admin account requested eight TGTs in the month.

A ninth TGT from a laptop in the finance team would be an event worth reading, and you would only know it mattered because the state says what the account can do. Most findings in the course have that shape: an event that would be ordinary for most accounts, made important by what the directory says the account can reach.

Lesson 0.3 sets out that evidence in full: the corpus month, its tables and how many events each holds, the evidence files that record the directory's state, and how lessons label the dates after 15 March, when the course follows Northgate's response past the end of the logs.

Practice

Next, lesson 0.3: the evidence this course reads.