ITDR for Active Directory and Entra ID: Detect DCSync, Token Theft and Shadow Credentials

In an October 13, 2026 technical explainer authored by SC Media Editorial Intelligence and reviewed by cybersecurity executive Christopher Ashby, SC Media breaks down the operational blueprint for Identity Threat Detection and Response (ITDR). Rather than treating identity merely as an administrative directory, ITDR approaches the identity plane as an active battleground, using behavioral analysis, log correlation, and anomaly detection to catch intruders who are already logged in.

For Windows Server administrators, cloud architects, and security operations center (SOC) analysts, building a real-world ITDR capability requires more than pasting a few detection queries into a SIEM. It demands a clear understanding of where posture management ends and active threat hunting begins, how Windows and Entra telemetry actually behave under the hood, and what happens when automated containment meets production reality.

ITDR vs. ISPM: Knowing Which Problem You Are Solving​

The cybersecurity industry loves a good acronym soup, and identity security has two major contenders that are frequently confused: Identity Security Posture Management (ISPM) and Identity Threat Detection and Response (ITDR).

As SC Media notes, the distinction comes down to configuration versus active exploitation:

• ISPM (Posture and Prevention): Focuses on finding and fixing structural weaknesses before an attacker arrives. This includes discovering overprivileged accounts, weak password policies, dormant administrative memberships, or risky Kerberos delegation settings.
• ITDR (Detection and Response): Operates as an active detection and response discipline. It assumes the attacker is already testing or exploiting those weaknesses, hunting for authentication anomalies, suspicious privilege changes, abnormal credential usage, and unauthorized directory modifications across both on-premises and cloud environments.

Why don't traditional network and endpoint tools catch these attacks? Because techniques like pass-the-hash, Golden Ticket forging, and DCSync replication look like standard, protocol-compliant authentication and directory traffic on the wire. Meanwhile, an EDR agent sitting on a Windows 11 laptop has zero visibility into an attacker replaying a stolen OAuth refresh token against a cloud API from an external network. ITDR bridges this gap by feeding identity telemetry into Security Information and Event Management (SIEM), Extended Detection and Response (XDR), and Security Orchestration, Automation, and Response (SOAR) platforms to establish behavioral baselines and flag deviations.

Section Summary: ISPM cleans up your directory misconfigurations; ITDR catches the adversary actively abusing your directory and cloud tokens in real time. Both are necessary, and neither replaces network or endpoint security.

Mapping the Hybrid Identity Attack Surface​

A modern Windows enterprise rarely lives in one place. Most organizations run a hybrid identity estate bridging on-premises Active Directory Domain Services (AD DS) with Microsoft Entra ID and third-party SaaS applications. Attackers target three primary pillars across this landscape.

The Mechanics of On-Premises AD Abuse​

Domain controllers remain the crown jewels of a Windows network. According to MITRE ATT&CK documentation for sub-technique T1003.006, a DCSync attack abuses the Windows Domain Controller's Directory Replication Service (DRS) Remote Protocol (MS-DRSR) API—specifically operations like IDL_DRSGetNCChanges—to simulate replication from a remote domain controller. Members of the Administrators, Domain Admins, or Enterprise Admins groups, as well as domain controller computer accounts, hold the permissions required to pull credential data, including current and historical password hashes. If an attacker pulls the KRBTGT account hash via tools like Mimikatz (lsadump), they can forge a Golden Ticket, granting themselves virtually unlimited domain access. Similarly, compromising a specific service account password allows an attacker to mint a Silver Ticket for targeted resource access.

Even more insidious is the Shadow Credentials technique. By modifying the msDS-KeyCredentialLink attribute on a user or computer object in Active Directory, an attacker injects an attacker-controlled certificate. This abuses Key Trust authentication, allowing the adversary to authenticate as that object via Kerberos PKINIT without ever knowing or changing the account's password.

Cloud Tokens and Consent Traps​

In the cloud, passwords and multi-factor authentication (MFA) prompts are only the initial hurdle. Once a session is established, cloud platforms rely on tokens. If an attacker steals an OAuth refresh token, they can perform a token replay attack, generating fresh access tokens and maintaining persistent access while bypassing MFA requirements entirely.

Attackers also rely on illicit consent grants. Rather than stealing a user's password, the attacker tricks a user into authorizing a malicious third-party OAuth application requesting high-impact Microsoft Graph permissions such as Mail.Read, Files.Read.All, or Directory.Read.All. Even if the user resets their password ten times, the malicious application retains delegated API access until the consent grant itself is revoked.

