Identity Threat Detection & Response (ITDR)

#Why Identity Is the Primary Battleground

The classic attacker had to exploit a vulnerability to get in. The modern attacker logs in. Phished credentials, stolen session tokens, and abused OAuth grants are now the dominant initial-access vector because:

• There is no network perimeter to breach in a SaaS + multi-cloud world — the IdP (Okta, Entra ID, Google Workspace) is the front door.
• A valid credential generates legitimate-looking authentication events. The attacker isn't exploiting anything; they're using the system as designed.
• Once inside, identity is how you move: assume a role, mint a token, pivot to the next service.

This is why "ITDR" exists as a named discipline: detecting the abuse of legitimate identity is fundamentally different from detecting malware, because there's no malicious binary — only a login that shouldn't have happened.

#The Core Detection Problem

The hard part of identity detection: a malicious login and a legitimate login look almost identical. Both present valid credentials. The signal is almost never the authentication itself — it's the context around it:

• Where from (new country, hosting-provider ASN, anonymizer)?
• When (3am for a 9-5 user)?
• How (new device, headless user-agent, unusual auth method)?
• What happened next (immediately enumerating permissions, accessing crown jewels)?
• Is it physically possible (two logins from continents apart, minutes apart)?

So identity detection is overwhelmingly behavioral and contextual, which makes IdP/audit logs (Okta System Log, Entra sign-in logs, GCP/AWS auth events) your most important data source.

#Identity Attacks and How to Detect Each

#Credential stuffing & password spraying

#MFA fatigue (push bombing)

#Impossible travel / anomalous location

#Session/token theft (the MFA bypass)

#OAuth / consent-grant abuse ("illicit consent grant" / consent phishing)

Last verified2026-06 (audit-log event names below reflect Microsoft Entra and Google Workspace as of this date.)

The mental model to fix first"Sign in with Google" by itself is just authentication — the app learns who you are (scopes openid, email, profile) and nothing else. Consent abuse is about authorization: the app additionally asks for API scopes — gmail.readonly, https://mail.google.com/, drive, or Microsoft Graph Mail.Read, Files.Read.All — plus offline_access. The moment the user clicks Allow, the app receives a refresh token: a long-lived key that lets it call those APIs as the user, indefinitely, with no further login. So the access isn't "the login button" — it's the grant sitting behind it.

So the danger usually isn't a famous app over-asking. It's an attacker-controlled app you've never heard of, and the consent screen you see is the real, genuine Google/Microsoft page — which is exactly what makes it work. You're not being phished for your password; you're being phished for a grant. The attacker never sees the password and never needs it, so MFA and password resets are irrelevant.

The real-world flow

1. Attacker registers an OAuth app with Google/Microsoft, requesting high-risk
   scopes (read mail, read files) + offline_access (so it gets a refresh token).
2. Phish: "A document was shared with you — click to view."
   The link goes to the LEGITIMATE consent URL, carrying the attacker's client_id.
3. Victim is already logged in, so they just see Google's real consent screen:
   "MyDocsViewer wants to: Read your email, See and download your files." → Allow
4. Google redirects an authorization code to the attacker's server, which trades
   it for an access token + a refresh token.
5. Attacker now calls the Gmail / Graph API directly with that token: reads mail,
   downloads files, creates auto-forwarding rules — with no further user action.

Why it's so dangerous — it's stealthy persistence. The grant survives password resets and MFA because there's no login to challenge; the API calls come from a "trusted" third-party app and blend in with normal usage; and no malware ever touches an endpoint. Evicting it requires revoking the grant — the step users and many responders forget.

Real examples

Variants worth naming

Which requested permissions count as abusive (red-flag scopes). Not every scope is equal. The triage rule of thumb: a scope is high-risk when it grants broad read of user data, the ability to send/write/modify, or tenant-wide application access — and the alarm escalates when it's an application permission (acts without any signed-in user) or paired with offline_access (a refresh token for permanent access). Concrete tiers:

Two more tells independent of the scope name: an app whose requested scopes don't match what it claims to do (a "PDF viewer" asking for Mail.Send), and any app requesting admin-restricted / admin-consent-required permissions, which by design only a privileged admin can approve — so a consent prompt for one is a moment to stop and verify.

How to actually revoke a grantThe critical catch: revoking the consent does not invalidate tokens already issued. Three steps, all needed — (1) remove the grant/consent, (2) revoke the user's refresh tokens/sessions, (3) disable or delete the app so it can't request new tokens. Access tokens already minted (typically valid ~1 hour) usually can't be individually revoked, so disabling the app is what stops new ones from being issued. Where each is done:

#Privilege escalation & role assumption

#Federation / SSO trust abuse (Golden SAML and friends)

The trust model firstIn SAML single sign-on, the identity provider (IdP) — Okta, ADFS, Entra ID — authenticates the user and hands back a signed assertion: an XML statement like "this is alice, an admin, valid for one hour," signed with the IdP's private signing key. The service provider (SP) — AWS, Salesforce, Google Workspace — doesn't phone home to check; it simply verifies the signature against the IdP's public certificate it has on file. Whoever controls a trusted signing key can mint a valid assertion for any user, any privileges, any lifetime — no login, no password, no MFA. That is Golden SAML; it's the SAML analogue of a Kerberos Golden Ticket (forging tickets with the krbtgt key).

There are two ways to get a trusted signing key, and the distinction matters:

Coined by CyberArk in 2017, the name echoes Kerberos Golden Tickets, which forge tickets with the krbtgt key.

Memory hook

Golden SAML = forging SAML assertions with a trusted signing key. Classically by stealing the ADFS key; in the cloud, more often by adding your own trusted key after compromising an IdP admin.

#Dormant & service accounts

#Non-Human Identity (NHI) — the fast-growing surface

Machines now vastly outnumber humans as authenticating identities: service accounts, API keys, OAuth tokens, cloud workload identities, CI/CD credentials. They're attractive because they're often over-privileged, long-lived, poorly inventoried, and unmonitored.

Detection leans on the fact that machines are predictable: a service account should call the same APIs, from the same hosts, on the same schedule. So deviation is unusually meaningful — a CI credential that suddenly enumerates IAM, or a workload identity authenticating from outside its normal subnet, is a strong signal precisely because legitimate machine behavior is so consistent.

#UEBA: behavioral baselining for identity

User & Entity Behavior Analytics builds a per-identity baseline of "normal" — typical login times, locations, devices, data-access volume, and API usage — then scores deviations. It's how you catch the valid login that's anomalous for that specific user, which static rules miss.

The tradeoff: UEBA reduces missed novel attacks (better recall) but generates false positives when normal behavior legitimately changes (travel, role change, new project). It's best used to prioritize and enrich rather than to auto-page — an anomaly score feeding human triage, not a standalone high-severity alert.

#Response Actions for Identity Compromise

Detection is half the discipline; the "R" in ITDR is the response. For a confirmed identity compromise, revoking the session is as important as resetting the password — because of token theft, a password reset alone leaves stolen tokens valid: