New AiTM Attack Campaign Bypasses MFA to Target Microsoft 365 and Okta Users

New AiTM Attack Campaign Bypasses MFA to Target Microsoft 365 and Okta Users

Cybersecurity researchers at Datadog have uncovered a sophisticated adversary-in-the-middle phishing campaign targeting organizations that use Microsoft 365 and Okta for single sign-on authentication.

The campaign leverages advanced techniques to hijack legitimate SSO authentication flows and bypass multi-factor authentication methods that lack phishing-resistant capabilities, posing a significant threat to enterprise security infrastructures.

The attack addressed phishing emails masquerading as year-end compensation reviews from ADP, a popular HR and payroll service provider.

These emails contain links hidden behind URL shorteners such as lnk.ie, directing victims to first-stage phishing domains hosted on Cloudflare infrastructure.

The domains use benefits-themed lures including employee-hr-portal.com, corporate-hr-portal.com, and mybenefits-portal.com, all registered through NameSilo.

In some variants, attackers embed malicious links within password-protected PDF attachments, with credentials provided in the email body to evade automated detection systems.

The campaign employs a two-stage attack mechanism specifically designed to compromise Okta-federated Microsoft 365 environments.

First-stage phishing pages impersonate legitimate Microsoft 365 login interfaces and inject malicious JavaScript that monitors HTTP responses for the FederationRedirectUrl field.

When the legitimate Microsoft endpoint returns JSON data indicating that a victim uses Okta as their identity provider, the malicious script intercepts this response and dynamically rewrites the federation URL to redirect victims to second-stage Okta phishing domains.

These second-stage domains use lookalike infrastructure including sso.oktasecure.io, sso.okta-cloud.com, and sso.okta-secure.io.

The phishing pages proxy all traffic to legitimate Okta tenants using a URL parameter format /?company=.okta.com, ensuring that organizational customizations and branding elements are preserved to enhance authenticity.

The attack leverages client-side URL rewriting by hooking the window.fetch method, systematically replacing legitimate Okta domains with malicious proxies while maintaining the appearance of expected authentication flows.

AiTM Attack Campaign

The phishing infrastructure deploys inject.js, a client-side credential stealer that monitors critical Okta session cookies including idx, JSESSIONID, proximity_, DT, and sid.

The campaign has been active since at least August 2025 with code improvements detected in December 2025, indicating ongoing development by sophisticated threat actors with advanced knowledge of Microsoft and Okta authentication flows.

Sample phishing page hosted on sso.okta.

The script captures usernames through DOM event listeners tracking change and submit events on input fields, storing credentials in okta_captured_username cookies.

Every second, the malware checks for new cookies and exfiltrates any critical session tokens to the /log_cookie endpoint via POST requests containing JSON payloads with captured credentials, session cookies, URLs, and timestamps.

Attackers employ multiple evasion techniques including Cloudflare turnstiles for anti-analysis purposes and base64-encoded JSON objects embedded in URL paths containing campaign tracking metadata such as campaign_id, session identifiers, IP addresses, expiration timestamps, and usage limits.

This indicates centralized campaign management infrastructure allowing threat actors to control access and monitor phishing effectiveness across hundreds of targeted users and dozens of organizations.

Mitigations

Organizations using Okta FastPass can identify phishing attempts through user.authentication.auth_via_mfa events with outcome FAILURE and reason “FastPass declined phishing attempt” in debugContext.debugData risk fields.

New AiTM Attack Campaign Bypasses MFA to Target Microsoft 365 and Okta Users
Flow of Microsoft 365 phishing pages.

The field contains mismatched request origin information showing domains like sso.okta-secure.io instead of legitimate Okta tenants.

Organizations without FastPass should monitor policy.evaluate_sign_on events with CHALLENGE or DENY outcomes originating from Cloudflare infrastructure, particularly when debugContext.debugData.logOnlySecurityData indicates MEDIUM or HIGH anomalous behavior ratings.

Security teams should also monitor user.authentication.verify events where debugContext.debugData.behaviors flags new devices and locations as POSITIVE, especially when combined with network.client.geoip.as.domain showing cloudflare.com.

Organizations must implement phishing-resistant MFA methods and continuously monitor authentication logs for anomalous patterns to defend against these evolving adversary-in-the-middle attacks.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.



Source link