Section Summary: Identity attacks span on-premises Kerberos and replication protocols, cloud OAuth workflows, and emergency PAM accounts. Because each vector uses native authentication mechanisms, defenders must monitor the underlying directory attributes, replication calls, and token grants directly.

Building Detection Capability: Rules, Queries, and Real-World Caveats​

To move from theory to practice, SC Media outlines seven core detection patterns across Splunk, Microsoft Sentinel (KQL), Elastic, and Windows Security Event Logs. While these query patterns illustrate exactly what SOC teams should hunt for, veteran engineers know that sample rules should never be pasted directly into production without validating schemas, audit policies, and environmental noise.

Here is how those core detections work—and the Microsoft-specific engineering caveats you must account for when deploying them.

1. Authentication Anomalies: Impossible Travel and Password Spraying​

Tracking anomalous login behavior starts with geography and failure volume.

• Impossible Travel: SC Media illustrates a Splunk detection that calculates the geographic distance between consecutive logins (geodist) and flags accounts where the elapsed time is shorter than the physical travel time at 800 km/h.
  • Engineering Caveat: Generic impossible travel math requires enriched geolocation and prior-login state fields in your SIEM. More importantly, corporate VPNs, split-tunneling, cloud proxy egress nodes, and mobile carrier routing will trigger massive false positives unless you baseline known corporate IP ranges and correlate device IDs.
• Password Spraying: In Microsoft Sentinel, defenders can query SigninLogs for Microsoft Entra error code 50126 (invalid username or password), summarizing failed attempts, unique IP addresses (dcount(IPAddress)), and unique user agents over a 1-hour window to spot distributed brute-force campaigns:

// Conceptual Password Spray Detection in Microsoft Sentinel
SigninLogs
| where TimeGenerated >= ago(1h)
| where ResultType == "50126" // Invalid username or password
| summarize FailedAttempts = count(), UniqueIPs = dcount(IPAddress), UniqueUserAgents = dcount(UserAgent) by UserPrincipalName
| where FailedAttempts >= 5 and UniqueIPs >= 3
| project UserPrincipalName, FailedAttempts, UniqueIPs, UniqueUserAgents

2. Privilege Escalation and DCSync Monitoring​

Watching for unauthorized elevation requires monitoring both group changes and directory replication.

• Admin Group Additions: SC Media suggests monitoring IAM events (group-member-added or role-assigned) where the target group matches privileged patterns (admin, root, domain admin, enterprise admin) and excluding expected service account naming conventions.
• DCSync via Windows Event ID 4662: When an account requests directory replication, Windows logs Security Event ID 4662 (An operation was performed on an object). SC Media’s sample query looks for Event ID 4662 containing the specific replication extended rights GUIDs 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes) or 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All) where the source computer name does not match a regex like DC\d+.
  • Critical Windows Auditing Caveat: According to Microsoft Learn documentation on Audit Directory Service Access, Event ID 4662 is not generated by default for every object access—and enabling it blindly across AD DS generates a high event volume on domain controllers. You must configure the Audit Directory Service Access subcategory and design appropriate System Access Control Lists (SACLs) on your directory objects. Furthermore, relying on a hostname regex (DC\d+) to exclude legitimate domain controllers is brittle; attackers can name a rogue machine or pass workstation parameters to evade simple string matching, and authorized services like Microsoft Entra Connect also perform legitimate directory replication. Always validate against an explicit allowlist of domain controller computer accounts, SIDs, and authorized sync service accounts.

3. Token, Consent, and Certificate Abuse​

Catching persistence in hybrid environments requires watching application grants and LDAP attribute changes.

• Suspicious OAuth Consent Grants: In Microsoft Entra ID, user consent events appear in AuditLogs under the ApplicationManagement category with the activity name Consent to application. SC Media provides a KQL pattern to surface high-risk permission grants:

// Conceptual OAuth Consent Monitoring in Entra AuditLogs
AuditLogs
| where ActivityDisplayName == "Consent to application"
| extend AppName = tostring(TargetResources[0].displayName)
| extend Permissions = tostring(AdditionalDetails.value)
| where Permissions has_any("Mail.Read", "Files.Read.All", "Directory.Read.All")
| project TimeGenerated, UserPrincipalName, AppName, Permissions, IPAddress

• Entra Schema Caveat: In production Microsoft Entra AuditLogs, the AdditionalDetails array order is not guaranteed to remain static across all event types, so hardcoding an array index like AdditionalDetails.value can miss events. Microsoft Learn also documents that administrators should monitor related ApplicationManagement audit activities—including Add app role assignment to the service principal (app-only access) and Add delegated permission grant—and cross-reference Microsoft Purview Audit logs when investigating illicit consent grants.
• Shadow Credentials (Event ID 5136): To catch certificate-based persistence in AD, monitor Windows Security Event ID 5136 (A directory service object was modified) where the AttributeLDAPDisplayName is msDS-KeyCredentialLink. Because 5136 relies on Audit Directory Service Changes, ensure that audit policy is active on your domain controllers.

