Microsoft 365 Device Code Phishing Cyber Attack – Demonstration, Analysis and Mitigation

[tkol2022]

Executive Summary

This article describes the results of a hands-on threat analysis to demonstrate the “device code authentication” cyber attack in Microsoft 365, which is an evolving threat to customer’s emails, files, chats and other data. The purpose of the assessment was to understand the scope and danger of the attach technique and how Scuba users can mitigate the attack vector in their organization’s M365 environment.

Recently, as observed by Microsoft and third party Cyber incident response corporations such as Volexity, there is a noticeable exploitation of the Internet standard OAuth Device Authorization Grant flow by nation-state actors. This amounts to threat actors leveraging a benign Internet authentication standard in a malicious way to gain access to victim’s Microsoft 365 accounts. Microsoft has prioritized the device code exploitation threat vector and is deploying mitigations to help customers.

The ScubaGear tool is currently being enhanced to detect if device code authentication is blocked in a user’s Microsoft 365 environment.

What is Device Code Authentication?

Device code authentication is a special type of sign in that is typically reserved for special scenarios such as giving Smart TVs (or other input-constrained “devices”) the ability to sign in on behalf of a specific user account in a particular system. Imagine the scenario where you want to use an app on a Smart TV and the TV needs your credentials so that it can sign in as you to customize the experience in the app and potentially show your data (like your favorite shows etc.).

How does Device Code authentication work?

Before we get to the part where the device code authentication standard is being exploited by threat actors, let’s walk through this type of authentication in a common, benign scenario such as a Smart TV app. The device code standard was designed because on input-constrained devices it is impractical to expect a user to sign in on the device itself (like a TV). In a subsequent section there are screenshots describing how the device code flow is currently being used in a malicious manner to gain access to victim’s Microsoft 365 emails and files.

• Step 1 – The device needs to sign in as the user. The device displays a short URL that the user must visit in a separate browser either on their phone or on a laptop. The device also displays a short code such as “AR66V7MUK” that the user must enter when they visit the URL.
• Step 2 – In a system that is separate from the TV (like the user’s iPhone), the user enters the URL and the code to start the process. Then the user is asked to sign in to the authorization system associated with the TV app. Finally, the user is asked to confirm that they want to give the TV app the ability to access the system “on their behalf”.
• Step 3 – At this point the TV app can authenticate as the user and conduct operations as the user. The specific operations that the TV app can perform depend on the permissions that were granted to the app. In benign real-world scenarios such as this one the Smart TV app commonly gets access to the user’s name and potentially some information to customize the experience such as the user’s favorites.
• Step 4 – At this point, without any additional interaction from the user, the TV app can continue to sign in on behalf of the user in the future as long as the TV app is programmed to refresh its tokens. This perpetual access from the TV app eliminates the need for the user to authenticate every time the TV is turned on.

Although a TV app was used in the example above, other Internet-based applications can be used to perform device code authentication including Microsoft 365 apps and herein lies the danger. In a subsequent section below where I demonstrate the attack, I used Microsoft Graph Command Line as the application (i.e. it is the “device” in the flow) and Microsoft 365 as the system being compromised.

What makes this attack so dangerous?

The factors described below make this attack a particularly dangerous threat to Microsoft 365 users. Some of these factors are shared with other OAuth-based cyber-attack exploits such as application consent-grant phishing in which victims also get tricked into giving third party applications access to their data. Device code phishing is similar to consent grant phishing but exploits a different part of the OAuth Internet application standard.

• Factor 1 -Not hard to do– The attack does not require any special or costly technical infrastructure for the threat actor. The threat actor does not have to connect to the victim’s machine at all. The attack mostly leverages Microsoft’s standard OAuth access infrastructure (specific web endpoints designed to support sign in and authorization). The threat actor needs a relatively simple application to handle generating the device code and processing the flow after the victim falls for the exploit. The threat actor can use the spear phishing infrastructure that they already have which delivers the phishing email, Microsoft Teams message or text message.
• Factor 2 – Perpetual silent access - Once the victim has given the requesting malicious application the ability to access M365 on behalf of the victim, the application can then, keep requesting more tokens and continue to sign in on behalf of the victim without the victim’s awareness.
• Factor 3 – Comprehensive access to the victim’s data - The malicious application can execute commands on behalf of the victim such as reading emails and accessing files.
• Factor 4 – Delivery and exploitation have been optimized - Recent reports by reputable sources indicate that threat actors have optimized the process of getting targeted victims to perform the necessary device code actions to a high enough degree for the attack to work a good percentage of the time.

Challenges in executing the attack

Below are some potential challenges for a threat actor to be successful with this type of attack.

