Wide uses the full column for everything, text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
▾
Active Directory Security for Defenders: Course Orientation
Module 0
ACTIVE DIRECTORY SECURITY FOR DEFENDERS · MODULE 00
Detect the domain compromise in the logs you already have.
An attacker who lands one phishing click and walks out with Domain Admin rarely uses a zero-day. They use Kerberos the way it was designed, a service account nobody rotated, a delegation right nobody reviewed, replication permissions that looked normal until they were not. Every one of those steps writes a record in the Windows Security log. This course teaches you to read that record: to recognize Kerberoasting, DCSync, AD CS abuse, and the 2025-era dMSA path as they happen, write the detection as a rule you can carry anywhere, and harden the weakness so the next attacker does not get the same run. You work against a real compromised domain in the browser, with no lab to build and no SIEM required.
12 modules
across 6 phases
Source-first
Sigma into Windows, KQL, SPL
Browser labs
nothing to provision
No prerequisites
every concept built up
Why this course exists
Active Directory is where a single compromised identity becomes the whole domain. One foothold on one laptop, and a patient attacker walks the trust relationships, the service accounts, and the delegation rights until they own everything. That path is well understood by the people running it. The gap is on the defending side, and it is wider than most teams admit, because the organizations most exposed on Active Directory are often the least instrumented. They do not have a cloud SIEM. They do not have Defender for Identity. They have a couple of domain controllers, the default audit policy, and an assumption that patching is the same as defending.
So a detection course built on Sentinel-only queries fails exactly the people who need it most. This one is source-first. The evidence layer is the Windows Security Event Log, which every domain already produces, the same events you can read with Get-WinEvent on a controller or forward to any collector. You learn the underlying event before you learn any query: what a 4769 with RC4 encryption actually means, why a 5136 on a service principal name is the start of an escalation, what a 4662 carrying replication GUIDs tells you about who is reading the directory. Then you render each detection four ways, as a portable Sigma rule first, then in Windows PowerShell, KQL, and SPL, so you leave with something you can deploy against whatever you actually run. Defender for Identity, when you have it, is an enhancement that sharpens a few detections. It is never the thing the detection depends on.
What you will be able to do
By the end you take an Active Directory intrusion apart from the telemetry side. You recognize reconnaissance for what it is and, where the native logs go quiet, you fall back to posture instead of pretending a detection exists. You catch Kerberoasting and AS-REP roasting by the encryption type on the ticket request, reconstruct lateral movement from the logon events, and spot the privilege-escalation writes, a service principal name set on the wrong account, a resource-based delegation right, the dMSA successor link that BadSuccessor abuses on Server 2025. You detect domain dominance at its loudest and its quietest: DCSync from a principal that has no business replicating, a golden ticket betrayed by an encryption downgrade, a certificate issued with someone else's name in it. And for every one of those, you leave with a portable Sigma rule and its concrete form in the stacks defenders actually run, plus the hardening change that removes the path so the detection becomes a backstop rather than the only line.
The attack surface you will defend
The course follows one domain compromise from first touch to total control, and it teaches you the event that catches each step. Reconnaissance maps the targets. Credential access roasts a weak service account and replays what it cracks. Escalation abuses a delegation right and a successor link. Dominance replicates the directory and forges tickets. The seam to the cloud carries the whole thing into your Entra tenant. None of it is silent if you know where to look.
How the course is built
Twelve modules across six phases, plus a capstone where you detect the whole chain end to end and produce a hardening plan as the deliverable. The two reference modules at the end hold the consolidated detection library and the further reading. You can read straight through, or jump to the phase that matches the attack you are worried about.
What you need and who this is for
There are no prerequisites, and every concept is explained the first time it appears. If you know Active Directory already, the you-already-know anchors let you move past what you have and spend your time on the detection. This course is for anyone who has to defend Active Directory rather than attack it: SOC analysts triaging identity alerts, detection engineers writing the rules, blue-teamers who want to understand the attacks they keep reading about, and AD administrators moving from running the directory to defending it.
A real compromised domain, in the browser
Every detection runs against the Northgate Engineering corpus, a full on-prem AD estate carrying one seeded intrusion. Nothing to provision, no domain to stand up, no attacker tools to run.
Detections you keep
You leave with a library of portable Sigma rules, each rendered into Windows PowerShell, KQL, and SPL, that you can deploy against whatever your environment actually runs.
Source-first, no SIEM required
The detections rest on the Windows Security log every domain has. A cloud SIEM or Defender for Identity makes some of them sharper, but none of them depend on it.
Do I already know this material?
Six quick scenarios across the full range of this course, from why a weak service account is a risk to detecting AD attacks with no SIEM at all. Answer them to find out where you sit, and whether this course fits or it will sharpen instincts you already have.
A service account has a registered service principal name and a password that has not changed in years. Why is that a risk even though the account is not an administrator?
It is not a risk; non-admin accounts cannot be abused.
Any domain user can request a service ticket for it and crack the password offline, because the ticket is encrypted with the account's password hash.
This is Kerberoasting. An account with an SPN can have a service ticket requested by any authenticated user, and that ticket is encrypted with the service account's key, so a weak password can be cracked offline at the attacker's leisure, with nothing logged on the cracking side.
Service accounts cannot have passwords, so there is nothing to steal.
The risk only exists if the account can log on interactively.
A Domain Admin logs on interactively to an ordinary user workstation to fix a problem. Why does that worry a defender?
The privileged credential or ticket is now exposed on a lower-trust machine an attacker may already hold, where it can be stolen and reused.
Tier-0 credentials should never touch Tier-2 machines. Once a Domain Admin authenticates to a workstation, the credential material is recoverable from that host, so a single compromised laptop becomes a path straight to the top of the domain.
It is fine; admin logons are always safe.
It only matters if the workstation is unpatched.
The risk is that the admin will see the user's files.
An attacker requests service tickets for many accounts so they can crack them offline. In the Windows Security log, what is the tell that separates this from normal Kerberos activity?
A spike in 4624 logon events.
A 4768 from an unfamiliar IP address.
A 4769 service-ticket request with RC4 encryption (type 0x17) for a normal service account, since attackers force the weaker, crackable cipher.
Healthy modern Kerberos negotiates AES. A 4769 requesting RC4 (0x17) for a service that is not krbtgt is the Kerberoasting signature: the attacker downgrades to the cipher they can crack. You filter on the encryption type, not the volume.
There is no way to detect this in the Windows log.
An account that is not a domain controller performs directory replication. What is happening, and how do you catch it?
A normal backup job; nothing to detect.
DCSync: the attacker is using replication rights to pull password hashes, visible as a 4662 carrying the replication access GUIDs from a principal that is not a DC.
DCSync abuses the same Get-Changes replication right that DCs use to sync. Only domain controllers and sync accounts should replicate, so a 4662 with the DS-Replication-Get-Changes GUIDs from any other principal is the detection, allowlisting the known replicators.
A misconfigured workstation; safe to ignore.
Replication is not logged, so it cannot be detected.
On Windows Server 2025, an operator writes the msDS-ManagedAccountPrecededByLink attribute on a delegated managed service account. Why does that matter to a defender?
It is routine dMSA maintenance with no security impact.
It only affects the service account's own password rotation.
It disables auditing on the object.
It is the BadSuccessor technique: the dMSA inherits the privileges of the linked account, so writing that link to a Tier-0 account is a domain-takeover path, detected on the 5136 attribute-modification event.
BadSuccessor abuses dMSA migration on Server 2025. Setting the preceded-by link makes the dMSA a successor that inherits the linked account's access, so a write pointing at a privileged account is escalation. The 5136 naming that attribute is the detection.
You have no Microsoft Sentinel and no Defender for Identity. Where do you still detect these Active Directory attacks?
You cannot; AD detection requires a cloud SIEM.
Only on the endpoints, through the antivirus.
In the Windows Security Event Log on the domain controllers, the universal evidence layer, with detections written as portable Sigma you can run there or forward anywhere; MDI is an enhancement, not a requirement.
This is the course's thesis. The Security log on the controllers carries the 4769, 4662, 5136, and 4887 events these attacks produce, readable with Get-WinEvent or forwarded to any SIEM. Defender for Identity sharpens recon and directory-change signal, but the detection never depends on it.
Nowhere reliable; you have to wait for the breach to surface.
This course is for you.
You will go from the structure of Active Directory and where it is logged, through detecting every step of a domain compromise, to hardening the paths and responding when one gets through, all in the Windows telemetry you already have.
You have the fundamentals. The value here is the harder half.
You understand the basics of why AD is exposed, so the payoff is the back half: detecting delegation and SPN abuse, the Server 2025 dMSA path, DCSync and forged tickets, AD CS abuse, the hybrid pivot, and writing it all as portable detections you can deploy without a SIEM.
You handled Kerberoasting by encryption type, DCSync by replication rights, BadSuccessor on Server 2025, and source-first detection with no SIEM, the senior end of this discipline. Take the course to sharpen what you have, pick up the current techniques like CVE-2026-25177 and the dMSA path, and turn strong instincts into a detection library you keep.
You are a student of this course now, so start by deciding what you want from it. Are you here to stand up AD detection where there is none today, to close the gaps that let a foothold become a domain compromise, or to understand the attacks well enough to harden against them before they run? Name that outcome, then turn it into a study plan: which phases matter most to your environment, how much time you will give it each week, and which detections you want deployed by the time you finish.
The rest of Module 0 sets you up to do that. Work through it to see the Northgate domain you will defend, how its telemetry is laid out, the way each detection is built and rendered across the four surfaces, and the lab you will work in. Then begin Module 1.
Stuck on this lesson?
Your question goes straight to the team and we'll reply by email. Sign in to ask.
