Conditional Access policies won’t stop token theft—and standard MFA won't fix it either. When teams roll out Microsoft Authenticator push codes or SMS, some assume the cloud perimeter is safe. But sophisticated actors have moved completely past brute-forcing passwords. They use Adversary-in-the-Middle (AiTM) phishing frameworks like Evilginx. The attack flow is clean: The proxy site mirrors your Entra ID login page. The user enters credentials and solves the genuine MFA challenge. Once Entra ID validates the session, it issues an ESTSAUTH session cookie. The malicious proxy server snatches that cookie before passing it back to the victim’s browser. The Result: The attacker drops that stolen cookie into their own machine. Because the session has already passed the MFA verification loop, they gain instant access to the mailbox or cloud apps. They bypass standard Conditional Access rules seamlessly. , when an identical session jumps between network or device contexts Advanced features like Continuous Access Evaluation (CAE), Token Protection session controls, or strict device compliance rules can mitigate this. But they are rarely part of an organization’s "default" browser-based setups. Because a stolen token completely bypasses the sign-in loop, you cannot hunt for it by looking for failed logins. You have to hunt for Session Anomalies—specifically when an identical session jumps network or device context mid-lifecycle. From Sentinel or Entra ID Advanced Hunting, you can run the below KQL query to identify active token replays across interactive and non-interactive sign-ins: