A reverse proxy sat between the victim and real Microsoft infrastructure, and every check still passed. China-aligned TA419 ran multi-stage adversary-in-the-middle phishing against US AI policy experts at think tanks, universities, and law firms, with a kit designed to capture passwords, MFA codes, and Microsoft 365 session cookies while the target completes a genuine Entra sign-in. According to Proofpoint on 1 October 2026, a target who finishes that legitimate-looking ceremony hands the attacker replayable session cookies.
Proofpoint does not report confirmed compromises, victim organizations, or account counts. The technical path is clear enough without them.
From rapport mail to a proxied OfficeHome login
According to Proofpoint, TA419 has run 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 wave was an extension of that focus, not a one-off stunt.
The social layer started soft. Operators sent benign rapport-building messages that impersonated AI policymakers, including Lynne Edwards Parker, former Principal Deputy Director of the White House OSTP, and economist Heidi Crebo-Rediker, beginning around 8 July 2026. An earlier February 2026 wave in the same report impersonated a senior Anthropic employee with a subject line about military integration of Claude and steered a US think-tank AI policy analyst into a similar Microsoft 365 chain. Replies and follow-ups then moved targets into multi-stage redirects toward OneDrive-themed pages.
An adversary-in-the-middle attack is a live reverse proxy that sits between the user and the real identity provider so the victim completes a genuine login while the attacker records everything the ceremony produces. TA419 combined a Frameless browser-in-the-browser overlay with an Evilginx Microsoft 365 phishlet and server-side injection into the proxied pages. Cloudflare Turnstile filtered casual scanners. Domains called out in reporting included driftshare[.]co and globalfileshareplatform[.]com, with backend hosting obscured through Cloudflare so a full infrastructure inventory is not fully enumerated in the public write-up.
The proxied application mattered. Phishing pages targeted Microsoft 365 and Entra through the first-party OfficeHome client (client_id=4765445b-32c6-49b0-83e6-1d93765276ca). That choice kept the sign-in path looking like ordinary workforce Microsoft access rather than a random third-party OAuth app the user had never seen.
Password, MFA response, and cookies in one ceremony
Proofpoint's core description 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.
That single sentence is the whole credential-phase failure. The password left the user. The second factor, whatever non-phishing-resistant method the account used, was completed in real time on the proxied page. Conditional access still saw a login that looked right against real Microsoft systems. Nothing in that path required the attacker to break cryptography on the IdP. They only needed the user to finish a login the proxy could watch.
Custom observe.js did the unglamorous work after the factors cleared. According to Proofpoint, the same script auto-accepted "Keep me signed in" to extend the stolen session and auto-submitted one-time codes as soon as they validated. OTP entry stopped being a race the operator had to win by hand. KMSI stretched how long the captured session remained useful without another prompt.
| Control at login | What reporting shows here | Why it failed the user |
|---|---|---|
| Password | Typed into proxied Entra/OfficeHome flow | Relay captured it live |
| OTP or similar MFA | Completed through the proxied page | Transferable factor, auto-submitted |
| Conditional access | Checked against real Microsoft stack | Proxy made the login look genuine |
| Session cookies | Captured right after auth completes | Replay needed no second MFA |
SSO made the cookies valuable. 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 of workforce SSO still applies: one good session is a skeleton key across the suite until someone revokes it.
What captured cookies would allow
Once a proxied authentication completes, the attacker holds the Microsoft 365 session cookies. Replay of those artifacts required no further MFA. That is not a second "bypass" of a login factor. Authentication had already finished. The tokens were the proof of a completed ceremony, now sitting with the attacker.
Stopping damage after that point is revoke-and-detect work. Kill access and refresh tokens, force re-authentication, watch for anomalous Graph, SharePoint, OneDrive, or mailbox activity, and assume KMSI-extended sessions last longer than a short incident window. Public reporting does not establish ransom demands, record counts, or a full list of exfiltrated datasets for this campaign. Proofpoint assesses the activity likely supports Chinese intelligence collection on US AI policy, not a smash-and-grab retail fraud story.
Compare the two phases cleanly. The initial access path was credential-phase AiTM: password plus live MFA response harvested while the real IdP said yes. Device-bound, origin-bound authentication closes that path because a proxy on the wrong origin cannot complete a hardware-bound signature the way it can relay a typed code or a pushable approval. Passkeys and similar phishing-resistant factors are what Proofpoint recommends for that reason. The persistence path was token-phase: cookies already issued after a successful login. No login factor undoes a cookie that already exists. Closing the phishable login stops this kit from harvesting the session in the first place. Malware after a legitimate login is a harder, separate problem.
A frustrated defender will still ask whether shorter session lifetimes would have saved the day. Lifetime limits only force the attacker to re-use or re-steal sooner. They do not prevent the AiTM capture. If the operator also enrolls a lasting factor during the window of access, lifetime math stops mattering. Public reporting on TA419 emphasizes cookie theft and KMSI extension rather than a documented secondary authenticator enrollment, so stay inside what Proofpoint actually shows.
The same actor's February 2026 Anthropic-themed wave and the July 2026 policymaker-impersonation wave used a similar Microsoft 365 AiTM chain against AI-policy targets. Treating them as isolated helpdesk accidents or random BEC noise misses the pattern: sustained China-aligned credential phishing, active since at least April 2025, aimed at people who live inside Entra every day.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: where passkeys block TA419-style Entra AiTM capture.
FAQ
How does TA419 get into Microsoft 365 accounts in this campaign?
TA419's chain uses multi-stage adversary-in-the-middle phishing that proxies genuine Microsoft 365 and Entra sign-ins through a Frameless BitB overlay and an Evilginx phishlet aimed at the OfficeHome client. According to Proofpoint, the target's password, MFA response, and conditional access checks all succeeded on real Microsoft infrastructure while attackers captured the resulting session cookies. Public reporting does not name the victim organizations.
Does MFA fail for the TA419 Microsoft 365 AiTM attacks?
Non-phishing-resistant MFA failed at the credential phase because one-time codes and similar transferable factors were completed on the proxied page and could be relayed or auto-submitted. Conditional access still passed because the login hit genuine Microsoft systems. After cookies were issued, replay needed no further MFA. That second stage is post-authentication token use, not another interactive login failure.
What does observe.js change about the captured TA419 sessions?
According to Proofpoint, custom observe.js auto-accepted "Keep me signed in" to extend captured Microsoft 365 sessions and auto-submitted one-time codes as soon as they validated. That reduced operator toil during the live relay and lengthened how long captured cookies remained useful without another prompt to the real user.
Were think tanks, universities, and law firms the only TA419 targets?
Proofpoint describes TA419 as a China-aligned, espionage-motivated actor observed against US- and Japan-based think tanks, defense contractors, universities, and law firms since at least April 2025, with 2026 campaigns focused on US AI policy experts. Public reporting does not establish a complete victim list or exact account counts for the AiTM waves.
Would revoking sessions alone have stopped the TA419 AiTM path?
Revoking sessions contains damage after cookies are already stolen. It does not stop the upstream reverse-proxy login that minted those cookies. For TA419-style AiTM, prevention means closing phishable, transferable factors at Entra sign-in so the kit never obtains a workforce session. Revoke remains necessary hygiene once a token exists.
