Device code authentication was designed to provide a seamless authentication experience for users when it comes to devices that lack a standard login interface, such as smart TVs, gaming consoles, or IoT devices. However, this flow does not inherently tie authentication to a specific device, making it an attractive target for attackers.

Here’s how device code phishing works. By socially engineering victims into entering a device code on a legitimate Microsoft authentication page (microsoft.com/devicelogin), attackers can extract access and refresh tokens without needing to interact with a victim’s device directly. Once obtained, refresh tokens allow long-term access to accounts, bypassing multi-factor authentication (MFA) requirements for extended periods.

 

The exploitation phase

The exploitation phase of device code phishing begins with an attacker generating a device code, typically using a tool like TokenTactics.

Import-Module C:\Tools\TokenTactics\TokenTactics.psd1
Get-AzureToken -Client Graph
user_code : EL804DT07

A phishing lure is then crafted to trick a victim into entering this code on a legitimate Microsoft authentication page (microsoft.com/devicelogin). The lure often takes the form of an email impersonating IT support, a Microsoft Teams meeting invitation, or another seemingly legitimate request. It can be as simple as the following:

Company Call at 3PM
Your Code is: EL804DT07
https://www.microsoft.com/devicelogin?meetup-join/14%3ameeting_dGVhbXNtZWV0aW5n

Once the victim navigates to the authentication page and enters the provided code, they are prompted to authenticate using their actual credentials and MFA. Since the authentication request originates from a legitimate Microsoft endpoint, security tools and users alike may not recognize it as a phishing attempt. Upon successful authentication, Microsoft issues an access token (valid for approximately an hour) and a refresh token (which can persist for up to 90 days).

The attacker intercepts these tokens, which is built into TokenTactics, and can immediately use them to gain unauthorized access to the victim’s Microsoft 365 environment, including Outlook, SharePoint, and Teams or use tooling like RoadTools to find what can be accessed.

RefreshTo-SubstrateToken -refreshToken $response.refresh_token -domain domain.tld -Device WindowsPC -Browser Edge
Open-OWAMailboxInBrowser -AccessToken $SubstrateToken.access_token -Device Windows -Browser Chrome

More advanced attackers will refresh the token and use tools like Roadrecon or AzureHound to map out the Azure Active Directory that can then be abused to maintain long-term access, pivot within an organization, and escalate privileges. In other words, they can effectively bypass continuous MFA challenges.

Additionally, conditional access policies can often be circumvented by spoofing device types (e.g., presenting as an iPhone or Android) and using residential proxy services to blend in with normal user behavior. This method not only evades traditional phishing detection but also allows attackers to maintain persistent, stealthy access to a victim’s accounts without requiring further credential harvesting. It is quieter than using Evilginx. Furthermore, dynamic device code phishing allows less experienced attackers to craft simpler pretexts with powerful results.

 

The rising popularity of device code phishing

