0.1 What Active Directory Is and Why Attackers Want It

Introduction

Active Directory is the database a Windows business uses to decide who anyone is and what they may do. Every account a person signs in with, every computer joined to the network, every group that grants access to a share or a server, lives in it.

Northgate Engineering runs one domain, corp.ne.com, and this course defends it. Before any module reads an attack, it helps to see the parts an attacker is after and how they fit, because every attack in the course is a misuse of one of them.

The figure is the whole subject on one page. The directory lives on domain controllers, and every writable controller holds all of it, including the secret derived from each account's password. When someone signs in, their computer proves who they are in one of two ways.

With Kerberos it asks a controller's Key Distribution Center for tickets and shows those tickets to servers. With NTLM it answers a challenge from the server, and the server asks a controller whether the answer is right. Either way, the controller is the authority.

Whoever controls the controllers decides who everyone is, which is why attackers aim for them and why this course spends most of its time on the events controllers write. By the end of this lesson you will be able to name the parts, read a Kerberos sign-in in the controllers' own events, and say which stage of an intrusion each later module is about.

Microsoft describes a directory as a hierarchical structure that stores information about objects on a network, and Active Directory Domain Services is that structure for a Windows business. An object is a thing the business needs to name: a person's account, a computer, a group, a printer, a policy. Each object is a set of attributes, and the attributes are where the decisions live.

A user object holds the name you sign in with, the groups you belong to, when your password last changed and whether the account is enabled. Here is one Northgate user, read the way an administrator reads it:

PS C:\> Get-ADUser n.ellery -Properties Department, MemberOf, lastLogonTimestamp |
>>     Format-List SamAccountName, UserPrincipalName, DistinguishedName, SID, Enabled, Department, MemberOf
SamAccountName    : n.ellery
UserPrincipalName : n.ellery@ne.com
DistinguishedName : CN=n.ellery,OU=Staff,DC=corp,DC=ne,DC=com
SID               : S-1-5-21-3623811015-3361044348-30300820-1567
Enabled           : True
Department        : Operations
MemberOf          : {CN=Operations,OU=Groups,DC=corp,DC=ne,DC=com}

Three lines carry most of the meaning. The distinguished name, CN=n.ellery,OU=Staff,DC=corp,DC=ne,DC=com, is the object's place in the tree: a container called Staff inside the domain corp.ne.com. The SID is the number Windows actually uses to identify the account; the name can change, the SID cannot, and every permission in the domain is written against SIDs.

MemberOf is the list of groups, and groups are how access is granted, so what an account can reach is mostly a question of what its groups can reach.

The structure matters because almost every control in the domain is attached to a place in it. Group Policy is linked to containers, so where a computer object sits decides which settings it gets. Permissions on a container are inherited by the objects inside it, so a right granted on Staff is a right over every account in Staff.

An administrator who moves an object, or grants a right on a container, is changing more than one thing at once, and a lot of the attacks in this course rely on that: a single permission high in the tree that reaches many objects below it.

The directory is also the schema, the rules for which kinds of objects exist and what attributes each may hold, and the global catalog, a forest-wide index for finding objects. You will meet both again, but the working idea is simple: the directory is a database of objects, and security in it is a matter of who may read or change which attribute of which object.

A domain controller is a server that holds a copy of the directory and answers questions about it. Microsoft's overview puts it plainly: all domain controllers in a domain participate in replication and contain a complete copy of all directory information for their domain, and any change to directory data is replicated to all domain controllers in the domain.

Northgate's inventory lists two writable controllers at its Manchester office, NE-DC01 and NE-DC02, and a read-only controller at the Birmingham branch, NE-RODC01, which holds a copy it cannot change and, by default, no passwords. What a writable controller holds and does:

Read the first row twice, because it is the reason the course exists. The directory database on every writable controller holds the secret derived from every account's password, including every administrator's and the secret of the krbtgt account that signs every Kerberos ticket.

A copy of that file, or the right to ask a controller to replicate those secrets, is a copy of every identity in the business. Module 1 opens on exactly that: who signs in to the controllers, how the database file gets stolen, and how replication rights get abused to pull secrets over the network without touching the file at all.

Replication is the other half. Because every writable controller accepts changes and sends them to the rest, a change made on NE-DC02 at Manchester reaches NE-DC01 within moments and the Birmingham controller soon after.

That is what makes the domain reliable, and it is also what makes an attacker's change durable: a group membership added on one controller is everywhere. It also means a controller nobody watches is still a full participant, holding the same secrets and accepting the same changes, which is a question Module 1 asks of Northgate's own estate.

Kerberos is how a domain account proves who it is without sending its password around the network. The Key Distribution Center runs on every domain controller and uses the directory as its account database. When a user signs in, the computer contacts the KDC once, proves it knows the password, and receives a ticket-granting ticket, the TGT.

