Intro
It started with a link. An employee received a message that looked routine, clicked through, and landed on what appeared to be her company's Okta sign-in page. She entered her username and password, and when the Okta push arrived on her Samsung S24 a moment later, she approved it without hesitation. Why wouldn't she? She had just logged in. The prompt was exactly what she expected to see.
What she couldn't see was that the page she'd trusted was never really hers. It was a proxy, sitting invisibly between her and the real login, capturing her credentials as it passed them through to the legitimate site. Her password, her approval, the whole authentication flow, all of it moved through the attacker's infrastructure. And the moment she tapped approve, she satisfied the second factor not for herself, but for them.
Seconds later, her Azure single sign-on token was being replayed from machines she had never touched. Within three minutes it was active on three continents. The attacker hadn't broken MFA. They hadn't cracked a vault or exploited an unpatched flaw. They'd let her complete her own login on their behalf, then walked through the door her approval held open.
This was an Adversary-in-the-Middle (AiTM) attack, and it turned one of security's most trusted controls into the mechanism of the breach. Because the stolen token carried Okta's MFA-satisfied claim, Azure honored it on sight. No prompt, no challenge, nothing to slow the intruder down. Azure's own risk engine noticed the anomaly within five minutes, then marked it remediated, because on paper the user had passed MFA. Every system in the chain behaved exactly as designed. It is a case study in how federated trust, the very thing that makes single sign-on so seamless, can quietly become the thing that betrays you.
The attack didn't end because one of those controls finally caught it. It ended because Exaforce was asking a different question of the same data: not whether the login was valid, but whether it was hers. First-ever access from the United States, a Linux device with no history, a residential ISP her account had never seen. The baseline broke, and an Exaforce Automation Agent moved immediately, reaching out to her and her manager with a simple question: was this you? She said no. That answer triggered containment on the spot. Sessions revoked, password reset, her security team notified of what had already been done.
From the attacker's first use of the stolen token to full lockout took under twenty minutes. No analyst triaged the finding, no ticket sat in a queue, and no one in the SOC had to intervene. Detection, triage, user verification, and containment ran autonomously end to end, with every step audited for review after the fact.
That is the part worth dwelling on, because attacks like this are getting cheaper and faster to run. AiTM kits are sold as subscriptions and the proxying is point-and-click, which means the ordinary credential phish is turning into session hijacking at scale. The volume and velocity will keep climbing, and a stolen token that reaches three continents in three minutes does not wait for an analyst to pick it up. Defense has to move on the same clock. This incident is what that looks like: AI verifying with the one person who knew the truth, then acting on her answer at machine speed.
Attack Chain
On July 1st 2026 at 15:40:41 UTC, a user clicked on a phishing link impersonating Okta, authenticated to it and approved the MFA on 2026-07-01 at 15:43:26 UTC from Davenport, Florida, United States (IP 47.200.149.234, AS5650 Frontier Communications). At 15:41:26 UTC, an Okta SSO token issued.
The authentication exhibited unfamiliar properties including first-time access from United States, new Linux/Chrome device profile, and new residential ISP. User's established locations are United Kingdom (via TalkTalk Communications), Mauritius, and Spain. Azure's risk engine triggered MFA challenge, which the user successfully passed with enrolled device.
Upon getting the Okta Token and access to user’s M365, the attacker used the token retrieved on three machines controlled by them:
- Davenport/US (Linux Chrome 145) (IP:
47.200.149.234) - Lagos/NG (Mac Chrome 149) (IP: ) (IP:
41.58.214.43) - Zagreb/HR (Windows Chrome 147) (IP:
154.47.29.20)
Using those machines, they accessed user’s M365 environment, their emails and other office app, with AddEvent.com and Microsoft Auth Broker failing.
Azure Identity Protection detected the different baseline of location at 15:46:47 UTC, about 5 min after first attacker access. The session had different IP and Operating system, but was marked as remediated with reason userPassedMFADrivenByRiskBasedPolicy, meaning the risky login happened successfully and verified by credentials and MFA potentially done by the user. This was the first finding as part of a composite group of findings.
At 15:50:52 UTC, a failed attempt to register a new device via Microsoft Authentication Broker was observed from a third Croatian IP (188.129.83.50, A1 Buzin, Croatia) suggesting the attacker attempted to establish persistent device-level access.
Exaforce product detected the change on baseline, notified the user and their manager, as well as Exaforce’s MDR team.
The user confirmed that the login was malicious, and not made by them, at which point, at approximately 16:02:52 UTC, the compromised Azure session was reset.
Attacker’s second attempt
Having the user’s credentials, the attacker then attempted to establish fresh Okta sessions from both Zagreb and Lagos, but was blocked. By 16:04:46 UTC, due to the password reset, even the legitimate user’s AD authentication began failing.
Why Standard MFA Didn’t Stop This
By the time User's session was terminated, three separate protection layers had already been passed, and none of them had failed in the way a security team would normally expect. Each one behaved exactly as designed.
The initial authentication flow was genuine. From Okta's perspective, MFA had been satisfied legitimately, because it had. There was no forged token and no bypassed prompt, nothing to distinguish this approval from any of the thousands User had made before.
Azure never re-challenged either, and it had a defensible reason not to. Azure trusts Okta's federation, and the token it received carried an amr (Authentication Methods Reference) claim stating that MFA had already been completed. A second factor had, on paper, been satisfied upstream, so Azure honored the claim and issued the session without asking again.
IP-based detection was the last layer, and it fired too late to matter. The initial Okta login came from a US residential ISP, Frontier Communications, which looked entirely unremarkable next to User's normal activity. The risk signals only began firing once the token had been distributed and replayed from the Lagos and Zagreb machines, well after the authentication itself had already succeeded.
What would have stopped it
Phishing-resistant MFA is the control that breaks the attack at its root. FIDO2 keys and passkeys cryptographically bind the MFA response to the domain that originated it, so a proxy sitting on a lookalike page cannot relay the response to the real site. The ceremony simply fails, no matter how convincing the fake login looks.
Beyond that, several layers would have contained the damage. A Conditional Access policy requiring a compliant device would have blocked the Lagos and Zagreb machines outright, since neither was Intune-enrolled. Continuous Access Evaluation would have allowed the session to be revoked in real time the moment a risk signal appeared, rather than leaving the attacker in place until the token expired on its own. And number matching, which shows the user the IP and location of the login request before they approve, would have given User a chance to notice that the sign-in she was authorizing did not match where she actually was.
Response actions
Exaforce's Automation Agents (AA) were leveraged to contain this issue. The time to contain the issue was less than 20 mins from the first detection fired and it was all done autonomously. Two different automation agents were used.
First one is used to automatically contact the users in case something weird is happening with their account. The trigger can be anything from unexpected travel, unusual device logging in to their account from an unexpected location, and so on. User is contacted in a friendly manner where we briefly explain what is going on and what is the suspicious part of their behavior. They have an option to respond that the actions were legitimate or that the actions were not legitimate and they don't recognize what's going on. They also have an option to append a quick summary of their actions or explanation. From there, the workflow branches into three different paths:
- The user answered legitimate, and we don't consider the actions highly disturbing or dangerous. In that case, the finding is automatically re-evaluated with the user response taken into account and usually closed as a false positive or benign. If any concerns remain, the issue is handed over to human operator to verify.
- Second branch is where the user confirms actions are legitimate, but the nature of the actions can have high impact or the alerting signals are too severe to be dismissed by user confirmation only. There's also possibility that user's communication channel is under control as attacker. In that case we automatically contact the user's manager to confirm the actions.
- That third branch is where the user or user's manager recognizes actions as not legitimate. We immediately trigger the second AA - User Containment. This AA does sessions revoke & password reset across multiple systems and inform customer's SOC about the actions.
The whole process is fully automatic, and no operator is involved unless necessary. All the actions and responses are fully audited, so the operator can later step in and investigate timestamps and messages which were sent to the user or the manager and any other detail.
In this specific case the third branch was used: User answered that the actions are not familiar and that immediately triggered the containment.
Indicators of Compromise
IPs
- 47.200.149.234 (Davenport, Florida initial authentication)
- 41.58.214.43 (Lagos, Nigeria concurrent session)
- 154.47.29.20 (Zagreb, Croatia concurrent session)
- 188.129.83.50 (Buzin, Croatia)
ASN
- AS5650 (Frontier Communications of America, Inc.)
- AS36923 (Swift Networks Limited)
- AS212238 (DataCamp Limited (VPN/hosting))
User Agent
- Mozilla/5.0 (X11; Linux x86_64) Apple...afari/537.36 (Davenport Linux device)
- Mozilla/5.0 (Macintosh; Intel Mac OS ....0.0 Safari/537.36 (Lagos Mac device)
- Mozilla/5.0 (Windows NT 10.0; Win64...fari/537.36 (Zagreb Windows device)
Conclusions
What makes AiTM phishing so dangerous is that, when done right, very little about it looks wrong while it's happening. User entered valid credentials and approved a valid MFA prompt, so from the identity provider's view every step was exactly as expected. No failed factor, no brute-force pattern, no malformed request to flag. The attacker didn't defeat any single control, they attempted a completed login, and the only tell, can be the domain they will input their credentials on. And even that can be made to look legitimate enough to trick technical people.
The strongest defense, apart from awareness training, is phishing-resistant MFA like FIDO2 keys and passkeys, which bind the credential to the real site so a proxy can never complete the authentication flow.
But prevention is never perfect, and once a session is live, the only thing that matters is how fast you can kill it. In this incident five minutes passed before the session was terminated, and that is exactly the gap Exaforce is built to close. Rather than waiting for an analyst to investigate and manually respond, Exaforce revokes malicious sessions automatically the moment they're identified as hostile, collapsing the attacker's working window from minutes to near zero.
