Attackers increasingly log in rather than break in. Stolen passwords, phished sessions, abused service accounts, forged tokens and social-engineered MFA resets let them move through an environment using valid identities that endpoint and network tools treat as legitimate. Identity threat detection and response (ITDR) is the discipline of detecting and stopping these attacks across directories, identity providers, cloud IAM, SaaS and, increasingly, non-human identities and AI agents. This guide explains what ITDR covers, the techniques it targets, the telemetry and detections that matter, and how to contain an identity compromise. It is written for security operations, detection engineering and identity teams building or reviewing an ITDR capability.
Key takeaways
- Identity is the attack surface. ITDR protects the identity infrastructure itself (directories, IdPs, federation) and detects misuse of identities everywhere they are used.
- Non-human identities need the same coverage. Service accounts, service principals, OAuth apps, API keys and agent credentials cannot use MFA and are among the most abused identities.
- Posture and detection work together. Fixing MFA gaps, standing privilege and dormant accounts shrinks what detection has to catch.
- Persistence lives in identity objects. New MFA methods, app credentials, OAuth grants, federation trusts and role assignments outlast a password reset, so detections must watch them.
- Response means revoking, not isolating. Containment revokes sessions and refresh tokens, resets credentials through a verified process and removes persistence; shared signals such as CAEP spread that revocation to applications.
What ITDR covers
MITRE ATT&CK's Credential Access tactic sums up the adversary goal: "trying to steal account names and passwords". T1078 Valid Accounts then describes what they do with them. ITDR covers both halves across six domains. For a ranked view of the techniques, see our top 10 identity attacks.
- Directory attacks: Kerberoasting (T1558.003), DCSync (T1003.006), pass-the-hash and pass-the-ticket, golden and silver tickets, delegation and certificate services abuse.
- Identity provider attacks: password spraying, MFA request generation or fatigue (T1621), adversary-in-the-middle phishing, session cookie theft (T1539), malicious federation and self-service password reset abuse. The Lapsus$ threat actor profile shows how MFA fatigue and help desk abuse play out in practice.
- Cloud identity attacks: access key theft, role assumption chains, privilege escalation through IAM misconfiguration, and new credentials added to service principals (T1098.001).
- SaaS and OAuth attacks: consent phishing, stolen OAuth tokens, malicious inbox rules and mailbox access. See the SaaS and OAuth App Governance Guide.
- Non-human identity misuse: service accounts used from new hosts, keys used from unfamiliar infrastructure, tokens replayed, and humans using NHI credentials (OWASP NHI10:2025 Human Use of NHI). See the Service Account Security Guide.
- AI agent misuse: agents using credentials outside their purpose, or an attacker steering an agent that holds broad delegated access. See the AI Agent Observability and Incident Response Guide.
Recent identity-led attacks
| Incident | Identity technique | What ITDR should have seen |
|---|---|---|
| Scattered Spider campaigns (CISA advisory AA23-320A, updated July 2025) | Callers posed as employees to get help desk staff to reset passwords and transfer MFA, and posed as IT staff to obtain one-time codes; push bombing and SIM swaps | Help desk resets on privileged users followed by new MFA registration and sensitive access |
| Storm-2949 Azure Attack 2026 | Microsoft assesses with high confidence that the actor abused self-service password reset, persuading users to approve MFA prompts, then removed their authentication methods and enrolled its own | SSPR followed by method removal and new device registration; Graph enumeration; Key Vault access changes |
| Microsoft Midnight Blizzard Breach 2024 | Password spray against a legacy, non-production test tenant account without MFA, then a legacy test OAuth app with elevated access and new malicious OAuth apps granted the full_access_as_app role | Spray patterns; admin consent to full_access_as_app; new apps with offline access |
| Snowflake Breach 2024 | Mandiant found UNC5537 used customer credentials taken by infostealers, some from infections as far back as 2020, against accounts without MFA or network allow lists | Sign-ins with long-unrotated credentials from unfamiliar infrastructure |
| Stryker Cyberattack 2026 | Security Affairs, citing BleepingComputer's source, reports an administrator account was compromised, a new Global Administrator created and the Intune wipe command used on nearly 80,000 devices | New Global Administrator creation; mass device actions from one account |
None of these relied on malware for initial access. Microsoft says Storm-2949 "didn't rely on traditional malware", using legitimate cloud management features instead; that is the gap ITDR exists to close. Machine credentials are abused the same way: in the Rspack npm compromise, a stolen npm token was used to publish a malicious release.
Identity telemetry sources
Detections are only as good as the logs behind them. Confirm each source is collected, retained long enough to scope an intrusion and parsed with the fields analysts need.
| Source | Key events | Used for |
|---|---|---|
| Domain controllers | Kerberos service ticket requests (Event ID 4769, with encryption type), directory replication, privileged group changes | Kerberoasting, DCSync, privilege escalation |
| Identity provider sign-in and audit logs | Sign-ins with risk, MFA events, SSPR, authentication method changes, role assignments, app consents, federation changes | Spraying, MFA abuse, persistence |
| IdP risk detections | Entra ID Protection examples: password spray, anomalous token, attacker in the middle, suspicious MFA approval, leaked credentials | Pre-correlated user and session risk |
| Workload identity risk | Entra examples: suspicious sign-ins, leaked credentials, anomalous service principal activity | Service principal and app compromise |
| Cloud control plane | Role assignments, key and secret reads, network rule changes, run commands | The Storm-2949 pattern of control-plane abuse |
| SaaS audit and API logs | Bulk exports, mailbox rules, integration activity | Data theft through valid sessions |
| Secrets managers and PAM | Secret reads, check-outs, session recordings | NHI credential misuse |
Microsoft's workload identity documentation explains why the last rows matter: workload identities "can't perform multifactor authentication", often have no formal lifecycle process and must store their secrets somewhere. Its suspicious sign-in detection for them learns a baseline over 2 to 60 days, so new service principals start with little behavioural cover.
Core detections
| Area | Signals to detect | ATT&CK reference |
|---|---|---|
| Authentication | Password spraying; MFA push volumes not tied to user-initiated sessions; impossible travel; sign-ins from anonymising or residential proxy infrastructure; legacy protocol use | T1110.003, T1621 |
| Sessions and tokens | Token replay from new devices or networks; anomalous token lifetime; session cookie reuse; refresh token abuse | T1539, T1550 |
| Account changes | SSPR or help desk resets followed by method removal, new MFA registration and sensitive access; resets of privileged users | T1098.005 |
| Privilege | New Global Administrator or other privileged role assignments; changes to privileged groups; elevation outside normal patterns | T1098.003 |
| Persistence | New federation trusts; credentials added to apps and service principals; admin consent to high-impact scopes; mailbox forwarding rules | T1484.002, T1098.001 |
| Directory attacks | Unusual volumes of service ticket requests or RC4 tickets (Event ID 4769, etype 0x17); replication requests from non-domain controllers | T1558.003, T1003.006 |
| Non-human identities | Service account interactive logon; keys used from new sources; unusual API volumes; dormant identities becoming active; secret reads by unexpected principals | T1078.004 |
MITRE's detection strategy for Kerberoasting describes exactly that Event ID 4769 and RC4 pattern, and its strategy for Additional Cloud Credentials looks for credentials added to service principals or OAuth apps "by non-standard identities or IP ranges". Midnight Blizzard's use of residential proxies is a reminder that IP indicators alone are weak: Microsoft says searching for traditional IOCs "is not sufficient" for that activity, so behaviour baselines matter. See the Detection Engineering Guide and the Identity Attack Paths Guide.
Detections for non-human identities and AI agents
- Leaked credentials: Entra's workload identity detection of this name fires when a service principal's valid credentials appear in public code on GitHub or in a data breach; treat it as an incident, not a ticket.
- Anomalous administrative activity: Microsoft baselines normal administrative service principal behaviour and flags suspicious directory changes; replicate the idea for any NHI with write access to identity or cloud control planes.
- Managed identity token requests: Microsoft reports that Storm-2949 used Run Command to request a managed identity token from the Instance Metadata Service and tried to read Key Vault secrets with it, failing only because the identity lacked permissions. Alert on token requests from unexpected processes and keep managed identities narrowly scoped.
- Human use of NHI: interactive sign-ins by service accounts, or keys used from employee laptops, match OWASP NHI10:2025 and remove accountability.
- Agent purpose drift: compare an agent's API calls and data access with its approved purpose and owner, and alert on new resources, new tools or volumes far above its baseline.
Posture: reduce the attack surface
Many ITDR tools also assess identity posture, and the incidents above show which weaknesses to fix first.
- MFA everywhere, phishing-resistant for administrators: CISA's Scattered Spider advisory recommends phishing-resistant MFA; Midnight Blizzard and the Snowflake victims both began with accounts that had no MFA. See the Phishing-Resistant MFA Guide.
- Harden recovery: SSPR and help desk resets are now an initial access route, so require stronger verification for privileged users and alert on resets followed by method changes.
- Fewer standing administrators: just-in-time elevation and tightly scoped custom roles; Storm-2949's victims held privileged custom Azure RBAC roles on several subscriptions. See the JIT Access Guide.
- Directory hygiene: long random passwords or gMSAs for Kerberoastable accounts, AES rather than RC4 (a MITRE mitigation), and delegation and certificate template weaknesses fixed.
- Lifecycle for NHIs: dormant accounts, unused app credentials and legacy test apps removed; credentials rotated so stolen ones expire.
See the ISPM Guide and the Active Directory and Entra ID Hardening Guide.
Response playbook for identity compromise
- Contain: disable the account or service principal, revoke all sessions and refresh tokens, and block the source. For an NHI, disable or rotate its credentials before the attacker notices.
- Reset: reset passwords and MFA methods through a verified out-of-band process, never on the strength of the same phone call; rotate keys and secrets for affected NHIs, including any secrets the identity could read (Storm-2949 read dozens of Key Vault secrets in four minutes, according to Microsoft).
- Remove persistence: check for new MFA methods, registered devices, app credentials, OAuth grants, federation trusts, mailbox rules, role assignments, VM extensions and remote management tools.
- Scope: review activity by the identity across IdP, cloud control plane, SaaS and endpoints since first compromise; include other identities targeted the same way.
- Recover and harden: fix the weakness that enabled the attack and add a detection for it.
Automate the first steps through SOAR where confidence is high. Use shared signals so revocation reaches applications quickly: the OpenID Continuous Access Evaluation Profile defines events such as Session Revoked, Credential Change, Assurance Level Change and Risk Level Change, carried over the Shared Signals Framework. NIST SP 800-61 Rev. 3 frames incident response through CSF 2.0 Functions, which helps place these steps in the wider plan. See the Identity Incident Response Playbook and the SOAR and Security Automation Guide.
Where ITDR sits
ITDR overlaps with several categories. Its value is identity-specific context: which accounts are privileged, how they normally behave and how attack paths connect them.
| Capability | Primary question | Relationship to ITDR |
|---|---|---|
| SIEM and XDR | What happened across all telemetry? | ITDR detections often run in or feed the SIEM; XDR correlates identity with endpoint |
| IdP security features | Is this sign-in risky? | A key signal source, but limited to one IdP |
| ISPM | Which identity weaknesses exist now? | The posture half of ITDR |
| PAM | Who can use privileged credentials, and how? | Reduces standing privilege and records sessions ITDR can analyse |
| NHI and secrets platforms | Which machine identities exist and who owns them? | Supplies the inventory and baselines NHI detections need |
See the ITDR Buyer's Guide and the SIEM Guide.
Framework mapping
An indicative NHI Mgmt Group alignment, checked against the published control lists; CIS references are at control level.
| ITDR area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 |
|---|---|---|---|---|---|
| Identity telemetry and logging | PR.PS-04 | AU-2, AU-12 | A.8.15 | 8 | n/a |
| Identity threat detection | DE.CM-03, DE.AE-02, DE.AE-03 | SI-4, AU-6, AC-2(12) | A.8.16 | 8, 13 | NHI10 |
| Posture: MFA and authentication | PR.AA-03 | IA-2, IA-5 | A.5.17, A.8.5 | 6 | n/a |
| Posture: privilege and dormant accounts | PR.AA-05, ID.AM-08 | AC-6, AC-2(3) | A.8.2, A.5.18 | 5, 6 | NHI1, NHI5 |
| Machine identity authentication | PR.AA-01, PR.AA-03 | IA-9, IA-5 | A.5.16, A.5.17 | 5 | NHI4, NHI7 |
| Containment and eradication | RS.MI-01, RS.MI-02 | IR-4, AC-2 | A.5.26 | 17 | n/a |
| Incident analysis and scoping | RS.AN-03, DE.AE-04 | IR-4, AU-6 | A.5.25, A.5.28 | 17 | n/a |
Common failure patterns
- Password reset treated as remediation: attacker-registered MFA methods, devices and app credentials survive the reset, as do issued refresh tokens.
- Help desk and SSPR outside detection: resets are logged but never correlated with the method changes and sensitive access that follow, the pattern in Scattered Spider and Storm-2949 Azure Attack 2026.
- Legacy and test identities forgotten: the Microsoft Midnight Blizzard Breach 2024 began with a legacy test tenant account and a legacy test OAuth app.
- Credentials never rotated: in the Snowflake Breach 2024, Mandiant found infostealer credentials "still valid, in some cases years after they were stolen".
- Only humans baselined: service principals and API keys have no behavioural model, so their misuse looks like normal automation.
- Management planes unwatched: a new Global Administrator or a mass device action goes unalerted, as reported in the Stryker Cyberattack 2026.
- IOC-only hunting: residential proxies and cloud hosting defeat IP blocklists; without behaviour-based detections the activity blends in.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Identity sources onboarded (directories, IdPs, cloud, SaaS, NHI) | Telemetry coverage | Up |
| Priority identity techniques with a tested detection | Detection coverage against your threat model | Up |
| Mean time from identity alert to session and token revocation | Containment speed | Down |
| Privileged accounts without phishing-resistant MFA | Exposure to phishing and MFA fatigue | Down, towards zero |
| Standing privileged role assignments | Blast radius of one compromise | Down |
| Service accounts and service principals with a baseline and owner | NHI detection readiness | Up |
| Incidents where persistence was found after initial containment | Quality of eradication | Down |
See the Identity Security Metrics Guide.
Implementation roadmap
| Phase | Actions | Exit criteria |
|---|---|---|
| First 30 days | Onboard IdP sign-in, audit and risk logs plus domain controller security logs; alert on new privileged role assignments, federation changes and credentials added to service principals; write the identity containment runbook | Core identity logs in the SIEM; high-impact persistence alerts live |
| Days 31 to 90 | Add spraying, MFA fatigue, SSPR-then-method-change and token anomaly detections; enforce phishing-resistant MFA for administrators; automate session and refresh token revocation for high-confidence alerts | Detections tested by emulation; admin MFA gap closed |
| Days 91 to 180 | Extend to cloud control planes, SaaS and secrets managers; baseline service accounts and service principals; adopt shared signals where applications support them; rehearse a help desk social engineering scenario | NHI baselines in place; one full exercise completed; metrics reported monthly |
Practitioner checklist
- Collect identity telemetry from directories, IdPs, cloud control planes, SaaS and NHI sources, with retention long enough to scope an intrusion.
- Detect authentication abuse, token replay, account and method changes, privilege changes and persistence.
- Correlate help desk and SSPR resets with the method changes and access that follow.
- Baseline and monitor service accounts, service principals, OAuth apps and AI agents, not only users.
- Alert on new Global Administrator or equivalent roles and on mass actions from management platforms.
- Close high-risk posture gaps: MFA, standing admins, Kerberoastable accounts, legacy test identities, dormant NHIs.
- Build identity response playbooks that revoke sessions and refresh tokens and remove persistence.
- Automate high-confidence containment and use shared signals where supported.
- Rehearse identity compromise scenarios, including help desk social engineering, at least annually.
Standards and references
- MITRE ATT&CK: TA0006 Credential Access
- MITRE ATT&CK: T1078 Valid Accounts
- MITRE ATT&CK: T1558.003 Kerberoasting
- MITRE ATT&CK: T1098.001 Additional Cloud Credentials
- OpenID Foundation: Shared Signals Working Group (SSF, CAEP, RISC)
- OpenID Foundation: OpenID Continuous Access Evaluation Profile 1.0
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- OWASP: Top 10 Non-Human Identities Risks 2025
- Microsoft Learn: What are risk detections? (Microsoft Entra ID Protection)
- Microsoft Learn: Securing workload identities with Microsoft Entra ID Protection
- CISA: Scattered Spider (AA23-320A)
- Microsoft Threat Intelligence: How Storm-2949 turned a compromised identity into a cloud-wide breach
Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide · Privileged Access Management Guide · Identity Incident Response Playbook · ISPM Guide