CSIPE

Published

- 20 min read

The Microsoft Login Worked. The Attacker Still Got the Session

Phishing Identity Security Threat Modelling Passkeys

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

The email offers you a seat on an AI policy committee. The sender uses the name of a former White House official. You reply because the subject is your work, the request sounds plausible, and the first message asks for no password and carries no suspicious attachment.

The link comes later. It opens what looks like a shared OneDrive folder, then a Microsoft sign-in window. Your password works. Your multi-factor prompt works. The document view appears to behave like the cloud service you use every day. Behind that ordinary sequence, a proxy is relaying the real Microsoft login and collecting the session created when Microsoft accepts it.

Proofpoint disclosed that operation on 1 October 2026. The company tracks the group as TA419 and assesses it as China-aligned and motivated by espionage. It observed campaigns against people at US think tanks, universities, and law firms, including outreach impersonating prominent economists, AI policy figures, and a senior Anthropic employee (Proofpoint: Hallucinating Credibility). Independent reporting from CyberScoop confirmed the disclosed sequence and added an essential limit: Proofpoint did not identify victims or say whether any account was successfully compromised (CyberScoop: AI policy circles targeted in China-linked phishing operation).

That limit should stay attached to the story. This is a documented campaign, not proof that every approach succeeded. Its practical lesson is still sharp. A familiar name can start the conversation, and a genuine login service can finish the authentication, while the browser session lands in hostile hands. The reassuring parts of the experience are the machinery of the attack.

In July 2026, the first messages did not behave like the phishing examples pinned to an office noticeboard. Proofpoint says TA419 impersonated Lynne Edwards Parker, a former senior official in the White House Office of Science and Technology Policy, and Heidi Crebo-Rediker, an economist and foreign-policy expert. The lures invited recipients to join a fictitious “AI Policy Advisory Committee” or contribute to a report about AI export controls and supply chains (Proofpoint: Hallucinating Credibility).

The first move was a conversation. Only after a target replied did the sender provide a shortened link said to hold more information. That delay mattered because the reply created history in the inbox. The next message arrived inside a thread the recipient had already helped to make.

A February 2026 campaign followed the same human logic with a different identity. Proofpoint reported that TA419 impersonated a senior Anthropic employee and used the subject line “Request for Feedback on Military Integration of Claude” when approaching an AI policy analyst at a US think tank. The topic matched a live policy argument. The sender’s claimed role matched the topic. The request matched the target’s expertise.

The recipient was selected for what they knew and who they could reach. CyberScoop reported that the wider targeting covered people at think tanks, universities, and legal organisations whose cloud accounts may hold correspondence, drafts, sources, contact lists, and private policy discussions (CyberScoop: AI policy circles targeted in China-linked phishing operation). The value sits in the account, but the path begins with professional courtesy.

This is why “do not click links from strangers” gives high-risk people too little protection. The sender tries to stop feeling like a stranger before the dangerous link arrives. A reply becomes a small investment. The target has acknowledged the person, accepted the subject, and begun a legitimate-looking exchange. Each step lowers the friction of the next one.

The attribution needs equal care. Proofpoint calls TA419 China-aligned and says its activity probably supports Chinese intelligence objectives around US AI policy. CyberScoop noted that the report did not directly connect the activity to the Chinese government, and China has repeatedly denied conducting cyber espionage. The useful defensive conclusion does not require us to promote an assessment into a court finding. A capable group targeted a narrow policy community with tailored identity theft and a live sign-in relay. That mechanism deserves a response whatever flag an operator ultimately serves.

A person who covers AI policy, defence, civil liberties, export controls, or state surveillance should treat subject expertise as part of the attack surface. Public biographies tell an operator which committee invitation will feel earned. Conference programmes show who knows whom. Published articles supply vocabulary and current interests. A good lure does not have to invent your desires. It offers the recognition that your career has taught you to accept.

The practical defence begins at that first moment. Unexpected professional outreach can remain unanswered for ten minutes while you verify it through an address, phone number, encrypted account, or colleague you already trust. The question is simple: did this person send this request through this channel? Verification should start from a contact route you find independently, never from the signature or number inside the message being checked.

That pause costs less than incident response. It also has a limit. A compromised real account can answer through the expected mailbox, and a colleague can confirm only that the sender is usually reachable there. High-risk work needs the human check and a login method that refuses the wrong site. The campaign was built to survive either control used alone.

The real Microsoft page can be inside the wrong route

After the reply, TA419 used a chain of redirects. Proofpoint observed a shortened link leading through one attacker-controlled domain that presented a Cloudflare check and a fake OneDrive loading screen, then into a second domain hosting the credential trap. The extra steps made the journey feel like an ordinary protected file share rather than a single crude imitation.

