Adversary-in-the-Middle Attacks: When MFA Is Not the End of the Story

What has been observed

A kit that made AiTM a subscription product. Microsoft tracks Tycoon2FA, a phishing-as-a-service platform run by the actor it calls Storm-1747, as one of the most widespread AiTM kits. It was sold through Telegram and Signal, from US$120 for 10 days or US$350 for a month. Microsoft reports campaigns producing tens of millions of phishing messages a month that reached more than 500,000 organizations, across education, healthcare, finance, non-profit and government. Phishing subdomains were short-lived, often 24 to 72 hours, and mostly hosted on Cloudflare. Microsoft’s Digital Crimes Unit, working with Europol and industry partners, has since disrupted the platform’s infrastructure. These volumes are Microsoft telemetry and have not been independently verified.

A campaign that used a trusted sender and a familiar workflow. Microsoft Defender researchers described a campaign against energy-sector organizations. Phishing emails arrived from a trusted organization’s address, probably an account already compromised. They imitated SharePoint document-sharing notices and linked to a page that captured credentials and the session cookie. The attacker then signed in from a different IP address and created an inbox rule that deleted incoming mail and marked everything as read. More than 600 phishing emails went to the victim’s contacts, including distribution lists. When recipients questioned the message, the attacker replied to confirm it was legitimate, then deleted the exchange. Recipients who clicked became the next AiTM victims.

How the relay works

The user is never asked to do anything unusual. That is the point.

The user follows a link to a page that looks like the real sign-in. It is a proxy sitting between the user and the real service.
Credentials typed into the page are forwarded to the real service immediately.
The real service issues its genuine MFA challenge. The proxy shows it to the user.
The user completes the challenge, whether a code, an approval or a typed number. The proxy forwards the response.
The service issues a session. The proxy captures the session cookie and the attacker replays it.

Every step in that chain succeeded on the real service’s terms. The only thing wrong was the address in the browser bar, and a one-time code, a push approval or a typed number has no way to check it.

Why phishing-resistant authentication changes the outcome

NIST SP 800-63B-4 classes passwords, look-up secrets, out-of-band methods and one-time codes as not phishing-resistant. It describes cryptographic authentication as phishing-resistant when it meets additional requirements, including audience restriction: a response produced for an impostor cannot be reused at the real service. In practice, a passkey or FIDO2 security key signs a challenge that is scoped to the legitimate site’s identity. A response generated on the attacker’s domain is worthless at the real one. The user can be fooled completely and the relay still fails.

NIST also sets the direction for assurance levels: verifiers must offer at least one phishing-resistant option at AAL2, and AAL3 requires one with a non-exportable key.

METHOD	STOPS THE RELAY?	WHY
SMS or voice code	No	The user types the code into the proxy, which forwards it.
Authenticator app code	No	Same as above. The code is valid for the real service.
Push approval, including number matching	No	The user approves the genuine challenge. Number matching reduces approval fatigue, not relay.
Passkey or FIDO2 security key	Yes	The signed response is bound to the legitimate site and fails at the proxy.
Certificate-based authentication with a non-exportable key	Yes, when it meets NIST’s phishing-resistance requirements	Cryptographic and audience-restricted.
Risk-based Conditional Access and continuous access evaluation	Reduces impact, does not stop the relay	Microsoft recommends these alongside phishing-resistant MFA.

Where organizations still leak

The weaker method that is still allowed

Enrolling users in passkeys does not help if their password and a code, push or SMS method remain valid sign-in routes. A lure can steer a user toward whichever method still works, and the user often has a “sign in another way” option. Microsoft’s guidance to use authentication strength in Conditional Access for critical applications addresses exactly this. We have no public data on how many organizations leave this open, so treat this as an assessment to test in your own tenant.

MFA registration as a persistence route

Microsoft’s analysis notes that an attacker holding a session can register a new MFA method, such as a one-time code to a phone they control, and keep access after the standard clean-up. If registering a new method needs only the session the attacker already has, the control protects the front door and leaves the lock-change desk open.

Containment that stops at the password

In an AiTM case the attacker already holds a valid session, so a password reset alone does not end access. Microsoft’s steps are: reset the password and revoke active sessions, reverse any MFA changes, and delete suspicious inbox rules.

Detection signals worth building

Sign-in followed by session use from a different IP address. Microsoft describes the attacker signing in from a different address after capture.
A new MFA method registered soon after a risky or atypical sign-in.
An inbox rule that deletes mail and marks messages as read.
A sudden burst of outbound mail to contacts and distribution lists, especially carrying a sharing link.
Sharing notifications from a known partner that fail ordinary checks such as an unexpected document, an unusual time, or a link that asks for authentication.

What to change, in order

PRIORITY	CHANGE	REASON
1	Enforce phishing-resistant MFA for privileged roles and for identities that can move money or change payment details.	Highest impact per user, and the population is small enough to complete quickly. Microsoft recommends this for privileged roles.
2	Remove the fallback. For users enrolled in a strong method, restrict sign-in to that method with authentication strength and retire weaker registered methods.	Without this, enrollment is a preference, not a control.
3	Require strong authentication to register or change an MFA method, and alert on every new registration.	Closes the persistence route Microsoft describes.
4	Write session revocation, MFA review and inbox-rule review into the response runbook as one step, not three.	A reset-only response leaves the attacker in.
5	Extend to the wider workforce in waves, starting with the roles attackers target in your sector.	Full coverage takes time. Sequence by exposure.

What is not known

Public evidence shows the technique and its scale in Microsoft’s telemetry. It does not show how many organizations have already closed the fallback path, how often registration is abused, or how quickly the kit ecosystem rebuilds after an enforcement action. Those would sharpen the priorities above.

Next step

Start with one inventory: for each privileged or financially sensitive identity, list every method that can still produce a valid sign-in. Any entry that a proxy can relay is an AiTM path. Cybrilliant’s identity and access security work begins with this view of authentication strength, fallback paths and MFA registration controls.

Sources

Microsoft Security Blog. Inside Tycoon2FA: how a leading AiTM phishing kit operated at scale. microsoft.com
Microsoft Security Blog. Multistage AiTM phishing and BEC campaign abusing SharePoint. microsoft.com
NIST. SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management. csrc.nist.gov