The Defender's Telemetry Map for Active Directory

You already know a domain controller writes a Security log. What you may never have done is ask it the one question this course depends on: if an attacker moved against the domain yesterday, which event would hold the proof, and is that event even switched on. This sub draws the map.

Every technique in this course produces evidence, but only in a specific event, and only if the right audit category is enabled. Learn that mapping once, here, and the rest of the course is reading comprehension.

The map is small. A handful of event IDs cover the whole chain from recon to dominance, and they cluster by attack stage, which is how you should hold them in your head.

Where the events come from

Almost everything starts with Kerberos, so start there. When you log on, your machine asks a controller to authenticate you and receives a ticket-granting ticket. That request is logged as a 4768.

When you then reach a specific service, a file share, a SQL database, your machine presents the ticket-granting ticket and asks for a service ticket for that service. That request is logged as a 4769.

The diagram below shows where each event is born. Hold onto it, because two of the most common attacks in the course are nothing more than an abnormal 4768 or 4769.

Kerberos is not the only authenticator

Kerberos is the modern path, but the domain still falls back to NTLM, and NTLM has its own event. A 4776 is logged on the controller when it validates an NTLM credential.

That matters for two reasons. An attacker holding a stolen hash rather than a ticket authenticates over NTLM, so a run of 4776s tied to a service account or an admin can be the tell for pass-the-hash.

And an NTLM authentication where Kerberos should have been used is itself a downgrade worth questioning. You spend most of the course in Kerberos, because most modern attacks live there, but keep 4776 in view. When the Kerberos events look clean and something is still wrong, the NTLM log is often where the answer sits.

The events, grouped by attack stage

Group the events the way the attack groups, and they stop being a list to memorize and become a story you can read. Each stage below has a small set of techniques and a small set of events, and the same handful of events recur in different costumes across the chain.

For credential access against Kerberos, the events are 4768 and 4769, and both carry the single most useful value in AD detection: the ticket encryption type. Healthy modern Kerberos uses AES, shown as type 0x12. An attacker forcing the weaker, crackable cipher shows RC4, type 0x17.

Kerberoasting is a 4769 with RC4 for a normal service account. AS-REP roasting is a 4768 for an account whose pre-authentication is disabled. The cipher is the tell in both.

The reason this works for the attacker is that the service ticket is encrypted with the service account's own key. Request it, carry it away, and crack it offline at leisure. Nothing on the controller records the cracking, so the only moment you can catch the attack is the request itself, which is why the 4769 and its cipher field carry so much weight.

For escalation through directory changes, the event is 5136, a directory object was modified. So many escalations are, at bottom, writing one attribute onto one object, and 5136 records the write.

The attribute name is what separates routine from hostile. Writing a service principal name is a 5136 on servicePrincipalName. Resource-based delegation is a 5136 on msDS-AllowedToActOnBehalfOfOtherIdentity. The Server 2025 dMSA abuse is a 5136 on msDS-ManagedAccountPrecededByLink. You learn to read the attribute, not just the event ID.

What makes 5136 so valuable is that it is the chokepoint for a whole class of escalations. An attacker can dress the goal up a dozen ways, but to gain the rights they want they usually have to write something into the directory, and the write is logged. Watch the right attributes on the right objects and you catch escalations that look nothing alike at the surface.

For domain dominance, three events matter. A 4662 carries the replication control-access-right GUIDs, and a 4662 with those GUIDs from anything that is not a controller is DCSync. A 4769 reappears for a forged golden ticket presented with an encryption downgrade. And 4728, 4732, and 4756 record a member added to a privileged group.

These are the highest-severity detections in the course, because by the time they fire the attacker is at or near the center. A real DCSync from a workstation, a golden ticket for the krbtgt service, a controlled account dropped into Domain Admins, each is close to game over and has to be treated as an incident the moment it appears, not triaged like a routine alert.

