Modern AI-Driven Phishing Proxies: Why MFA Still Fails

The phrase “AI-driven phishing proxy” joins two related but technically separate developments. Artificial intelligence can improve targeting, message generation, localization, code generation, and evasion. The phishing proxy performs the authentication relay that places attacker-controlled infrastructure between the user and the legitimate identity service.

That distinction matters. Browser fingerprinting, CAPTCHA gates, dynamic redirects, and device-aware pages can all operate through conventional automation. Their presence does not prove that a campaign uses artificial intelligence.

Microsoft documented a credential-phishing campaign in September 2025 that likely used large-language-model-generated code to conceal malicious behavior inside an SVG file. Microsoft described AI as assisting lure creation, obfuscation, and code generation, but the report did not establish that every modern phishing proxy contains an autonomous AI component.

AI-Assisted Social Engineering Makes Proxy Lures Harder to Dismiss

Traditional phishing detection often relies on visible mistakes: broken grammar, generic wording, mismatched branding, or messages that make little sense in the recipient’s job. Generative systems reduce the time needed to produce polished variations, translate the same pretext into several languages, and tailor wording to a department, industry, or business event.

AI assistance can support several stages of campaign preparation:

• Public-information analysis
• Role-specific pretext generation
• Multilingual message variants
• Business-language imitation
• Attachment-code modification
• Detection-evasion experiments

None of these capabilities requires the proxy itself to “think.” The attacker may use a language model to prepare a believable payroll notification, document-sharing message, or help-desk script, then send the victim to conventional AiTM infrastructure.

Microsoft’s 2025 SVG investigation provides a grounded example. The campaign used a compromised business email account, copied the appearance of a file-sharing notification, hid recipients through the BCC field, and attached an SVG represented as a PDF. Microsoft assessed that verbose business terminology and an overengineered code structure indicated likely LLM assistance.

The campaign also shows why grammar-based awareness training is no longer enough. A message can be polished, arrive from a compromised business account, refer to a familiar process, and still lead to credential theft.

AI attribution remains uncertain

Polished writing does not prove AI involvement. Neither do randomized HTML, CAPTCHA screening, browser checks, or complicated JavaScript. Security teams should label a campaign AI-assisted only when code characteristics, infrastructure evidence, operator material, model artifacts, or other technical indicators support that conclusion.

Overstating AI involvement creates two problems. It gives ordinary automation more mystique than it deserves, and it distracts defenders from the part they can measure: suspicious delivery infrastructure, authentication anomalies, token use, mailbox changes, and post-login behavior.

An Adversary-in-the-Middle phishing proxy does more than display a copied password form. It relays parts of the victim’s interaction to the real identity provider while controlling the domain through which the victim is communicating.

MITRE ATT&CK classifies Adversary-in-the-Middle activity under technique T1557. MITRE identifies Evilginx2 as an example capable of relaying traffic between a phished user and a legitimate website while capturing usernames, passwords, authentication tokens, and session cookies.

Step 1: The lure starts a legitimate-looking workflow

The victim receives an email, QR code, shared-document notice, text message, or telephone instruction leading to an attacker-controlled domain. The lure may abuse a trusted sender account or legitimate collaboration service to avoid immediate suspicion.

Microsoft observed a January 2026 campaign that abused SharePoint file-sharing workflows and trusted organizational identities. Following initial compromise, the operators used internal accounts to expand phishing activity across affected organizations.

Step 2: Anti-analysis controls inspect the visitor

The landing infrastructure may check the IP address, geographic region, browser, operating system, user agent, automation indicators, and previous visits. Suspected scanners can be redirected to a harmless page while intended victims receive the real phishing flow.

Cloudflare’s CAPTCHA gates and anti-analysis checks can hide phishing pages from automated scanners, but the  shows why edge filtering alone cannot provide complete protection.

Microsoft found that Tycoon2FA used anti-bot screening, browser fingerprinting, obfuscated code, self-hosted CAPTCHAs, custom JavaScript, and dynamic decoy pages. Cloudflare also observed Tycoon2FA infrastructure redirecting researchers to benign destinations while harvesting sessions from selected users.

Step 3: The proxy forwards the victim’s credentials

When the victim submits a username and password, the proxy passes those values to the legitimate identity provider. The response is then relayed back through the attacker-controlled domain.