From then on, to reach a service, the computer shows its TGT to the KDC and asks for a service ticket for that particular service, then presents the service ticket to the server. Here is n.ellery's morning of 16 February as those messages:

The password is used once, at 08:00:46, and the controller records it as event 4768, a TGT requested. Every service ticket after that is event 4769, a service ticket requested, with the service named in it.

Microsoft's reference for both events says they are generated only on domain controllers, which is why the controllers' Security log is where Kerberos is read. The same morning, as the controller wrote it down, runs on the corpus here:

SecurityEvent
| where TimeGenerated between (datetime(2026-02-16 08:00) .. datetime(2026-02-16 10:40))
| where EventID in (4768, 4769)
| where TargetUserName startswith "n.ellery"
| project TimeGenerated, EventID, Computer, TargetUserName, ServiceName, IpAddress
| sort by TimeGenerated asc

Five rows, all from the laptop at 10.0.3.78 and all on NE-DC02. The first has ServiceName krbtgt, the account whose key signs every TGT, so a 4768 always names it. The next four name what n.ellery reached in the next two and a half hours: the backup service account, NE-DC01 itself, an application server and the print server.

That is an ordinary morning, and it is the shape every Kerberos attack in the course distorts: a ticket requested for an unusual service, a TGT that was never requested from a password, a ticket encrypted the old way, a service ticket for an account that should never have one. Module 9 reads those distortions one at a time. The reading starts here, with what normal looks like.

Two settings explain the rhythm of these events.

Northgate's Kerberos policy, read from the Default Domain Policy in Module 1, gives a TGT a lifetime of 10 hours and a service ticket 600 minutes, and allows clocks to differ by five minutes. So a person who signs in at eight and works until six needs about one TGT a day, and the 4768 for n.ellery each morning is the start of a working day.

A TGT is also only as trustworthy as the key that signed it, the krbtgt account's. The KDC does not look a TGT up to see whether it issued it; it checks that the krbtgt key decrypts it.

Anyone holding that key can write a TGT for any account, with any groups, and the controllers will honor it, which is why the krbtgt secret is among the first things an attacker who reaches the database takes, and why resetting it is a step in every recovery the course teaches.

NTLM is the older protocol, and it works differently. The server sends the client a challenge, the client answers with a value computed from the password's hash, and the server, which does not hold domain secrets, passes the answer to a domain controller to check.

Microsoft's NTLM overview calls Kerberos the preferred method in Active Directory and NTLM still supported, used for systems in a workgroup, for local sign-ins, and by applications that ask for it. Which one a sign-in uses comes down to one question:

The fork matters to a defender because NTLM is weaker in ways attackers use. The answer to a challenge can be relayed to a different server, and the hash behind it is as good as the password for signing in, which is the subject of Module 8.

Microsoft's reference for event 4776 says it is written on the computer that is authoritative for the credentials, which for a domain account is a domain controller. So both protocols leave their trace on the controllers, and one count over the month shows how much of each Northgate's controllers handled:

SecurityEvent
| where EventID in (4768, 4769, 4771, 4776)
| summarize Events = count() by EventID, Activity, Computer
| sort by EventID asc, Computer asc

Seven rows. NE-DC01 and NE-DC02 share the Kerberos work, and every NTLM validation in the month, 202 of them, happened on NE-DC01, against 15,723 Kerberos tickets. That ratio is healthy, and it is also a list: 202 validations is a small enough number to read by hand, and Module 8 does.

The 84 pre-authentication failures, 4771, are Kerberos sign-ins that started with the wrong password, mostly mistyped. The course writes every detection in Splunk as well as KQL, and the same count in SPL returns the same seven rows:

index=wineventlog sourcetype="WinEventLog:Security" EventCode IN (4768, 4769, 4771, 4776)
| stats count AS Events BY EventCode, host
| sort EventCode, host

The two languages agree row for row, and that agreement is a rule the course holds itself to: every detection is written for Sentinel and for Splunk against the same evidence, and both must return the same entities before either is shown. If your SIEM is neither, the logic carries over, because what you are reading is the controller's event and its fields.

What this count cannot tell you is who used NTLM, or why, and that is the more useful question. A count is where a reading of authentication starts, and every later detection in the course moves from a count like this one to the few rows inside it that do not belong.

The directory decides who may do what everywhere it is trusted, and in a Windows business that is nearly everywhere: file shares, mail, databases, the laptops people carry, the servers that run payroll. A small number of groups hold the power to change those decisions, and the built-in Administrators group shows how they nest:

