Identity Threat Detection and Response: Building the ITDR Program

A general-purpose SIEM ingests identity logs but rarely models identity. Identity attack patterns require state that the SIEM does not maintain: the typical login locations and devices for each user, the baseline rate of MFA challenges per user, the normal hours and days of access, the usual SaaS applications accessed, the typical token lifetimes seen. Without this state, an alert like 'sign-in from new country' is either too noisy (every traveling executive triggers it) or too quiet (the baseline includes any country ever seen, so an attacker logging in from a country a user visited once five years ago does not alert). ITDR tools maintain per-identity behavioral baselines and correlate signals across systems: a sign-in from a new IP that is followed within 90 seconds by a privileged role activation in Azure AD and an OAuth grant to an unfamiliar third-party application is a coherent attack chain that no single log source surfaces. ITDR also covers attack patterns that have no network indicator at all: an attacker who phishes a session cookie and replays it from an attacker-controlled host does not generate any endpoint or network signal in the victim's environment; the only telltale is the identity log showing the token used from an unusual IP or autonomous system. EDR will not catch this; ITDR can.

ITDR coverage requires five signal sources. First, IdP audit logs: Microsoft Entra ID SignInLogs and AuditLogs (via Graph API or Diagnostic Settings export to Log Analytics or an event hub), Okta System Log (via the System Log API or SIEM connector), Ping Identity audit log, OneLogin events. These are the canonical source for sign-in attempts, MFA challenges, conditional access decisions, and OAuth grants. Second, directory audit logs: on-premises Active Directory event logs (4624, 4625, 4768, 4769, 4776, 4728, 4732, 4756) collected via WEF or agent, LDAP query logging if the directory is a target for enumeration, Azure AD directory write events. Third, email authentication telemetry: DMARC aggregate reports (rua) provide visibility into spoofing attempts against your domain, anomalous sending patterns indicating a compromised mailbox sending phishing internally. Fourth, SaaS audit logs: Microsoft 365 Unified Audit Log (covering Exchange, SharePoint, Teams, OneDrive, and Entra), Google Workspace Admin Audit and Login Audit, Salesforce Setup Audit Trail and Login History, GitHub audit log, AWS CloudTrail with a focus on IAM events. Fifth, EDR telemetry tied to identity events: process events that correlate to suspicious sign-ins (token theft from browser process memory, unusual lsass.exe access on Windows, credential file reads on macOS Keychain). The correlation across these five sources is what makes ITDR effective. Any one source alone produces too many false positives.

Impossible travel: a successful sign-in from two geographic locations within a time window that physical travel cannot bridge, typically 30 minutes minimum or calculated as miles between locations divided by 500 mph. Implement with care because VPNs and corporate proxy egress points produce false positives; allowlist your corporate egress IPs and exempt sign-ins via known VPN concentrators. MFA fatigue or MFA bombing: a surge of MFA challenges for one user within a short window, typically 5 or more challenges within 10 minutes, followed by an Approve, indicating the user gave in to repeated prompts. The Uber 2022 breach was textbook MFA fatigue. Detect on Entra ID via SignInLogs filtered for ResultType 50158 (MFA required, user did not complete) clustering, or on Okta via System Log eventType=user.authentication.auth_via_mfa with consecutive denies. New device enrollment immediately followed by privileged role activation or sensitive resource access: an attacker who has reset a victim's credentials will register their own MFA device, then attempt to use it. The window of correlation is typically under 15 minutes. Token age and reuse anomalies: a refresh token used far beyond its typical lifetime, or an access token used from an IP or user agent different from the original token-issuance context (Storm-0558 pattern). Directory enumeration: LDAP query volume exceeding 10x the baseline for the source account, or recursive group membership enumeration patterns characteristic of BloodHound/SharpHound collection. OAuth consent grants to unfamiliar third-party applications, especially those requesting Mail.Read or full Graph scopes, requested in bulk across multiple users.

If you cannot deploy a commercial ITDR product, you can build effective coverage in your existing SIEM with the right rules and the discipline to maintain per-user baselines. The SigmaHQ repository contains community-maintained rules for identity attack patterns: rules/cloud/azure/signinlogs/azure_ad_impossible_travel.yml for impossible travel using Entra ID SignInLogs, rules/cloud/okta/okta_password_spray.yml for password spray patterns, rules/cloud/azure/auditlogs/azure_ad_user_added_to_admin_role.yml for privileged role assignment. Convert Sigma rules to your SIEM query language with sigma convert (Splunk SPL, Microsoft Sentinel KQL, Elastic ES|QL, Chronicle YARA-L). For per-user baselines, ingest a rolling 30-day window of sign-in metadata per identity (typical countries, ASNs, user agents, time-of-day distribution) into a summary index or KQL function, and reference it in detection queries. KQL example for Entra ID impossible travel that handles VPN egress: join SignInLogs to itself on UserPrincipalName within a 30-minute window, filter where IPAddress is different and the geo-distance exceeds 500 miles, exclude known corporate egress IPs via an allowlist watchlist. The investment is real (several weeks of detection engineering to build the baseline functions and tune the rules) but the result is durable detection content under your control.

The commercial ITDR market has consolidated around several vendors with different focus areas. Microsoft Defender for Identity covers on-premises Active Directory and hybrid Entra ID with strong coverage for AD-specific attacks (Kerberoasting, DCSync, Golden Ticket, Pass-the-Hash) and is integrated with Defender XDR; its weakness is non-Microsoft IdPs and SaaS. Crowdstrike Falcon Identity Protection covers AD and Entra ID with identity-aware policy enforcement (challenge-based MFA on risky access) and integrates with the Falcon EDR for token-theft detection. Silverfort focuses on adding MFA and identity-based segmentation to legacy systems that do not natively support it, and is strong for protecting service accounts and legacy applications. Vectra Identity (formerly Vectra AI) emphasizes behavioral analytics across AD and Microsoft 365 with strong account graph visualization. Push Security focuses on SaaS identity sprawl and shadow IT, identifying unmanaged accounts and risky OAuth grants across the SaaS estate. Selection depends on your environment: Microsoft-heavy with on-premises AD points to Defender for Identity; mixed IdP with significant SaaS points to Push or Vectra; legacy-heavy environments needing MFA retrofitting point to Silverfort. Regardless of tool, the SOC integration is what makes ITDR useful: define a runbook per alert class (impossible travel, MFA fatigue, OAuth grant to suspicious app, directory enumeration) specifying triage steps, containment actions (revoke session, force password reset, block sign-in, revoke OAuth grant), and escalation criteria. Without runbooks, ITDR alerts become another queue analysts dismiss.