ITDR: Detecting and Responding to Identity Attacks

ITDR (identity threat detection and response) is the set of tools and practices for detecting, investigating, and responding to attacks aimed at identities: user accounts, tokens, and the systems that issue access such as Active Directory or an identity provider. It matters because many attackers do not break in; they sign in with a valid account, so tools focused on malware and traffic may see nothing unusual. This article explains ITDR identity threat detection in a vendor-neutral way, from what attackers do to the signals worth watching and the first steps you can take.

What ITDR does

ITDR is an industry term. Secondary sources mostly credit Gartner with popularizing it around 2022, and definitions vary by vendor. Microsoft's Defender for Identity documentation is a useful concrete example: it describes monitoring signals from on-premises Active Directory, Microsoft Entra ID, and other IAM systems such as Okta, using sensors on identity infrastructure and analyzing them with behavioral analytics, threat intelligence, and known attack patterns. ITDR complements IAM, PAM, EDR, and SIEM; it does not replace them.

• Reduce the attack surface: assess risky configurations and the lateral-movement paths an attacker could use, before they are used
• Detect: rely on behavioral analytics and correlated signals rather than single events
• Investigate: provide context such as the identities involved, nearby activity, and the technique used
• Respond: revoke sessions, reset passwords, or disable accounts through the identity system or the SOC's incident queue

What attackers do to identities

MITRE ATT&CK groups Credential Access (TA0006) as the tactic in which an adversary tries to steal account names and passwords. As of October 2026 it lists 18 top-level techniques. Separately, Australia's ASD ACSC, together with CISA, NSA, and agencies from Canada, the United Kingdom, and New Zealand, published guidance on 17 common techniques used to compromise Active Directory. Common examples follow.

• Guessing or stealing passwords: brute force and password spray, which tries common passwords against many accounts
• Getting past MFA by wearing down the user: MFA Request Generation (T1621) sends repeated prompts until the user approves. MITRE lists APT29, LAPSUS$, and Scattered Spider as groups that have used it
• Stealing tokens or session cookies: for example T1528 and T1539. An attacker who can replay an existing session does not need to pass MFA again
• Abusing Kerberos: Kerberoasting (T1558.003) requests service tickets and cracks service-account passwords offline. DCSync (T1003.006) mimics domain controller replication to pull password hashes. Golden Ticket (T1558.001) forges TGTs once the KRBTGT account hash is known
• Tricking the help desk: per CISA advisory AA23-320A, Scattered Spider impersonated employees to get passwords reset and MFA moved to devices they control, and also used SIM swapping and registered their own MFA methods
• Creating lasting access in the cloud: per ATT&CK T1078.004, adversaries create additional long-lived cloud credentials that can bypass MFA, and exploit misconfigured role assignments to escalate privileges

Signals ITDR looks for