The last stage used an adversary-in-the-middle technique. Think of a dishonest receptionist who calls the real office while you stand at the desk. You give the receptionist your name. They repeat it to the office. The office asks for a code. The receptionist repeats that request to you, then passes your answer back. Every answer can be correct because the real office is participating. The receptionist keeps the visitor badge issued at the end.

In a browser, that visitor badge is a session cookie. After a service accepts your password and extra factor, it gives the browser a token that represents the signed-in session. Otherwise, you would have to type every factor again before reading each message or opening each document. The token is useful by design. Whoever can replay a stolen one may be able to act as the accepted session until the service expires or revokes it.

Proofpoint reported that TA419 adapted an open-source “browser-in-the-browser” kit called Frameless BitB. The page drew a false Chrome window over a OneDrive-style listing while a proxy relayed the authentication to genuine Microsoft infrastructure. A custom script watched the target’s progress, automatically accepted “Keep me signed in,” and submitted one-time codes after validation (Proofpoint: Hallucinating Credibility). Help Net Security independently described the same flow and the custom session monitoring based on the published research (Help Net Security: Chinese spies impersonate White House, Anthropic figures).

The important detail is what the attacker relays. The target may receive a real Microsoft authentication response. The password can be checked by Microsoft. A one-time code can be checked by Microsoft. Conditional-access rules can run. A familiar page can load afterwards. Success proves that Microsoft accepted the credentials presented through that route. It does not prove that the route belonged to Microsoft from the target’s browser all the way through.

Ordinary multi-factor authentication still improves security. A stolen password by itself will fail where an extra factor is required. That blocks enormous numbers of attacks. The TA419 chain targets the narrower gap left by factors that a person can copy, approve, or relay in real time. A six-digit code answers “does this person possess the current code?” It does not bind the answer to the exact website asking for it.

Push approval can have the same weakness. If the target initiates a sign-in through a hostile proxy and then approves the matching request, the approval may authorise the real sign-in happening behind the proxy. Number matching reduces accidental approvals and notification fatigue. It cannot make a person notice that the browser’s outer route belongs to an attacker when the inner content looks right.

A browser window drawn inside a webpage also attacks visual habits. People are trained to look for a logo, a lock icon, familiar colours, and a plausible address. A fake sub-window can draw every one of those details. The decisive address belongs to the outer browser tab, not to pixels painted inside it. On a small screen, in a hurried moment, that distinction is easy to miss.

“Hover over the link” also reaches its edge here. A shortened URL hides the final route. Redirects change the destination. A clean-looking first domain can filter visitors before forwarding selected targets. Link inspection remains useful, but high-risk users should avoid using the message’s path for authentication at all. Open the known service from a bookmark, the application launcher, or a fresh browser tab, then locate the shared item from inside the account. If it does not exist there, stop.

The attacker has to keep the relay working. That creates detection opportunities for an identity team: unfamiliar sign-in infrastructure, impossible or unusual session properties, newly added authentication methods, mailbox changes, suspicious consent grants, and access from places that do not fit the user. Those signals can shorten the window. They cannot give the person at the keyboard a clean certificate that the page is safe.

The strongest front-line control changes the authentication ceremony itself. The browser and authenticator should know which site they are signing for and refuse to produce a valid answer for another origin. That is the point of phishing-resistant, origin-bound authentication.

A passkey checks the site as well as the person

A passkey is built around a cryptographic key pair. The service stores a public key. Your device or security key protects the private key. During sign-in, the service sends a fresh challenge, and the authenticator signs it for the registered site. The private key does not travel to the server or get typed into a form.

The site binding changes the phishing problem. Google’s developer documentation states that passkeys work only on their registered websites and applications, so a deceptive site cannot ask the authenticator to produce a valid response for the genuine one (Google for Developers: Passkeys). Microsoft describes phishing-resistant authentication as part of its effort to eliminate unmanaged credentials and protect cryptographic keys (Microsoft Learn: Phishing-resistant multifactor authentication).

Suppose the outer page belongs to example-attacker.test while the content inside imitates Microsoft. A password manager may still be tricked by a person who copies a password manually. A one-time code can be typed anywhere. An origin-bound authenticator sees that the requesting site differs from the site where the credential was registered. It refuses to create the Microsoft answer for the attacker’s origin.

That is why Proofpoint’s recommendation names passkeys, not merely “turn on MFA.” As of 5 October 2026, its published guidance for people in TA419’s scope is to use phishing-resistant, origin-bound authentication and verify unsolicited subject-matter outreach through an independent medium (Proofpoint: Hallucinating Credibility). The two controls cover different seams: the independent channel checks the claimed person, while the passkey checks the site asking to authenticate.

