1) Detection mindset: “Exploit chain” rules vs. single events

The fastest way to build a noisy SIEM is to alert on every “security event ID of interest.” The fastest way to build a useful SIEM is to alert on attack behavior: rare sequences, impossible combinations, or privilege transitions that should not happen.

Prefer these alert shapes

• Multi-event correlation: “Directory replication permission used” + “unusual host” + “non-DC account”.
• Rate-based anomaly: “>N service tickets requested in M minutes” (Kerberoast-style patterns).
• Invariant violations: “Non-admin workstation performing domain admin activity”.
• Change monitoring: “Sensitive attribute changed” (delegation flags, key credentials, RBCD).

2) Data sources you actually need

You can build a strong AD exploitation rule set with a “core four” data collection strategy:

3) High-signal SIEM rule packs (with logic + tuning)

Below are rule packs that map cleanly to exploitation attempts. Each entry includes: what to detect, data prerequisites, and tuning guidance.

Rule Pack A — Replication abuse (DCSync / replication-permission misuse)

Why it matters: Replication permissions let attackers pull password material (or equivalent secrets) at scale. It’s one of the highest impact AD exploitation moves.

• Detect: Directory replication permissions being exercised by non-DC principals, especially from non-DC hosts.
• Signals: Object access / directory service access events (commonly 4662 with replication-related GUIDs) plus host/account context.
• Tune: Allowlist legitimate sync services (Azure AD Connect/Entra Connect, identity governance tools, backup products), and restrict by host.

// Pseudocode / SIEM-agnostic logic
WHEN event_id IN (4662)
AND operation IN ("Directory Replication")
AND subject_user NOT IN allowlisted_replication_accounts
AND source_host NOT IN domain_controllers
THEN ALERT "Possible DCSync / replication abuse"

Rule Pack B — Kerberos abuse (Kerberoasting, AS-REP roasting, ticket anomalies)

Detect: ticket request patterns that look like password cracking preparation or forged-ticket activity.

B1) Kerberoasting-style spikes (service ticket request bursts)

• Signals: 4769 (service ticket requests) aggregated by user + source host.
• Logic: “Many distinct SPNs requested in a short window” or “unusual encryption types” depending on your environment.
• Tune: Exclude known service management accounts, vulnerability scanners, monitoring tooling, and jump boxes used by admins.

// Example aggregation logic
WINDOW 10m
COUNT_DISTINCT(service_name/SPN) BY requester_user, source_host
IF count > 30
AND requester_user NOT IN allowlisted_accounts
THEN ALERT "Possible Kerberoasting behavior"

B2) Suspicious TGT/TGS characteristics (possible Golden Ticket / ticket forgery signals)

• Signals: 4768/4769 plus fields for ticket lifetime, client address, and service name (field availability varies by ingestion/parser).
• Logic: “Impossible lifetime”, “TGT used from an unexpected host”, “privileged user authenticating without expected preconditions”.
• Tune: Focus on protected accounts, Tier-0 users, and admin workstations first.

// Pseudocode
WHEN kerberos_ticket_event IN (4768,4769)
AND (ticket_lifetime > baseline_max OR source_host_is_unseen_for_user = true)
AND user IN tier0_or_privileged_scope
THEN ALERT "Kerberos ticket anomaly - investigate for forgery"

Rule Pack C — NTLM & lateral movement (Pass-the-Hash style patterns)

Detect: NTLM network logons that violate your expected admin operating model.

• Signals: 4624 (LogonType 3), 4776 (NTLM auth), plus workstation/user relationships.
• Logic: “Privileged account authenticating via NTLM from a non-admin workstation” or “sudden NTLM auth across many hosts.”
• Tune: Allowlist legacy apps if needed, but treat privileged accounts as “no-exception” where possible.

// Pseudocode
WHEN event_id = 4624
AND logon_type = 3
AND auth_package = "NTLM"
AND user IN privileged_scope
AND source_host NOT IN admin_workstations
THEN ALERT "Privileged NTLM network logon from non-admin host (PtH risk)"

Rule Pack D — Privileged group abuse (fastest “you lose” moves)

Detect: membership changes in Tier-0 / privileged groups and suspicious privilege assignment.

• Signals: group membership changes (commonly 4728/4729/4732/4733/4756/4757), special privileges (4672), account enablement/reset events depending on policy.
• Logic: “User added to Domain Admins (or equivalent) outside approved change window” + “initiator not in admin workflow.”
• Tune: Integrate with your change ticketing system, or at least maintain an allowlist of expected admin operators and jump hosts.

// Pseudocode
WHEN event_id IN (4728,4732,4756)   // add to privileged group
AND target_group IN ("Domain Admins","Enterprise Admins","Schema Admins","Administrators","Account Operators")
AND initiator_user NOT IN approved_admin_operators
THEN ALERT "Privileged group membership change (unexpected initiator)"

Rule Pack E — Directory attribute tampering (delegation, RBCD, shadow credentials)

Detect: the “quiet” AD object changes that enable stealthy persistence and lateral movement. This is where Directory Service change logs (often 5136) pay for themselves.

E1) Resource-Based Constrained Delegation (RBCD) changes

• Detect: changes to msDS-AllowedToActOnBehalfOfOtherIdentity on computer/service objects.
• Signals: 5136 with attribute name + new value details (parser-dependent).
• Tune: Focus on Tier-0 servers (DCs, identity servers) and high-value application servers.

