The Committee That Didn't Exist: TA419's AI Policy Lure and the Kit That Clicks 'Stay Signed In' for You

On 8 July 2026, an email landed in the inboxes of AI policy researchers at US think tanks, universities and law firms. It came from "Lynne Parker", the former Principal Deputy Director of the White House Office of Science and Technology Policy, and it invited the recipient to join an "AI Policy Advisory Committee".

There was no committee. The sender was leparker@mail[.]com, and Proofpoint attributes it, with moderate confidence, to TA419, a China-aligned espionage actor it has tracked since April 2025. Proofpoint published the full write-up last week, and Cybersecurity Dive, Security Boulevard and SecurityOnline have since confirmed the core details.

I've read a lot of think tank phishing reports. Most are variations on a theme: plausible persona, fake document share, password page. This one is worth slowing down for because of one small piece of JavaScript that does something I hadn't seen documented this plainly before. It ticks the "Keep me signed in" box on the victim's behalf.

Three personas, one target list

TA419's pretexts tell you exactly what it wants. Proofpoint lists three:

• February 2026: a senior Anthropic employee asking an AI policy analyst for feedback, under the subject line "Request for Feedback on Military Integration of Claude".
• From 8 July 2026: Lynne Parker, inviting targets onto the fictitious advisory committee.
• Later in July: Heidi Crebo-Rediker, an economist and foreign policy expert, asking recipients to contribute to a Senate Committee on Foreign Relations report on AI export controls and supply chains.

Notice the progression. Model use in defence, then AI governance, then export controls and chip supply chains. That's not a spray. That's a collection requirement written out as a sequence of email subjects. Annie Fixler of the Foundation for Defense of Democracies put the stakes simply to Cybersecurity Dive: getting into these mailboxes gives an adversary "behind-the-scenes details about future policy changes."

The senders were free webmail accounts (mail[.]com, outlook[.]com) plus a few lookalike domains aimed at other audiences, such as heritiages[.]org for the Heritage Foundation and tw-koryu[.]org for the Japan-Taiwan Exchange Association. Proofpoint says mail went out through actor-controlled VPS hosts and residential proxies.

And the first email carried no link at all. TA419 waited for a reply. Only once a target had engaged did a shortened URL arrive, framed as "additional information". By then you're in a conversation with someone you believe is a former White House official, and the link is an answer to a question you asked.

Following the link

Here's the chain Proofpoint reconstructed, step by step.

1. URL shortener. Hides the destination from anyone skimming the email.
2. First-stage filter domain (driftshare[.]co in the July waves). It shows a fake OneDrive loading screen while running a Cloudflare Turnstile check. Scanners and sandboxes tend to stop here.
3. Second-stage phishing domain (globalfileshareplatform[.]com). This is the adversary-in-the-middle proxy, fronted by Cloudflare's CDN so the backend IP stays hidden. Domains came from NameSilo and were themed around file sharing, with registrations going back to sharehub[.]space in December 2025.

The proxy is built on Frameless BitB, an open-source kit that bundles a Browser-in-the-Browser overlay, an Evilginx phishlet for Microsoft 365, and server-side substitution rules. TA419 customised it.

What makes it nasty is where the fake lives. The proxy fetches Microsoft's genuine /common/oauth2/v2.0/authorize page and injects two scripts into the response. One builds a Shadow DOM container holding a convincing OneDrive folder listing with the lure documents in it. When you click a file, another script pops a fake Chrome window over the page, and inside that window is Microsoft's real sign-in flow, relayed live. The OAuth request targets the first-party OfficeHome application, client_id=4765445b-32c6-49b0-83e6-1d93765276ca, so the app name on screen is one you'd expect.

Proofpoint's description of the result is the sentence every identity team should read twice: the kit "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."

The script that does your clicking

The third injected file, /secondary/observe.js, is TA419's own addition. It handles telemetry and automation on the relayed page. Two behaviours stand out:

• It auto-submits one-time codes the moment they validate.
• It auto-accepts "Keep me signed in".

The first is about speed. A TOTP code has a short shelf life, and a human hesitating over a fake window costs the operator the session. Submitting instantly closes that gap.

The second is the one I'd underline. "Keep me signed in" (the KMSI prompt) decides whether Entra ID issues a persistent session cookie. Without it, the stolen cookie may die when the browser closes. With it, the operator gets a long-lived session that survives restarts, and in many tenants it'll quietly refresh for days or weeks. The victim never sees the prompt answered because the overlay sits between them and the real page.

So the operator doesn't just steal a login. It chooses, on the victim's behalf, the most durable version of that login Microsoft will hand out. That's a design decision by someone who has replayed a lot of cookies and been annoyed when they expired.

There's a practical tip in there for defenders. If your tenant lets users choose KMSI, check whether you actually need it. A Conditional Access sign-in frequency control or persistent browser session policy set to "never persistent" for high-risk groups takes the choice away from the user, which means it's also taken away from observe.js.

"No successful compromises" is the wrong comfort

Proofpoint told Cybersecurity Dive it contacted every targeted organisation and isn't aware of any successful compromises. That's good news, and I'm not going to argue with it. But I'd be careful about what it proves.

It proves Proofpoint didn't see one. A successful AitM session theft against Microsoft 365 produces almost nothing a mail gateway or the victim would notice. The user signed in to real Microsoft, passed real MFA, and landed on a page that looked like OneDrive. From their seat, a link from a former White House official opened a document viewer. Then, at some later point, a session cookie starts being used from a residential proxy that geolocates near the victim's city.