Organisations using Microsoft Entra can require a phishing-resistant authentication strength through Conditional Access. Microsoft’s current setup guidance describes that strength as the most restrictive built-in option and recommends it for the policy (Microsoft Learn: Require phishing-resistant MFA). A useful deployment starts with the people whose accounts carry the most sensitive correspondence and authority: policy staff, researchers, executives, administrators, lawyers, incident responders, and anyone who handles source identities.

The deployment has to include recovery. A brilliant sign-in method paired with a weak help-desk reset gives the attacker a side door. Record which recovery factors are allowed, who can approve replacement credentials, how identity is checked, and how a person reports the loss of every enrolled device. Keep spare security keys in controlled locations for people whose threat model warrants them. Test the recovery before a conference trip, not from an airport after a phone disappears.

Passkeys also have an honest limit. Malware running inside an already signed-in device may act through that live session. A malicious browser extension may read pages or manipulate actions according to its permissions. An attacker who controls account recovery may register a new credential. A person can still approve a dangerous application consent request after signing in safely. Origin binding closes the relayed-login route; it does not clean a compromised endpoint or repair a broken authorisation model.

Some organisations will need a staged move because old applications and workflows do not support the chosen method. That is a reason to map exceptions, not to label all MFA equivalent. Put the most sensitive accounts on the strongest path first. Restrict legacy protocols. Watch every exception. Give temporary fallback methods an owner and an expiry date.

For an individual using a personal Google or Microsoft account, the same principle applies without enterprise policy. Add a passkey or hardware security key through the account’s own security settings reached from a known bookmark. Keep a separate recovery route. Remove old methods you no longer need after confirming that recovery works. Never enrol a new sign-in method because an unexpected email or caller tells you to “upgrade security.”

A security key does something psychologically useful too. It moves part of the judgement out of the frightened or flattered human moment. You can mistake the sender. You can be tired. The authenticator still checks the site. Good security gives fallible people machinery that can say no.

If you used the page, treat the session as exposed

Imagine that you replied, followed the link, entered a password, completed the extra factor, and then felt something was wrong. Changing the password is sensible. It is incomplete because the valuable object may already be the accepted session.

Microsoft’s incident guidance for adversary-in-the-middle campaigns explicitly calls for revoking session cookies as well as resetting passwords, and for removing authentication settings added by an attacker (Microsoft Security Blog: Detecting and mitigating a multi-stage AiTM phishing campaign). Its current Microsoft 365 guidance also provides a response path for compromised mail accounts (Microsoft Learn: Respond to a compromised email account).

Move quickly, but preserve enough information to reconstruct the event. Keep the original message, full headers, shortened link, time of the click, browser used, account involved, and any prompt you approved. Take screenshots if doing so will not expose source material. Report through a trusted channel from a separate device if the original device may be compromised.

A defensible sequence is:

  1. Disconnect from the message path. Close the page. Reach your organisation’s security team through a known number, internal directory, or established secure channel. Do not use contact details supplied by the suspected sender.

  2. Revoke active sessions. An administrator should invalidate the affected account’s sessions and tokens. For a personal Microsoft account, use the account’s official “sign out everywhere” control reached independently (Microsoft Support: Sign out of your Microsoft account everywhere).

  3. Reset the password from a clean route. Open the account service directly on a trusted device. Use a unique replacement. If the old password was reused anywhere, treat those accounts as separate exposures and change them through their own official paths.

  4. Inspect the account’s authority. Check registered authentication methods, recovery details, application consents, forwarding addresses, inbox rules, delegates, connected devices, and recent sign-ins. Remove changes you cannot account for, preserving evidence according to your incident process.

  5. Protect the people around the account. Review sent mail, drafts, deleted items, and recent conversations for follow-on messages. Warn colleagues and sources through another channel if the account may have sent requests in your name. A stolen mailbox can turn your trusted identity into the next pretext.

  6. Move future sign-ins to an origin-bound method. Enrol the repaired account in a passkey, security key, or another phishing-resistant method supported by the service. Verify recovery and remove obsolete fallback routes where policy permits.

The exact administrative commands depend on the tenant and licence. Do not improvise destructive cleanup before evidence is collected. A newsroom, law firm, university, or policy organisation should have an identity incident runbook that names who can revoke sessions, preserve audit records, check mailbox rules, review application consent, and contact affected people.

The device question remains separate. The TA419 flow described by Proofpoint is a credential and session theft chain. Its published report does not say that this chain installs endpoint malware. If you only passed credentials through the proxy, that fact alone does not prove the laptop is infected. If you downloaded or opened an unknown file, installed an extension, ran a command, or granted an application permission, the incident has another branch and the device needs appropriate examination.

Avoid the opposite mistake too. A clean antivirus scan cannot clear a stolen cloud session. Endpoint tools examine one part of the event. Identity logs and account state show another. The response closes both paths that evidence supports without inventing paths that have not been observed.

