Intro
An employee received a message that looked routine, clicked through the link sent, and landed on what appeared to be the company’s Okta sign-in page. They entered their username and password, and when the Okta push arrived on their phone a moment later, they approved it without hesitation. Why wouldn’t they? They had just logged in. The prompt was exactly what they expected to see.
What they couldn’t see was that the page they trusted was never really the legitimate one. It was a proxy, sitting invisibly between them and the real login, capturing their credentials as it passed them through to the legitimate site. Their password, their approval, the whole authentication flow, all of it moved through the attacker’s infrastructure. And the moment they tapped approve, they satisfied the second factor not for themselves, but for the attacker.
Seconds later, their Azure token was being replayed from machines and locations they were not observed from. 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 them complete their own login on the attacker’s behalf, then walked through the door their 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 did not complain. 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.
What ended it was Exaforce looking at the same telemetry and asking a different question. Not “did authentication succeed,” because it obviously had, but rather whether the person using the
account was the person who normally used it.
Within minutes, Exaforce had confirmed with the user that the activity wasn’t theirs, revoked the active sessions, reset their credentials, and handed the security team a complete record of everything that happened. The whole thing was contained before a Tier 1 analyst would have finished gathering context.
Attack chain
An employee ended up on what looked like their company’s Okta sign-in page during a normal workday. Credentials were entered and an MFA prompt was approved, and nothing about the experience stood out as unusual at the time.
The page wasn’t Okta. It was an adversary-in-the-middle (AiTM) proxy sitting between their browser and the real authentication service. Every credential and every authentication token they submitted passed through infrastructure the attacker controlled before it reached its destination. Within minutes, the attacker was replaying their authenticated session from other countries.
The authentication exhibited unfamiliar properties including first-time access from the United States, new Linux/Chrome device profile, and new residential ISP. Azure’s risk engine triggered an MFA challenge, which the user successfully passed with an enrolled device.
Upon getting the Okta Token and access to the user’s M365, the attacker used the retrieved token on three machines controlled by them. Using those machines, they accessed the user’s M365 environment, their emails, and other office apps.
Azure Identity Protection detected the different baseline of location about five minutes after first attacker access. The session had a different IP and operating system, but was marked as remediated with reason userPassedMFADrivenByRiskBasedPolicy, meaning the risky login happened successfully and was verified by credentials and MFA potentially done by the user. This was the first finding as part of a composite group of findings. The attacker still continued to attempt to establish persistent device-level access.
"dataSource":"azure",
"riskDetail":"userPassedMFADrivenByRiskBasedPolicy",
"description":"One or more properties (IP, ASN, location, device, browser, tenant IP subnet) of this sign-in are different from what we have seen recently for the given user.",
"findingType":"unfamiliarFeatures",
"identityName":"<identity UPN>",
"identityType":"EntraIDUser",
"riskActivity":"signin",
"threatEvents":[
{
"eventId":"*************************"
"eventName":"Sign-in activity"
"eventCategory":"AUTHENTICATION"
}
],
"findingSource":"IdentityProtection"Exaforce response
Exaforce product detected the change in the 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 the compromised Azure session was reset.
The attacker tried to access other Okta apps, but during containment, every session of the user, either legitimate or not, was revoked. Having the user’s credentials, the attacker then attempted to establish fresh Okta sessions in another location, but, due to the password reset during containment, they could not do anything.
The attack lasted for about 20 minutes, during which time the attacker was able to look into the M365 apps that the user had access to, and the user was contained.
Why standard MFA didn’t stop this
By the time the 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 the user had made before.
Azure never re-challenged either, as it 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 the user’s normal activity. The risk signals only began firing once the token had been distributed and replayed from the other locations, 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 the user a chance to notice that the sign-in they were authorizing did not match where they actually were.
Exaforce automated response actions
Automation Agents (AA) are a feature Exaforce offers, which allows easily configurable automatic flows to be executed upon a specific trigger or condition. They can vary from script execution, to user and system containment, to notification, automatic re-evaluation of the threat, or just all of them at the same time. Them being configured allows for the trigger or user executing them to ensure the task requested will be executed, or in cases of a failure due to missing conditions, re-execution and notification.
They were leveraged in this scenario to contain the user. The containment time was less than 20 minutes from when the first detection fired, and it was all due to the agents running autonomously. In this case, two different automation agents were used.
The first one was used to automatically contact the user regarding the threat. Upon their confirmation of the threat, containment was immediately triggered, where password reset and session revocation on all data sources happened.
The user’s manager was also notified and asked for confirmation about the impact this attack might have had on the resources that the identity had access to. In cases when there is not a manager (cases of high management positions), the notification automatically goes to the SOC team for approval.
Once the confirmation was received, the second Automation Agent was automatically triggered by the first one, where the user containment happened. The user’s session on the IDP, which in this case was Okta, was revoked, preventing the attacker from further accessing other apps through it. Parallel to the IDP session, the impacted EntraID session was also revoked, preventing the access the attacker had to the M365 resources of the user. Then, a password reset was attempted on all the data sources for the user, in order to be certain the attacker would not attempt further access using the phished credentials, which they did try, but failed. Lastly, after the user was contained, they, their manager, and the security team were notified of the containment and advised to further monitor the user for potential future attack attempts.
Conclusions
What makes AiTM phishing so dangerous is that, when done right, very little about it looks wrong while it’s happening. The 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.
