I’m so ACDC! – Alarmingly Concerned (about) Device Codes!

What’s a Device Code?

When you want to log in and authenticate to Entra ID, you may not always have the same input capabilities as you have on your computer. This can be devices without keyboard, for example an IoT device, printer, meeting room equipment, or other input-constrained devices. This makes signing in very cumbersome, if not impossible, for these kind of devices.

As part of the Oauth 2.0 authorization framework, devices in these categories can issue a device code request. This will provide a URL and a one-time code (which I refer to as device code). The idea is that the user can then go to an ordinary client (like their computer) and use the provided URL and user code to sign in interactively and if applicable use the equipment’s user account credentials. This also provides capabilities for MFA on such devices.

Pretty cool huh?

Sounds great! What’s the problem?

As with everything else in the world, it can be used and it can be abused. While it does require a good portion of social engineering to pull off, device code authentication is a great tool for phishing attacks. Mostly because the sign-in goes through an authentic Microsoft portal, so there’s no need to set up a phishing site with fake names or URLs.

So this will, for many phishing-tools, appear as a legitimate sign-in and this makes the attack so much harder to detect! And technically IT IS a legitimate sign-in!

How the attack can be executed:

1. The attacker opens a webportal, app or script which requests authentication using a device code.
2. The website/app/script provides a URL and a one-time code.
3. This is the tricky part: The attacker must persuade the victim to use the link and user code provided, and then log in using his/hers credentials to authenticate to Entra ID. The link and code is fortunately only valid for 15 minutes by default and sometimes even shorter. However, for a targeted attack or with good social engineering, this would not be a significant issue for the attacker.
4. When the victim completes his/her sign-in, the attacker is automatically signed in with the victims credentials.

A simple demonstration:

Here I’m logged in to a client as an attacker and I want to get access to the victims tenant. In this demo I use PowerShell and do a simple connect to Graph with device code.

Connect-MgGraph -DeviceCode

Above you see the URL and one-time-code to sign in.

On the victims machine I (as the victim) have been manipulated and persuaded to click on the link which brings me to this windows where I need to insert the provided one-time code.

Then, I need to select which account to log in with and complete any MFA requests. I have an admin account, and the attacker is very persuasive, so this time I see no issues with logging in with a privileged account and performing any MFA requirements.

And then on the attackers machine which you see below, the welcome message to Graph appears and the attacker is logged in with admin privileges.

How do we prevent these attacks?

Fortunately, this is very easy to block using our favorite Tool: Conditional Access!

But be aware that this will require that you know your environment because you may have devices which depend on this sign in method. So it is important that those use-cases have an exception from policies which block the use of device code. This exception can be temporary if you want, but make sure you do have them if your environment need to use device code from time to time.

Create a new Conditional Access policy and navigate to “Conditions” – “Authentication flows” – Set “Configure” to “Yes” and check the “Device code flow” checkbox. Scope this to all users and all resources with any exceptions you need. Finally “Block access” under “Grant”. You can see an example below.

How so we detect these logins?

In the Entra ID sign-in logs, logins of this type will register as “devicecode” under “AuthenticationProtocol“. So you can easily filter for those in the sign-in logs.

Alternatively, you can use PowerShell to find them with a simple one-liner. You’ll need the Microsoft.Graph.Beta.Reports module. Keep in mind that the Microsoft Graph API has two versions: ‘v1.0’ and ‘beta’. This information is only available in the beta version, which is why you need to use the cmdlet ‘Get-MgBetaAuditLogSignin‘ instead of ‘Get-MgAuditLogSignin’.

Get-MgBetaAuditLogSignin -Filter "AuthenticationProtocol eq 'devicecode'"

And finally if you forward your sign-in logs to either Azure Log Analytics or a SIEM solution like Sentinel, you can set up alerts there as well based on the same filter.

Conclusion:

In conclusion, while the device code flow in Microsoft Entra ID offers convenience, it also presents potential security risks if not properly managed. By understanding how attackers can exploit this feature for phishing attacks, you can take proactive steps to safeguard your organization.

So most important is USER TRAINING, USER TRAINING AND MORE USER TRAINING!

Beyond this step, you should absolutely try to block this feature as much as possible using Conditional Access. However, many organizations will still need to use device codes to some extent. This should definitely be the exception rather than the rule. Additionally, if possible, make access to device codes temporary and only available when absolutely necessary.

I hope you found this post useful and informative. Don’t forget to subscribe (it’s free) so you’ll be notified every time we publish more posts to share our knowledge and experiences. Thank you!!