High-risk teams should rehearse this sequence. Give a staff member a harmless simulation, start the clock when they report it, and measure how long session revocation takes. Check whether the duty contact answers outside office hours. Confirm that logs survive after revocation. The exercise should end with a receipt: which account was contained, which sessions were invalidated, which changes were reviewed, and who was notified.

Speed matters because a mailbox is a map. It contains other people’s trust, future meetings, password-reset messages, private attachments, and years of context for the next impersonation. The first account may be only the doorway.

Build a second channel before you need one

Independent verification sounds simple until the message arrives on a Sunday, the supposed sender is important, and you have never agreed how to verify each other. Build the route while nothing is wrong.

For a small policy team, newsroom, legal clinic, or research group, every person handling sensitive correspondence should have at least one verified contact path outside ordinary email. That may be a Signal number confirmed in person, an internal directory entry controlled by the organisation, a hardware-backed work account, or a known assistant reached through a published switchboard. The route must be independent of the message under review.

The verification question should stay narrow. “Did you send the invitation about the advisory committee and the OneDrive document?” is better than “Is this really you?” The first question binds the person, request, and channel. It also gives the real person enough detail to recognise an impersonation campaign without asking you to disclose the document or the identities of other recipients.

For sensitive files, agree that the recipient will open the service directly. A sender can say, “I placed the document in our existing shared folder,” or provide a filename and location through the second channel. The recipient reaches the folder from a bookmark. This removes the shortened link and redirect chain from the authentication path.

Public figures and organisations can make impersonation harder to check when they scatter contact details across stale biographies. Maintain one current public route for professional invitations. State which file-sharing services the office uses. Give staff a procedure for confirming unusual requests. A target should not have to choose between ignoring legitimate work and trusting a polished stranger.

Email systems can support the human process. Preserve external-sender markings. Make the full sender address visible. Give staff a one-action reporting button that sends the original message and headers to the security team. Detect newly registered lookalike domains and unexpected file-sharing themes. None of those controls should silently reassure the recipient that a surviving message is safe.

The same discipline protects sources. If a journalist’s mailbox is stolen, the harm can travel past the account holder to people whose names, schedules, drafts, and concerns appear in correspondence. Source-protection planning should therefore include cloud identity, session revocation, and impersonation response, alongside encrypted messaging and device security. A secure conversation can still be exposed by an insecure reset route or a compromised calendar invitation.

The Anonymity Playbook returns to this seam: the cryptography often holds while two identities are joined by a habit, account, or trusted route. TA419 used that seam twice. The lure borrowed a professional identity, and the relay borrowed Microsoft’s working login. The countermeasure has to separate both joins.

There is no perfect procedure. Attackers can compromise real accounts. Contact lists can become stale. A determined operator may call the office and imitate urgency. Passkeys can be undermined by weak recovery or a hostile endpoint. The aim is to force the attacker across several boundaries that fail differently, then leave evidence when one is crossed.

That is what “expensive to watch” means in practice. The target does not become unreachable. The operator has to steal or convincingly imitate a known channel, defeat an origin-bound sign-in, survive identity monitoring, and outrun a rehearsed revocation process. Each layer buys time and raises cost.

The reassuring moment needs a new meaning

The dangerous moment in this campaign was ordinary. Microsoft accepted the sign-in. The extra factor completed. The page behaved as if a protected document sat on the other side. Years of security advice have trained people to treat those events as reassurance.

They prove less than we want. A working password proves that someone supplied the right secret. A completed code proves that someone supplied the current code. A successful session proves that the service accepted the exchange. The browser’s route and the sender’s identity remain separate claims unless the system binds them.

TA419’s reported campaign combined patient social engineering with that technical relay. It started with a harmless conversation, waited for the target to answer, and then moved through familiar cloud furniture. The group did not need to make Microsoft fail. It needed Microsoft to work through the attacker’s path.

As of 5 October 2026, no public source cited here establishes how many accounts, if any, were compromised by these specific lures. That uncertainty belongs in the account. It does not weaken the controls. People in targeted policy, research, legal, defence, and journalism circles should verify unexpected professional outreach through an independent route, open shared services directly, and move sensitive accounts to phishing-resistant authentication.

Teams should prepare for the miss. Revoke sessions, inspect authentication and mailbox state, preserve the evidence, and warn the people whose trust may be used next. A password reset by itself closes yesterday’s secret while a stolen session may still be walking through today’s account.

The old lesson was to look for a fake login. The better lesson is to make the wrong site unable to complete the right login. Let the browser and authenticator check the origin. Let a second channel check the person. Let the incident plan cut off the session when both checks fail.

If you want more plain-English analysis without a daily panic feed, join the newsletter. It is one email per month.

Sources