How to use audit policies to detect threats early

Most Active Directory compromises begin quietly: a single weak password, a misused privilege, an unusual logon, a sensitive group membership change, or a domain controller (DC) receiving a rare replication request. Audit policies convert those “quiet” moments into evidence.

But enabling auditing is not the goal. The goal is to produce high-fidelity signals that let you:

• Detect threats early (before lateral movement and privilege escalation).
• Investigate quickly (clear event IDs + consistent collection).
• Prove what happened (forensics and compliance).

Treat auditing like a layered sensor network. Each layer answers different questions:

Don’t enable “everything” everywhere. It creates noise and retention failures. Enable broadly on DCs, selectively elsewhere.

Modern Windows auditing is driven by Advanced Audit Policy Configuration (subcategory-level), not the older “classic” category auditing. Subcategories give you precision (signal) and prevent “enable all” decisions that blow up log volume.

Where to configure it (Group Policy)

Use a dedicated GPO (and link appropriately) rather than editing Default Domain Policy. If you need a refresher on GPO basics and planning, see: Active Directory Group Policy.

Computer Configuration
  └─ Policies
     └─ Windows Settings
        └─ Security Settings
           └─ Advanced Audit Policy Configuration
              └─ Audit Policies

Recommended starting baseline (Domain Controllers)

This is a pragmatic baseline that supports early threat detection without turning your Security log into a firehose. Validate in a test OU/DC first.

• Account Logon: Audit Credential Validation (Success/Failure)
• Account Management: User Account Management, Security Group Management (Success/Failure)
• Logon/Logoff: Logon, Logoff, Special Logon (Success/Failure where applicable)
• Policy Change: Audit Policy Change, Authentication Policy Change (Success)
• Privilege Use: Sensitive Privilege Use (Failure, consider Success for privileged hosts)
• DS Access: Directory Service Access (Failure; enable Success selectively with SACLs)
• DS Changes: Directory Service Changes (Success)
• System: Security System Extension, System Integrity (Success/Failure)

If you’re using MDI, Microsoft has specific audit requirements. The walkthrough (including “where in GPMC” and which subcategories matter) is covered here: Event collection with Microsoft Defender for Identity.

Below is a threat-driven set of “watch first” events. Your SIEM rules should correlate these over time, per user, per host, and by source IP/subnet.

1) Password spraying and brute force (early credential access)

• 4625 (Failed logon) on DCs and endpoints
• 4771 (Kerberos pre-authentication failed) on DCs
• 4776 (NTLM authentication) where NTLM is still used
• 4740 (Account lockout) on DCs

2) Kerberos abuse patterns (early lateral movement indicators)

• 4768 (TGT requested), 4769 (TGS requested), 4771 (pre-auth failures)
• Alert on unusual service ticket volume per user, or “first time seen” requests for high-value SPNs
• Alert on service ticket requests from atypical hosts (e.g., workstation requesting many server tickets)

3) Privilege escalation via group changes (fastest “domain takeover” path)

• 4728 (member added to global security group)
• 4732 (member added to local security group)
• 4756 (member added to universal security group)
• 4729 / 4733 / 4757 (member removed)

If your environment uses nested groups heavily, direct “added to Domain Admins” isn’t the only danger—nested paths can create silent privilege. See: Auditing Nested Group Memberships: An Expert Guide.

4) Suspicious admin logons (early “hands on keyboard”)

• 4624 (Successful logon) + logon type analysis (e.g., 3 network, 10 RDP)
• 4672 (Special privileges assigned to new logon) – very useful on DCs and privileged servers
• Alert on admin logons from non-admin workstations, unusual geos/subnets, or outside expected hours

5) Directory changes and risky object modifications

Directory Service Changes are where “configuration tampering” shows up—changes to users, groups, delegation, and security descriptors.

• 5136 (Directory object modified)
• 5137 (Directory object created)
• 5141 (Directory object deleted)

For sensitive objects, configure SACLs so the “right changes” are logged without logging all reads. Prioritize:

• Admin groups and their members
• Service accounts (especially with SPNs)
• GPOs and GPO-linked containers (domain controllers OU, tier-0 OUs)
• Objects with delegation settings

6) Log tampering and “covering tracks”

• 1102 (The audit log was cleared) — always alert
• 4719 (System audit policy was changed) — alert, and include “who/where” context

7) Hybrid visibility (Entra ID / Azure AD)

Early identity threats often straddle on-prem AD and the cloud. If you’re hybrid, correlate: on-prem logon anomalies + Entra sign-in risk + Entra audit events.

For practical monitoring and reporting patterns in Entra, see: How to monitor and report security events in Microsoft Entra ID.

Start with “where” tuning (scope), then “what” tuning (subcategory)

• DCs: broad coverage (you need it)
• Servers: prioritize tier-0 and high-value servers
• Endpoints: privileged workstations and high-risk users first

Prefer correlation rules over single-event rules

A single 4625 is usually noise. One hundred 4625 events across many accounts, from one source, in ten minutes is a spray. Use thresholds plus “distinct account count” and “distinct host count”.

Use SACLs for precision on object access

Enabling “Directory Service Access: Success” everywhere can explode volume. Instead, enable the subcategory and apply SACLs only on: admin groups, high-value OUs, and critical objects.

1) Centralize log collection

Options include Windows Event Forwarding (WEF), SIEM agents, or native security platforms. The most important thing: standardize what is collected from which tier so investigations are consistent.

2) Add context enrichment

• Tag assets by tier (DC, Tier-0 server, workstation, etc.)
• Tag accounts (break-glass, service, admin, VIP)
• Add identity context (group membership, “newly privileged”, recent password reset)

3) Build a small, high-confidence alert pack first

If you only build 10 alerts, make them count. A strong starter pack:

• Audit log cleared (1102)
• Audit policy changed (4719)
• Added to privileged group (4728/4732/4756) for a defined privileged set
• Password spray heuristic (4625/4771 correlation)
• Admin logon from unusual host/subnet (4624 + 4672 correlation)
• Suspicious directory changes on protected OUs/objects (5136 on scoped SACL targets)

• Enable Advanced Audit Policy (subcategory-level) via dedicated GPOs
• Baseline DC auditing first (account logon, logon/logoff, account management, policy change, DS changes)
• Forward Security logs off-host (WEF/SIEM/MDI) and validate retention
• Implement a “top 10” high-confidence alert pack before expanding
• Use SACLs to log high-value object access/changes precisely
• Tune via correlation + thresholds, not single noisy events
• Document: what’s enabled, where, and why (so it survives staff changes)

• Event collection with Microsoft Defender for Identity
• Account Lockout Event ID: How to Find Account Lockouts
• Auditing Nested Group Memberships: An Expert Guide
• Active Directory Group Policy
• How to monitor and report security events in Microsoft Entra ID