It has certainly been very encouraging to see stronger multi-factor authentication gain broader adoption. However, as often happens in our industry, this progress carries a cost. In this case, it has triggered the familiar cycle of adaptation and counter-adaptation that defines our exhausting reality as cybersecurity professionals.
Around 2017, adversary-in-the-middle (AiTM) phishing kits emerged to counter MFA methods that disrupted traditional credential phishing – like push notifications and number matching. Our response was to promote more effective mitigations such as FIDO2 security keys and Entra ID's token protection, which in turn forced adversaries to adapt once more. But rather than continuing to focus on complex bypass mechanisms, some have shifted to a methodology that uses social engineering to coerce users into authenticating on their behalf through abuse of a legitimate authentication flow.
Enter device code phishing, a technique used to compromise accounts through exploitation of OAuth 2.0 device authorisation grant. It works so well because the process looks completely genuine: users interact with Microsoft's own infrastructure, see familiar URLs, and complete their normal authentication steps (including any configured MFA).
Although first documented in 2020 by Dr. Nestori Syynimaa on his infamous AADInternals blog, the technique has seen increased use over the past six months by threat actors such as Midnight Blizzard. So, despite awareness of its abuse, it remains commonplace for device code authentication to be used by administrators and developers, even when alternative methods are available.
Microsoft’s device code authentication follows the OAuth 2.0 Device Authorization Grant flow (RFC 8628), a standard specifically designed for devices that lack keyboards or have limited input capabilities – such as Teams Phones, smart TVs, and cloud-enabled printers. Instead of authenticating directly on the device, the user is prompted to visit a browser link and to authorise the device by signing it in with valid credentials. The process is clearly illustrated in this diagram from Auth0:
Source: auth0
The authentication process follows this sequence:
1. Device code request: A device or application sends a POST request to Entra ID’s /oauth/device/code endpoint, specifying a client_id (the application requesting access) and resource parameter (the target service)
2. Code generation: Entra ID responds with multiple values:
3. User interaction: The device displays the verification_uri and user_code to the user, who must navigate to the URL on a separate device
4. Authentication: The user enters the user_code, completes their normal sign-in process (including MFA), and authorises the requesting application
5. Token polling: The original device continuously polls Entra ID's /oauth/token endpoint every 5 seconds using the device_code until either authentication completes or the code expires
6. Token issuance: Upon successful authentication, the device receives valid OAuth access and refresh tokens with the same privileges as a standard interactive loginPractically speaking, the 15-minute validity window requires attackers to coordinate their social engineering lure within this relatively short timeframe, but the technique still offers several tactical advantages:
Further to that last point, because attackers receive valid OAuth tokens through Microsoft's legitimate authentication infrastructure, traditional token replay detections and Entra ID's token protection capabilities are ineffective. The tokens are indistinguishable from those generated through legitimate authentication flows.
However, the technique faces operational limitations at scale. Aside from the 15-minute validity window of codes, Microsoft appears to enforce rate limiting mechanisms that restrict device code generation and polling to approximately 50 concurrent operations per public IP address – constraints not faced by AiTM phishing kits.
Starting in mid-January 2025, Volexity identified several social-engineering and spear-phishing campaigns by Russian threat actors aimed at compromising Microsoft 365 accounts. They have assessed with medium confidence that at least one of these campaigns was conducted by CozyLarch (who overlap with DarkHalo, APT29, Midnight Blizzard, CozyDuke), whilst tracking additional activity as UTA0304 and UTA0307.
The first campaign began with a victim being contacted on Signal by an individual purporting to be from the Ukrainian Ministry of Defence. This individual requested that the victim move to another secure chat application called Element. The adversary operated an Element server under the domain sen-comms[.]com, allowing real-time messaging to coordinate the device code phish within the 15-minute validity window.
The email received by the victim was designed to look like a meeting invite for a secure chatroom in the Element server. However, all links in the email were to https://login.microsoftonline.com/common/oauth2/deviceauth (the page used for the device code authentication workflow).
Separate campaigns involved fake Microsoft invitations claiming to be from the US Department of State, targeting users with invitations to join their Microsoft tenant or a Teams chat named "Measuring Influence Operations". These campaigns used redirects to the same authentication workflow URL:
Source: Volexity
A third campaign employed automated device code generation through actor-controlled websites. Victims received emails impersonating European Parliament members that requested meetings, then fake Teams invitations linking to connect-71q.pages[.]dev. This site automatically generated fresh device codes each time it was visited, solving the 15-minute expiry constraint that limits other approaches. The site continuously polled rosejob[.]com to monitor successful authentications and redirect victims to legitimate Teams meetings post-compromise, making the attack appear legitimate.
Amazon's threat intelligence team also identified and disrupted a watering hole campaign conducted by APT29. The actor compromised various legitimate websites and injected JavaScript that redirected approximately 10% of visitors to actor-controlled domains, including findcloudflare[.]com, which mimicked a Cloudflare verification page:
Source: Amazon
The campaign's ultimate target was Microsoft's device code authentication flow. When disrupted, APT29 adapted by migrating infrastructure and switching to server-side redirects.
Microsoft Threat Intelligence Center discovered a Storm-2372 campaign that had been active since August 2024. Targets of this included government and non-governmental organisations, information technology services, defence, telecommunications, health, education, and energy/oil and gas sectors in Europe, North America, Africa, and the Middle East.
The actor's methodology involved initial contact through third-party messaging services including WhatsApp, Signal, and Microsoft Teams. To establish rapport, their messaging impersonated prominent individuals relevant to the target:
Source: Microsoft
This initial contact was followed by meeting invitations sent via email. These lured users into completing device code authentication requests that mimicked familiar messaging services:
Source: Microsoft
Post-compromise, Microsoft observed Storm-2372 using Microsoft Graph to search through compromised account messages using keywords such as username, password, admin, teamviewer, anydesk, credentials, secret, ministry, and gov. This was followed by exfiltration via Microsoft Graph of email messages matching these criteria.
In February 2025, Microsoft noticed a shift to using the specific client ID for Microsoft Authentication Broker in the device code sign-in flow. This enabled the actor to receive a refresh token that could be used to request another token for the device registration service, then register a controlled device within Entra ID. With the same refresh token and the new device identity, they could also obtain a Primary Refresh Token.
On July 23rd, Exploit.in user "sha256sum" advertised the sale of a Golang-based tool intended to automate the execution of device code phishing. This was offered to a single buyer for $1200, or $1500 with included technical assistance. They specifically referenced the Volexity article discussed above as a reference for the technique:
On July 29, without an apparent sale, the user published the deployment instructions and source code for all forum members to download for free:
Note: Machine translated from RU
Unfortunately, at the time of writing the share link had expired so we were unable to assess the source. Initial sale of this tool coincided with the publication of a similar tool on Github just a few days prior. However, according to the second posting, there are some minor differences in sha256sum’s version, including URI structure and command-line parameters. The use of an application registration is also a notable difference, but the deployment instructions don't clarify its purpose.
GraphSpy is one of many tools available to automate device code phishing against Microsoft 365 targets. The tool demonstrates how this technique requires minimal infrastructure as compared to campaigns relying on AiTM frameworks such as Tycoon 2FA and Evilproxy. As well as obtaining access and refresh tokens via device code authentication flow, it also offers functions to abuse the tokens, including management of MFA and OTP methods, OneDrive and SharePoint files, and Outlook and Teams messages.
Installation is straightforward and requires only three steps:
1. Cloning the repo: git clone https://github.com/RedByte1337/GraphSpy && cd GraphSpy
2. Setting up a Python virtual environment: python -m virtualenv env
source env/bin/activate
3. Installing GraphSpy and its dependencies: pip install .
The server can then be started using the command:
graphspy -i 0.0.0.0 -p 8080
This will make the web UI available on port 8080:
Under Authentication > Device Codes, GraphSpy automatically populates the Resource and Client ID fields with common options, but you can also define your own. Selecting “Submit” will generate a device code with the defined parameters, and start polling its status:
Through some means, the target is socially engineered into visiting the workflow URL and entering the code:
Assuming they are signed into a valid Microsoft 365 session, they’ll be asked to select an account to authenticate with. The prompt also emphasises the Client ID of the device code (Microsoft Office) request and the geolocation of its IP address (Australia):
This is followed by a final confirmation prompt:
Upon accepting this, both the target and attacker are presented success messages:
The refresh and access token tables will describe the tokens as being created using device code authentication:
After activating an access token (or generating a fresh one from the refresh token), services can be interacted with under the context of the compromised account. For example, access to SharePoint has been granted:
And Outlook:
It is our strong recommendation to block device code flow wherever possible. To do this, organisations can implement a Conditional Access policy that prevents device code authentication except for accounts and devices that explicitly require it.
To configure this policy:
Before migrating the policy to block, you should use the Insights and Reporting workbook to evaluate legitimate device code usage in your environment – also ensuring that the Log Analytics Workspace connected to the workbook receives all required sign-in types. Common legitimate use cases include:
Exclusions can be configured based on the resource, or specific user groups, but should be minimised wherever possible.
For Azure CLI and other applications that use device code authentication, Microsoft provides some alternative authentication methods. It is our general experience that device code authentication remains used out of convenience and habit, rather than it being the only viable option.
Azure CLI:
PowerShell:
Application Registrations: For applications that can support it, dedicated App Registrations with appropriate API permissions are preferable over relying on device code authentication. Development environments and automated processes can also be configured to use service principals and managed identities. This provides better security controls, auditing capabilities, and eliminates the device code attack surface entirely.
Device code authentication creates specific telemetry values in Microsoft Entra ID sign-in logs. When a user enters a device code and subsequently authenticates, the authenticationProtocol field is set with the value “deviceCode”, therefore making it possible to filter on via KQL:
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| extend deviceDisplayName = tostring(parse_json(DeviceDetail)["displayName"])
| extend deviceOS = tostring(parse_json(DeviceDetail)["operatingSystem"])
| project TimeGenerated, UserPrincipalName, UserType, UserAgent, IPAddress, AppDisplayName, deviceDisplayName, deviceOS
As authenticated sessions refresh and are kept alive, subsequent sign-ins that initially occurred via deviceCode often do not have anything set for authenticationProtocol, but they will contain: "originalTransferMethod" = "deviceCodeFlow".
Our Microsoft 365 and Azure assessments are built upon respected industry benchmarks and extensive internal research. Each engagement takes an adversary-centric approach to reviewing your cloud security posture and designing an improvement roadmap that addresses your specific threats. These assessments include a comprehensive review of your conditional access policies – an area we frequently see organisations struggle to implement effectively. Our expertise enables you to tackle this complex challenge through structured rollout planning, thorough testing and auditing, and confident implementation. Contact us to learn more.