Your Users Have Passkeys and Still Got Breached: The Pass-the-Cookie Gap in Phishing-Resistant MFA

Passkeys are among the strongest MFA you can roll out, and we have made the case before for treating phishing-resistant methods as the goal. Few organizations are mature enough to have deployed them broadly yet, but here is the uncomfortable part for the ones that have: a user protected by a YubiKey or passkey can still be fully compromised in Microsoft 365. We have seen it firsthand. One organization we consulted with wired $530,000 to a fraudulent bank account after multiple users were compromised, every one of them behind strong MFA. This post walks through how that happens and the native Microsoft 365 protections that close the gap.

What is the attack, in one sentence?#

It starts with a pass-the-cookie attack, also called cookie hijacking. Most websites store a session cookie when a user signs in, and Microsoft is no exception. Microsoft's default session lifetime is one hour, after which continuous access evaluation (opens in new tab) can re-evaluate and extend the session under certain conditions. Cookie hijacking has existed for years across every kind of site; what follows is how it plays out specifically against a Microsoft account protected by phishing-resistant MFA.

Stage one: the initial compromise#

The setup, working through the diagram:

• Assume the organization has done the right thing and set users up with phishing-resistant MFA. Our example user logs into Microsoft with a YubiKey.
• That user can still reach their Microsoft account from a personal device. That device is not managed by the MSP and carries the usual weaknesses: out-of-date hardware, missing patches, no antivirus or substandard antivirus.

A note before going further: the personal-device framing does not mean this is impossible on a managed machine. The likelihood is simply higher on personal devices.

• When the user signs in, they authenticate with the YubiKey and the session cookie lands in the browser.
• The attacker's method for initial access varies, but a popular one is a malicious link in email. Say the company uses Workday for HR and the attacker sends an automated-looking message: "We need you to approve Jane's time-off request, click this link." After the click, malware deploys to the device.
• With the malware running, the attacker remotely extracts cookies from a browser like Chrome. Taking the Microsoft session cookie, they insert it into a browser on their own device and refresh the page to sign in as the user automatically. The user is now compromised, and the passkey was never challenged, because authentication already happened on the victim's machine.

Stage two: locking in persistence#

The stolen session token is good for only an hour, and CAE is likely to terminate it once it sees a new IP. The attacker knows this and moves to keep access:

• Join a device to the tenant so it appears to be a trusted device on the network
• Add a secondary MFA method so they can re-authenticate and keep the session alive

From there the attacker's next moves depend on the goal. In this case the objective was moving money, which meant compromising additional users or running reconnaissance to find who handles payments.

Stage three: moving the money#

With a plan in place, the attacker cleans the inbox to hide the initial attack and creates inbox rules to stay invisible, often correlated to the additional users they intend to target. Those rules quietly move messages to archive or mark them read, so the campaign runs without the legitimate user noticing.

Then comes the payload: the attacker reaches out to multiple contacts claiming a supplier updated their bank details for regular ACH payments, collecting the change by email or through a fake "update" page. The money goes to the fraudulent account.

Stage by stage: how Microsoft 365 closes each gap#

Now walk the same attack again with the defenses in place. Keep in mind that most of these are not on by default.

Lock down the device, not just the login#

• Passkeys already give us a strong MFA method, so authentication is well protected.
• Users should be prevented from accessing corporate data on personal devices. Where that is not feasible, require the device to be enrolled in Intune with baseline requirements (minimum OS, AV installed, and so on), which sharply reduces the chance of malware in the first place. Requiring device compliance through Conditional Access adds the decisive layer: a session token replayed from the attacker's own device fails the compliance check and is blocked.

Shorten or bind the session#

• You can technically enforce non-persistent browser sessions (opens in new tab) through Conditional Access, but booting users every hour earns you frustrated tickets fast. There is a better, lower-friction policy below.

Catch the malicious email and the malicious file#

• Defender for Office 365 has native phishing and link protections (opens in new tab) that can catch the malicious email or attachment on the way in. Real-time click protection can block a malicious link even if the user clicks it.

• Windows Defender can block the malicious executable from landing if the link is accessed. Devices can be onboarded to Microsoft Defender (opens in new tab) and AV policies configured in Intune (opens in new tab), both included if you are on Business Premium.

Bind the session to a trusted location with strict CAE#

• The most restrictive defense against pass-the-cookie when a device is compromised is strict continuous access evaluation enforcement in a Conditional Access policy (opens in new tab). This requires configuring trusted locations in Entra. Strict CAE takes evaluation a step further: if the user is not at a trusted IP, the session terminates. An attacker replaying the token from elsewhere has a different IP and cannot use it.

• Microsoft also has a setting in preview, Require token protection for sign-in sessions (opens in new tab), which as of June 2024 does not yet support web cookies but would, once it does, defend against this attack without requiring trusted locations, which are hard to configure in most organizations.

Let identity protection flag the anomaly#

• Outside the session itself, Entra's native Identity Protection (opens in new tab) may flag the new session as suspicious based on its IP. With Entra ID P2, Identity Protection policies can automatically block the user, and this also feeds CAE's native protections.

Current CAE near real-time detections:

Block the persistence moves#

• To counter the device join, add a Conditional Access policy that requires MFA to register a device in Entra. Because this user uses passkeys, the attacker cannot fulfill a fresh MFA prompt to join the device. To block a second MFA method being added, use the same User Actions (opens in new tab) setting in Conditional Access to require a trusted IP, trusted device, and/or another MFA fulfillment.

• Configure the authentication methods policy (opens in new tab) to prevent other MFA forms from being added. If only FIDO2 keys are allowed, the attacker cannot add Authenticator, OTP, or SMS/email as a second factor. And with passkeys, the attacker never harvested the username and password in the first place, since the session token did not contain them; a man-in-the-middle attack would have, which is the difference.

Detect the inbox rules and the campaign#

• Many of us have set a transport rule in Exchange Online to block automatic forwarding to external domains, a hardening recommendation for years. It does not cover the evasion tactics here, where rules mark messages read or move them to archive. Defender for Office 365 has native alerting for suspicious inbox rules (opens in new tab). These alerts go to tenant admins by default; route them into your ticketing system for investigation instead.

• Defender for Cloud Apps also has native detection for suspicious inbox rules (opens in new tab), configurable with a Business Premium license.

• Because the campaign may originate from an internal, legitimate user, native email protections may not catch the attacker emailing colleagues. This is where security awareness training carries weight: anything touching financial information should register as alarming, and that instinct is reinforced through automated and manual training.

The takeaway#

Phishing-resistant MFA is necessary and not sufficient. It protects the moment of authentication and does nothing for the session token afterward, so the defenses that matter against pass-the-cookie are the ones that bind the session to a known device and location, limit what a compromised account can do next, and alert you when the quiet persistence work begins. Business Premium remains a capable platform for stopping these attacks, provided the controls are actually turned on.