4. Dormant Account Reactivation​

Accounts that have sat idle for 90, 180, or 365+ days and suddenly log in successfully represent prime targets for credential stuffing or insider abuse. While SC Media’s generic SIEM logic calculates (now() - last_login_time) / 86400 > 90, Windows administrators should remember that in Active Directory, the lastLogon attribute is not replicated across domain controllers, while lastLogonTimestamp only replicates periodically (typically within a 9-to-14-day window by default). Accurate dormant-account alerting requires maintaining a stateful lookup table of authentication events inside your SIEM or querying Entra sign-in state directly.

Section Summary: Effective ITDR detections target impossible travel, password sprays, admin group changes, DCSync GUIDs (4662), OAuth consent grants, Shadow Credentials (5136), and dormant accounts. However, every query depends on properly configured Windows SACLs, resilient field parsing, and strict allowlisting of legitimate sync and replication servers.

Deploying Microsoft Defender for Identity: What Admins Need to Know​

While building custom SIEM rules is essential, many Windows enterprises anchor their on-premises and hybrid ITDR strategy with Microsoft Defender for Identity. According to Microsoft’s deployment and alerting documentation, rolling out Defender for Identity involves several critical architectural boundaries that every IT team should verify:

1. Comprehensive Sensor Coverage: Microsoft instructs administrators to install Defender for Identity sensors on all domain controllers, including read-only domain controllers (RODCs), as well as dedicated Active Directory Federation Services (AD FS), Active Directory Certificate Services (AD CS), and Microsoft Entra Connect servers.
2. Sensor v3.x vs. v2.x Boundaries: For servers running Windows Server 2019 or later (with the September 2026 or later cumulative update), Microsoft recommends Defender for Identity sensor v3.x, whereas Windows Server 2016 or earlier requires sensor v2.x. Note that while domain controllers can onboard to sensor v3.x with or without Microsoft Defender for Endpoint, AD FS, AD CS, and Entra Connect servers require Defender for Endpoint onboarding before activating v3.x. Additionally, sensor v3.x always uses the local system account (ignoring v2.x gMSA configurations) and does not support VPN integration or syslog notifications—if you rely on those two features, you must keep sensor v2.x on the applicable domain controllers.
3. It Is Not a Replacement for Log Archival: Microsoft explicitly notes in its security alerts documentation that Defender for Identity is not designed to serve as a comprehensive auditing or logging solution that captures every operation on sensor-equipped servers. It only captures the telemetry required for its detection and recommendation engines. You still need centralized SIEM log ingestion and verified Microsoft Entra data-retention policies for forensic and compliance investigations.
4. Learning Periods and VPN/NAT Tuning: While SC Media notes that general User Behavior Analytics (UBA) baselines often take 30 to 90 days of normal activity to mature, Microsoft’s product-specific documentation notes that certain Defender for Identity detections use built-in learning periods, and test-mode settings run for a maximum of 60 days. Microsoft also warns administrators to exercise caution when lowering alert thresholds for detections like DCSync or identity theft in environments using NAT or VPNs, as those network topologies can skew source IP and machine attribution.

Containment, Hardening, and the Session Revocation Trap​

Detecting an active identity attack at 2:00 AM is only half the battle; the "R" in ITDR is what prevents a minor credential compromise from turning into a domain-wide ransomware event.

The Speed vs. Continuity Tradeoff​

SC Media highlights three primary immediate response actions: automated account lockout, OAuth token revocation, and active session termination. Connecting your detection engine to a SOAR platform allows playbooks to execute these steps automatically, enriching alerts with device context and preserving forensic artifacts (such as memory dumps, authentication logs, and timeline records) before containment alters system state.

However, automated containment carries a well-known operational hazard: false positives lock out legitimate users, potentially halting executive workflows or breaking critical production service accounts. Most mature SOCs pair automated containment with a risk-scoring framework—auto-isolating standard user accounts when multiple correlated signals fire, while routing high-impact service accounts or questionable single-signal alerts to rapid human triage.