PS C:\> Get-ADGroupMember Administrators | Format-Table Name, ObjectClass -AutoSize
Name              ObjectClass
----              -----------
Administrator     user
Domain Admins     group
Enterprise Admins group

Administrator is the built-in account, and the two groups are the domain's and the forest's administrators, nested inside the built-in group. Microsoft's guidance on privileged groups explains what each reaches. Domain Admins is a member of the domain's Administrators group and of the local Administrators group on every computer joined to the domain.

The built-in Administrators group has full control of most directory objects. Enterprise Admins is placed in Administrators in every domain of the forest. And a member of any one of the three can change the directory to join the others, so Microsoft says that from the perspective of potential privilege all three should be considered effectively equivalent. Drawn as what one group reaches:

Each route ends at everything. Through the directory, Domain Admins can reset any password and add anyone to any group. Through local administrator rights it can sign in to any workstation or server and read what is there. Through the controllers it can read the database and take every secret.

Microsoft's guidance on securing controllers draws the conclusion for the third route: because controllers can read and write anything in the database, a compromised controller means the forest can never be considered trustworthy again unless it is recovered from a known good backup.

That is why an attacker inside a Windows business works toward the directory rather than toward a single file server: one identity with these rights is every file server. It is also why the course treats membership of these groups, and the much larger set of rights that are equivalent to it, as the thing to watch.

Module 5 lists every way into them at Northgate, and Module 3 shows a compromise that reached the domain without joining any of them.

An intrusion into Active Directory is rarely one act. It is a sequence: a foothold on one machine, learning the domain, taking a credential, using it to reach somewhere with better credentials, and repeating until the attacker holds an identity that controls the directory. Then they make sure they can come back.

The course's Project follows one such sequence from first email to persistence, and each stage is taught in its own module:

The middle of that line is where a defender wins. An attacker on one workstation with one user's password has done limited harm; an attacker who has replicated the domain's secrets has done harm that only a forest recovery undoes, the subject of Module 23.

Every stage in between leaves events on the controllers, and each module teaches the stage's events and the detection that catches them. The questions each stage asks of you:

Two cautions keep the line honest. Real intrusions skip stages, repeat them and take routes the line does not show: an attacker who finds a privileged account's password in a script on SYSVOL, the share every computer reads its policy from, skips most of the middle, which is lesson 1.3. And the stages are not all attacks in the narrow sense.

Several are an attacker using exactly the rights the domain gave them, which is why so much of the course is about finding what those rights are before anyone uses them. Lesson 3.1 reads Northgate's own intrusion as a sequence like this one, with the gaps between stages measured in hours.

Every module reads events, so it helps to see the whole month at once. The course's corpus holds the Security logs from Northgate's two writable controllers and its certificate authority, from 14 February to 15 March 2026, and one query counts them by event ID:

SecurityEvent
| summarize Events = count() by EventID, Activity
| sort by Events desc

Thirteen event IDs in a month, which is fewer than you might expect, drawn by size so the scale of each is visible:

Nearly three quarters of the month is authentication: the two Kerberos events and the NTLM validations from sections 3 and 4. The next block is what the directory itself does: 4662, an operation on an object, which is how replication is recorded, and 4624, a sign-in to the controller.

The rare rows at the bottom are where most of this course's attacks appear, because attacks are rare events against a large normal background: a password reset, a group addition, a directory change. That is the shape every detection in the course works with.

A rule that fires on a common event fires all day; a rule that fires on a rare one has to be sure the event really is rare and does not hide in a common one.

Module 2 teaches which audit settings make each of these events appear in the first place, because a controller writes only what its audit policy tells it to, and an event that was never enabled cannot be found.

The exercises in this course are graded on the rows your query returns from the corpus, the same way your own queries would be judged on your own data. This first one asks a simple question that teaches a habit: when the controllers hand out ticket-granting tickets, who are they giving them to? Write it in the editor and run it:

The answer surprises people the first time. Computers ask for tickets too, because a domain-joined computer has its own account in the directory and signs in to the domain on its own, and in Northgate's month they asked for about as many TGTs as people did.

That is the habit: an identity in Active Directory is any account, and a computer account can be used by an attacker who controls the computer exactly as a user account can. Several modules turn on that fact, from delegation in Module 13 to the controllers' own accounts replicating in Module 1.

The rest of Module 0 shows the parts of the course that sit around the lessons: Northgate's domain in detail in lesson 0.2, the evidence the course reads in 0.3, a first full investigation in 0.4, the four forms every detection is written in in 0.5, and what the course builds in 0.6.

Each lesson after that names one attack or one defender task, and each ends where this one does, with something to do in a domain of your own.

Practice

Next, lesson 0.2: Northgate's domain, its controllers, its tier 0, its certificate authority, Entra Connect, the trust with Calder, and the people who run it.