Since August 2024 there has been a sophisticated phishing campaign actively leveraging the device code authorization flow. Currently, there is a wide range of attacks targeting a wide range of sectors including government/ IT services and critical industries. The attack is known as Storm-2372 and is linked to Russian state interests.

However this attack is not new – on my blog this device code flow abuse has already been explained since 2022 and has already been abused in the past years, there is now more exposure and active attacks – since more customers are implementing controls against AiTM/ Token tactics and other new modern identity attacks. Victims are always researching new ways to bypass existing controls and evaluating with the new techniques.

Examples of blogs related to more advanced techniques used to get identity access

It is also really easy to use; You can go to https://microsoft.com/devicelogin enter a code that is generated on another device/services and fill in and authenticate without MFA or any additional authentication; sounds perfect right? All attackers are thinking the same:) – since the user is already authenticated in the session where the token is used. When sign-in via the AZ PowerShell module – Microsoft already mentioned: “If no web browser is available or if the web browser fails to open

What is Device Flow?

The Device Authorization Flow is not needed. With input-constrained devices that connect to the internet, rather than authenticate the user directly, the device asks the user to go to a link on their computer or smartphone and authorize the device. This is common for devices with a poor user experience to enter text, like game consoles/ TVs and other devices without a proper keyboard or input mechanism. Device apps use the Device Authorization FLow, in which they pass along their Client ID to initiate the authorization process and get a token.

Device Code Flow is a great feature – it makes authentication easy. A good example is Netflix on the television, it is hard to type in the randomly generated password via the TV keyboard, but when scanning a QR code you can authenticate via the phone and auto-fill the password via the password generator, this is a typical example of a device code flow. Spotify, Disney, and Netflix, all of them use the device code flow to easily authenticate.

A typical Device Authorization Flow contains two different paths. There is a device flow requesting the authorization and the other is in the flow of the browser.

A good device code flow example is explained by auth0.com:

Microsoft explains the OAuth 2.0 device code flow in-depth based on the typical Microsoft authorization URL flows. (Microsoft Docs). A must-read to understand the flow of the device code authorization.

STORM-2372 (active threat actor using the technique)

In the past months, there has been a phishing campaign leveraging the device code authentication. The campaign, attributed to a threat actor known as Storm-2372, has been active since August 2024 and is assessed to align with Russian state interests.

Two must read blogs:

The tricky part is that this attack method exploits a legitimate authentication mechanism to compromise accounts and gain unauthorized access to sensitive data and corporate resources.

The device code phishing attack cycle is looking like this:

A typical attack simulation flow:

The following is a typical attack simulation related to Device Code abuse:

HD version of the graph: Link

Initial Contact: The attackers contact the end-user via third-party messaging platforms such as WhatsApp/ Signal or even Microsoft Teams. Mostly they share context related to fake meeting invitations/ calendar invitations with a code (device code)

Phishing Execution: Via the chat messages victims are directed to enter a code on the Microsoft login page, one authenticated and the device code flow is not prevented – the attackers are getting full access.

Post-Compromise Activities: The attackers are now using the tokens to access sensitive data via the API/ harvest credentials or lateral movement within the environment from the compromised accounts.

A good example from the flow via the threat actor to get access via Signal: (image source: Microsoft). It can be similar on WhatsApp/ Microsoft Teams. Email is also commonly used- they switch more to direct messaging apps like Microsoft Teams and WhatsApp, since the device code will expire and spam filters are detecting it as spam, so attackers use legitimate channels.

For meetings they rebrand the Microsoft Teams invitations and include the device code authentication page, all of it looks legitimate – since the original device code flow from Microsoft is used, so no way to block it via URL phishing detection techniques like SmartScreen or network protection. The URL is legitimate and part of the authentication flow of Microsoft. On the device code authentication page, the user is tricked into entering the code which is explained as Teams meeting invitation code in the communication.

The hyperlinks are linked to https://login.microsoftonline.com/common/oauth2/deviceauth, the page used for the Microsoft Device Code authentication workflow. Clicking the link leads to the dialogue shown below.

Another example (image source: Volexity)

In this case, the accept invitation button links directly to https://login.microsoftonline.com/common/oauth2/deviceauth when the user clicks it will show the device code login sign-in page, the user adds the invitation code, and bingo!! the attackers gain the token.

How to simulate device code – Easy way

There are many ways to trigger a device code flow; via OAuth/ Postman build or easily using PowerShell to explain the flow. When sign-in via AZ powershell you normally use the AZ login command. When changing it to the below command you can use the device code flow: 

az login --use-device-code

When the user launches the command, it will already show the device login and linked code.

Now when we go to the website and enter the code we can easily authenticate:

What is needed? Restricted by policy; like this:

TokenTactics

Another way to collect the bearer token directly is through TokenTacktics. When running the Get-AzureToken -Client MSGraph you get a device code/ verification URI and expires In time. As you can see in the PowerShell it will wait for the authorization flow to get completed.

Now the user is going to the device login URL and typing in the device user_code.

In TokenTactics you can see the response and that the token is acquired and saved in $response

When running $response.access_token you can extract the access_token and re-use it in the authentication.

With prevention controls enabled it will be prevented:

Ok, what is the risk of device code abuse?

