Introduction
Device code phishing is a method employed by threat actors to exploit the device code authentication flow. By capturing authentication tokens, attackers gain unauthorized access to targeted accounts, enabling them to retrieve data and utilize services associated with the compromised accounts. This method becomes particularly appealing to attackers due to its potential for sustained access, as long as the tokens remain valid.
The Microsoft Threat Intelligence Center has identified an ongoing and effective device code phishing campaign orchestrated by a threat actor designated as Storm-2372. Our investigations reveal that this campaign has been active since August 2024. The threat actor has been employing deceptive tactics by crafting lures designed to imitate messaging platforms such as WhatsApp, Signal, and Microsoft Teams.
You can read more about Microsoft Threat Intelligence Centers investigation and more about the Device Code phishing techniques here: https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/
In the article from Microsoft Threat Intelligence Center there is also some KQL that can be used for helping identify possible device code phishing attempts. Have a look and check your own environment!
Identify excludes
Before we go any further we need to identify who is using device code authentication. This is important because of two things.
- We need to notify users that are affected so that they can adjust and use other methods
- sometimes (quite often) they cannot adjust fast enough so we need the list of users that we can exclude from the policy.
An important note here, it may be that we only do the exclution from a certain network location, only from compliant devices, only a small list of users and so on.
We can use KQL against sign-in logs to identify users
SigninLogs
| where TimeGenerated > ago(30d)
| where AuthenticationProtocol == “deviceCode”
| summarize by UserId, UserDisplayName, TimeGenerated, IPAddress, AppDisplayName
We can also use the Sign-in logs directly in the Entra admin portal to identify the users using device code authentication
Block device code with Conditional Access
Navigate to Entra Admin Center — >> Protection –>> Conditional Access –>> Policies
From here we need to create a new policy and give it a name, Assign it to all users (exept from the one identified and planed for).
Then we will scope it for ALL resources under “Targeted resources.
And now for the most important part (almost)
Let`s head into Conditions and select that this CA Policy is affecting “Device code flow”
And the last part is to actually BLOCK device code flow on the users and applications that we have choosen.
go to “Grant” and choose “Block”
And now save it and remember to enable the policy as well 🙂
Conclution
- Identified users of device code authentication: We reviewed and confirmed who is currently utilizing this method.
- Implemented a Conditional Access policy: A quick policy was created to block the usage of device code authentication.
Recommendations & Next Steps
Continue monitoring the users or IP addresses that still rely on device code authentication to ensure proper oversight.
It’s straightforward to identify users of device code authentication. Start by using available techniques to pinpoint usage and block it for all users by default.
Engage with current users:Initiate dialogue with individuals already using device code authentication.
Offer guidance and support to help them transition away from this method entirely.
Handle exceptions thoughtfully:For corner cases—because there are almost always some—allow exceptions as needed but keep an close eye by monitoring known users or IP addresses.