What Microsoft Entra Session Revocation Actually Does (And Doesn't Do)​

When an attacker compromises a cloud identity, administrators instinctively reach for the Revoke sessions button in the Microsoft Entra admin center (or run the equivalent Microsoft Graph API call).

According to Microsoft Learn’s emergency access revocation guidance, administrators must understand a critical architectural limitation: Microsoft Entra ID cannot directly revoke a session token that has already been issued by a third-party or relying-party application.

When you revoke access in Entra ID, you invalidate the user's refresh tokens and block them from requesting new access tokens. However, if an attacker has already authenticated to a connected SaaS application or web portal that maintains its own independent session cookie or long-lived application token, the attacker's access inside that specific application can persist until the application’s own session timer expires or the application supports Continuous Access Evaluation (CAE) and processes the state change. Consequently, your incident response playbook cannot stop at clicking "Revoke sessions" in Entra—responders must inspect the audit logs to see which downstream applications the compromised account accessed and terminate sessions directly inside those target platforms as well.

Proactive Identity Hardening​

To make the attacker's job exponentially harder before an alert ever fires, pair your detection rules with four foundational hardening controls:

• Privileged Access Workstations (PAWs): Dedicate hardened, isolated workstations strictly for administrative tasks so domain admin credentials are never exposed to phishing emails or web browsing on standard corporate endpoints.
• Just-in-Time (JIT) Access: Eliminate standing administrative privileges where possible, granting elevated roles only for approved time windows.
• Risk-Based Conditional Access: Enforce device compliance checks, location boundaries, and phishing-resistant MFA dynamically based on real-time sign-in risk signals.
• Certificate-Based Authentication: Transition away from reusable passwords toward smart cards, Windows Hello for Business, or FIDO2 security keys, backed by tightly monitored Public Key Infrastructure (PKI) and AD CS auditing.

Actionable ITDR Implementation Checklist for Windows Admins​

If you are ready to audit or build out your organization's Identity Threat Detection and Response capability, use this structured operational checklist adapted from SC Media’s framework and Microsoft’s deployment guidance:

Phase 1: Telemetry and Signal Integration​

• [ ] Collect Windows Security Event Logs from all domain controllers (including RODCs), ensuring Audit Directory Service Access (4662) and Audit Directory Service Changes (5136) are properly scoped with SACLs.
• [ ] Deploy identity sensors (such as Microsoft Defender for Identity) across all domain controllers, AD FS, AD CS, and Microsoft Entra Connect servers.
• [ ] Ingest Microsoft Entra Sign-in Logs and Audit Logs into your SIEM, and verify tenant retention policies and archive exports.
• [ ] Integrate cloud application audit trails (Microsoft 365 Purview Audit, Salesforce, ServiceNow) to track post-authentication data access and OAuth activity.
• [ ] Ingest VPN, remote access, DHCP, and DNS query logs to correlate authentication events with physical network and endpoint context.
• [ ] Connect Privileged Access Management (PAM) vault access logs and session recordings to your central monitoring platform.

Phase 2: Baselining and Detection Engineering​

• [ ] Establish behavioral baselines (30 to 90 days of historical telemetry) covering normal login hours, geographic footprints, application usage, and admin elevation frequency.
• [ ] Deploy and tune detections for password spraying (such as Entra ResultType 50126 spikes) and impossible travel (accounting for corporate VPNs and proxies).
• [ ] Configure high-priority alerts for additions to privileged groups (Domain Admins, Enterprise Admins, Entra Global Administrators).
• [ ] Implement DCSync (Event ID 4662 replication GUIDs) and Shadow Credentials (Event ID 5136 on msDS-KeyCredentialLink) rules, explicitly allowlisting verified domain controller accounts and Entra Connect sync servers.
• [ ] Monitor Entra ApplicationManagement audit logs for Consent to application, Add app role assignment to the service principal, and Add delegated permission grant involving broad permissions like Mail.Read or Files.Read.All.
• [ ] Track dormant account reactivation for identities inactive for 90+ days using stateful login tracking.

Phase 3: Triage and Response Playbooks​

• [ ] Implement a risk-scoring model that weighs user privilege level, target data sensitivity, and multi-signal correlation to prevent SOC alert fatigue.
• [ ] Build a feedback loop to tune out benign administrative automation, NAT/VPN anomalies, and expected Microsoft 365 background write-backs (such as Microsoft Substrate Management directory sync events).
• [ ] Define clear SOAR and manual playbooks covering account lockout, Entra refresh token revocation, downstream SaaS session termination, and malicious OAuth app permission revocation.
• [ ] Mandate forensic evidence preservation—capturing volatile logs, authentication artifacts, and host state—prior to executing automated remediation steps that alter system state.

How is your team handling hybrid identity monitoring across on-premises Active Directory and Microsoft Entra ID? Have you run into event-volume headaches with Event ID 4662 or migrated your domain controllers to Defender for Identity sensor v3.x? Share your experiences and detection tips in the WindowsForum security community discussions!