Device code phishing is poised to grow in popularity among attackers for several reasons. First, as organizations become more aware of traditional phishing techniques (e.g., fake login pages and credential stuffing), adversaries must find new ways to bypass existing security controls. Although device code phishing is a relatively old technique (with Black Hills https://www.blackhillsinfosec.com/dynamic-device-code-phishing/ releasing its premier blog on dynamic device code phishing in 2023), it still offers a stealthier alternative. This is because it does not require victims to input credentials into a fake login page, which can often be detected by trained users or security tools. Instead, users are prompted to enter a seemingly legitimate code into a well-known Microsoft authentication portal, making this much harder to identify as a phishing attempt.

When Black Hills revealed the technique publicly, many clients rushed to configure conditional access policies to circumvent it. However, as time has progressed, I have been seeing it crop up more and more in both red and purple team engagements across industries. The attack is often successful, as it almost uniquely, solely relies on user behavior. Many employees, particularly those embroiled in zero trust environments, have grown accustomed to authentication prompts for collaborative tools like Microsoft Teams, making them less likely to question a request for device code authentication. This is exacerbated by the fact that device code phishing can be executed in various ways, including via email, SMS, phone call, or even within Teams or external service chats, further increasing the likelihood of success. One of the key dampeners of attacker success is that codes are only valid for a small amount of time. This gave rise to the “dynamic device code” attack, which uses additional systems to generate new codes every 30 seconds. This does limit the vectors for attack, but ultimately, it does not discourage advanced attackers.

Unlike traditional credential harvest phishing, which requires victims to visit a phishing site before an attacker can collect credentials, device code phishing only requires victims to input a code into a legitimate Microsoft page—something they are conditioned to do in legitimate authentication flows. The added advantage of refresh tokens means attackers can maintain persistent access to victim accounts, even after initial authentication. However, this is rare these days.

Given all of these factors, we can expect device code phishing to be increasingly weaponized by a range of threat actors for access to cloud-based environments.

 

Protecting against device code phishing

Recently, Bugcrowd published a blog on some of the overall strategies for protecting against general MFA bypass techniques. Let’s look at five specific steps organizations can take to build a multilayered security strategy that protects against device code phishing.

  1. Restrict or disable device code authentication where possible: Organizations should assess whether device code authentication is necessary within their environments. In many cases, this authentication flow can be disabled entirely, or its use can be restricted to specific managed devices. If device code authentication must be enabled, organizations should enforce strict conditional access policies to limit access to compliant and trusted endpoints.
  2. Implement conditional access policies and risk-based authentication: Microsoft Entra ID (formerly Azure AD) provides several controls that can mitigate the risk of device code phishing. Since device code phishing often originates from attacker-controlled infrastructure, enforcing strict authentication conditions can significantly reduce the likelihood of a successful attack. Conditional access policies should be configured to enforce the following:
    • Device compliance requirements (e.g., requiring Intune-enrolled devices)
    • Geolocation restrictions to block access from unexpected regions
    • Application control policies to prevent access from unauthorized applications or non-corporate browsers
    • Risk-based authentication that prompts for additional verification when sign-in behavior deviates from a user’s normal patterns.
  3. Enhance detection and response to token theft: Security teams should monitor authentication logs for anomalous behaviors associated with device code phishing. Organizations should leverage Microsoft’s Identity Protection features to generate alerts for risk-based sign-ins and enforce automatic token revocation when suspicious activity is detected. Security information and event management (SIEM) tools should be configured to correlate these events with other anomalous behaviors, such as new MFA enrollments or privilege escalation attempts. Key indicators include the following:
    • Sign-ins from unexpected IP addresses or locations immediately following device code authentication
    • Sign-ins using token-based authentication without a preceding interactive login
    • Multiple device code sign-ins from different IPs in a short timeframe.
  4. Strengthen user awareness and phishing training: User training remains one of the most effective defenses against social engineering attacks. Organizations should also incorporate device code phishing scenarios into red team exercises and simulated phishing campaigns to measure employee susceptibility and improve overall resilience. Employees should be educated on the following:
    • Recognizing phishing attempts that ask for authentication outside of expected workflows
    • Verifying unusual authentication requests with IT before proceeding
    • Understanding that MFA does not protect against all phishing techniques, especially those targeting authentication tokens.
  5. Harden email security and threat intelligence capabilities: Security teams should stay informed of emerging attack techniques through cyber threat intelligence feeds and adjust defenses accordingly. Since many device code phishing campaigns begin with an initial phishing email, organizations should deploy advanced email security measures to detect and block such attempts. Although this does not cover all social engineering vectors, email security should be locked down. Hardening includes the following:
    • Implementing DMARC, DKIM, and SPF to reduce spoofed emails
    • Deploying email filtering solutions that analyze links and attachments for phishing indicators
    • Using machine learning-based anomaly detection to flag suspicious communications.

Mitigating device code phishing requires a multilayered security strategy that includes authentication policy restrictions, proactive detection mechanisms, and ongoing user education. With these best practices in mind, organizations can decrease their risk of a breach via device code phishing methods. 

Tags: