The Login Page That Was Not Yours (Twelve Ways In, Part 1)

The multi-factor prompt did its job. It just did it for the wrong person.

Adversary-in-the-middle phishing does not break multi-factor authentication. It stands between the user and the real login page, relays each step in real time, and keeps the session token that gets issued at the end. The victim completes a genuine challenge against a genuine service. The attacker then uses the result, usually within minutes, from a laptop somewhere else.

This is part one of Twelve Ways In, a series on the twelve routes attackers most often use against a small or mid-size business, one per installment, each followed by the controls that close it. It seemed fair to start with the path that makes people say "but we have MFA" and mean it. The technique is not new. What changed is the price: kits that perform it are now sold as monthly subscriptions to people who could not have built one, and the volume is showing up in incident data.

The mechanics, in order

Step one is a click from somebody with a reason to click. A document share, an invoice, a voicemail notice, sometimes a QR code that moves the whole thing onto a phone. The lure matters less than the fact that the recipient was doing their job at the time.

Step two is the part most people misunderstand. The landing page is not a fake login form. It is a reverse proxy sitting in front of the real one. The address bar belongs to the attacker, but the page is being fetched through attacker infrastructure from the actual identity provider. The branding, the tenant name, the layout, the error messages are all genuine because the source is genuine.

Step three: the victim types the password. The proxy relays it to Microsoft, Okta or Google in real time and relays the answer back. A wrong password produces a real error message, which is oddly reassuring. This is why the experience feels normal. It is normal. It is simply being watched.

Step four: the MFA challenge arrives. Because the proxy is in the middle, the challenge is real as well: a real push, a real six-digit code, whatever the tenant enforces. The victim satisfies it. That is the entire point. The attacker never has to defeat the second factor. The attacker only has to be present while someone else completes it.

Step five: the identity provider does what it is supposed to do and issues an authenticated session. The proxy captures the session cookie on the way back. The attacker imports that cookie into their own browser and is now inside an authenticated session, with no prompts, no codes and no alerts.

The last step is housekeeping, and it is why these incidents last longer than they should. A competent operator registers an additional authentication method or joins a device to the account before doing anything else. Password resets then land on the owner of the mailbox and leave the intruder untouched.

Why the token is the real credential

Everything above depends on one design fact: after login, the session cookie is the credential. It is a bearer token. Whoever holds it is treated as the authenticated user, on any machine, in any country, until it expires or is revoked. That is not a flaw. It is how web sessions have worked for twenty years, and it is what makes single sign-on usable.

The gap the technique exploits is that the MFA prompt is bound to the login event, not to the future use of the session it produces. The second factor proves a human was there at the moment of authentication. It makes no claim about where the resulting session travels next. Adversary-in-the-middle attacks live in that gap, and they have for years.

The practical consequence is uncomfortable. Changing the password does not evict an intruder holding a live session. It changes the key to a door that is already open. What removes them is revoking sessions and refresh tokens, removing the rogue authentication method, and removing any device they enrolled. If your incident playbook says "reset the password and monitor," the intruder reads that playbook with some relief.

Once inside, the pattern is consistent. Inbox rules that quietly forward or hide mail. Access to SharePoint, OneDrive and Teams. Reconnaissance of who approves payments. Then either a business email compromise asking a supplier or a customer to change bank details, or straightforward data theft and extortion.

What it looked like this quarter

In August, researchers at Island described a phishing kit called NovaCookies, sold as a subscription at roughly 320 dollars a month, which had been used against hundreds of organizations across the United States, the United Kingdom, Canada, Germany, Israel and the United Arab Emirates. Every layer of the delivery was designed to survive scrutiny on its own.

The email was a genuine Docusign notification. Not a spoof. The sender authentication checks passed because the sender really was Docusign, and what was malicious was the document shared through it. Clicks were then routed through legitimate Microsoft or Google sign-in endpoints as redirect hops before reaching attacker infrastructure. Each hop is individually trustworthy. A mail gateway sees a real document service. A URL reputation check sees a real identity provider. The point where those hops become a single attack is the browser, and no single tool owns the browser.

The kit also gates access with a Cloudflare challenge and detects debugging tools before serving the fake login page, so automated scanners get a harmless page and a human gets the harvest. It is assessed to be a variant of the Sneaky 2FA kit, with dedicated flows added for Okta and for Entra domains federated to GoDaddy.

This is not a boutique problem. Cisco Talos reported that phishing was the primary means of initial access in over half of its incident response engagements in Q2 2026, up from roughly a third the quarter before. Authentication abuse appeared in 65 percent of engagements, against 35 percent the prior quarter, driven by exactly this category: adversary-in-the-middle proxies, session token theft, MFA fatigue and self-enrolled devices.

The mobile numbers are worth a moment. Verizon's 2026 Data Breach Investigations Report found a median click rate of about 1.4 percent on email phishing simulations and roughly 2 percent on voice and text simulations, with mobile click rates around 40 percent higher than desktop. A phone has a smaller screen, a shorter attention span and, in most companies, no URL filtering. Attackers have noticed.

The tells, from the owner's chair

Honesty first: during the login itself, a well-built attack is close to invisible to the person typing. That is the design, and telling staff to "look closely at the URL" is not a control, it is a hope. The place this becomes visible is immediately after.

A sign-in from an unfamiliar city, with MFA satisfied, at a time the user was not working. A new inbox rule forwarding mail to an outside address, often named something dull like "." or "rss". An authentication method or device on the account that the user did not add. Colleagues receiving messages the user did not write. A session that survives a password change.

There are business-level tells too, and they tend to arrive as ordinary requests. A supplier emails to say their bank details have changed. An invoice arrives with new payment instructions and a slightly different domain. A finance director asks, by email, for a transfer that is urgent and confidential. Each of these is a normal thing to receive and a normal thing to be suspicious of, which is why the verification step has to be a phone call to a number already on file rather than a reply to the email.

The controls that actually close it

There is one control that breaks this technique rather than narrowing it: phishing-resistant authentication, meaning FIDO2 security keys and passkeys. The credential is cryptographically bound to the origin it was registered with. A proxy on an attacker-controlled domain cannot produce a valid signed assertion for the real identity provider, because the browser will not release it. The attacker can relay pages all day. The passkey will not answer the wrong door. This is precisely why CISA's guidance on phishing-resistant MFA, and the federal M-22-09 requirements, steer agencies toward FIDO and certificate-based methods instead of codes and push approvals.

The second control is device conditionality. Conditional Access policies that require a compliant or managed device, and that block legacy authentication, mean a stolen cookie replayed from an unmanaged laptop fails a condition the token cannot satisfy. This is the layer that held in the Microsoft 365 token-spray campaign we wrote about at the end of October: the accounts behind a compliant-device policy did not fall over when the session was replayed.

The third is reducing the value of a stolen cookie. Where the platform supports token protection or binding, turn it on. Shorten session lifetimes, especially for mail, finance and admin portals, and require re-authentication for sensitive actions. A session that lives for an hour is worth considerably less on a marketplace than one that lives for ninety days.

The fourth is alerting, and it is the cheap one. Two events catch most of these intrusions after the fact: a new authentication method being registered, and an inbox rule created that forwards mail externally. Both are legitimate administrative actions that almost never happen in a healthy account without a reason, and both are available as alerts in every major cloud identity platform.

One realistic note. Not every business can deploy all four across every employee next month. FIDO2 keys or passkeys for administrators and anyone who can approve a payment, first. Device-based access for mail and finance apps, second. Everyone else, in the next hardware refresh. That ordering alone removes most of the exposure, because the accounts worth proxying are the ones with authority.

The short version for the person signing off

MFA is still worth having. It stops credential stuffing, password spraying and most of the low-effort daily noise, and removing it would be worse than keeping it. What it does not do is prove that the person who completed the challenge is the person using the session an hour later. Adversary-in-the-middle phishing is built entirely on that difference, and it is now sold by the month to people who cannot write the code themselves.

The fixes are unglamorous and mostly about identity, not detection. Phishing-resistant authentication for the accounts that matter, device conditions on the apps that hold money and mail, session lifetimes that assume a cookie will eventually be stolen, and two alerts that tell you when a session has been taken over. None of it is exotic. All of it is cheaper than the alternative, which is finding out during a bank reconciliation.

One closing observation worth carrying into the rest of this series. Every one of the twelve paths we will cover in the coming months ends in the same place: an authenticated session that the business believes belongs to an employee. The path changes. The destination rarely does.

Sources

• Island research, reported by The Hacker News, NovaCookies Campaigns Abuse Genuine Docusign Notifications to Steal Microsoft 365 Sessions, August 26, 2026: https://thehackernews.com/2026/08/novacookies-campaigns-abuse-genuine.html
• Cisco Talos, IR Trends Q2 2026: Phishing and weaponized remote management tools drive attack chains, July 28, 2026: https://blog.talosintelligence.com/ir-trends-q2-2026/
• Microsoft Security Blog, Inside Tycoon2FA: How a leading AiTM phishing kit operated at scale, March 4, 2026: https://www.microsoft.com/en-us/security/blog/2026/03/04/inside-tycoon2fa-how-a-leading-aitm-phishing-kit-operated-at-scale/
• Verizon, 2026 Data Breach Investigations Report, executive summary: https://www.verizon.com/business/resources/executivebriefs/2026-dbir-executive-summary.pdf
• CISA, Implementing Phishing-Resistant MFA: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
• OMB Memorandum M-22-09, federal zero trust strategy, phishing-resistant MFA requirement: https://learn.microsoft.com/en-us/entra/standards/memo-22-09-multi-factor-authentication