This is why the displayed page may contain accurate tenant branding, genuine error messages, and the expected sequence of authentication screens. The browser is still connected to the phishing domain, but much of the content originates from the legitimate service.

Step 4: The victim completes MFA

If the account requires a one-time code, push approval, or another relayable factor, the victim may complete that challenge through the proxy. The verification occurs against the real service, so the attacker does not need to break the authentication algorithm.

Sekoia describes this process as relaying usernames, passwords, and MFA codes to the legitimate authentication API while the phishing server intercepts the returned session cookie.

Step 5: The proxy captures session material

After successful authentication, the identity service issues session material representing the authenticated user. If the session cookie can be reused from another environment, the attacker may replay it without repeating the original password and MFA sequence.

That changes the real target of the attack. The password and MFA response help create the session, but the session becomes the asset that enables account access.

Step 6: The attacker operates inside trusted services

A stolen session may expose email, cloud storage, collaboration platforms, or applications connected through single sign-on. Follow-on activity can include internal reconnaissance, sensitive-file access, inbox-rule creation, external forwarding, second-stage phishing, fraudulent payment requests, or Business Email Compromise.

Microsoft’s January 2026 SharePoint investigation found that password resets alone were insufficient because defenders also needed to revoke active session cookies and remove attacker-created inbox rules.

Relayable MFA Protects the Login but Not Every Issued Session

Saying that an AiTM proxy “breaks MFA” is technically misleading. The victim may complete a valid MFA challenge, and the identity provider may correctly approve it. The weakness lies in allowing the verification to occur through an attacker-controlled origin and then issuing session material that can be reused elsewhere.

Two-factor authentication (2FA) is a form of MFA that uses exactly two authentication factors. However, SMS codes, time-based one-time passwords, and some push-based 2FA workflows can still be relayed through an AiTM phishing proxy because they are not bound to the legitimate web origin.

One-time codes can be relayed immediately

A one-time code has a short lifetime, but an AiTM proxy operates while the code is valid. The victim supplies the code, the proxy forwards it, and the legitimate service processes it as part of the live authentication attempt.

The attacker does not need to save the code for later. The goal is to obtain the authenticated session returned after the service accepts it.

Push approval may confirm the attacker-mediated request

A push notification can show that a login is occurring, but users may approve it because the prompt appears while they are actively attempting to sign in. Number matching reduces blind approval and MFA-fatigue attacks, but CISA treats it as an interim improvement rather than equivalent protection to phishing-resistant MFA.

FIDO2 and WebAuthn change the trust boundary

WebAuthn-based authenticators use public-key credentials associated with the legitimate web origin. A credential registered for the correct service should not authenticate an unrelated phishing domain. This origin binding makes FIDO2 security keys and properly deployed passkeys more resistant to proxy-based credential relay.

CISA recommends phishing-resistant MFA and identifies security keys among the strongest available options. NIST SP 800-63-4, published in July 2025, provides current requirements covering authenticators, authentication protocols, federation, and session management.

Passkeys are not a complete account-security strategy by themselves. Administrators still need to secure:

• Account-recovery processes
• Authenticator enrollment
• Help-desk resets
• Legacy sign-in methods
• Unmanaged devices
• Less-resistant fallback factors

If an organization introduces passkeys but leaves SMS recovery or weak help-desk verification available, attackers may target the remaining path instead.

Phishing-as-a-Service Turns Session Theft Into a Managed Product

Phishing-as-a-Service separates platform development from campaign execution. Operators maintain templates, proxy logic, hosting workflows, anti-analysis controls, and victim-management interfaces. Customers can then conduct campaigns without developing the underlying framework.

Sekoia’s January-to-April 2025 tracking identified Tycoon2FA, Storm-1167, NakedPages, Sneaky 2FA, EvilProxy, and Evilginx among the most prevalent AiTM threats in its monitored data. Its research also found that turnkey offerings were available at relatively low cost and required limited technical expertise.

The service model changes the scale of the problem:

• Developers maintain the proxy platform
• Infrastructure providers host campaign components
• Customers select templates and targets
• Delivery specialists distribute malicious messages
• Compromised accounts feed follow-on campaigns
• Fraud operators monetize access

This division of labor means defenders are not facing one fixed toolkit. They are dealing with an ecosystem that can replace domains, update templates, move infrastructure, and adopt new delivery methods.

Tycoon2FA shows the scale of managed AiTM phishing

