Phishing is still the most common way attackers get their first foothold inside European networks. According to the ENISA Threat Landscape (October 2025), it accounts for roughly 60 percent of initial network intrusions across Europe. The uncomfortable part for any IT manager who has already rolled out multi-factor authentication: most MFA does nothing to stop the technique behind a growing share of those breaches.
Adversary-in-the-middle (AiTM) phishing does not try to guess your password or brute-force your MFA. It sits between the user and the real login page, lets the user authenticate normally, and walks away with the live session. The credential and the MFA response both get handed over without the attacker breaking a thing.
This post explains the attack itself. How the reverse proxy intercepts, why SMS and push approvals fail, what prompt bombing adds, and which controls actually break the chain. The defensive answer here is not endpoint detection. It is isolation and identity-and-device-bound access, the layer where platforms like Jimber operate.
How does AiTM phishing bypass MFA?
AiTM phishing bypasses MFA by placing a real-time reverse proxy between the victim and the genuine cloud provider, then capturing the active session cookie after a successful login. The attacker replays that cookie to hijack the account directly. Because the stolen session is already authenticated, the password and the MFA approval no longer matter. Stopping it means binding credentials to the real domain, blocking stolen tokens from unmanaged devices, and isolating untrusted web sessions before they ever reach the proxy.
What happens during a reverse proxy interception?
An AiTM attack works as a live gateway between the victim and the legitimate service. The proxy requests the real login screens on behalf of the user. As the victim types, the proxy relays every keystroke forward and captures the password and the MFA response in transit.
Open-source kits made this trivial. Tooling like Evilginx uses configuration files, often called phishlets, that mirror a target service such as Microsoft 365 down to the login flow. The victim sees a convincing page on a lookalike domain. Behind it, the proxy passes traffic to the real provider and back.
The prize is not the password. It is the session cookie the identity provider issues after authentication succeeds. Once the proxy holds that cookie, the attacker imports it into their own browser and is logged in as the user. No second prompt. No new MFA challenge.
Phishing-as-a-service turned this into a product. Sophisticated kits add evasion such as invisible Unicode characters and code that wipes itself from the page’s DOM to dodge scanners. Tycoon 2FA became one of the most prominent examples. According to Microsoft, Intel 471 and Rescana (March 2026), at its peak the kit was behind 62 percent of phishing attempts that Microsoft blocked. When Europol disrupted the Tycoon 2FA infrastructure in March 2026, analysis by Bridewell tied the network to more than 60 percent of global MFA-bypass campaigns.
The scale is matched by user behaviour under pressure. An analysis of 159,188 stolen credential sets by SpyCloud and Bridewell (March 2026) found that 41 percent of victims entered more than one password on the phishing page, handing attackers extra accounts to try elsewhere.
Why does traditional MFA fail against token replay?
SMS codes, push notifications, and one-time passwords only protect the first moment of a login. Once the check passes, the identity provider issues a session cookie that proves the user is who they claimed to be. That cookie is the weak point.
Traditional MFA does not tie the session to the origin domain. The cookie is portable. An attacker who captures it can replay it from a different machine, a different country, a different network, and the provider treats the session as valid until it expires or is revoked.
This is also why endpoint detection struggles here. Nothing malicious runs on the victim’s device. There is no payload to flag, no process to quarantine. The user logged in to what looked like the real site, approved a legitimate-looking prompt, and the theft happened in transit. By the time anomalous activity shows up in a SIEM, the attacker is already inside.
For the Belgian mid-market the exposure is wider than many assume. The Centre for Cybersecurity Belgium (August 2025) reported that only 46.4 percent of Belgian organisations enforce MFA on external connections at all. Among those that do, most rely on the SMS-and-push variety that AiTM walks straight through. The CCB and AJA Consulting (April 2026) also recorded a 38 percent rise in reported incidents at Belgian organisations between 2024 and 2025.
What is prompt bombing and authentication fatigue?
Prompt bombing, also called MFA fatigue, attacks the person rather than the protocol. The attacker already has a valid password, often bought or phished, and triggers login attempt after login attempt. Each one fires a push notification at the user.
The notifications keep coming. Late at night, mid-meeting, dozens in a row. Eventually someone taps approve to make it stop, or assumes IT is testing something. That single tap hands over access.
The technique needs no malware and no clever exploit. It shifts the entire security burden onto a tired human making a snap decision. This matters more as attacks get faster and more convincing. ENISA (October 2025) reports that over 80 percent of social engineering activity is now AI-assisted, which raises both the volume and the polish of these campaigns.
How do you implement phishing-resistant authentication?
Phishing-resistant authentication moves the identity layer onto public-key cryptography, through FIDO2 security keys and passkeys. These standards bind the credential to the genuine domain at a cryptographic level. If a user lands on a malicious proxy, the browser simply refuses to release the credential, because the domain does not match. The reverse proxy collects nothing.
The Microsoft Digital Defense Report (May 2025) found that phishing-resistant MFA based on FIDO2 blocks more than 99 percent of automated identity attacks. On the merits, it is the strongest control available against AiTM.
The catch is operational, and it hits the mid-market hardest. Existing guides tend to assume a full physical security-key rollout across every employee. For an organisation of 50 to 400 users, distributing hardware keys, handling lost-key recovery, and supporting remote staff can overwhelm a small helpdesk. Passkeys on managed devices ease part of this, but the gap between the textbook advice and what a lean IT team can actually run is real.
There is a second trap. Many organisations turn on phishing-resistant MFA but leave SMS or push active as a fallback. Attackers then use social engineering to push the user toward the weaker method, and the protection quietly collapses. If you deploy FIDO2, the fallback path needs to close too.
How do device compliance checks restrict stolen tokens?
Device posture checks add a second test that a stolen cookie cannot pass. Access to resources is restricted to company-managed, compliant endpoints. When a session connects, the platform inspects the state of the connecting machine before trusting it.
If an attacker steals a session cookie and replays it from their own laptop, that machine is unmanaged and non-compliant by definition. The connection is refused. The cookie still proves the user authenticated, but it no longer proves anything about where it is being used from. That distinction is what neutralises the replay.
Device posture is not a silver bullet on its own. Continuous Access Evaluation, which revokes sessions in near real time, carries a propagation delay before every SaaS application honours the revocation. During that window a stolen token can still work. Device-bound access narrows that window hard, because the attacker’s endpoint fails the check regardless of how fresh the token is.
This is one of the live controls Jimber enforces. Device posture validation runs continuously, so a token lifted by a Tycoon-style kit is worthless the moment it tries to connect from an endpoint the platform does not manage.
Can browser isolation stop credential theft at the source?
Browser isolation breaks the attack one step earlier, before any credential is entered. Most existing guidance focuses on detecting the breach after it happens, by spotting odd login locations in a SIEM. Isolation flips that to prevention.
The mechanism is streaming. Untrusted web sessions run inside a remote container, and only a visual stream of the page reaches the user’s device through pixel-based rendering. The endpoint never executes the page’s code and never connects directly to the destination. So when a user clicks a link to a malicious lookalike served by a reverse proxy, the local browser is not the thing talking to that proxy.
Because there is no direct connection between the endpoint and the malicious domain, the proxy has nothing to intercept. Active credential prompts and the proxy engine cannot reach local session data. The login flow is sealed off from external manipulation. Even a polished page from a kit like Tycoon 2FA cannot harvest a cookie that was never exposed to it.
This is where a platform like Jimber sits in the chain. Its browser isolation streams the session as a container, so a convincing phishing link opens in a space where credential theft has no surface to attack. Combined with device posture checks, the attacker is blocked at entry and again at replay.
What about protection across the IT-OT bridge?
Identity theft is usually treated as an office problem. It is not, once administrative accounts are involved. A compromised cloud admin identity can reach physical infrastructure through the same management tools used to run it.
The Stryker attack in March 2026 showed the ceiling of this risk. According to CMIT Solutions (March 2026), attackers who reached cloud administration used Microsoft Intune to remotely wipe 200,000 devices. A stolen session that grants admin rights does not stay contained to email and documents. It can touch the machines that run the business.
For manufacturing, logistics, and any operation with a production floor, this is the line that matters. A stolen office token should never be able to reach an industrial network. Secure integration through a hardware gateway keeps the two environments strictly separate.
Jimber handles this with its NIAC hardware, an agentless IT-OT bridge. It connects operational devices that cannot run an agent, printers, sensors, industrial machines, while keeping the production environment isolated from the office cloud. If a cloud identity is compromised, the bridge prevents the attack from crossing into systems that keep production running.
For Belgian organisations this also ties into compliance. The CyberFundamentals (CyFun) deadline has now passed, and many mid-market firms are still working through the practical detail. Bringing identity security, session isolation, and network segmentation into one console is a direct route to meeting NIS2 obligations without stitching together five separate tools. According to KPMG (2025), 38 percent of Belgian organisations have already been hit through their supply chain or an IT service provider, which makes that consolidation more than a paperwork exercise.
Breaking the AiTM chain does not need a megavendor budget or a dedicated team to manage. The European mega-alternatives, Zscaler, Palo Alto Networks, Cloudflare, deliver capable platforms, but at a scale and operational weight that the mid-market rarely needs and often cannot staff. A single-vendor European SASE platform like Jimber covers the same defensive layers, isolation, device posture, and IT-OT separation, in one console built for teams of 50 to 400 users. If you want to see how those controls block a live AiTM attempt in your own environment, book a demo and walk the attack chain with us.
Frequently asked questions
What is an adversary-in-the-middle phishing attack?
An adversary-in-the-middle attack uses a reverse proxy to relay traffic between a victim and a real website. The proxy captures the password and the active session cookie in real time, so the attacker can hijack the authenticated session even when MFA was used.
Why is traditional MFA vulnerable to token theft?
Traditional MFA only verifies the user at the start of a session. After that, the identity provider issues a session cookie that is not bound to the origin domain. Attackers can copy that cookie and replay it from their own machine.
How do passkeys prevent reverse proxy phishing?
Passkeys use FIDO2 cryptography that binds the login secret to the verified domain name. If the user reaches a fake domain through a proxy, the browser will not release the credential, so the reverse proxy captures nothing usable.
Can an attacker use a stolen session token indefinitely?
No. A stolen token grants access until it expires, is explicitly revoked by an administrator, or is blocked by a continuous risk or device-posture policy. Revocation is not instant, so narrowing that window matters.
How does browser isolation protect against credential theft?
Browser isolation streams a visual representation of a website to the user. The local endpoint never connects directly to or authenticates through the malicious proxy, so the attacker has no session data to intercept.
What does ZTNA cover against token theft?
ZTNA restricts network access to authorised applications and devices, which limits how far an attacker can move with stolen credentials. It does not prevent the initial credential theft at the identity provider layer, so it works best alongside isolation and device posture.
