Identity Threat Detection and Response: Stopping Credential-Based Attacks
Most intrusions now begin with a valid login. Detecting identity abuse matters more than detecting malware.
The intrusion pattern has changed. Attackers rarely need malware to enter an enterprise now; they need a working login. Credentials are purchased, phished, or lifted from an infostealer log, and the resulting activity looks exactly like a legitimate employee at work — because technically it is.
That is why identity has become the primary detection surface, and why endpoint and network tooling alone leaves a substantial blind spot.
How credential-based intrusions actually run
The sequence is consistent: obtain credentials, defeat or bypass second-factor authentication, establish a durable session, enumerate what the identity can reach, escalate privilege through misconfigured roles or group membership, and establish persistence by registering a new authentication method or granting an application consent.
The persistence step is the one most often missed. An attacker who registers their own MFA method or issues an OAuth consent grant retains access even after the original password is reset.
Close the entry paths first
- Phishing-resistant authentication. Passkeys and FIDO2 keys defeat real-time relay proxies that harvest one-time codes. Prioritise administrators, finance, and executives.
- Number matching and context in MFA prompts. Removes the effectiveness of prompt bombing.
- Conditional access with device trust. Sensitive access only from managed, compliant devices.
- Token binding and shorter session lifetimes for privileged sessions, limiting the value of stolen tokens.
- Legacy authentication disabled wherever it still exists — it bypasses modern policy entirely.
The signals worth alerting on
| Signal | What it usually indicates |
|---|---|
| Repeated MFA denials followed by approval | Prompt bombing that eventually succeeded |
| New MFA method registered | Attacker persistence |
| Sign-in from anonymising infrastructure | Credential use by a third party |
| Consent granted to unfamiliar application | Token-based persistence and data access |
| Privileged group membership change | Escalation |
| Dormant account suddenly active | Use of an unmonitored identity |
| Mass file access or export by one identity | Exfiltration in progress |
These are high-signal, low-volume detections — unusual in security operations, and the reason identity monitoring gives disproportionate return.
Reduce what a compromised identity can do
Detection buys time; least privilege limits damage. Remove standing administrative access in favour of just-in-time elevation with approval, separate administrative accounts from daily-use accounts, review privileged group membership monthly, and inventory service accounts and non-human identities — which typically outnumber human accounts and frequently hold excessive, unrotated credentials.
Non-human identities deserve special attention because they rarely have MFA, often have broad permissions, and almost never appear in access reviews.
Respond with the right sequence
Password reset alone does not evict a determined attacker. The correct order is: revoke active sessions and refresh tokens, reset credentials, remove attacker-registered MFA methods, revoke suspicious application consent grants, review and reverse privilege and group changes, then examine what data the identity accessed during the compromise window.
Automate the first two steps for high-confidence detections, and rehearse the whole sequence — teams that improvise it typically leave at least one persistence mechanism intact.
Governance keeps it from regressing
Run quarterly access reviews with business owners, not IT, and enforce joiner-mover-leaver automation so role changes actually remove old entitlements. Privilege accumulation through internal moves is the most common source of over-permissioned accounts, and it is invisible without periodic review.
Frequently asked questions
What is ITDR?
Monitoring identity systems and authentication behaviour to detect attacks using valid credentials or sessions — credential theft, token replay, MFA bypass, privilege escalation, and dormant or service account abuse.
Why is MFA not enough?
Push and code-based MFA can be defeated by relay proxies, prompt bombing, and token theft. Phishing-resistant methods plus session monitoring are required.
Which signals matter most?
New MFA method registration, MFA denials followed by approval, anonymised sign-ins, unfamiliar app consent grants, privileged group changes, and dormant account activation.
What is the first response action?
Revoke sessions and refresh tokens before resetting the password — otherwise the existing session survives the reset.