Identity Threat Detection · Guide
Investigating Identity-Based Attacks: A Modern SOC Guide
Identity is where the modern attacker lives. Phishing a password used to be the goal; now it is a stepping stone toward stealing a live session, taking over a mailbox, and rerouting a payment, all without tripping a single endpoint alert. Identity-based attacks are the SOC's hardest alerts precisely because the malicious activity looks like authenticated, MFA-passed, policy-compliant work. This guide covers identity threat detection and account compromise investigation for the three attack patterns that dominate the modern identity surface, how to investigate them with evidence discipline, and why "reset the password" closes the door the attacker already walked through but leaves three others open.
The identity attack landscape
The perimeter moved to identity years ago. Attackers follow the money, and the money is in valid sessions. Three patterns account for most of what lands in your queue.
AiTM (adversary-in-the-middle) phishing. A reverse-proxy phishing kit such as Evilginx sits between the victim and the real login page. The victim authenticates normally, completes MFA, and the proxy relays every step while quietly capturing the session cookie and token that the identity provider hands back. The attacker replays that cookie and is signed in as the user with MFA already satisfied. MFA did not fail; it was bypassed by stealing what comes after MFA. MITRE: T1557 (adversary-in-the-middle), T1539 (steal web session cookie).
BEC (Business Email Compromise). This is the business-logic endgame. Once inside a mailbox, the attacker reads the thread history, learns who approves payments and how invoices flow, then acts: diverts an invoice, hijacks a vendor thread, or launches internal phishing from a trusted account. The canonical variants are classic mailbox compromise, invoice/payment fraud, OAuth-scaled BEC via consent-grant abuse, and internal phishing follow-on, with payroll diversion as a close sibling. MITRE: T1114 (email collection), T1564.008 (hidden/forwarding rules), T1098 (account manipulation).
Device-code phishing. This one abuses the OAuth device-authorization grant, the flow built for input-constrained devices like smart TVs. The attacker initiates the flow and tricks the victim into approving the device code on a legitimate Microsoft page. The tell-tale signal is a geographic split between where the code was requested and where it was approved, and remediation is refresh-token-specific.
How they chain. These are rarely standalone. AiTM steals the session; BEC monetizes it. The proxy harvests the cookie, the attacker replays it into the mailbox, sets up persistence, and the operation pivots from credential theft to fraud. When you see an AiTM signal, assume BEC is the objective and investigate forward, not just the sign-in in isolation.
How to investigate
Identity investigations fail when analysts react to a single signal. One "impossible travel" alert is noise; a VPN, a phone roaming, or a corporate proxy all produce it. The verdict lives in correlation across the identity, email, and endpoint planes. Build the case with evidence discipline.
Label evidence by tier
Tag every fact so the verdict is auditable and reviewers can see where judgment entered:
- Observed: directly seen in a log. A sign-in from a new ASN at 02:14. An inbox rule that moves messages containing "invoice" to RSS Subscriptions.
- Correlated: multiple independent sources agree. A SafeLinks click on a lookalike domain, followed 90 seconds later by an Entra sign-in from that same proxy ASN.
- Assessed: analyst judgment built on the above. "Assessed with high confidence this is AiTM-driven session theft, not legitimate travel."
The tiers keep you honest about the line between what the data shows and what you concluded.
Correlate across planes
No single tool sees the whole attack. The signal is in the seams between them:
| Plane | Signals that matter |
|---|---|
| Identity (Entra, Okta) | New ASN/geo, anomalous token use, a session active without a fresh interactive auth, a new MFA method registered |
| Email (Exchange, M365) | New inbox/forwarding rules, mass-read of a thread, OAuth app consents, suspicious sent items |
| Endpoint (Defender, CrowdStrike) | Absence of endpoint activity for a "successful" interactive login is itself a signal, the auth happened somewhere you don't manage |
The most diagnostic AiTM signal is a valid session appearing without a corresponding fresh interactive authentication on a managed device. Correlating Microsoft SafeLinks click telemetry with the subsequent Entra sign-in is the cleanest way to catch the proxy domain, because it ties the phishing click to the resulting session in one timeline.
Map to MITRE and state confidence
Map each correlated finding to ATT&CK (T1557, T1539, T1114, T1564.008, T1098) so the narrative is portable across teams and tools, and close every assessment with an explicit confidence level. "Malicious, high confidence" and "suspicious, low confidence, needs the user contacted" drive very different response actions, and the next analyst inherits your reasoning instead of re-deriving it.
A note on the judgment the tiers expose: the hardest calls are not technical. Is this a malicious login or an exec traveling? Did it touch a production system you must protect right now? That context rarely lives in a document. It lives with the senior analyst who knows this user, this app, and what normal looks like here. Capturing that organizational knowledge so it informs the verdict is the harder half of the problem, and it is the through-line of AI for the SOC and the tribal knowledge the team never wrote down.
Why "reset the password" is necessary but not sufficient
The instinct on a confirmed account compromise is to reset the password and close the ticket. That step is necessary. It is also the one form of persistence the attacker least depends on. Modern identity intrusions are built to survive a password change, because the attacker anticipated it.
Here is what a password reset does not touch:
- Live sessions and refresh tokens. The stolen session cookie keeps working until the session is explicitly revoked. Refresh tokens mint new access tokens for hours or days, independent of the password. The attacker stays signed in while you congratulate yourself on the reset.
- Inbox and forwarding rules. A rule that auto-forwards or hides messages keeps exfiltrating mail and keeps the attacker informed of your response, password or not (T1564.008).
- OAuth grants and app consents. A consented malicious app holds its own token and its own access path. The password is irrelevant to it (T1098). This is the engine behind OAuth-scaled BEC.
- Attacker-registered MFA methods. If the attacker enrolled their own authenticator or phone number during the intrusion, they can re-authenticate through the front door after your reset, with MFA, looking entirely legitimate.
Eviction checklist
Full eviction, in order:
- Revoke sessions and refresh tokens: kill the active access first.
- Remove malicious inbox and forwarding rules: stop ongoing exfiltration and the attacker's visibility into your response.
- Revoke OAuth grants and app consents: close the token-based side door.
- Audit registered MFA methods: remove any the attacker added.
- Reset the password: now it actually means something.
Do this across a rolling ~7-day window, correlating multi-IP and multi-geo sign-ins, because the initial compromise usually predates the alert that surfaced it.
Detection and remediation that actually evicts the attacker
Detection and remediation have to target the artifacts the attacker actually relies on, not the credential they have already moved past.
Revoke sessions and refresh tokens first. This is the single highest-value action and the one most often skipped. Revoking the refresh token invalidates the attacker's ability to mint new access tokens; revoking the session kills the replayed cookie. For device-code phishing specifically, remediation is refresh-token-specific because that grant is the whole point of the attack.
Kill the rules and the consents. Enumerate every inbox rule, forwarding configuration, and OAuth grant on the account. Treat anything created during or shortly before the intrusion window as hostile until proven otherwise. These are the persistence mechanisms that quietly survive everything else.
Audit MFA registrations. Compare registered methods against what the user recognizes. An unfamiliar authenticator app or phone number is an attacker's re-entry ticket.
Move toward FIDO2 and passkeys. This is the durable fix for AiTM. FIDO2 and passkeys are origin-bound: the credential cryptographically checks the domain it is talking to, and the attacker's proxy domain cannot satisfy that origin check. The reverse-proxy kit relays the password and the OTP, but it cannot relay a passkey, because the passkey refuses to sign for the wrong origin. Phishing-resistant authentication does not detect AiTM after the fact; it removes the attack class. Pair it with conditional-access policies that require phishing-resistant methods for sensitive applications.
The honest constraint: even a perfect remediation runbook still hinges on a human verdict about whether this account is compromised, how far the blast radius reaches, and which systems to protect first. That judgment is where these investigations live or die, and it is the part the tooling consistently hands back to you.
Where to go deeper
Identity attacks reward correlation, evidence discipline, and remediation that targets tokens and grants rather than passwords. The two deep dives below take the patterns in this guide down to the log-query level:
- BEC investigation guide: the variants, the ~7-day correlation window, and the full eviction sequence for a compromised mailbox.
- AiTM phishing detection: correlating SafeLinks click telemetry with Entra sign-ins, spotting session-cookie replay, and why FIDO2 ends the attack class.
The mechanics of eviction are knowable and largely the same across incidents. The verdict that triggers them is not: it depends on knowing this user, this environment, and what normal looks like here. Cade's premise is that the organizational knowledge behind that verdict is the asset worth capturing, so the judgment improves every time your team works an identity alert instead of starting from zero.