// Pseudocode
WHEN event_id = 5136
AND attribute_name = "msDS-AllowedToActOnBehalfOfOtherIdentity"
AND target_object_type IN ("computer","user","serviceAccount")
AND (target_is_tier0 = true OR initiator_is_unusual = true)
THEN ALERT "RBCD attribute modified - possible delegation abuse"

E2) Shadow Credentials (key credential link modifications)

• Detect: changes to msDS-KeyCredentialLink for users/computers (commonly used to add attacker-controlled keys).
• Signals: 5136 attribute changes; correlate with subsequent logons/ticketing.
• Tune: Make this high priority for privileged users and service accounts.

// Pseudocode
WHEN event_id = 5136
AND attribute_name = "msDS-KeyCredentialLink"
AND target_user IN privileged_scope
THEN ALERT "Shadow credentials attempt on privileged identity"

E3) Delegation flags / userAccountControl risky flips

• Detect: user/computer delegation-related flag changes (e.g., unconstrained delegation enablement).
• Signals: 5136 (attribute changes) + user/computer modification events depending on your audit configuration.
• Tune: Alert when delegation is enabled on servers that should never delegate.

// Pseudocode
WHEN event_id = 5136
AND attribute_name IN ("userAccountControl","msDS-AllowedToDelegateTo")
AND change_enables_delegation = true
AND target_is_server_or_privileged_identity = true
THEN ALERT "Delegation settings modified (persistence / lateral movement risk)"

Rule Pack F — GPO tampering & domain policy manipulation

Detect: changes to Group Policy that can deploy scripts, scheduled tasks, startup items, or security setting downgrades.

• Signals: 5136 for GPO object attribute changes (plus SYSVOL file modifications if you ingest them), and domain policy change events depending on audit settings.
• Logic: “GPO changed” + “initiator not in GPO admin set” + “change outside window” + “GPO linked to sensitive OU”.
• Tune: Maintain an allowlist of GPO admins and expected automation accounts; alert hard on Tier-0 OU-linked policies.

// Pseudocode
WHEN event_id = 5136
AND target_object_contains "CN=Policies,CN=System"
AND initiator_user NOT IN gpo_admin_allowlist
THEN ALERT "GPO modified by unexpected user (possible domain-wide persistence)"

Rule Pack G — Tooling & “hands-on-keyboard” exploitation indicators (endpoint + DC)

These rules are especially strong if you have EDR/Sysmon alongside DC logs.

• LSASS dumping indicators: suspicious processes (procdump, taskmgr in odd contexts, rundll32 comsvcs) accessing LSASS; correlate to privileged logons.
• Credential theft tooling hints: unusual DLL loads, access to \\*\ADMIN$, or known dumping binaries executed from temp/user profile paths.
• NTDS access attempts: file access auditing on ntds.dit (if configured) or suspicious VSS usage.

// Pseudocode - endpoint centric
WHEN process_name IN ("procdump.exe","rundll32.exe","powershell.exe","cmd.exe")
AND (command_line CONTAINS "lsass" OR command_line CONTAINS "comsvcs.dll")
AND user IN privileged_scope
THEN ALERT "Potential LSASS credential dump attempt"

4) Baselines & allowlists that make rules usable

The difference between “cool detections” and “operational detections” is almost always: baselining + scoping.

Baselines worth building (minimum viable)

• User ↔ workstation mapping: which hosts a user normally logs in from (especially admins).
• Admin workstation list: PAWs / jump hosts / management subnets (treat as sacred).
• Expected automation identities: sync, backups, monitoring, IAM tools, scheduled jobs.
• Service ticket norms: typical volume of 4769 by user/host/service class.
• Tier-0 object inventory: DCs, ADFS/identity servers, PKI, Entra Connect servers, privileged groups.

5) How to test and validate (without lying to yourself)

Validation principles

• Test in a lab first, then in production with “audit-only” mode and controlled accounts.
• Prove data presence before writing rules (“Do I even ingest 5136 with attribute details?”).
• Run replay checks: query last 30–90 days to estimate noise and build allowlists.
• Measure time-to-triage: if an analyst can’t decide “benign vs suspicious” quickly, enrich the alert.

Alert enrichment fields that matter

• Initiator user + initiator host + initiator IP
• Target object DN (for 5136) and attribute changed + old/new values (if available)
• Group name and member added/removed (for group change rules)
• Was this inside a change window? Was there a matching change ticket?
• Is the initiator on an admin workstation? Is the target Tier-0?

6) If you use Microsoft Defender for Identity

If MDI is part of your identity detection stack, you can either: (A) alert directly on MDI incidents, or (B) use your SIEM to correlate MDI signals with DC/endpoint/network telemetry.

• Overview and deployment context: Microsoft Defender for Identity: A comprehensive overview
• Audit policy and event collection prerequisites: Event collection with Microsoft Defender for Identity

7) Quick-start checklist

• Collect: DC Security logs + Directory Service changes (5136 family) + privileged group change events.
• Inventory: Domain Controllers, admin workstations, Tier-0 groups, Tier-0 accounts.
• Implement first: privileged group change alerts, replication abuse alerts, RBCD/shadow credential alerts.
• Add baselines: “user normal hosts,” “admin workstation list,” “approved automation accounts.”
• Enrich alerts: who/where/what changed + target tier + change window + last-seen history.
• Test monthly: run controlled simulations and verify alert fidelity + triage speed.

Further reading (internal links)

Use these as contextual jump-links inside this article and as “next step” recommendations at the end:

• NTLM and Kerberos Authentication Protocols Explained
• User authentication and user authorization process: An explanation
• Microsoft Defender for Identity: A comprehensive overview
• Event collection with Microsoft Defender for Identity
• Active Directory 25-year evolution