Microsoft reported that Tycoon2FA emerged in August 2023 and grew into a widely used PhaaS operation. Campaigns associated with the platform generated tens of millions of phishing messages and reached more than 500,000 organizations per month.

Tycoon2FA imitated Microsoft 365, Outlook, OneDrive, SharePoint, Gmail, and other sign-in experiences. It intercepted credentials and session cookies while relaying MFA codes through its proxy servers. Microsoft stated that access could survive a password reset unless active sessions and tokens were explicitly revoked.

In March 2026, Microsoft, Europol, Cloudflare, and other partners coordinated disruption activities against Tycoon2FA. Microsoft seized 330 active domains, while Cloudflare removed associated Workers projects and supporting infrastructure. The action reduced access to known campaign infrastructure, but no infrastructure takedown should be treated as permanent protection against replacement services or rebuilt operations.

Microsoft 365 and Google Workspace Concentrate the Post-Login Impact

Microsoft 365 and Google Workspace are valuable targets because one authenticated identity may provide access to email, files, collaboration services, contact lists, and federated applications. A compromised identity can become both a source of data and a trusted distribution channel for the next phishing wave.

Sekoia observed that modern AiTM kits primarily targeted Microsoft 365 and Google accounts, while Microsoft documented Tycoon2FA templates for Microsoft 365, OneDrive, Outlook, SharePoint, and Gmail.

Microsoft 365 compromise can move through trusted relationships

Microsoft’s SharePoint investigation showed how an attack can begin with a trusted vendor, abuse a familiar document-sharing process, compromise internal identities, and expand into large-scale internal and external phishing.

The use of SharePoint did not make the message safe. It gave the lure a legitimate service, familiar authentication expectations, and a trusted business context that could evade email-only analysis.

A Microsoft 365 investigation should therefore extend beyond the sign-in event to include:

• Entra ID authentication records
• MFA-method changes
• Registered devices
• Exchange inbox rules
• External forwarding
• OAuth application grants
• SharePoint and OneDrive activity

Google Workspace adds session-focused controls

Google provides investigation events for users signed out because of suspicious session cookies. Eligible administrators can search user log events for suspicious-cookie termination and then investigate the affected account and device.

Google also uses Device Bound Session Credentials to bind supported sessions to device-held cryptographic keys. Google states that DBSC is designed to make stolen cookies difficult to replay from another device. Current applicability depends on supported browsers, operating systems, hardware security, application type, and whether the session was established after protection became available.

Those limits matter. Google’s documentation states that DBSC enforcement applies to supported desktop web environments and does not cover mobile applications or APIs in the same way. Existing sessions may also remain unbound until the user signs out and authenticates again.

Identity, Session, and SaaS Signals Reveal the Account Takeover

Email content is only one part of AiTM detection. Once the victim authenticates, stronger evidence may appear in identity, session, mailbox, device, and SaaS telemetry. Protecting SaaS data security therefore requires monitoring activity before, during, and after authentication.

A valid username, correct password, and successful MFA event cannot independently establish that the resulting session belongs to the expected user. Detection needs to evaluate what happened before, during, and after authentication.

Authentication inconsistencies

Investigate combinations such as:

• Rapid network changes
• Unfamiliar hosting providers
• New device characteristics
• Reused correlation identifiers
• Inconsistent user-agent data
• Unusual session concurrency

Sekoia’s detection research recommends examining authentication-log anomalies, including user-agent differences, source network and country changes, application and resource identifiers, correlation reuse, and inconsistencies across authentication stages.

No individual signal proves AiTM activity. Employees travel, mobile networks change addresses, and privacy services alter source information. The value comes from correlation: a suspicious sign-in followed by a new authentication method, mailbox-rule creation, unusual file access, or external messaging is materially more concerning than an isolated location change.

Post-authentication changes

Account takeover commonly becomes visible through activity performed after login:

• New inbox or forwarding rules
• Deleted security notifications
• Unusual message searches
• Unexpected OAuth consent
• Authentication-method enrollment
• Bulk file access
• Internal phishing distribution

Microsoft’s SharePoint campaign used inbox rules to maintain persistence and reduce user awareness, while compromised identities were used to send additional phishing messages.

Delivery and infrastructure signals

Defenders should also examine newly registered lookalike domains, CAPTCHA-gated pages, redirects through legitimate services, mismatched file types, unusual SVG or HTML attachments, and pages that display different content to scanners and intended users.

