Another device code phishing campaign that abuses OAuth device registration to bypass multifactor authentication login protections has been discovered.

Researchers at KnowBe4 say the campaign is largely targeting North American businesses and professionals by tricking unwitting employees into clicking a link in an email from a threat actor.

The message purports to be about a corporate electronic funds payment, a document about salary bonuses, a voicemail, or contains some other lure. It also includes a code for ‘Secure Authorization’ that the user is asked to enter when they click on the link, which takes them to a real Microsoft Office 365 login page.

Victims think the message is legitimate, because the login page is legitimate, so enter the code. But unknown to the victim, it’s actually the code for a device controlled by the threat actor. What the victim has done is issued an OAuth token granting the hacker’s device access to their Microsoft account. From there, the hacker has access to everything the account allows the employee to use.

Note that this isn’t about credential theft, although if the attacker wants credentials, they can be stolen. It’s about stealing the victim’s OAuth access and refresh tokens for persistent access to their Microsoft account, including to applications such as Outlook, Teams, and OneDrive. 

It works because certain sites, including Microsoft 365, use the OAuth 2.0 Device Authorization Grant process to allow the adding of devices to an account. It’s similar to the way a home owner adds a smart TV to Netflix.

KnowBe4 calls it a novel attack, although Johannes Ullrich, dean of research at the SANS Institute, called it “old new.”

According to Trend Micro, a threat actor dubbed Pawn Storm has been leveraging OAuth in phishing campaigns since as far back as 2015. And in 2020, Microsoft warned users about what it called ‘consent phishing,’ in which threat actors seek permission for an attacker-controlled app to access data by installing an OAuth 2.0 provider. Ullrich admitted a SANS employee fell for one of these phishing emails.

The main defense against the latest version of this attack is to restrict the applications users are allowed to connect to their account, he said. Microsoft provides enterprise administrators with the ability to allowlist specific applications that the user may authorize via OAuth.

Roger Grimes, CISO advisor at KnowBe4, wrote about device code phishing in 2020. In an interview Thursday, he said what’s distinctive about the latest tactic is that the victim logs into a valid domain, and the goal is to get the user’s device token.

“The user’s not doing anything wrong,” in the sense that they are logging into a legitimate portal, he said. “If they look at the URL they’re logging into, it’s microsoft.com. But the attacker has pre-registered their device to get the code for [the victim] to verify.”

David Shipley, head of Canadian security awareness training provider Beauceron Security, said OAuth device code attacks have been gaining steam since 2024. “It’s the natural evolutionary response to improvements in account security, particularly MFA”, he said. 

The easiest defense is to turn off the ability to add extra login devices to Office 365, unless it’s needed, he said.

In addition, employees should also be continuously educated about the risks of unusual login requests, even if they come from a familiar system.

“The value of teaching people about new social engineering techniques like this, and doing phishing simulations based on these kinds of attack, is it gets people used to reporting them, which will help when real attacks are happening,” he added.

Cory Michal, CSO at AppOmni, said attacks often leverage OAuth tokens and service/integration identities because they are a blind spot for many organizations that have invested heavily in identity hardening and multifactor authentication.

“OAuth tokens often operate as bearer credentials,” he noted. “If an attacker obtains them, they can be used as a single-factor access method to act as the integration without triggering an interactive login or MFA challenge, and the activity can blend into normal API/integration patterns. In other words, strong MFA enforcement can coexist with a persistent exposure if non-human identities and OAuth token hygiene aren’t governed and monitored with the same rigor.” 

He said that IT leaders need to go beyond classic third-party vendor reviews, and actually inventory and audit the integrations running in their SaaS environments, determining which apps are connected, what OAuth scopes/permissions they have, and whether they’re still needed. 

 “Most teams have far more integrations than they realize, and many retain broad privileges long after the original business need,” he pointed out. 

“In parallel, we should raise the security bar for any SaaS vendor we rely on, [with] clear requirements around token security, logging, incident response, and secure integration patterns, and make sure our own tenant configurations and monitoring are hardened so integration activity is least-privilege, observable, and quickly containable when something upstream is compromised,” Michal added.

Grimes said that users can be educated to check how many devices are authorized to access their Microsoft, Google, and other login accounts. They should also be continually warned to be suspicious of email links that go to a login page.

In a blog about device code phishing, he noted that Microsoft Entra administrators can disable “device code flow” in their conditional access policies. This disables all users of device codes for Entra, not just malicious users. This means users will have to log in and provide more information than just a device code, but it will better protect an IT environment from this type of phishing attack.

This article originally appeared on CSOonline.