Identity Threat Detection Use Cases That Catch Real Attacks

What if the fastest way into your network is not a software bug, but a login box? That is the reality defenders face today. Attackers rarely break in anymore. They log in. They use stolen passwords, hijacked session tokens, and forgotten service accounts to walk through the front door looking like a legitimate employee. That shift is why identity threat detection has moved from a niche monitoring task to a core security discipline.

This article breaks down the practical use cases where identity threat detection earns its keep. It covers what each use case looks like, which data sources feed it, and the mistakes that trip up teams in the real world.

What identity threat detection actually means

Identity threat detection is the practice of monitoring authentication and authorization activity for signs of compromise, misuse, or policy abuse. Instead of watching only endpoints and network traffic, it watches the identity layer: sign-ins, token issuance, privilege changes, and access to sensitive resources.

The framing “identity is the new perimeter” became mainstream around 2020 to 2022 as cloud adoption and remote work dissolved the old network boundary. Microsoft’s own guidance now treats identity as the primary control plane for security. The logic is simple: if the attacker authenticates as a valid user, endpoint antivirus and firewall rules may never fire.

Detection at this layer depends on specific telemetry. Common sources include cloud identity provider sign-in logs (Microsoft Entra ID, Okta), Windows Security events such as 4624, 4625, 4768, and 4769, and correlation inside a SIEM. Understanding how that telemetry maps to attacker behavior is where the use cases begin.

Use case 1: Detecting credential dumping and brute force

The MITRE ATT&CK framework catalogs a full Credential Access tactic (TA0006) that includes techniques like OS Credential Dumping (T1003) and Brute Force (T1110). This is the foundational identity detection use case: catching attackers while they try to obtain or guess credentials. (Cybersecurity Framework)

What works in practice:

• Alert on high-volume failed authentications from a single source or against a single account, then correlate with a subsequent success.

• Watch for authentication attempts spread across many accounts from one IP, which signals password spraying rather than a forgetful user.

• Baseline normal login hours and geographies per account, then flag deviations with context, not in isolation.

The common mistake is treating every failed login as an incident. Most organizations drown in noise within a week and start ignoring alerts. Tuning matters more than coverage here. A password spray of one attempt against 500 accounts looks nothing like a brute force of 500 attempts against one account, and the detection logic should reflect that difference.

Use case 2: Kerberoasting and service ticket abuse

Kerberoasting (ATT&CK sub-technique T1558.003) is one of the clearest examples of an identity attack that leaves a detectable footprint. The attacker requests Kerberos service tickets for accounts registered with service principal names, then cracks them offline to recover passwords.

Detection relies on spotting the abnormal pattern: a burst of ticket requests (event 4769 on Windows domain controllers), unusual use of weaker RC4 encryption, and requests for service accounts the user has never touched before. Because the cracking happens offline, the ticket request itself is often the only signal. Teams that do not log and baseline ticket requests simply miss it.

This use case rewards patience. Analysts need a picture of which accounts normally request which service tickets. Without that baseline, every ticket request looks equally suspicious, and the real attack hides in the crowd.

Use case 3: MFA fatigue and push bombing

Multi-factor authentication is essential, but it is not magic. MFA fatigue attacks bombard a user with push notifications until they approve one out of frustration or confusion. Public reporting on high-profile breaches, including the 2022 Uber incident, pushed this use case into the mainstream. CISA’s guidance on MFA deployment now explicitly addresses these push-based weaknesses.

Detection patterns that work:

• Multiple denied push notifications followed by an approval within a short window.

• A successful sign-in immediately after a cluster of MFA prompts the user did not initiate.

• Authentication from an unusual device or location paired with repeated MFA challenges.

The practical fix is often policy as much as detection: number matching, phishing-resistant authenticators, and rate limits on push notifications. Detection still matters because it tells you which accounts are under active pressure. If you are building out a broader monitoring stack, resources on what is a cyber threat intelligence map can help you connect identity alerts to wider threat context.

Use case 4: Token theft and session hijacking

Session tokens are the quiet weak point in modern authentication. Adversary-in-the-middle phishing kits can capture a valid session token and replay it, bypassing MFA entirely because the token is already authenticated. ATT&CK documents this pattern under techniques like T1539 (Steal Web Session Cookie).

Detection focuses on the token lifecycle:

The mistake teams make is trusting password resets to end a compromise. If the attacker holds a valid refresh token, the reset may not revoke it. Detection rules should explicitly check whether sessions are revoked after credential changes. This is also why what is identity theft and how can you prevent it covers both consumer and enterprise angles: the mechanics of stolen credentials are the same, whether the victim is a person or a company. (Identity theft)

Use case 5: Risky sign-ins and leaked credentials

Vendor risk engines provide a ready-made detection layer. Microsoft Entra ID Protection, for example, ships risk detections such as leaked credentials, anonymous IP use, atypical travel, and password spray, and feeds them into risk-based Conditional Access. These signals are concrete, documented, and usable out of the box.

