Should you block device code flow in Entra? I'll tell you why and how to!

What is device code flow?

You may have heard about the Storm-2372 cyberattacks which Microsoft posted about earlier this year - if not, then no problem - I've got you covered! Link to the article at the bottom of this post.

Now I won't be going into all of the technical intricacies of how device code phishing works - there are some detailed blogs out their by security specialists where you can understand more; my focus is to simply demonstrate how you can discover activity and ultimately make the sound decision of blocking this in your Entra tenant.

Now I'll admit, this wasn't an authentication scenario I've seen used within Entra until recently (Always learning!) but I was doing some Azure Web App consultancy and needed to quickly authenticate into the Azure CLI to test the deployment. I thought how convenient, I can simply paste a code from the CLI into the browser, confirm my sign-in and voila - you're in.

However, the red flags starting waving here, if I can get in so easily then surely this can be exploited by a bad actor and of course, it can and has been!

Demo of device code flow in Azure & Entra

Demo time, I'll be using the "az login --use-device-code" to generate a device code and URL to paste into the browser.

Then I go to "https://microsoft.com/devicelogon" and keep in mind, this URL is not tenant specific and neither is the code in the CLI, it's the account which the user authenticates with is what then authenticates that CLI session - scary right?

Now I've entered the code, and as I'm already signed in with Single Sign-On, there's no additional authentication required by default (You could be doing some extra Conditional Access to restrict Azure access and require stronger authentication - but this is just a demo tenant)

Sign-in confirmed.

Now, the CLI has been authenticated with the permissions of that user account - you can probably already think of many ways this could be simply spoofed and exploited!

How to discover device code flow within the Entra portal

Here's a quick way to check if there have been any sign-in attempts using Device code flow into your tenant, head into the Entra tenant and navigate to Users and Sign-in logs.

Next you can select Add filters and search for "Original transfer method" then locate "Device code flow" and select it.

Go ahead and review your Sign-in logs!

How to block with Conditional Access

Now for the juice - let's get this blocked and ensure this hole is patched.

Create yourself a shiny new Conditional Access Policy - I've called mine "Block Device Code Flow" but make sure you follow your standard naming convention in production - also, let someone else know what you're doing and get it approved - Conditional Access can go wrong very quickly if you're unprepared and don't have a back-out plan!

Here's my policy for you.

I'd recommend popping it in Report-only mode, triggering a new sign-in then using the wonderful "What-If" feature to ensure the policy will be triggered.

Have a look at this and give it a go too.

As you can see, this user is trying to use a Device code to authenticate - they mustn't have got the memo 😮‍💨

Now I've switched the Conditional Access Policy On, this is what the end user will see.

We can then delve into the sign-in logs for the user and just like that, they're blocked now.

Closing thoughts and some useful exclusion tips

So my advice is to get this blocked with a Conditional Access policy (you need at least an Entra Premium Plan 1 licensing SKU for this - that includes Business Premium 👍). You may find a legitimate use case in your tenant for this, like registering a Teams device - then of course you can create a layered Conditional Access policy to explicitly allow the action for that scenario.

I'll talk more about how you should consider managing Conditional Access exclusions in another blog, but five quick tips would be:

• Exclude by Security Group (role assignable group please!)
• Create an additional layered Conditional Access policy, and include the Exclusion Group
• Include the required Cloud App (not all cloud apps/resources!)
• Require Strong Authentication at least, but require a Compliant Device if possible too
• Agree how long to keep the exclusion active for, track the sign-in then revert all changes to ensure it's blocked again - don't just setup and forget!

There we are - hopefully I've helped fill your Monday with a useful Tech Tip...or just added to the never-ending to-do list; either way, thanks for getting this far and taking time out of your day to read my first blog post 🤝

Until next time 😎

Storm-2372 conducts device code phishing campaign | Microsoft Security Blog

Microsoft Threat Intelligence Center discovered an active and successful device code phishing campaign by a threat actor we track as Storm-2372. Our ongoing investigation indicates that this campaign has been active since August 2024 with the actor creating lures that resemble messaging app experiences including WhatsApp, Signal, and Microsoft Teams. Storm-2372’s targets during this time have included government, non-governmental organizations (NGOs), information technology (IT) services and technology, defense, telecommunications, health, higher education, and energy/oil and gas in Europe, North America, Africa, and the Middle East. Microsoft assesses with medium confidence that Storm-2372 aligns with Russian interests, victimology, and tradecraft.

Microsoft Security BlogMicrosoft Threat Intelligence