A recently uncovered and highly sophisticated Adversary-in-the-Middle phishing campaign is actively targeting organizations utilizing Microsoft 365 and Okta, successfully circumventing the multi-factor authentication protections that many businesses consider a cornerstone of their security posture. This operation, first identified in early December 2025, does not brute-force credentials or exploit a vulnerability in the MFA protocols themselves; instead, it employs a far more insidious method of intercepting and stealing the authenticated session token generated after a user has legitimately verified their identity. The campaign’s success highlights a critical weakness in security architectures that rely solely on traditional MFA methods, demonstrating that even with robust authentication in place, the integrity of the user’s session remains a prime target for determined attackers who can exploit the trust inherent in modern single sign-on workflows.
Anatomy of a Sophisticated Deception
The attack initiates through a carefully orchestrated social engineering scheme, leveraging compromised Salesforce Marketing Cloud mailboxes to lend an air of legitimacy to the initial contact. Threat actors craft phishing emails disguised as official human resources communications, enticing employees with lures such as year-end salary reviews and bonus information—topics that command immediate attention and are likely to prompt action. These emails contain shortened links that redirect unsuspecting victims to a network of lookalike domains meticulously designed to mimic official authentication portals, such as sso.okta-secure.io. Hosted on Cloudflare’s resilient infrastructure, these phishing sites present a near-perfect replica of the genuine login pages, creating a seamless and convincing user experience that makes it difficult for even vigilant employees to detect the deception. This initial stage is critical, as it establishes the attacker’s infrastructure as the intermediary between the user and the legitimate identity provider.
At the heart of this campaign is a multi-stage phishing process powered by a malicious JavaScript proxy designed to harvest credentials and, more importantly, session cookies. Upon landing on the fraudulent login page, the victim’s browser begins proxying the legitimate Okta portal, but with a crucial modification: the injection of a malicious script named inject.js. This script is the engine of the attack, performing several key functions to compromise the user’s session before it even fully begins. It immediately captures the user’s username by listening to Document Object Model (DOM) events and persistently stores this information across the browser’s localStorage, sessionStorage, and cookies. This redundancy ensures that the captured data is not lost if the user refreshes the page or navigates away momentarily, laying the groundwork for the subsequent interception of the complete authentication flow.
The Mechanics of Session Hijacking
The primary technical mechanism for the attack involves hijacking the browser’s communication channels by hooking the native window.fetch method. This powerful technique allows the malicious script to intercept all outgoing network requests, including the legitimate authentication attempts the user makes to Okta’s servers. Instead of traveling directly to Okta, the user’s credentials and MFA responses are rerouted through the attacker’s proxy server. From the user’s perspective, the login process appears entirely normal; they enter their password, receive an MFA prompt on their device, and approve it as usual. However, behind the scenes, the attackers are capturing every piece of this exchange. This Adversary-in-the-Middle position gives them complete visibility into the authentication process without ever needing to break the underlying encryption or cryptographic protocols, effectively making them a silent observer of the entire login sequence.
Once the user successfully completes the MFA challenge, the script’s ultimate objective comes into play: stealing the session cookies generated by the identity provider. The malicious code continuously monitors the browser’s cookie storage for the appearance of specific, high-value session tokens, including idx, JSESSIONID, and sid. These cookies are the keys that prove to the service that a user has already authenticated, allowing them to remain logged in. Every second, the script checks for any new or modified cookies and immediately exfiltrates them to the attacker-controlled server. With these stolen tokens in their possession, the threat actors can simply replay them in their own browser, effectively impersonating the victim and gaining full, authenticated access to their accounts. This method completely bypasses the need to re-authenticate or face any MFA challenges, as the system already recognizes the session as valid.
Fortifying Defenses Against Modern Threats
The campaign is particularly devastating in federated environments where Okta serves as the identity provider for Microsoft 365, a common configuration in many enterprises. In this scenario, a second injected script specifically monitors the authentication response from Microsoft for a key piece of information: the FederationRedirectUrl. This URL is responsible for directing the user’s browser from the Microsoft login page to their organization’s Okta tenant to handle the authentication. The malicious script intercepts this process and dynamically modifies the URL, ensuring the redirection flows not to the legitimate Okta tenant but to the attacker’s second-stage Okta phishing page. This ensures that the entire SSO workflow, from initial login to final access token generation for Microsoft 365, is proxied through the attacker’s infrastructure, enabling the capture of the final, all-important session tokens needed for complete account takeover.
This incident served as a stark reminder that session hijacking remains a potent threat, capable of neutralizing many widely deployed authentication controls. In response, security teams were urged to adopt a multi-pronged defense strategy. Monitoring identity provider logs, such as Okta’s, for auth_via_mfa events originating from anomalous IP ranges, particularly those associated with Cloudflare or other proxy services not used by the organization, proved to be a critical detection method. However, the most effective long-term solution involved a strategic shift toward phishing-resistant MFA. The implementation of technologies like FIDO2 security keys, which bind the authentication process to the hardware device and the origin domain, was identified as the crucial step forward. Such methods were specifically designed to prevent the theft and replay of session tokens, effectively severing the core mechanism that made this type of AiTM attack possible and forcing a necessary evolution in organizational security posture.