The value is speed. A leaked-credential detection tells you a valid corporate username and password are circulating, often before the attacker uses them. The weakness is context. Risk scores are probabilistic, and a “medium risk” sign-in might be a traveling executive on hotel Wi-Fi. Good programs pair vendor risk signals with their own baselines rather than treating the score as a verdict.

NIST’s digital identity guidance, including the draft revision of SP 800-63B, reinforces the underlying principles: authenticator threats, rate limiting, and verifier impersonation resistance all shape what you should be able to detect.

Use case 6: Non-human identity and service account abuse

Service accounts, API keys, managed identities, and automation credentials make up a growing share of identities in cloud environments, and they are frequently over-privileged and poorly monitored. Non-human identities rarely trigger MFA prompts or password resets, which makes them attractive to attackers and easy to overlook.

Detection use cases here include:

• Alerting when a service account authenticates from an unexpected network range or at an unusual time.

• Flagging service accounts that suddenly access resources outside their historical pattern.

• Tracking credentials that have never rotated and are used interactively.

• Monitoring for new API keys or secrets created outside change management.

This is still an emerging area with no single standards body definition. A comparison of vendor approaches, such as Astrix vs Oasis vs Entro non human identity security 2026, shows how differently platforms scope the problem. Teams should expect definitional ambiguity and focus on the telemetry they can actually collect.

Use case 7: Privilege escalation and role changes

Attackers who gain a foothold quickly try to expand it. Detection should watch for suspicious role assignments, new global administrators, and changes to authentication policy that weaken controls. A user added to a privileged group at 2 a.m. by an account that has never done so before is a high-fidelity signal.

Pair this with monitoring of consent grants and OAuth application approvals. Malicious apps requesting broad permissions are a well-documented path to persistent access, and they show up in audit logs long before data exfiltration begins. Building a detection rule around “first-time privileged action by this account” catches a surprising amount of real activity.

Where these detections live: SIEM and correlation

Most of these use cases depend on a SIEM that can correlate identity logs with endpoint and network data. Open-source options like Wazuh are popular for this, and practical deployment guides such as Wazuh SIEM detect PHP2Shell 13 steps 2026 show how detection content gets built and tuned. The same tuning discipline applies to identity rules.

Three habits separate programs that work from programs that generate noise:

• Start with a baseline. Collect 30 days of normal sign-in and ticket data before writing aggressive rules.

• Tie every alert to an action. If no one knows what to do when a rule fires, the rule is theater.

• Review false positives weekly. Identity data is messy; rules need constant adjustment.

Common mistakes that undermine identity detection

Teams frequently make the same errors. They enable every vendor risk detection without tuning, then drown. They log sign-ins but not token events, missing session hijacking entirely. They ignore service accounts because “those are automated.” They treat MFA as a finish line rather than a control that itself needs monitoring.

The most damaging mistake is silence. An identity detection program with no documented use cases, no owners, and no response playbooks is just log collection. Detection only counts when someone acts on it.

Conclusion

Identity threat detection is not one product or one alert. It is a set of concrete use cases, from credential dumping and Kerberoasting to MFA fatigue, token theft, risky sign-ins, non-human identity abuse, and privilege escalation, each fed by specific telemetry and each requiring its own tuning. The organizations that get this right start with baselines, connect alerts to real response actions, and treat identity as the control plane it has become. Attackers have already made that shift. Defenders who follow will catch them at the login box, before the damage spreads.

FAQ

What is identity threat detection?

Identity threat detection is the practice of monitoring authentication and authorization activity, such as sign-ins, token issuance, and privilege changes, for signs of compromise or misuse. It focuses on the identity layer rather than endpoints or network traffic.

Why is identity threat detection important now?

Cloud adoption and remote work moved the security boundary to identity. Attackers increasingly log in with stolen credentials or tokens instead of exploiting software, so detection at the identity layer catches attacks that endpoint tools miss.

What data sources feed identity threat detection?

Common sources include cloud identity provider sign-in logs from Microsoft Entra ID or Okta, Windows Security events such as 4624, 4625, 4768, and 4769, audit logs for role and consent changes, and SIEM correlation across all of them.

What is Kerberoasting and how is it detected?

Kerberoasting is an attack that requests Kerberos service tickets for accounts with service principal names and cracks them offline. Detection relies on spotting abnormal ticket request bursts, unusual RC4 encryption use, and access to service accounts a user has never touched.

What is MFA fatigue?

MFA fatigue, or push bombing, is an attack that floods a user with push notifications until they approve one. Detection looks for clusters of denied prompts followed by an approval, or a successful sign-in right after repeated MFA challenges.

Can identity threat detection stop token theft?

It can catch it, though not always prevent it. Detection flags token replay through impossible travel, device mismatches, and refresh tokens used after password resets. Pairing detection with token revocation and phishing-resistant authentication closes the gap.