• At sign-in level: Entra ID Protection offers risk detections such as password spray (raised when an attacker guesses at least one account's password correctly), anomalous token (abnormal token traits such as unusual lifetime or replay from an unfamiliar location), suspicious MFA authentication approval, and leaked credentials (a valid credential found in leaked data)
• At Active Directory level: Defender for Identity organizes detections by attack stage: reconnaissance, compromised credentials, lateral movement, and domain dominance (for example DCShadow, malicious replication, and Golden Ticket). MITRE adds detection ideas: for Kerberoasting, watch Event ID 4769 requests using RC4 (0x17) and bursts of service-ticket requests from one account; for DCSync, watch replication requests from machines that are not domain controllers; for Golden Ticket, watch abnormal ticket lifetimes, RC4 use, and TGS requests with no preceding TGT
• At behavior level: changes to membership of highly privileged groups or roles, inbox rules that forward mail outside the organization, unusual directory enumeration through the Graph API, and odd service-account behavior

Signals differ in reliability. Microsoft notes that anomalous token still has a higher than normal chance of false positives at low and medium risk levels, whereas leaked credentials are always rated high because the match is verified rather than heuristic. Teams therefore need to rank investigations by both signal reliability and account importance.

What to do after a detection

The documents reviewed give specific guidance. Microsoft Entra says clearing an attacker-in-the-middle risk might require a secure password reset or revoking existing sessions. MITRE advises containing a previously created Golden Ticket by resetting the KRBTGT password twice per domain, with a replication step between the resets. AA23-320A notes that attackers registered their own MFA methods and historically added federated identity providers to SSO tenants, so check both after an account is taken over. A sequence that fits most incidents is shown below.

ITDR and your other tools

ITDR can detect on its own, but response usually runs through other systems. Microsoft Defender for Identity streams signals into the same Defender portal as endpoint, email, and cloud data so they correlate into one incident. For the wider picture of SIEM, SOAR, and XDR, see SIEM, SOAR and XDR: How They Differ. The levers that break an attack, such as revoking sessions or reducing privileges, live in IAM and PAM, which are compared in IAM vs IGA vs PAM vs CIEM. Some vendors sell ITDR as a module of an XDR platform and others sell it separately, so ask whether it has sensors on domain controllers and whether it supports the identity providers you use.

How to adopt it in stages

• Start with identity hygiene: CISA recommends phishing-resistant MFA such as FIDO/WebAuthn or PKI-based methods, which resist both push bombing and SIM swapping, and ATT&CK recommends disabling legacy authentication. See Which MFA Is Safer?
• Collect identity logs completely: domain controller security logs and the sign-in and audit logs of Entra or your identity provider, sent to your SIEM or XDR platform
• Begin with a few clear use cases: map them to ATT&CK Credential Access, for example password spray, token replay, Kerberoasting, and DCSync
• Decide the response in advance: who may revoke sessions or disable accounts, with automation only for low-risk steps and human approval for important accounts
• Look after non-human accounts: service accounts are Kerberoasting targets. MITRE recommends long, complex passwords (it cites 25 or more characters), group managed service accounts, and minimal privileges. See Service Accounts and Non-Human Identities
• Rehearse and measure: simulate a hijacked account and measure how long detection and containment take

Common mistakes

• Assuming the tool sees everything: without sensors or logs from domain controllers and identity providers, it is blind
• Chasing every alert equally: signals with high false-positive rates should rank below confirmed ones
• Detecting without fixing weaknesses: crackable service accounts and excess admin rights stay exactly as they were
• Automating response against the wrong account: disabling an emergency account or a critical service account can stop operations, so keep an exception list and approvals
• Forgetting the human channel: a help desk that resets passwords or MFA without strong identity checks is a gap that detection tools cannot see
• Having no Active Directory recovery plan: resetting KRBTGT twice and rotating secrets affect the whole domain, so plan and rehearse in advance

Start today

• Check how far identity logs reach: are domain controller security events and identity-provider sign-in logs collected and searchable?
• Find risky service accounts: accounts with a service principal name, an old or short password, and more privilege than needed
• Disable legacy authentication where it is still on, because Microsoft notes that unfamiliar-sign-in detection has limited data on those protocols and recommends moving to modern authentication
• Write a one-page hijacked-account playbook: revoke sessions, reset the password, remove unknown MFA methods, and check for inbox rules that forward mail outside
• Tighten help desk procedures: verify identity strictly before resetting a password or MFA
• Rehearse one scenario, such as MFA fatigue, and note who detected it, who decided, and how long it took

To see which gap matters most for your organization, try the self-assessment.

References and further reading

• MITRE ATT&CK: Credential Access (TA0006): the full list of credential-theft techniques
• MITRE ATT&CK: Kerberoasting (T1558.003): how it works and detection ideas
• MITRE ATT&CK: DCSync (T1003.006): abusing domain controller replication
• MITRE ATT&CK: Golden Ticket (T1558.001): detection and containment by resetting KRBTGT
• MITRE ATT&CK: MFA Request Generation (T1621): MFA fatigue and mitigations
• CISA: Scattered Spider (AA23-320A): help desk impersonation, MFA bypass, and defensive recommendations
• CISA: Detecting and Mitigating Active Directory Compromises: the international joint guidance on 17 techniques
• Microsoft Learn: Defender for Identity overview: an example of ITDR tooling capabilities
• Microsoft Learn: Entra ID Protection risk detections: the list of sign-in and user risk signals