Secure Your Device Code Auth Flows NOW!

Did you read the title and not know what device code auth flows are in Entra ID/M365? Well you’re probably in the right place because they are something fairly new that we can control, but are actively being targeted by threat actor groups.

Introduction: What are Device Code Authentication Flows?

A “device code authentication flow” is a method of user login where a device with limited input capabilities, like a smart TV or IoT device, displays a code on its screen, which the user then enters on another device (like a phone or computer) with a web browser to complete the login process and gain access to the service; essentially allowing users to sign in to devices that can’t handle a full browser-based login experience by using a different device to authenticate.
– Microsoft Copilot
Tweet

So basically, this is a method of authentication where you sign in on your computer, and associate that sign in with a device that cannot perform the authentication itself by providing the code presented on the device. If you’ve signed into Youtube TV or other apps on a smart TV, you’ve likely used this authentication method.

How are Threat Actors using this?

Now that we know how the auth flow works, let’s look at how the threat actors are exploiting the legitimate sign in process.

During the attach, the threat actor will use the device code auth flow service to generate a request for a sign in using the legitimate services. With this the threat actor will generate a code and trick a victim into inputting the device code into the legitimate sign in page. Once complete, this grants the threat actor access and allows them to capture the access token. From there, the threat actor will have access to the victims accounts, data, and services without needing a password or additional multifactor authentication. See the below image from Microsoft threat researchers depicting the attack:

https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/

What do the phishing messages look like?

Microsoft threat researches documented that the phishing messages usually will pose as someone prominent and trying to get them to join a meeting. The malicious links used to get the victim to the legitimate sign in page are typically obfuscated as Teams meeting join links.

https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/#Update-February-14

Once the user clicks the “Join the meeting” link, they would be taken to the device code authentication entry screen (aka.ms/devicelogin). Once there, the user will be asked to enter the code that the threat actor provided as the ID for the fake teams meeting, but in all actuality it is the code the threat actor generated to link their device.

Another example of device code authentication being exploited: https://www.volexity.com/blog/2025/02/13/multiple-russian-threat-actors-targeting-microsoft-device-code-authentication/

Now that the threat actor has access to the environment, they will go through and send more device code authentication requests to more users inside of the organization to secure their access and gain more of a foothold. They will also utilize the GraphAPI to search messages containing: username, password, admin, teamviewer, anydesk, credentials, secret, ministry, and gov. Once messages containing these keywords are identified, the threat actor exfiltrates those messages.

Just like any other threat actor targeting M365, we are seeing these threat actors use proxies or VPNs to obfuscate their locations so they are less easily identifiable.

How can we protect against this activity?

Ideally, we would just disable device code authentication flows all together. In all actuality, we likely can’t disable this all together. We may have smart devices like Surface Hubs or, more likely, Teams Phones that use device code auth for setup. So, what can we do? Microsoft suggests enrollment restrictions, but I’m not certain this is the best solution. I suggest Conditional Access, using a policy like the below:

Users:  All Users, Excluding Emergency Access Accounts
Target Resources:  All Resources
Network:  Exclude All trusted networks and locations (you must have your networks where device auth is allowed configured as Trusted)
Conditions:  Authentication Flows - > Device Code Flow
Grant:  Block Access

What does this policy above do actually? It gets your organization in a better place when adversaries like Storm-2372 are targeting organizations and government contractors. It technically also blocks device code authentication from happening anywhere except your trusted locations.

What are other ways we can protect our organization?

  • Educate your users:
    • Make them aware that the threat actors will typically start a conversation on another platform like Whatsapp, Linkedin, iMessage, etc where they can gain trust.
    • Continually evaluate your users susceptibility by using tools like KnowBe4 or Defender for Office 365 Phishing Simulations
  • Implement sign in risk policies to automate actions on risky sign ins.

Conclusion

In the ever-evolving landscape of cyber threats, attackers like Storm-2372 continue to exploit authentication weaknesses to gain unauthorized access to cloud environments. Protecting against these threats requires a multi-layered security approach, particularly when securing the device code authentication flow. By implementing Conditional Access policies and monitoring sign-in logs for anomalous behavior, organizations can significantly reduce the risk of compromise. As attackers refine their techniques, defenders must continuously adapt—proactively strengthening authentication mechanisms is key to staying ahead of emerging threats.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *