It’s common for a healthcare organization to discover a compromised Microsoft 365 account do exactly what they think they should: reset the password, force a re-login and confirm MFA is enabled. But in some cases, the attacker may still be accessing the mailbox, because the compromise never involved a password in the first place.

That scenario has become common enough that OAuth, a technical standard most clinical and administrative staff have never heard of, now sits at the center of how attackers get into healthcare email. Understanding what it is explains why some intrusions survive the standard response.

 

What OAuth actually is

Open authorization, shortened to OAuth, is a framework that lets one application access data in another without ever handling the user's password. As IBM explains, it is the mechanism behind every "Sign in with Google" button and every prompt asking whether an app can access your calendar or files. The user grants permission, and the application receives an access token instead of credentials.

A token is a piece of information that specifies exactly what an application is allowed to reach. The permissions attached to it are called scopes, so a token might be scoped to read a mailbox but not send from it. There is also a refresh token, which lets an application obtain a new access token once the original expires without asking the user to approve anything again.

The design is sound, and the security benefit is real, since a service that never receives your password cannot leak it. What attackers have figured out is that a token, once granted, is just as useful as a password and considerably harder to take away.

Read more: What is MFA? | What is a phishing attack?

 

Why attackers target tokens instead of passwords

Multi-factor authentication was built to make a stolen password useless. Token-based attacks route around that entirely by getting the victim to authorize access rather than surrender credentials.

Microsoft's Entra security team put the problem plainly, noting that with these attacks "the user's authentication method doesn't matter." Once someone grants consent to an application, that application can make requests on their behalf using whatever permissions were delegated, with no credentials involved at any point. Microsoft also flagged that because this attack is less familiar than credential phishing, users tend to be less alert to it.

The persistence is what makes it serious. A password reset invalidates a stolen password. It does not necessarily revoke a token that was legitimately issued, which means an attacker can retain access through the exact remediation steps an organization takes to lock them out.

 

OAuth consent phishing

The first variant works by getting a user to approve a malicious application. The attacker registers an app, often with a name that looks like a familiar service, then sends a link prompting the target to grant it access. The consent screen the victim sees is genuine, because the request itself is genuine. Only the application behind it is hostile.

Microsoft's guidance describes how a data-stealing app, once consented to, gives an attacker long-lasting and hard-to-detect access to an environment. No malware is installed, and no fake login page appears, so tools scanning for either find nothing.

 

Device code phishing

The second variant abuses a legitimate convenience feature. The OAuth device authorization flow exists so devices that are awkward to type on, such as smart TVs and conference room equipment, can sign in by having the user enter a short code elsewhere.

Attackers trigger a real device code request from Microsoft, then send a message presenting that code as a verification step or a document access code. The victim visits the genuine microsoft.com/devicelogin page, enters the code, completes their MFA challenge, and authorizes the attacker's device. BleepingComputer documented a sustained wave of these campaigns against Microsoft 365 accounts, with both financially motivated and state-aligned groups adopting the technique. Because every step happens on real Microsoft infrastructure, there is nothing visually wrong for the user to notice.

Healthcare appeared among the sectors hit in a large device code campaign tracked through early 2026, alongside construction, manufacturing, financial services, legal, and government.

Read also: Device code phishing: the new face of Microsoft 365 account takeover in healthcare

 

Why this lands harder in healthcare

The scopes attached to a Microsoft 365 token typically cover mailbox, files, calendar, and contacts. In a hospital or clinic, that is not a generic productivity bundle. It is referral correspondence, lab results, insurance documentation, and patient scheduling, which means an OAuth token granted to an attacker is a token granted to protected health information.

The regulatory consequence follows directly. Under HIPAA, unauthorized access to PHI is presumed to be a reportable breach unless the organization can demonstrate a low probability of compromise. An attacker holding a valid token with mailbox scope had access, and determining what they actually reached requires forensic work that the token's own legitimacy makes harder, since the activity appears in logs as an authorized application doing what it was permitted to do.

There is an operational problem underneath the compliance one. Most healthcare incident response plans assume a password reset ends the intrusion. Against a token-based compromise, an organization can complete every step of its documented playbook and still have an attacker inside.

 

What actually reduces the risk

In June 2025, Microsoft announced it was changing their default settings to block legacy authentication protocols and require administrator consent before third-party applications can be granted access, with the rollout completing that August. For organizations that had left user consent enabled, that single change removes the ability of any staff member to authorize an unknown app on their own.

Three further steps close most of what remains. Restricting or disabling the device code authorization flow in Microsoft Entra ID eliminates that attack path for organizations with no legitimate need for it. Auditing which applications already hold consent in the tenant surfaces anything granted before the controls tightened. Revoking refresh tokens, rather than only resetting passwords, becomes a required step in any account compromise response.

Each of those operates after a lure has already reached someone. Removing the message earlier is what prevents the authorization request from ever being seen. Paubox's 2025 Healthcare Email Security Report found employees report only 5% of known phishing attempts to their security teams, and Paubox's 2026 Healthcare Email Security Report tracked a 47% increase in attacks evading native email defenses in 2025. Because a device code lure points to a legitimate Microsoft URL and carries no malicious attachment, filters matching known-bad content have little to catch. Paubox Inbound Email Security analyzes sender behavior, message intent, and contextual signals instead, which is the approach that flags a message whose destination is entirely legitimate but whose purpose is not.

Learn more: Paubox Inbound Email Security

 

In the news

The risk does not stop at lures sent to staff. In August 2025, attackers tracked as UNC6395 stole OAuth tokens belonging to Drift, an AI chat application made by the sales software company Salesloft, then used those tokens to reach the connected systems of its customers. Google Threat Intelligence Group and Mandiant documented the campaign, which ran from August 8 to 18 and affected more than 700 organizations. Because Drift held tokens authorizing it to connect to Salesforce, Google Workspace, and Slack, stealing those tokens handed attackers the same access without a single password or phishing message involved. Salesforce revoked every Drift token and pulled the application from its marketplace, and the FBI issued a cybersecurity advisory the following month listing indicators of compromise. FINRA published its own alert to member firms, urging them to disconnect the integration and rotate exposed credentials.

For healthcare, the lesson sits with vendors. A business associate granted an OAuth token to a covered entity's environment holds standing access to whatever that token permits, and a breach at the vendor becomes a breach of that access. Auditing which third-party applications hold consent in a tenant guards against more than an app someone approved by mistake. It also covers the legitimate integrations that could be compromised somewhere else entirely.

 

FAQs

What is an OAuth token?

A token is a credential issued to an application that specifies what data it can access, granted after a user approves the request. Access tokens expire after a set period, while refresh tokens let an application obtain new ones without asking the user again, which is why a stolen token can outlast the session it came from.

 

Why doesn't MFA protect against OAuth attacks?

The victim completes the MFA challenge themselves as part of authorizing the attacker's application, so the second factor works exactly as designed and still results in access being granted. Microsoft's own guidance notes that the user's authentication method makes no difference to this class of attack.

 

Does resetting a password stop an OAuth compromise?

Not by itself. Tokens issued through a legitimate consent grant can survive a password change, which means revoking active tokens and reviewing consented applications has to be part of the response rather than an optional extra step.

 

What does an OAuth compromise mean under HIPAA?

A token scoped to a mailbox or file storage in a healthcare environment gives access to protected health information, and unauthorized access to PHI is presumed reportable unless the organization can show a low probability of compromise. The investigation is complicated by the fact that the attacker's activity appears in logs as authorized use.

 

What is the most effective control against these attacks?

Requiring administrator consent for third-party applications removes the ability of individual staff to authorize an unknown app, and restricting the device code flow closes the other main path. Pairing those with email filtering that stops the lure before it arrives addresses the problem at both ends.