For AD Certificate Services and coercion, a 4887 is logged on the issuing authority when it approves a request, and the ESC1 family shows as a 4887 where the requester and the subject do not match. A 5145 for the spoolss pipe is the fingerprint of coercion.

Certificate abuse deserves special attention because a certificate is a durable credential. An attacker who enrolls one in an administrator's name holds a key that survives password resets and is awkward to revoke, so the 4887 mismatch is worth catching early rather than after the certificate has been used.

Reading one event

A map is abstract until you read a record off it, so here is the most important event in the course, a 4769, with the fields that matter named. Notice the answer to "was this Kerberoasting" sits in plain fields, not hidden.

EventID:                 4769
TimeGenerated:           2026-03-11T09:24:50Z
Computer:                NE-DC01.corp.ne.com
TargetUserName:          r.lewis            (who requested the ticket)
ServiceName:             svc-sql            (the service the ticket is for)
TicketEncryptionType:    0x17               (RC4 - the weak, crackable cipher)
Status:                  0x0                (success)
IpAddress:               10.0.1.155

A normal user requested a ticket for a service account using RC4 instead of AES. You do not need a SIEM to reach that judgment, you need to know that 0x17 is RC4 and that a healthy domain negotiates AES.

That is the whole shape of AD detection: an event you can read, a field that carries the tell, and a sense of what normal looks like so the abnormal stands out.

Read the source as well as the cipher. The request came from 10.0.1.155, a workstation, for the SQL service account. A normal SQL service ticket is requested by the application servers that actually use SQL, not by a random workstation. The cipher tells you how, the source tells you from where, and together they turn one event into a small story you can act on.

Why you key on the field, not the volume

A busy controller writes an enormous number of events, and the attack records are a tiny fraction of them. A healthy domain produces thousands of legitimate 4769s a day, almost all AES, as people reach services normally.

The Kerberoast is one or two RC4 requests inside that flood. You will not find it by looking for a spike, because one extra ticket is not a spike. You find it by filtering on the field that separates hostile from normal and letting the count fall to the handful that match.

This is the habit that separates a usable detection from an alert cannon. You decide what single fact distinguishes the attack from the millions of normal events around it, you filter on that fact, and you accept that the right answer is usually a very small number of rows. If a detection returns hundreds, it is almost always keyed on the wrong thing.

The audit policy that has to be on

Now the part that bites teams. Several of these events are not written under default Windows settings. The logon events come for free, but the directory-change and object-access events that catch escalation and DCSync depend on advanced audit categories being enabled on the controllers.

The practical consequence is blunt: a domain can look like it has no AD attack telemetry when the categories were simply never switched on. Confirming they are enabled, and that 5136 is actually writing, is one of the first things you do when you take over a domain.

A quick check is to read the effective audit policy on a controller and confirm the Account Logon, DS Access, and Account Management subcategories are set to log success. If they are not, the events in this map do not exist yet, no matter how good your queries are, and the first fix is a policy change rather than a detection rule.

It is also the honest limit of the map. Even with everything enabled, native Windows does not log the LDAP queries an attacker uses for recon, which is why that module teaches posture rather than a detection rule. Knowing the limits of the map is as important as knowing the map.

What the map does not cover, and what sharpens it

Hold two more things in view. The native map above is the floor, the evidence every domain has. It has one real blind spot, recon, and one common enhancement, Defender for Identity.

Where you run Defender for Identity, its sensors on the controllers add signal the raw log does not have, most usefully around that recon gap, surfacing the LDAP and enumeration patterns as their own events. It also raises named, triaged alerts for many of these attacks, which is a faster entry point than reading raw 4769s.

This course treats Defender for Identity as an enhancement on top of the native map, never as a requirement. Every detection rests first on the Windows events here. Where the enhancement is present you gain sharper recon visibility and faster alerts; where it is absent the map still works, which is the whole point of building on the universal log.

With the map in hand, the next sub answers the question it raises: if all of this lives in the Windows Security log, what do you actually need to read it, and what changes when you do or do not have a SIEM on top.