Of course; there is a huge risk (as already seen in the above examples; it is not hard, without the complexity of spinning-up new servers). Some years ago we started to see a move from legacy password spray attacks to MFA abuse and in recent years more advanced attacks like OAuth2.0/ AiTM and cookie/token theft related to the tokens. Based on this there is a transition, and identity attacks are getting more advanced. Recently; Microsoft explored active abuse via the device code flow; since the device code flow can be easily used to bypass protections and hardened controls to prevent AiTM or token theft.

Device code flow is a high-risk authentication flow that might be used as part of a phishing attack or to access corporate resources on unmanaged devices. In the past years, the term Device Code Flow abuse has been quite common and becoming more active from attackers. The user already provided MFA, no phishing website had to be used and it is bypassing protections.

Check current Device Code activity via EntraID

In the EntraID Sign-ins log, filter by the device auth authentication. Use the newly introduced Original Transfer Method filter to show the device code flow authorization request and track the authentication flow events.

The authentication protocol can be used to view all the sign-in logs authentication protocol = device code

Another way is to use the below KQL query to search across the environment for the usage of the device code flow. 

SigninLogs
| where TimeGenerated > ago(90d)
| where AuthenticationProtocol == "deviceCode"
| summarize by AppDisplayName, UserId

Protections/ mitigations against device code phishing

With the growing enablement/adoption of MFA, device code abuse/phishing is expected to grow in the upcoming years (attackers using new techniques). Additional mitigations against Device code phishing are important.

Preventing Authentication via Conditional Access

The most effective way to prevent these potential attacks is via conditional access. It is possible to create a policy to disallow the device code authentication. When the device code flow is blocked the complete device code authentication flow is prevented and not working anymore.

Before implementing such a policy,  it is important to evaluate the use of device code authentication – in some environments, it can be legitimate. MS Teams rooms/ Authentication to flows and more. Of course; conditional access policies can be excluded or allowed when the device is compliant or from a specific network segment for example. All try to block in most of the devices and only make exceptions when needed.

Typical use-cases; Microsoft Teams Room devices/ onboarding of applications/ Connection to PowerShell modules from developers. When company apps are using the device code flow, please re-evaluate the flow. The use of device login should be as minimal.

Microsoft recommends organizations get as close as possible to a unilateral block on device code flow. Always implement the audit mode policy to evaluate the impact and review the use of the device code authentication.

Blocking can be done via Conditional Access:

  1. Sign in to the Microsoft Entra admin center
  2. Browse to Protection > Conditional Access > Policies.
  3. Select New policy.
  4. Under Assignments, select Users or workload identities
    • Under Include, select the users you want to be in-scope for the policy (all users recommended).
    • Under exclude, select the users that need to be excluded (break-glass accounts) and any other necessary users
  5. Under Target resources Include all resources
  6. Under Conditions > Authentication Flows, set Configure to Yes.
    • Select Device code flow.
    • Select Done.
  7. Under Access controls > Grant, select Block access.
  8. Confirm your settings and set Enable policy to Report-only.

More information: Block authentication flows with Conditional Access policy

Based on the above policy all authentication with the device code flow will be blocked for all users (except the excluded users) for all applications (except excluded applications)

Run the conditional access policy in audit mode to evaluate potential impact and switch to block where possible. When there is no legitimate use or exclusions needed, block the device code authentication flow completely. And for the users that might be impacted you still can create an exclusion in this policy, please check if there is no alternative and the device code flow is needed.

!! When excluding users – please review the list regularly.

Result of the block

When the policy is configured and configured on the block action – the authentication flow will be blocked:

Result in conditional access:

Report only result

In Conditional Access the review events can be reviewed and analyzed, it will show the potential impact. Review them, make when needed tweaks, and add the policy to block.

Exclusion examples

As already mentioned the device code flow can be used during legitimate applications or authorization flows. So in all cases, review the impact first.

Some common exclusions are typical using the device code flow.

Teams Phones

Teams Phones are commonly using the device-code flow for authentication. When for example the device code flow is needed, you can use device compliance or put these devices on an isolated network and apply location-based CA policies. With this, you can allow the devices from a specific network or make sure the device is compliant.

Users

When specific users are needed for the authentication flow; a first review of the usage is needed and if there are alternatives. When a user needs the flow you can exclude it from the block policy, all require a specific network location or device compliance, so there is always an additional control in place.

More information and recommendations for MS Teams rooms: Authentication best practices for Teams phones

Other recommendations

Some other recommendations;

Limitation device registrations

Attackers can use the Device code flow to register devices in the tenant to bypass the device compliance controls. It is heavily recommended to track new device registrations and limit the registrations of new devices (hardening the registration process).

Additionally, enrollment restrictions – limiting the user permissions that can enroll devices into your Microsoft Entra ID environment – can also help to address this attack behavior. Fabian Bader created a really good detection script to detect new device registrations enforced by a device code flow. GitHub – So make sure to track also the newly registered devices and restrict them when possible to avoid this type of abuse as well.

The following recommendations are recommended:

  • Implement EntraID Identity Protection policies with actions and not only report-mode
  • Require device compliance in conditional access/Require Microsoft Entra hybrid joined device
  • Make sure Attack Disruption is working
  • Make sure the identity is protected against AiTM (See below blog)

Read the following blog; when you are protected against AiTM and Device Code Flow there is a huge win in terms of protecting against attacks; all keep improving since attackers are not waiting.

AiTM/ MFA phishing attacks in combination with “new” Microsoft protections (2025 edition)

And make sure to read the following article; since Microsoft is updating the context: Storm-2372 conducts device code phishing campaign

Sources and must-reads

Microsoft:

Community: