Active Directory (AD) doesn’t get “hacked” in a single step—attackers authenticate, escalate, move laterally, and persist. Your best early-warning system is a carefully chosen set of audit logs, collected consistently from the right hosts (especially domain controllers).
What “good logging” looks like (before the top 10)
- Use Advanced Audit Policy (not legacy “Audit policy” only). Enforce via GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration.
- Increase Security log size on DCs (and critical servers). Most environments underestimate volume during password-sprays and ticket storms.
- Centralize collection (WEF, SIEM agent, or Defender for Identity). If a DC is impacted, local logs are the first thing attackers try to clear.
- Tag every event with asset context: DC vs member server vs workstation; tiering (Tier 0/1/2); internet-facing; jump host.
- Start with “high-signal” detections, then widen coverage. You want alerts you’ll actually respond to.
If you’re building a log pipeline specifically around identity threats, see: Event collection with Microsoft Defender for Identity.
Top 10 audit logs to collect (with what they catch)
The list below focuses on the highest “threat detection per GB” logs for AD environments. For each, you’ll see: where it lives, what to enable, and why it matters.
1) Security Log (Domain Controllers): authentication + logons
- Where: Domain Controllers → Windows Logs → Security
- Enable: Account Logon, Logon/Logoff, Kerberos auditing (Advanced Audit Policy)
- Detects: password sprays, brute force, abnormal logon types, new credential use, suspicious service ticket activity
- High-signal events (common): 4624, 4625, 4648, 4672, 4768, 4769, 4771, 4776, 4740
If lockouts and bad-password storms are a recurring issue, this is your baseline: Account Lockout Event ID: How to Find Account Lockouts.
2) Security Log (Domain Controllers): account management + group changes
- Where: Domain Controllers → Windows Logs → Security
- Enable: Account Management, Security Group Management, User Account Management
- Detects: privilege escalation via group membership, stealthy admin creation, GPO-editors being added, “shadow admin” moves
- High-signal events (common): 4720, 4722, 4723, 4724, 4725, 4726, 4728/4729, 4732/4733, 4756/4757
For one of the most abused attack surfaces (groups), also read: Auditing Nested Group Memberships: An Expert Guide.
3) Security Log (Domain Controllers): directory service access (object-level auditing)
- Where: Domain Controllers → Windows Logs → Security
- Enable: Directory Service Access + targeted SACLs on high-value objects (Domain Admins, AdminSDHolder, critical OUs, key service accounts)
- Detects: sensitive object reads/writes, permission tampering, replication-rights abuse (when scoped correctly)
- High-signal events: 4662 (object operation), 4670 (permissions changed)
Practical tip: Don’t blanket-SACL the whole directory. Start with Tier 0 objects and expand iteratively.
4) Directory Service Log (NTDS): object change trail + LDAP security signals
- Where: Domain Controllers → Applications and Services Logs → Directory Service
- Enable: keep the log; consider LDAP interface events where appropriate
- Detects: high-value attribute changes, LDAP signing/channel binding gaps, unusual directory behaviors worth correlating
- High-signal events (common): 5136 (object modified), 5137/5138/5139/5141 (create/delete/move/undelete); LDAP-related events vary by configuration
5) Kerberos-focused events (DC Security Log): ticket abuse + Kerberoasting patterns
- Where: Domain Controllers → Security
- Enable: Kerberos Service Ticket Operations, Kerberos Authentication Service
- Detects: Kerberoasting candidates being queried at scale, unusual service ticket requests, failures that map to password spraying
- High-signal events: 4768 (TGT), 4769 (TGS), 4771 (pre-auth failure)
If you want a strong mental model for what these events mean, refresh the protocol side: NTLM authentication and Kerberos Authentication Protocols Explained.
6) NTLM Operational + Security Log correlation (DCs and critical servers)
- Where:
- Applications and Services Logs → Microsoft → Windows → NTLM → Operational (where available)
- Security (e.g., 4776 validation events in many environments)
- Enable: NTLM auditing / restrictions according to your compatibility needs
- Detects: NTLM fallback, relay-prone patterns, legacy auth hotspots, high-risk servers that still accept weak flows
Win condition: you can inventory where NTLM is still required and progressively reduce it (without breaking apps).
7) Group Policy Operational Log (clients + servers): “what applied?” + “why didn’t it apply?”
- Where: Endpoints/Servers → Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational
- Enable: ensure the operational log is enabled; collect from Tier 0/1 systems first
- Detects: abnormal policy processing, suspicious refresh patterns, settings that suddenly stop applying (often a precursor to persistence)
Group Policy is a control plane. If you don’t understand the management surface, start here: Managing GPOs with Group Policy Management Console.
8) DFS Replication (DFSR) Operational Log: SYSVOL tampering + replication anomalies
- Where: DCs → Applications and Services Logs → Microsoft → Windows → DFSR → Operational
- Enable: keep DFSR operational logs; monitor SYSVOL-related paths and unexpected file activity
- Detects: malicious scripts pushed via SYSVOL, unexpected GPO template changes, replication backlog that can hide or delay changes
Why it matters: many “AD compromises” become “enterprise compromises” when attackers use GPO/SYSVOL as a software distribution mechanism.
9) DNS Server Audit + Analytical Logs: record manipulation and “AD-as-DNS” abuse
- Where: DNS servers (often DCs) → Applications and Services Logs → Microsoft → Windows → DNS-Server (Audit/Analytical where available)
- Enable: DNS auditing appropriate for your OS/version; consider selective analytical logging for investigations
- Detects: rogue record changes, suspicious dynamic updates, pivot infrastructure (C2 via DNS patterns), name-resolution manipulation used for lateral movement
Pro tip: for AD-integrated DNS, also correlate with directory object change events (because DNS records are AD objects in that model).
10) Active Directory Certificate Services (AD CS) logs (if you run a CA)
- Where: CA servers → Applications and Services Logs (CA operational logs) and Security depending on configuration
- Enable: CA auditing (issue/deny/revoke, template changes, enrollment agent activity)
- Detects: certificate-based persistence, template abuse, suspicious enrollments, stealthy long-lived access paths
Why it matters: AD CS abuse can bypass passwords entirely. If you run a CA, this belongs in your “Tier 0” logging set.
Minimum viable checklist (if you want to start today)
- DC Security log: authentication + group/account changes
- DC Directory Service log: object modifications
- DFSR Operational: SYSVOL integrity signals
- GroupPolicy Operational: processing trail from Tier 0/1 systems
- DNS logs: record changes + suspicious resolution behavior
Example: enable a few core audit categories (reference snippet)
Apply via GPO whenever possible. For quick validation/testing on a host, you can use auditpol
(run elevated). Example categories (adjust to your standards):
auditpol /set /category:"Account Logon" /success:enable /failure:enable
auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
auditpol /set /category:"Account Management" /success:enable /failure:enable
auditpol /set /category:"DS Access" /success:enable /failure:enableHigh-signal mappings: attack pattern → events to hunt
Password spray / brute force
- DC Security: spikes in 4625, 4771, 4776; correlated across many users from a small set of sources
- Watch for: many failures followed by a small number of successes (4624) from the same origin
Privilege escalation via groups
- DC Security: 4728/4729, 4732/4733, 4756/4757 on privileged groups
- Watch for: changes outside change windows; “helpdesk” accounts touching Tier 0 groups
Kerberoasting setup / execution
- DC Security: 4769 surges for specific service accounts; unusual encryption types and request volume
- Watch for: one user requesting many different service tickets quickly
GPO/SYSVOL-based persistence
- Directory Service: 5136 changes to GPO-related objects
- DFSR: unusual SYSVOL replication activity; new/modified scripts in policy paths
- GroupPolicy Operational: endpoints suddenly processing new scripts or scheduled tasks
Replication-rights abuse (DCSync-style behavior)
- DC Security (when scoped with SACLs): 4662 on directory replication-related rights
- Watch for: non-DC principals exercising replication permissions
NTLM fallback / relay-prone flows
- NTLM Operational + Security correlation: identify which servers still accept NTLM and from where
- Watch for: “sudden” NTLM usage where Kerberos was expected
Collection architecture (so your logs survive an incident)
- Collect from DCs first (they hold the identity truth).
- Centralize quickly: Windows Event Forwarding (WEF), SIEM agents, or Defender for Identity sensors.
- Normalize and enrich: resolve SIDs, map hosts to tiers, tag admin workstations/jump boxes.
- Protect log pipelines: separate credentials, least privilege service accounts, and immutable storage for critical streams.
- Alert on log tampering: “log cleared” events and sudden drops in volume from critical sources.
Tuning tips (reduce noise without going blind)
- Start with Tier 0: DCs, CA servers, ADFS (if present), privileged admin workstations, identity tooling servers.
- Prefer allowlists for admin tooling: known jump hosts and management servers should be measurable and explainable.
- Make baselines: “normal” 4769 volume, normal 4625 rate, normal privileged group change cadence.
- Turn raw events into detections: alerts should describe an investigation step, not just an event ID.
- Keep retention realistic: keep enough to investigate “slow” intrusions (weeks), not just noisy incidents (hours).