• Challenge 1 - Device codes are valid for 15 minutes in Microsoft 365. From the time the code is generated by the threat actor until the victim authenticates and completes the flow, there is little time. That said, threat actors devised a simple workaround for this according to Volexity. The threat actor creates a web page that dynamically generates a new device code when a victim visits the page. This ensures that the victim sees a freshly minted device code no matter when they click on the link in the phishing message.
• Challenge 2 – The victim must go through at least a few steps in order to complete the flow on their end. Look at the screenshots in the next section and you will see that the victim must first perform an authentication and then confirm that they want to let the application access the system on their behalf. If the victim is already signed into their Microsoft 365 account, this reduces the number of steps, but the victim still has to confirm to allow the application access. All these screens may seem like a high bar for an threat actor to cross for the attack to succeed but just like in the case of OAuth consent grant phishing, threat actors have optimized their messaging and interactions with victims.

See the Attack in Action for Microsoft 365

In this section I demonstrate the device code attack with some screenshots to help visualize the malicious process flow within the context of Microsoft 365. In my demonstration I used the Microsoft Graph Command Line application as the “device” requesting access but in a real-world attack scenario it could be a different application that is hosted in the victim’s Microsoft 365 environment, such as Microsoft Teams as noted by Volexity.

Image courtesy of Microsoft "Storm-2372 conducts device code phishing campaign"

Steps 1 & 2 – Threat actor asks service for device code

In the first step, I initiate the attack by starting the process of logging into Microsoft Entra Id using the -Device parameter which starts the device code authentication flow by generating a standard Entra Id URL (https://microsoft.com/devicelogin) and a freshly generated device code (AR66V7MUK). This code is provided to the victim during the phishing process in the next step. I used the Connect-MgGraph cmdlet (which is part of the Microsoft Graph Command Line application) to initiate the device code authentication flow and wait until the victim completes the authorization process in the next step.

Step 3 & 4 – Threat actor sends the code to the victim and the victim signs in to Microsoft 365

During this step, the victim may receive a phishing text message asking them to visit the Microsoft.com/devicelogin link and enter the code created in step 2. The victim may be tricked into thinking they are going to participate in a special meeting hosted in Microsoft Teams or something like that. Typically, the threat actor will tailor the phishing message to match the victim’s specific job role and topical interests to increase the chances that the victim will act on the phishing request. The victim clicks on the link the message and proceeds to sign in and click on a confirmation without realizing what is really happening.

The victim enters their username and authenticates to Microsoft 365.

Then the victim is asked to confirm that they want to sign into the application requesting access and is warned that they should only continue if the app is from a trusted store. In this demo the application is the Microsoft Graph Command Line Tools. The victim must click Continue for the attack to be successful.

After the victim clicks Continue, they will be shown one final message confirming that they signed into a device. This is “game over” time.

Steps 5 & 6 - Game Over (threat actor receives access token)

Meanwhile back at the ranch, since the victim completed their part of the flow, Connect-MgGraph (the threat actor’s application) can now begin interacting with Microsoft 365 on behalf of the victim and access their data. This is because the application receives an access token as part of the device code flow. In the screenshot below, notice the “Welcome to Microsoft Graph” message which indicates that the authentication flow completed and the Microsoft Graph Command Line application is now signed in on behalf of the victim.

Next, I executed a command to display the name of victim’s user account that was hacked the permissions granted to the application. In this example you will notice that the threat actor has been given a list of permissions that include items such as User.Read.All and Domain.Read.All. The permissions gained by this attack will be different in each hacking scenario.

List of Microsoft Graph API permissions.

Finally, the threat actor can now start executing commands on behalf of the victim. In the screenshot below I executed a command to canvass the groups in the Microsoft 365 system. In a real world scenario, the threat actor might execute commands to download the victim’s emails and files.

Mitigating the Attack

Fortunately, this attack is straightforward to mitigate via a Microsoft Entra Id conditional access policy that blocks device code authentication. I tested this and it works as expected without any observed complications. See screenshots below for configuration and what it looks like when the attack is blocked.

Create a conditional access policy that is scoped to all users and all apps. In Conditions > Authentication Flows select the Device code flow option. In Grant select Block Access.

Once the conditional access policy is in place, after the victim enters the device code and then signs in, the victim will see an error message as per the screenshot below, indicating that Microsoft Entra Id denied the device authorization and therefore the threat actor won’t be able to access the system.

How are we handling this on Scuba?

The Scuba team is working on a new policy check that will be included in ScubaGear that will detect if device code authentication is blocked in a Microsoft 365 environment. Our new policy check compliments recent actions by Microsoft since they are starting to automatically deploy the conditional access policy described in the previous section to customer environments.