Hackers gain persistent access to employee accounts by tricking unsuspecting staff into registering the attacker’s device and generating OAuth tokens.
A new device code phishing scheme has emerged, exploiting OAuth device registration to circumvent multi-factor authentication (MFA) login safeguards.
KnowBe4 researchers report that this particular campaign predominantly targets North American businesses and professionals. It works by duping unsuspecting employees into clicking a malicious link within an email sent by an attacker.
The email often masquerades as a notification about a corporate electronic funds payment, a salary bonus document, a voicemail alert, or another enticing lure. Crucially, it provides a ‘Secure Authorization’ code, which the user is prompted to enter after clicking the link that directs them to an authentic Microsoft Office 365 login page.
Believing the message to be legitimate due to the authentic login page, victims readily input the code. Unbeknownst to them, this code is for a device controlled by the threat actor. By doing so, the victim inadvertently issues an OAuth token, granting the hacker’s device full access to their Microsoft account. This access then allows the hacker to utilize any application or service the employee’s account is authorized for.
It’s important to note that this attack primarily focuses on stealing OAuth access and refresh tokens for continuous access to a Microsoft account, including apps like Outlook, Teams, and OneDrive, rather than just stealing credentials, though that is also possible.
The vulnerability arises because certain platforms, including Microsoft 365, utilize the OAuth 2.0 Device Authorization Grant process for adding new devices to an account, much like connecting a smart TV to a streaming service.
While KnowBe4 refers to this as a novel attack, Johannes Ullrich, the SANS Institute’s dean of research, described it as “old new.”
Trend Micro previously reported that a threat group known as Pawn Storm has been exploiting OAuth in phishing campaigns since 2015. Furthermore, in 2020, Microsoft issued warnings about “consent phishing,” where attackers trick users into granting permissions for an attacker-controlled app to access their data via an OAuth 2.0 provider. Ullrich himself confirmed that a SANS employee had fallen victim to one such phishing attempt.
Ullrich emphasized that the primary defense against this updated attack method involves limiting the applications users are permitted to link to their accounts. Microsoft offers enterprise administrators the capability to ‘allowlist’ specific applications that users can authorize through OAuth.
Roger Grimes, CISO advisor at KnowBe4, addressed device code phishing in a 2020 blog post. In a recent interview on Thursday, he highlighted that the unique aspect of this latest technique is that victims authenticate on a legitimate domain, with the attacker’s objective being to acquire the user’s device token.
He explained that “the user isn’t doing anything wrong” in the sense that they are logging into a genuine portal. “If they check the URL they’re logging into, it says microsoft.com. However, the attacker has already pre-registered their device to obtain the code for [the victim] to verify.”
David Shipley, who leads Canadian security awareness training provider Beauceron Security, observed that OAuth device code attacks have been gaining traction since 2024. He stated, “It represents the natural evolutionary response to enhancements in account security, particularly MFA.”
He suggested that the simplest defense is to disable the option for adding additional login devices to Office 365, unless absolutely necessary.
Furthermore, employees should receive continuous training on the dangers of unusual login prompts, even when they appear to originate from familiar systems.
He added, “The benefit of educating people about emerging social engineering methods like this, and conducting phishing simulations based on such attacks, is that it familiarizes them with reporting these incidents, which will be crucial when actual attacks occur.”
Cory Michal, CSO at AppOmni, observed that attacks frequently exploit OAuth tokens and service/integration identities. He notes these are often overlooked areas for organizations that have heavily invested in identity hardening and multifactor authentication.
He pointed out that “OAuth tokens frequently function as bearer credentials.” “If an attacker acquires them, they can be used as a single-factor access mechanism to impersonate the integration without prompting an interactive login or MFA challenge, and this activity can blend seamlessly with typical API/integration patterns. Essentially, robust MFA enforcement can exist alongside a persistent vulnerability if non-human identities and OAuth token management aren’t governed and monitored with comparable strictness.”
Michal stated that IT leaders must move beyond standard third-party vendor assessments and actively inventory and audit the integrations operating within their SaaS environments. This includes identifying connected applications, understanding their OAuth scopes/permissions, and verifying if they are still required.
He further highlighted that “Most teams possess far more integrations than they realize, and many maintain broad privileges long after their initial business purpose has concluded.”
Michal also advised, “Concurrently, we should elevate the security standards for every SaaS vendor we rely on, establishing clear demands for token security, logging, incident response, and secure integration patterns. We must also ensure our own tenant configurations and monitoring are robust, so integration activity adheres to least-privilege principles, is observable, and can be quickly contained if an upstream component is compromised.”
Grimes suggested that users could be trained to regularly check the number of authorized devices linked to their Microsoft, Google, and other login accounts. They should also receive ongoing warnings about suspicious email links that lead to login pages.
In a blog post detailing device code phishing, he explained that Microsoft Entra administrators have the option to deactivate “device code flow” within their conditional access policies. While this disables device code usage for all Entra users, not just malicious ones, it compels users to log in with more than just a device code, thus enhancing protection for an IT environment against this specific type of phishing attack.
This article was first published on CSOonline.