What does that look like in the sign-in logs? A token replay, often flagged by Entra ID Protection as an anomalous token or unfamiliar sign-in properties if you license it, and missed entirely if you don't. What does it look like in the mailbox? MailItemsAccessed events, assuming you have the audit tier that records them. For a think tank with a small IT team on a basic licence, the honest answer is often "nothing at all."

Palo Alto Networks' Unit 42 2026 Global Incident Response Report found identity weaknesses played a material role in almost 90% of its investigations, and that 65% of initial access came through identity-based techniques. Those are the cases somebody noticed. Espionage collection from a mailbox is the category least likely to get noticed, because nothing breaks.

The same week, the same targets

TA419 isn't alone in this lane. On 29 September, Microsoft published research on Star Blizzard, the FSB-linked actor, and its new "RedFlick" malware delivery technique. Microsoft says those campaigns hit more than 100 organisations between January and August 2026, mainly in the US and UK, and the lures impersonated Chatham House, the Atlantic Council and IISS with fake conference invitations.

Two state-aligned actors, two different toolkits (one steals sessions, one installs a backdoor), and largely the same address book: policy researchers whose value is what they know and who they talk to. If you run security for a think tank, you are not a soft target that happens to get swept up. You are the requirement.

Why passkeys are the fix and why they aren't enough by Monday

Proofpoint's main recommendation is phishing-resistant, origin-bound authentication such as passkeys. It's correct. A FIDO2 credential bound to login.microsoftonline.com won't sign an assertion for globalfileshareplatform[.]com, and the whole relay collapses.

Two caveats from doing this work.

First, rollouts take months, and the attacker knows it. We covered how the passkey rollout itself became a phishing pretext only last week. During the transition, users usually keep a fallback method, and AitM kits are very good at steering a sign-in to whatever weaker method is still registered.

Second, think tanks are full of people who aren't employees: visiting fellows, senior advisers, external contributors on personal Gmail. They're precisely who TA419 writes to, and they're outside your passkey policy entirely. Their compromised mailbox still contains your drafts.

So you need a way to know when a stolen session is being used, independent of whether the sign-in looked clean.

Where deception fits in this kill chain

Look at what the operator does after the cookie works. It opens the mailbox and OneDrive of someone it selected for their policy access, and it reads. It searches for terms like "export controls", "draft", "Senate", "briefing". It opens attachments. That reading phase is where the operator is most exposed, because every action is a choice to touch something.

That's the point to plant something worth touching. A few placements I'd prioritise for a policy organisation:

• A decoy document in the mailbox or OneDrive of likely targets, titled the way TA419's own lures are titled: "AI export controls: draft committee input (not for circulation)". The legitimate user knows it's a tripwire and never opens it. Anyone else who opens it sets off an alert that carries the source IP and user agent, which is exactly the session replay evidence your sign-in logs may not show.
• A decoy credential inside that document or in a sent-items thread, such as a login for a "shared research portal". Nobody legitimate will ever use it. So an attempt to use it needs no scoring or tuning. It's a confession. Our honeytoken and decoy solutions are built for this kind of placement in Microsoft 365.
• A decoy persona. List a "research associate, AI governance" on the website with a monitored address. Real collaborators have no reason to write to a person who doesn't exist. A message from "Lynne Parker" to that address tells you the campaign has reached your organisation before any real employee replies.

One honest caveat. Phishing kits have started fighting back against canary content. We wrote about BigBear 2.0, an Evilginx-based kit that strips canary tokens from the pages it proxies. That's a reason to put your tripwires in the post-compromise data rather than in the login page. A kit can rewrite the HTML it relays. It can't know which of the 4,000 files in a mailbox is the one nobody is supposed to open.

The design point I keep coming back to: TA419 spent real effort making the sign-in indistinguishable from a real one. It succeeded. Scoring that sign-in harder is a losing game. Make the data the attacker came for do the detecting instead.

What I'd do this week

If your organisation does AI, export control or China policy work, here's a short list.

1. Search your mail logs for the published senders (leparker@mail[.]com, hcrediker@mail[.]com, hcrediker@outlook[.]com) and for any inbound mention of an "AI Policy Advisory Committee". Proofpoint's report has the rest of the indicators.
2. Hunt OfficeHome sign-ins (4765445b-32c6-49b0-83e6-1d93765276ca) where the session was later used from a different ASN than the one that completed MFA. That gap is the cookie moving.
3. Turn off user-chosen KMSI for staff in policy roles, and shorten sign-in frequency for them. Don't let the kit pick the longest session for you.
4. Revoke sessions, not just passwords, if anyone clicked. A password reset does nothing to a cookie that's already been issued.
5. Brief the fellows and advisers, not just staff. Proofpoint's advice to individuals is to verify unexpected subject-matter outreach through a second channel. A former official will understand a phone call to check.
6. Seed the mailboxes of your most-targeted people with decoys before the next persona arrives.

The persona will change. Lynne Parker and Heidi Crebo-Rediker are burnt now, and TA419 will pick someone else from the same small world of names your researchers trust. What won't change is that once a session is stolen, someone has to open your documents to get anything out of it. If you'd like to see how a decoy document and credential behave inside a Microsoft 365 tenant when a replayed session touches them, book a Mine2 demo and we'll walk through it on a live tenant.