The alert came in mid-afternoon: a user-reported phish in the abuse mailbox, a SharePoint share lure with a PDF that pointed to a Microsoft login page. The old me would have grabbed the URL, detonated the linked page in a sandbox, blocked the domain, and closed the ticket in eight minutes.
I did exactly that. Sandbox clean, PDF benign, URL already dead, so I closed it. That call cost me three hours, because the session token was already gone.
That's the thing about phishing detection in 2026. The signal analysts were trained to spot in 2019 is one the attacker no longer needs to leave behind. I learned that here the hard way. I only pivoted into identity logs after the user's mailbox started auto-forwarding invoices to an address nobody recognized.
In Brief:
- Phishing detection in 2026 runs on identity telemetry. The sandbox produces no signal when the attack is a session cookie replayed from a new IP.
- The 2019 playbook of sandbox the attachment, check the URL, block the domain closes the ticket before the actual compromise is visible. The damage lives in sign-in logs, OAuth consent grants, and conditional access evaluations.
- Adversary-in-the-middle phishing kits have helped commoditize MFA bypass. The post-MFA session token can be replayed as access, and containment has to include OAuth grant review, active session revocation, and app-consent cleanup.
- The defining gap in modern phishing investigation is the identity plane blind spot. If your investigation stops at the inbox, you miss the entire kill chain.
Phishing detection is now identity investigation
The textbook still defines phishing detection as identifying and blocking malicious emails before a user interacts with them. By the time the reported email reaches triage, the compromise has already happened in the identity plane, the attacker has what they came for, and it lives where the email never points.
The attack is an adversary-in-the-middle (AiTM) proxy that sits between your user and the real identity provider, captures the post-MFA session token, and replays it. The proxy forwards everything to the legitimate sign-in page, including the password and the MFA code, so the authentication log entry looks legitimate. Your detection has to live in sign-in logs, conditional access telemetry, and OAuth grant analysis, because the giveaway is the context around the sign-in, and that is the only place the attack writes evidence.
How the alert came in before I knew what it was
The lure was textbook AiTM delivery: a SharePoint file share, a PDF, and a link to a Microsoft login page that was actually a Tycoon 2FA proxy. It pulled organizational branding straight from Entra ID, so the fake page looked like our tenant. The user entered the password, completed MFA on their phone, saw a broken document, reported the email, and moved on.
The trap is that nothing looked like it happened: the user completed MFA against a real Microsoft sign-in because the proxy relayed it in real time, and once the token is stolen the attacker can replay the session without needing the username, password, or another MFA challenge during that session's useful life. My sandbox verdict was clean because there was nothing to detonate, since the attack happened in the browser and the identity plane without endpoint execution.
The evidence chain a modern phishing investigation runs on
I reopened the ticket when the mailbox forwarding rule fired, then started with Entra sign-in logs filtered to the user. The successful authentication was there, completed against OfficeHome, the main Microsoft 365 portal, and two hours later a second successful sign-in appeared on the same session from a different ASN in a different country. That's the replay, and the principle I run by now is that successful anomalous logins matter more than failed attempts. Microsoft's guidance makes the same operational point by starting with sign-in activity and then pivoting across audit data when token behavior is suspicious.
The replay tripped Entra ID Protection's Anomalous Token detection, and the SessionId, CorrelationId, and UniqueTokenIdentifier let me filter Exchange and SharePoint audit logs in Purview for the mailbox searches, inbox rule, and forward.
Then came the pivot the 2019 playbook never reaches. I checked the Entra audit log for a Consent to application event and an Add service principal credentials entry, and the attacker had registered an OAuth app and granted it Mail.ReadWrite with offline_access. That grant is the real persistence, so containment required the app-consent investigation, removal of the grant, deletion of the service principal, and session revocation, none of which a password reset would have covered.
Where the 2019 investigation playbook breaks down
The 2019 playbook breaks at the first pivot, and it breaks silently. Sandboxing the attachment comes back clean because the payload isn't an attachment, checking the URL is late because phishing infrastructure rotates quickly and known-bad lookups age badly against fresh infrastructure, and blocking the domain is pointless because the session token is already replayed. The endpoint telemetry the old playbook depends on, file hashes, process trees, and network IOCs, is irrelevant to an attack that never touches disk.
I've watched this failure mode in three different SOCs, including my own that afternoon, where the investigation produces a clean verdict at exactly the moment the attacker is most active. The numbers confirm the shift, since stolen credentials rose to second place as an initial vector and surpassed email phishing, and CrowdStrike reported its 2024 malware-free detections reached 79%. There is nothing for a sandbox to catch because there is no malware, so if your phishing triage still treats attachment detonation as the verdict step, you are measuring the wrong plane.
What the attacker was doing, and why it took too long to see
The attacker's actual goal was the OAuth grant, and the business email compromise was the cover. The session replay let them read the mailbox, the inbox rule hid their tracks, and the OAuth app gave them durable access independent of the user's password. This is the OAuth persistence pattern Microsoft documented in 2023, where the proxy steals the token, the token replays the session, and persistence comes from an attacker-created OAuth application, and it has moved into phishing-as-a-service commodity tradecraft.
It took longer than it should have because I treated the email as the investigation for the first hour, when the compromise lived in the identity plane and the email was just the delivery. The lesson I keep relearning is that the log retention cliff is real, so if you don't export to your security information and event management (SIEM) before rotation, the evidence chain you need is gone. Containment required revoking the OAuth grant with Remove-EntraOAuth2PermissionGrant, killing the service principal, and revoking active session tokens, because the password reset alone would have changed nothing.
What this investigation changed about how I run phishing triage
I rebuilt the phishing triage runbook after this one, and the verdict step now asks whether a successful authentication produced anomalous downstream activity. The first three pivots are pulling the sign-in logs for the reported user to look for a successful auth followed by a same-session sign-in from a new IP or ASN, checking the Entra audit log for any Consent to application or new MFA device registration in the window, and pulling the mailbox audit log for new inbox rules. Attachment detonation is still in the runbook, at the bottom, where it belongs.
The structural fix is upstream of triage. Token Protection is a stronger upstream control because device-bound tokens fail when replayed from the attacker's machine, and pairing it with conditional access requiring compliant networks and phishing-resistant MFA prevents up to 99% of identity-based attacks, per Microsoft.
If you run a tabletop next week, don't simulate a malicious attachment. Simulate a session token replayed from a new country two hours after a clean MFA login, and see whether your analyst pivots into the identity plane in under five minutes. If they reach for the sandbox, fix the runbook before blaming the analyst.
Frequently asked questions about phishing detection
How should a SOC define phishing detection in 2026?
Phishing detection is now primarily identity investigation. Modern phishing uses AiTM proxies to steal post-MFA session tokens, OAuth consent grants to establish persistence, and device code flows to capture authentication tokens. The evidence lives in sign-in logs, conditional access telemetry, and OAuth audit logs.
How has phishing detection changed in 2025 and 2026?
The attack moved off the endpoint and onto the identity plane. In 2019 you detonated attachments and blocked URLs, while in 2026 the attacker captures a session cookie through an AiTM proxy that relays your real MFA, so the authentication looks legitimate and leaves no malware signal. Mandiant's M-Trends 2025 data shows stolen credentials rose to second place as an initial vector and overtook phishing for the first time.
What telemetry does a phishing investigation need?
At minimum, Entra ID sign-in logs, service principal sign-in logs, conditional access evaluation results, the Unified Audit Log for mailbox and OAuth activity, Entra audit logs for consent grants and MFA registrations, and Entra ID Protection risk detections. Export all of it to a SIEM before the 30-to-90-day retention window closes, because the evidence chain disappears on rotation.
How do SOC teams detect AiTM phishing in Entra logs?
AiTM (adversary-in-the-middle, MITRE T1557) places a proxy between the victim and the real identity provider to steal the authenticated session token, which bypasses MFA entirely. Detect it in sign-in logs by looking for a successful authentication followed by a same-session sign-in from a different IP or ASN, OfficeHome or other Microsoft 365 portal activity in the session, and Entra ID Protection's Anomalous Token and Attacker in the Middle detections. Prioritize successful logins with anomalous context over failed login noise.
How does OAuth abuse show up in a phishing investigation?
Look for OAuth consent events such as Consent to application and Add OAuth2PermissionGrant in the Entra audit log, and Add service principal credentials entries that signal persistence. Suspicious scopes include offline_access, .default, and Mail.ReadWrite. Containment requires revoking the grant and the service principal before a password reset can matter.