Device Code Phishing: The Modern Threat That Bypasses MFA
You have multi-factor authentication (MFA) enabled across your cloud accounts, so you’re safe from phishing, right? Not necessarily. A sophisticated and increasingly common attack vector known as device code phishing is proving highly effective at tricking users and gaining persistent access to sensitive corporate data, even when MFA is active.
This attack method cleverly abuses a legitimate feature called the “device authorization grant flow,” which is designed to let users sign into apps on devices with limited input capabilities, like smart TVs or IoT devices. Hackers have repurposed this flow to target users on standard computers, turning a convenience feature into a dangerous security backdoor.
How Device Code Phishing Works
The attack is deceptive because it uses legitimate login infrastructure from major providers like Microsoft and Google against you. Here’s a step-by-step breakdown of how a typical attack unfolds:
- The Bait: An attacker sends a standard phishing email, perhaps with a link to a “document” that requires your credentials to view.
- The Code: When the user clicks the link, they are taken to a malicious application that immediately initiates a real login process with Microsoft 365 or Google Workspace. Instead of a password field, the user is presented with a short, one-time device code and instructed to go to a legitimate URL, such as microsoft.com/link or google.com/device.
- The Switch: The user, believing this is a legitimate security step, opens a new browser tab or uses their phone to visit the specified URL. They enter the code provided by the attacker’s application.
- The Deceptive Consent: After entering the code, the user is presented with a real, official consent screen from Microsoft or Google. This screen asks for permission to grant the attacker’s (maliciously named) application access to their account. Because the URL is legitimate and the interface is familiar, many users approve the request without a second thought.
- The Breach: The moment the user grants consent, the attacker’s application receives powerful access tokens. These tokens act as a long-term key to the user’s account, allowing the attacker to access emails, read SharePoint and OneDrive files, and exfiltrate data—all while completely bypassing MFA.
The core of this attack is tricking the user into authorizing a malicious application, not stealing their password. Once authorized, the attacker has ongoing access until the token is revoked.
Microsoft 365 vs. Google Workspace: A Crucial Security Difference
While the attack flow is similar for both platforms, the user experience during the final consent step reveals a significant difference in security design.
Microsoft 365 / Azure AD Scenario
When a user approves a device code flow for a Microsoft account, the consent screen is often generic. It displays the name of the application seeking access and the permissions it’s requesting. However, it fails to provide critical context, such as what kind of device is being authorized or where the request originated. An attacker can name their app something innocuous like “Office365 Documents” to lull the user into a false sense of security. This lack of specific information makes it dangerously easy for an employee to unknowingly approve a malicious request.
Google Workspace Scenario
Google’s approach provides a much stronger layer of user-facing security. When a user enters a device code to authorize an application, the Google consent screen explicitly warns them that they are signing into a “new device” and, crucially, often specifies the device’s operating system (e.g., “Linux”).
For a typical corporate user on a Windows or Mac computer, seeing a prompt to authorize a “Linux” device is a major red flag. This single piece of context is often enough to make a user pause and recognize that something is wrong, effectively stopping the attack in its tracks.
How to Protect Your Organization from Device Code Phishing
Defending against this threat requires a multi-layered approach that combines technical controls with user education.
- Educate Your Users: Train employees to be suspicious of any login process that asks them to enter a code on a separate device, especially if it was initiated unexpectedly. Teach them to scrutinize every application consent screen, paying close attention to the app’s name and the permissions it requests.
- Implement Strict Conditional Access Policies: For organizations using Azure AD, Conditional Access is a powerful tool. Configure policies to block or limit sign-ins from unmanaged or non-compliant devices. Because the attacker’s machine is unmanaged, these policies can often prevent the malicious app from successfully obtaining an access token, even if the user grants consent.
- Restrict User Consent to Applications: One of the most effective technical controls is to change the default settings to prevent non-administrator users from consenting to new third-party applications. This forces any new application to be vetted and approved by IT, drastically reducing the attack surface.
- Monitor and Audit: Regularly review your cloud environment for unusual sign-ins and newly consented applications. Look for suspicious app names, unusual permission grants, or sign-in activity from unexpected locations or device types.
Device code phishing is a testament to how attackers are constantly evolving their methods to bypass even robust security measures like MFA. By understanding how the attack works and implementing a combination of user training and stringent technical policies, you can significantly reduce your organization’s risk.
Source: https://www.bleepingcomputer.com/news/security/oauth-device-code-phishing-azure-vs-google-compared/