Microsoft’s AI-assisted SVG case demonstrates why static attachment labels are insufficient. The attachment was represented as a PDF but used scriptable SVG content and an obfuscated redirect mechanism. Microsoft detected it through infrastructure, behavior, and message context rather than relying solely on visible wording.

Layered Controls Reduce Both Authentication and Session Risk

No single control covers the full attack chain. Email filtering may stop the lure, phishing-resistant authentication may block the relay, device requirements may prevent session use, and behavioral monitoring may expose post-login activity.

Priority 1: Move high-risk accounts to phishing-resistant MFA

Begin with administrators, executives, finance staff, help-desk personnel, human resources, and users with access to sensitive data or broad SaaS privileges.

Use FIDO2 security keys or properly governed WebAuthn-based passkeys where supported. Remove weaker fallback paths when operationally possible, because an attacker will target the least-resistant recovery or sign-in option rather than the strongest configured factor.

Priority 2: Restrict sensitive access to trusted devices

Conditional access and context-aware controls can require managed devices, suitable authentication strength, trusted hardware, or other risk conditions before permitting access to sensitive applications.

Device requirements do not replace phishing-resistant authentication. They reduce the chance that a stolen session can be reused from an unmanaged environment, provided the service evaluates the relevant device state and does not expose a weaker alternative path.

Priority 3: Monitor sessions after successful authentication

Treat successful MFA as one input, not the final security decision. Monitor session behavior, token use, mailbox activity, OAuth grants, downloads, device enrollment, and security-setting modifications.

Google’s suspicious-cookie event handling and DBSC controls address risks after sign-in, while Microsoft Entra provides token and session revocation procedures for compromised identities.

Priority 4: Update phishing awareness around origins and workflows

Training should no longer focus mainly on spelling mistakes. Users need practical habits:

• Open services from known bookmarks
• Check the browser’s actual domain
• Question unexpected MFA prompts
• Verify unsolicited help-desk calls
• Report mismatched attachment types
• Confirm financial requests independently

HTTPS is not proof that a site belongs to Microsoft, Google, or another expected provider. It only confirms that the browser has an encrypted connection to the displayed domain.

Compromised Sessions Require More Than a Password Reset

An organization that suspects AiTM phishing should treat the incident as a session and cloud-identity compromise, not merely a leaked-password event.

The responder needs suitable administrative privileges in the affected identity, email, device-management, and SaaS platforms. Revocation can interrupt legitimate work, so account containment should follow the organization’s incident-response authority and preserve relevant evidence before logs expire.

1. Disable or restrict the affected identity when ongoing misuse is likely.
2. Revoke active sessions, refresh tokens, and other supported authentication artifacts.
3. Reset the password through a trusted administrative process.
4. Review registered MFA methods, passkeys, recovery details, and enrolled devices.
5. Remove unauthorized inbox rules, forwarding destinations, OAuth grants, and application registrations.
6. Search sent mail and audit records for secondary phishing, data access, or administrative changes.
7. Review connected SaaS applications reached through single sign-on.
8. Preserve identity, email, browser, DNS, endpoint, and cloud audit evidence.

Microsoft notes that access revocation may not become effective everywhere at the same moment because applications use different token and session mechanisms. Its Entra guidance explains that administrators need to understand access tokens, refresh tokens, and browser session cookies when containing a compromised identity.

The expected result is that active attacker sessions stop functioning, unauthorized persistence is removed, and legitimate users must authenticate again through approved methods. Failure indicators include continued mailbox activity, renewed token use, new authentication enrollment, further internal phishing, or access from the previously observed infrastructure.

A password change without session revocation is not adequate verification. Microsoft’s documented AiTM incidents explicitly required session-cookie revocation and inbox-rule removal in addition to ordinary credential remediation.

Session Trust Remains the Downstream Security Boundary

Modern AI-driven phishing proxies show why authentication cannot end at “the password and MFA were correct.” AI can improve the approach to the victim, while an AiTM proxy abuses the live sign-in path and targets the session produced afterward.

Organizations still relying on relayable MFA should prioritize phishing-resistant authentication for high-impact identities. That change must be paired with secure recovery, controlled authenticator enrollment, managed-device policies, session-aware monitoring, and tested token-revocation procedures. NIST’s current identity guidance and CISA’s MFA recommendations support treating authentication and session management as connected but distinct security problems