Most security teams assume their SIEM already detects identity attacks, because the domain controller and identity provider logs are flowing into it, yet several of the attacks that matter most leave little or nothing in those logs. Identity threat detection and response (ITDR) tools watch the identity plane directly: Kerberos and LDAP traffic at the domain controller, token issuance and session state at the identity provider, and changes to privileged objects. A security information and event management (SIEM) platform correlates logs from everything, keeps them for investigation and compliance, and is where the SOC works. This guide covers which identity attacks a log-only SIEM tends to miss, which it catches well, and how to route ITDR detections into the SIEM without duplicate alerts or lost evidence. It is for SOC leads, detection engineers and identity owners.
Key takeaways
- The gap is telemetry, not analytics. A SIEM can only correlate the events it receives; several Kerberos, replication and federation attacks are clearest in protocol traffic or identity provider state that never becomes a log line.
- ITDR is not a log store. ITDR tools capture what their detections need, not a complete audit trail, so the SIEM stays the system of record for investigations, retention and compliance evidence.
- Response power is the second difference. ITDR tools act on identities (disable, revoke sessions, force reset); a SIEM raises alerts, and acting on identities needs SOAR or a person with directory rights.
- Feed ITDR alerts into the SIEM, not raw duplicates. Forward ITDR detections as enriched alerts keyed on a stable alert ID, and suppress the overlapping SIEM rules the ITDR tool now covers better.
- Prove coverage with tests, not datasheets. Run a coverage matrix per technique, per identity plane (directory, IdP, cloud IAM, SaaS) and per identity type, including service accounts and workload identities.
The short answer
If your SIEM ingests the right domain controller, identity provider and cloud audit logs, with the audit policy that generates them, it can detect a useful share of identity attacks: password spraying, many directory changes, new credentials on cloud applications, privileged role assignments and consent grants. Add ITDR when you need detections that depend on protocol inspection or identity state rather than logs (forged and anomalous Kerberos tickets, replication from non-domain controllers, honeytoken use, lateral movement paths), near-real-time containment on the identity, or coverage your team cannot build and maintain by hand. Keep the SIEM either way: it holds the evidence, correlates identity alerts with everything else and runs case management.
For the disciplines on their own, see the ITDR Guide and the SIEM Guide. For neighbouring comparisons, see ITDR vs UEBA and ITDR vs XDR.
ITDR and SIEM side by side
| Dimension | ITDR | SIEM |
|---|---|---|
| Core question | Is an identity being stolen, forged or abused, and how do we contain it? | What happened across the estate, and is it malicious? |
| Data collection | Sensors on domain controllers, AD FS and AD CS servers that inspect authentication traffic and events locally; API connectors to identity providers; identity graph and posture state | Logs forwarded from every source: endpoints, network, directories, identity providers, cloud control planes, SaaS and applications |
| Detection style | Technique-specific identity detections, protocol anomalies, identity risk scoring, honeytokens | Correlation rules, searches and analytics written by the SOC or shipped as content packs, plus UEBA where licensed |
| Identity context | Native: privilege tier, group nesting, sensitive accounts, attack paths | Whatever is enriched in: watchlists, asset and identity lookups, often maintained by hand |
| Response | Built-in identity actions: disable account, revoke sessions, force password change, mark compromised, end sessions across federated applications | Alert, case and ticket; containment through SOAR playbooks or analysts |
| Retention and evidence | Limited to detection needs; not designed as an audit log | Designed for search, long retention and audit evidence |
| Main blind spot | Anything outside identity: endpoint, network, data and application behaviour after the login | Attacks that leave no log line, sources not onboarded, audit policy not enabled, identity context missing |
Where log correlation runs out: identity attacks a SIEM tends to miss
A SIEM's identity coverage is bounded by three things: whether the event is generated at all, whether it is collected, and whether the event carries enough context to tell attack from normal. Microsoft states that Defender for Identity "isn't designed to serve as an auditing or logging solution" and captures only what its detections need, which is the mirror image of the SIEM's job.
| Attack (ATT&CK) | What a log-only SIEM sees | What ITDR adds | Typical lead |
|---|---|---|---|
| Kerberoasting (T1558.003) | Event 4769 per service ticket, logged on domain controllers only, with a Ticket Encryption Type field; RC4 (0x17) requests on a modern domain stand out, but AES requests for roastable accounts look ordinary | Detection of SPN enumeration and ticket request bursts in traffic (Defender for Identity alert 2410, Suspected Kerberos SPN exposure; LDAP reconnaissance alert 2038) | ITDR, SIEM as backup on 4769 encryption type |
| AS-REP roasting (T1558.004) | Event 4768 for accounts without pre-authentication, if the audit subcategory is on | AS-REQ requests sent without pre-authentication flagged directly (alert 2412) | Either; ITDR with less tuning |
| DCSync (T1003.006) | Event 4662 with replication rights on the domain object, if directory service access auditing and the right SACL are configured; noisy because domain controllers replicate constantly | Replication requests from a computer that is not a domain controller (alert 2006) | ITDR |
| Golden Ticket (T1558.001) | Very little: a forged ticket is never issued by the KDC, so there is no 4768 for it; later 4769 or 4624 events look normal | Ticket anomalies, nonexistent accounts, encryption downgrade, time anomalies and forged authorisation data (alerts 2009, 2013, 2022, 2027, 2032) | ITDR |
| Skeleton key (T1556.001) | Little in standard events | Encryption downgrade on Kerberos error messages (alert 2010) | ITDR |
| Password spraying (T1110.003) | Strong: 4625, 4771 and 4776 failures on premises, IdP sign-in failures in the cloud; a classic correlation rule | Learned baselines (Defender for Identity uses a one-week learning period for its brute force alert) and direct lockout or step-up | SIEM, with ITDR response |
| MFA request flooding (T1621) | Good if the IdP logs MFA denials and pushes; a count rule per user | Session risk and automatic session termination | Either |
| SAML token forgery (T1606.002) | The forged token is signed outside the federation server, so no authentication event exists there; only downstream application sign-ins appear | Alerts on the precursors: AD FS DKM key read (2413) and trust modification (2420) | ITDR for precursors, SIEM for cross-checking sign-ins with no matching IdP event |
| Additional cloud credentials (T1098.001) | Strong: audit events for new secrets and certificates on applications and service principals | Same events, plus privilege context of the application | SIEM is sufficient if the rule exists |
| Stolen application access tokens (T1528, T1550.001) | Non-interactive and service principal sign-in logs, if collected; token replay looks like normal use | Session and token risk where the IdP supports it, and token revocation | Shared; both need the IdP's own risk signals |
Alert numbers above are Microsoft Defender for Identity classic alerts, used as documented examples of identity-plane detection. Platforms named in this guide are listed alphabetically as examples of documented behaviour, not as a ranking or recommendation.
The three reasons a SIEM misses identity attacks
- The event is never generated: forged tickets and forged SAML assertions are created by the attacker, not issued by the KDC or federation server, so there is no issuance event to correlate.
- The event is generated only if audit policy says so: the ASD and CISA priority logs guidance notes that many events, including 4768, 4769 and 4662, appear only once the matching audit policy setting is enabled, and that cloud logging may be off by default. Event 4769 needs the Audit Kerberos Service Ticket Operations subcategory; 4662 needs directory service access auditing and an object SACL.
- The event lacks context: a 4769 does not say whether the target account is a privileged service account with a crackable password, and a service principal sign-in does not say whether the application holds mail-wide permissions. ITDR tools carry that context; a SIEM needs it enriched from watchlists.
Threat model and architecture of each
ITDR: identity-plane sensors with write access
The ITDR threat model is an outsider becoming an insider through an identity, then escalating and persisting through identity objects. Its architecture: sensors on domain controllers and on AD FS and AD CS servers (some Defender for Identity alerts need sensors on those servers), API connectors to cloud identity providers, an identity graph, and a response layer holding privileged rights in the directory and IdP. Okta Identity Threat Protection is the IdP-side equivalent: continuous session evaluation, entity risk from the past seven days of detections, and policies that end sessions, prompt for MFA or trigger Universal Logout.
Failure modes: missing sensors (one domain controller or a new AD FS farm without a sensor is a blind spot); learning periods that hide attacks in the first week; automated response firing on a false positive against a service account; and the ITDR tool itself becoming a tier zero target, because it holds rights to disable accounts. See Securing the identity threat detection and response (ITDR) tool itself.
SIEM: central correlation and evidence
The SIEM threat model is broader: any attacker activity that leaves a trace in any onboarded source. The ASD and CISA priority logs guidance ranks domain controller and Active Directory logs directly after EDR and network devices, and lists the Entra sign-in categories (interactive, non-interactive, managed identity, service principal and AD FS sign-ins) along with Entra Connect synchronisation events. Its strength is joining an identity event to the host, process and data activity around it.
Failure modes: identity sources onboarded partially (interactive sign-ins but not non-interactive or service principal sign-ins, which is where token replay and workload identity abuse show up); audit policy drift on new domain controllers; and Kerberos events dropped to save cost. See the SIEM Log Source Onboarding Checklist.
Non-human identities: the decisive test
Service accounts, application registrations, managed identities and API tokens break both approaches in different ways. A SIEM sees service principal and managed identity sign-ins only if those log categories are routed (the Log Analytics tables are separate from interactive sign-ins: SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs and AADManagedIdentitySignInLogs), and has no idea which workload owns each identity. ITDR tools know which accounts are sensitive, but automated containment against a production service account can stop a business process.
- Kerberoastable service accounts: ITDR detects the roasting; the SIEM holds the 4769 history of earlier requests. Retire SPNs where possible: see How to find and retire Active Directory service accounts with SPNs.
- New credentials on applications: SIEM rule on audit events, enriched with the application's permissions. The Microsoft Midnight Blizzard breach began with a low-volume password spray on a legacy test tenant without MFA and moved through OAuth applications; one of its lessons is that test and legacy tenants need the same monitoring as production.
- Response on NHIs: never auto-disable a production service account; rotate its credential and restrict its source instead, with the owner informed. See the Service Account Security Guide.
Integrating ITDR alerts into the SIEM
The goal is one queue, one case per incident and one evidence store.
| Integration path | How it works | Watch out for |
|---|---|---|
| Syslog or CEF from the ITDR tool | Defender for Identity can forward new alerts, updated alerts and health issues to one Syslog endpoint through a configured sensor, over TCP or UDP, in RFC 3164 or RFC 5424 format | Only one endpoint; key automation on the stable externalId field, not the display name, which Microsoft notes can change |
| Platform-native connector or API | Defender XDR streams Advanced Hunting events to Azure Event Hubs or a storage account; Microsoft recommends the Graph security API for new integrations and the Defender XDR connector for Sentinel | Streaming raw events and alerts can double ingestion cost |
| IdP log streaming | Okta log streams send all System Log events, including ITP events, in near real time to Amazon EventBridge or Splunk Cloud | No filtering or replay; at-least-once and possibly out of order, so deduplicate on eventId; after failed retries the stream deactivates until reactivated, so alert on its health |
| Shared signals | OpenID Shared Signals Framework 1.0 (published 29 August 2025): transmitters send Security Event Tokens to receivers by push (RFC 8935) or poll (RFC 8936, the default) | Suits session revocation between IdP, ITDR and applications; the SIEM still needs logs |
Deduplication and ownership rules
- Map overlaps first: list every SIEM identity rule and mark which ITDR detection covers the same technique. Where the ITDR detection is better (Golden Ticket, DCSync, honeytokens), retire or demote the SIEM rule to a hunting query; where the SIEM rule is better (cross-source correlation), keep it and use the ITDR alert as enrichment.
- Correlate on identity: join ITDR alerts to SIEM events on a normalised account key (UPN, SID, object ID).
- One response owner per action: if ITDR revokes sessions, SOAR must not repeat it; log ITDR actions into the SIEM case.
- Monitor the pipes: alert when the ITDR tool stops sending, a sensor reports a health issue, or an IdP stream deactivates.
Decision criteria
| Situation | Lean towards | Why |
|---|---|---|
| On-premises Active Directory is still tier zero | Add ITDR | Forged tickets, DCSync and rogue DC attacks are protocol-level and weakly visible in logs |
| Cloud-only identity, single IdP, strong detection engineering team | SIEM with the IdP's own risk signals | Cloud identity attacks mostly leave audit events; the IdP's native protection covers session risk |
| Several directories and IdPs, few detection engineers | Add ITDR | Maintaining technique coverage across planes by hand is the costly part |
| Regulatory evidence and long retention needed | SIEM is non-negotiable | ITDR is not a log store |
| Need fast containment of compromised identities | ITDR, or SIEM plus SOAR with directory rights | Response must act on accounts and sessions within minutes |
Smaller organisations get most of the value from audit policy, full sign-in log onboarding and the identity protection already licensed. The ITDR Buyer's Guide covers evaluating a dedicated tool.
Worked scenario: Kerberoasting to domain dominance
An attacker with a phished workstation account enumerates service principal names over LDAP, requests service tickets for twelve service accounts with RC4, cracks one offline, and uses it, two days later, to run replication requests from a member server.
- SIEM only, default rules: sees twelve 4769 events among millions. A rule on Ticket Encryption Type 0x17 catches the burst; with AES tickets, or auditing off on one domain controller, nothing fires. Without 4662 and a SACL on the domain object, the DCSync is invisible.
- ITDR only: raises Security principal reconnaissance (LDAP) and Suspected Kerberos SPN exposure alerts on day one, and Suspected DCSync attack on day three, from traffic between the member server and the domain controller. It does not see what happened on the workstation.
- Integrated: the ITDR alert lands in the SIEM case on day one, keyed to the user and host; the SIEM adds workstation telemetry and the 4769 history; the twelve service account passwords are reset with their owners and the workstation is isolated. The day three DCSync never happens.
Detection logic for these techniques is covered in the Kerberoasting and AS-REP Roasting Defence Guide and the Golden Ticket, Silver Ticket and DCSync Guide.
How to implement
- Baseline the SIEM's identity coverage: confirm audit policy on every domain controller (Kerberos authentication service, Kerberos service ticket operations, credential validation, directory service access and changes) and onboard all four Entra sign-in categories or the equivalent IdP logs, plus AD FS and Entra Connect logs. See the Active Directory Security Monitoring and Event IDs Guide.
- Build the coverage matrix: rows are techniques (the table above is a start), columns are identity planes; mark each cell SIEM rule, ITDR detection, both or none.
- Pilot ITDR in alert-only mode: sensors on every domain controller and federation server; judge noise only after documented learning periods.
- Wire the integration: forward alerts and health events; map alert IDs to SIEM severities; build the identity join.
- Test: run benign emulations in a test forest or with approved scope for each technique and record which platform fired, how fast, and with what context. See ITDR validation.
- Turn on response in tiers: session revocation for user accounts first, account disablement only for confirmed high-fidelity detections, never automatic for service accounts.
- Retire duplicates, with rollback: demote overlapping SIEM rules to hunting queries once the ITDR equivalent has proven itself, and keep them in version control so they can be restored if the ITDR tool is removed, loses a sensor or changes licensing.
Detection and measurement
- Technique coverage: percentage of identity techniques in the matrix with at least one tested detection, per identity plane.
- Sensor and source completeness: domain controllers, federation servers and IdP tenants with a healthy sensor or log stream, target 100 percent.
- Mean time to contain an identity: from first identity alert to sessions revoked or credential reset.
- Duplicate alert rate: identity incidents raised twice by SIEM and ITDR; should fall after integration.
- Emulation pass rate: share of quarterly technique tests detected within the target time.
Framework mapping
| Framework | Reference | Where it applies |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01, DE.CM-03, DE.AE-02, DE.AE-03, DE.AE-06, RS.MI-01 | Monitoring, correlation of multiple sources, providing event information to tools, containment |
| NIST SP 800-53 Rev. 5 | AU-6(3) Correlate Audit Record Repositories, AU-12, SI-4, AC-2(12) Account Monitoring for Atypical Usage, IR-4 | SIEM correlation, log generation, identity monitoring, incident handling |
| CIS Controls v8.1 | 8.2 Collect Audit Logs, 8.9 Centralize Audit Logs, 8.11 Conduct Audit Log Reviews, 13.1 Centralize Security Event Alerting | Identity logs collected centrally; ITDR alerts centralised in the SIEM |
| ISO/IEC 27001:2022 Annex A | A.8.15 Logging, A.8.16 Monitoring activities, A.5.26 Response to information security incidents | Evidence retention, monitoring, response |
| MITRE D3FEND | D3-ANET Authentication Event Thresholding, D3-UBA User Behavior Analysis, D3-CR Credential Revocation, D3-ST Session Termination | Detection and response techniques split between the platforms |
Common failure patterns
- Assuming ingestion equals detection: logs flow, but no tested rule exists for RC4 tickets or replication from member servers.
- Audit policy gaps on one server: a new domain controller built without the Kerberos audit subcategories silently removes coverage for every ticket it issues.
- Collecting interactive sign-ins only: token replay, service principal abuse and managed identity misuse live in the non-interactive and workload sign-in logs.
- Forgetting the federation layer: forged SAML tokens create no authentication event at the federation server, as the SolarWinds supply chain compromise showed, so monitoring must cover token-signing certificate access and new credentials on service principals. See the Golden SAML and Federation Trust Abuse Defence Guide.
- Two tools, two queues: ITDR alerts handled in a separate console, so no one sees them beside the endpoint alert from the same host.
- Silent pipeline failure: an IdP log stream deactivated after failed deliveries, or an ITDR forwarder down for weeks, with no alert.
Practitioner checklist
- Confirm Kerberos, credential validation and directory service audit policy on every domain controller, and recheck after every new build.
- Onboard interactive, non-interactive, service principal and managed identity sign-in logs, plus AD FS and Entra Connect logs, into the SIEM.
- Build a technique-by-plane coverage matrix and mark each cell SIEM, ITDR, both or none.
- Deploy ITDR sensors on every domain controller, AD FS and AD CS server if you run on-premises identity.
- Forward ITDR alerts and health events to the SIEM keyed on a stable alert identifier, and join them on a normalised account key.
- Exclude production service accounts from automatic disablement; rotate and restrict instead.
- Run quarterly benign emulations per technique and record which platform detected each one.
Standards and references
- ASD's ACSC and CISA: Priority Logs for SIEM Ingestion, Practitioner Guidance
- CISA: Guidance for SIEM and SOAR Implementation
- OpenID Foundation: Shared Signals Framework Specification 1.0
- Microsoft: Event 4769, A Kerberos service ticket was requested
- Microsoft: Defender for Identity classic security alerts
- Microsoft: Defender for Identity notifications and Syslog forwarding
- Okta: About log streams
- Okta: Identity Threat Protection overview
Related NHI Mgmt Group resources: ITDR Guide · SIEM Guide · SOAR vs SIEM · Identity Threat Hunting Guide · ISPM vs ITDR