A reverse proxy built to watch a real Microsoft 365 sign-in finish can walk away with the session. China-aligned TA419 ran multi-stage adversary-in-the-middle phishing against US AI policy experts at think tanks, universities, and law firms, using a kit designed to capture passwords, MFA codes, and Entra session cookies while Conditional Access still passes on genuine Microsoft infrastructure. Closing that phishable login with phishing-proof, device-bound MFA stops the kit from minting a workforce session. Cookies already stolen after a completed login still need revoke, and malware after a legitimate sign-in is a harder separate problem.
What TA419's AiTM campaign took from Entra sign-ins
According to Proofpoint on 1 October 2026, TA419 is a China-aligned, espionage-motivated actor observed in regular targeted credential phishing against people at US- and Japan-based think tanks, defense contractors, universities, and law firms since at least April 2025. The 2026 AI-policy waves extended that focus. Operators built rapport with benign mail impersonating AI policymakers, including former White House OSTP leadership and economist Heidi Crebo-Rediker, beginning around 8 July 2026. An earlier February 2026 wave in the same report impersonated a senior Anthropic employee and steered a US think-tank AI policy analyst into a similar Microsoft 365 chain.
Replies moved targets through multi-stage redirects into OneDrive-themed pages. The stack combined a Frameless browser-in-the-browser overlay with an Evilginx Microsoft 365 phishlet and server-side injection into proxied pages. Cloudflare Turnstile filtered casual scanners. Domains called out in reporting included driftshare[.]co and globalfileshareplatform[.]com. TA419 fronts its domains with Cloudflare to hide backend hosting; Proofpoint lists further indicators back to December 2025.
The proxied app was the first-party OfficeHome client (client_id=4765445b-32c6-49b0-83e6-1d93765276ca). That choice made the ceremony look like ordinary workforce Microsoft access rather than a strange third-party OAuth grant. Proofpoint does not report confirmed compromises, victim organizations, or account counts. It assesses the activity likely supports Chinese intelligence collection on US AI policy.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: how TA419 AiTM-proxied real Microsoft 365 sessions.
Why transferable MFA fed TA419's reverse proxy
An adversary-in-the-middle attack is a live reverse proxy between the user and the real identity provider, so the victim completes a genuine login while the attacker records everything the ceremony produces. Proofpoint's core line is blunt: behind a BitB overlay, the proxy relays the sign-in to genuine Microsoft infrastructure, so the target's password, MFA code, and conditional access checks all succeed while the attacker captures the resulting session cookies.
Apply the failure by phase, not by slogan.
Credential phase (initial access). The password left the user on the proxied page. The second factor, whatever non-phishing-resistant method the account used, was completed in real time where the proxy could see it. Conditional Access still evaluated a login that hit real Microsoft systems and looked right. Nothing required breaking IdP cryptography. The attacker only needed the user to finish a login the proxy could watch. Custom observe.js auto-submitted one-time codes as soon as they validated, so OTP entry stopped being a manual race for the operator.
Token phase (persistence). If the target completes that authentication, the attacker holds the resulting Microsoft 365 session cookies. Replay required no further MFA. That is not another interactive login failure. Authentication had already finished. The tokens were proof of a completed ceremony, now sitting with the attacker. The same script auto-accepted "Keep me signed in" to extend stolen sessions, stretching how long captured cookies remained useful without another prompt to the real user.
| Phase | What the kit captures | Why the control failed |
|---|---|---|
| Credential | Password plus live MFA response | Transferable factor relayed through an attacker-origin proxy |
| Credential | Conditional Access decision | Proxy made the login look genuine on real Microsoft stack |
| Token | Session cookies after success | Replay needed no second interactive factor |
| Token | KMSI-extended lifetime | observe.js lengthened usefulness of captured sessions |
SSO amplified the cookies. One Microsoft 365 cloud session is not a single mailbox password. Federation and integrated apps mean mail, files, chat, and adjacent cloud resources can open from the same proof without a fresh interactive login at each boundary. Public reporting does not inventory every app each target could reach. The blast-radius design still applies: one good session is a skeleton key across the suite until someone revokes it.
The same AiTM class showed up earlier in UK industrial workforce campaigns analyzed on this site, where reverse-proxy kits likewise harvested live factors and sessions. Different sector, same login physics: if the second factor can be typed, approved, or relayed, a patient proxy wins the ceremony.
A shorter token lifetime would not have prevented capture. Lifetime limits only force the attacker to re-use or re-steal sooner. They do not stop the reverse-proxy login.
What phishing-proof MFA changes for this Entra path
Device-bound, origin-bound authentication changes the credential phase first. There is no password to type into a proxied OfficeHome page. There is no OTP, SMS code, email code, or push approval for observe.js to auto-submit or for an operator to relay. The private key never leaves the enrolled device. The signature the IdP demands is bound to the real origin. A proxy on the wrong host cannot complete that challenge the way it completes a transferable factor.
That is prevention, not detection. The kit never finishes a successful workforce sign-in, so it never receives the session cookies that made this campaign valuable. Closing the phishable login stops this path. Fooling a user into a proxied login is easy. Planting malware on a machine that already holds a legitimate session is not.
Be honest about the token phase. Once cookies already exist after a completed login, no login factor undoes them. MFA 2.0 does not stop malware on a machine that already holds a legitimate session. That leftover path is endpoint compromise, not another login-factor failure. For TA419-style AiTM, the primary win is upstream: the reverse proxy never obtains the session. Revoke, short-lived sessions where policy allows, continuous access evaluation, and anomaly hunting remain hygiene after any token is already out. Revoke is backup, not the fix for a phishable login.
SSO still collides with zero-trust intent. Classic SSO issues one proof many apps trust, so a single stolen cloud session becomes multi-app access without a fresh check at each boundary. Prefer per-app, device-bound proof with no shared replayable federation cookie. Secure Explicit Sign-On keeps the one-tap user experience while each application receives its own fresh, device-bound signature. No shared reusable token exists to steal once and replay across mail, files, and chat.
The prevention-focused architecture is the point: remove transferable factors so the AiTM position has nothing useful to harvest at sign-in.
Proofpoint recommends phishing-resistant, origin-bound authentication such as passkeys. That recommendation targets exactly the credential-phase failure above. Full-lifecycle phishing-proof coverage goes further still, which the next two sections separate cleanly.
How passkeys origin-bind the OfficeHome ceremony
Passkeys and FIDO2 are phishing-resistant at the login act. The device holds a key pair. The private key stays inside hardware. The identity provider stores only the public key. At sign-in, the browser or OS asks the authenticator for a signature scoped to the real relying-party origin. A generic enterprise IdP that issues only hardware-bound signatures rejects a ceremony completed on an attacker host, because the origin in the signed challenge does not match. TA419's Evilginx phishlet could relay a password and a typed code. It cannot exfiltrate a private key that never leaves the TPM or secure enclave, and it cannot forge an origin-bound assertion for the real Entra host from a BitB overlay.
Where login-only passkeys still leave a lifecycle gap
FIDO2 and passkeys harden authentication. They do not automatically harden enrollment, device onboarding, or recovery. If a phishable factor such as email OTP, SMS, or push is still used to register a user or add a device, an attacker who controls that channel can enroll hardware that later signs requests looking fully legitimate. Public reporting on TA419 does not show helpdesk re-enrollment or recovery abuse in this wave. The campaign lived at the proxied login. The lifecycle gap still matters for workforce Entra estates that adopt passkeys for sign-in while leaving phishable bootstrap paths open. MFA 2.0 is phishing-proof because no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning. Resistant hardens the login. Proof closes the lifecycle. The enrolment model is where that difference is enforced in practice.
Key Takeaways for Defenders
- Require origin-bound, device-bound factors on Microsoft 365 and Entra workforce sign-in so reverse proxies cannot complete OfficeHome ceremonies with relayed OTP or push.
- Treat "Keep me signed in" and long-lived cloud sessions as blast-radius multipliers after any successful AiTM capture; plan explicit revoke playbooks for Graph, mailbox, and file activity.
- Prefer per-app device-bound proof over classic SSO session sharing when designing zero-trust access to mail, files, and chat.
- Block or tightly control flows that mint broad cloud sessions from untrusted clients, and monitor for sudden KMSI-style persistence after unusual sign-in geography.
- Close phishable enrollment and recovery even when the current campaign did not need them, so tomorrow's operator cannot register a lasting factor during a short access window.
The forward path is architectural. Stop minting workforce sessions through transferable factors on pages a proxy can watch.
FAQ
Would passkeys have stopped TA419's Microsoft 365 AiTM credential capture?
Passkeys would have blocked TA419's credential-phase capture on the proxied Entra and OfficeHome login because origin-bound device signatures cannot be completed on an attacker host the way passwords and one-time codes can. According to Proofpoint, the proxy relied on relaying a real sign-in so password, MFA response, and Conditional Access all succeed while the attacker captures the resulting session cookies. Phishing-resistant passkeys break that relay. Session cookies already issued after a completed login still need revoke; no login factor undoes tokens that already exist.
Does phishing-proof MFA 2.0 undo captured Microsoft 365 session cookies from TA419?
Phishing-proof MFA 2.0 does not undo Microsoft 365 session cookies an AiTM kit like TA419's captures after authentication completes. Replay of those cookies required no further MFA because authentication had already finished. The prevention claim is upstream: device-bound, origin-bound sign-in stops the AiTM kit from obtaining the session in the first place. Revoke, continuous access evaluation, and endpoint controls handle residual token abuse and malware after a legitimate login.
Why does classic SSO increase damage after a TA419-style session theft?
Classic SSO increases damage after TA419-style session theft because one Microsoft 365 cloud session can unlock mail, files, chat, and other integrated apps without a fresh interactive login at each boundary. That design conflicts with zero-trust's never-trust, always-verify requirement. MFA 2.0 does not recommend classic SSO. Secure Explicit Sign-On keeps one-tap UX while each application receives its own fresh, device-bound signature, so no shared reusable federation cookie exists to replay across the suite.
Is phishing-resistant MFA the same as phishing-proof MFA for Entra AiTM?
Phishing-resistant MFA is not the same as phishing-proof MFA for Entra AiTM. Passkeys and FIDO2 are phishing-resistant at the login act: origin-bound signatures stop reverse-proxy completion of the sign-in TA419 used. Phishing-proof MFA 2.0 removes phishable factors across registration, device onboarding, authorisation, authentication, and decommissioning. Proofpoint's passkey recommendation addresses the login relay. Full-lifecycle coverage closes enrollment and recovery paths that login-only deployments can still leave open.
What should defenders still do after deploying device-bound MFA against AiTM?
Defenders should still revoke access and refresh tokens quickly, watch for anomalous Microsoft 365 activity, and harden endpoints after deploying device-bound MFA against AiTM. Closing the phishable Entra login stops TA419-style kits from harvesting new sessions. Malware or infostealers on a machine that already holds a legitimate session remain a separate, harder problem that no login factor solves alone.
