Security-Column
Date: 

Device Code Phishing: Why attackers don’t need your password to compromise your account

In IT security, technical safeguards are often only effective in combination with employee awareness training. Phishing, as an attack type, can demonstrate this very clearly.

Established mechanisms such as Multi-Factor Authentication (MFA) have significantly raised the bar against traditional credential-theft phishing approaches. However, modern attack techniques no longer rely solely on stealing credentials — instead, they exploit legitimate authentication processes to gain access to user accounts.

At the same time, more sophisticated phishing campaigns are continuing to evolve. Through the automation enabled by phishing frameworks and the use of artificial intelligence (AI), attacks can today be carried out with considerably less technical effort. Alongside the well-established market for Phishing-as-a-Service offerings, this further lowers the barrier to entry for attackers.

A particularly compelling example of this is the Device Code-Phishing, in which attackers exploit the legitimate device code flow authentication method used by modern authentication services such as Microsoft Entra ID1 in the Microsoft cloud environment which is used, among others, by modern authentication services such as Microsoft Entra ID within the Microsoft cloud ecosystem.

Basic Overview of the Device Code Flow

The so-called device code flow is an authentication method originally developed for devices that do not themselves support browser-based login—such as conference systems, smart TVs, or IoT devices. To better understand how the device code flow can be exploited as an attack technique, it is worth first examining its standard workflow using an everyday example (Figure 1): 

Mr. Meier wants to use the fictional streaming app “Fuchs Film” on his smart TV. To do so, he must first verify his device so that it is authorized to use the “Fuchs Film” app (1). To do so, an authentication process (device code flow) is initiated in the background when the application is launched. During this process, a device session is initialized, and a so-called user code as well as a corresponding device code are generated. The device code remains on the device and will be used in the background to identify the session, while the user code is intended to be entered by the user and is therefore displayed on the TV. To help Mr. Meier know where to log in, a link to the login page is also provided, which can optionally be opened using a QR code (2). To log in, Mr. Meier scans the displayed QR code with his smartphone or another browser-compatible device and is redirected to the corresponding login page. Here, he enters the six-digit user code shown earlier (3). He then authenticates himself using both his usual login credentials (username and password) (4) and the second factor as part of multi-factor authentication (5). Once logged in successfully, the previously initiated device session is confirmed, and the device is granted access to the service (Fuchs Film). Mr. Meier can now watch the movies on his TV without having to log in again (6).

Figure 1: Standard authentication using the device code flow method
Click to enlarge

However, it is precisely this legitimate authentication process that forms the basis for a growing trend of abuse: the so-called device code phishing.

During this type of attack, malicious actors specifically exploit the process described above to trick users into authorizing a session they control. This technique is currently being observed with increasing frequency in phishing campaigns, particularly in the Microsoft Entra ID environment.

How a device code phishing attack works in Microsoft Entra ID

A typical attack scenario (illustrated in Figure 2) often begins with a seemingly harmless email. For example, an employee in the finance department receives a message purportedly from its IT support or a partner company, asking them to review a document or perform a quick verification of their Microsoft 365 session. Attackers often use compromised accounts for this purpose, leveraging existing relationships to make the message appear more credible.

The message contains a link that leads to a phishing site controlled by the attacker. If the link is opened, the attacker initiates a device code flow authentication within Microsoft Entra ID in the background. This creates an authentication session for a device under the attacker’s control. In this step, Entra ID provides the two key elements previously introduced in the Mr. Meier example: a device code for assigning the session and a user code that the victim must later enter (1).

This user code is displayed to the victim on the phishing page, along with a prompt for signing in via Microsoft Entra ID and confirm the code (2). A link on the phishing page then leads directly to the official Microsoft sign-in page for entering the device code (3).

In the next step, the victim authenticates via the genuine Microsoft login page. The legitimate mechanisms are used here, including multi-factor authentication (4+5). After successful login, Microsoft Entra ID validates the previously entered user code and associates the authentication with the authentication session initiated by the attacker. Following the user’s consent (6), the attacker can then successfully authenticate (7).

To the victim, the process appears completely legitimate: the login is indeed handled by Microsoft, the multi-factor authentication is carried out correctly, and there are no obvious irregularities.

The key difference is that the user is not confirming their own session but is instead authorizing the authentication session previously initiated by the attacker.

Figure 2: Illustration of the attack sequence exploiting the device code flow
Click to enlarge

What makes this attack dangerous?

The primary danger posed by device code phishing attacks lies in the fact that no login credentials in traditional sense are compromised. The user does not disclose either their password or an MFA code to the attacker. Instead, as part of a legitimate Microsoft sign-in process, they authorize a session initiated by the attacker.

This distinction is crucial for detection: From the perspective of Microsoft Entra ID, this is a successful and valid login.

The real danger arises because this successful authentication leads to the issuance of so-called tokens, which enable further access to cloud resources.

Understanding Tokens in the Microsoft Cloud Context

After a successful login, Microsoft Entra ID typically issues two types of tokens — an access token and a refresh token.

The access token is used to directly access the authorized cloud service. By including the access token in requests to the service, data can be retrieved in the context of the user or the service. For example, if Microsoft Office is authorized, an attacker can access the user’s files, emails, and Teams data. Due to the sensitivity of the data accessible through this method, Microsoft typically limits the validity of access tokens to approximately 60 to 90 minutes.

The refresh token is used to automatically request new tokens after the access token expires, without requiring the user to interact again. This allows an authenticated session to be maintained over a longer period of time. In practice, this means that after a successful device code phishing attack, an attacker not only gains one-time access but can continue to access Microsoft cloud services via valid tokens as long as the session remains active.

What can I do about it, or how can I protect myself?

When implementing measures against device code phishing, it is important to distinguish between reactive and preventive actions.

Reactive measures

If a successful attack has already been detected, affected accounts should be locked immediately and active sessions should be reset via Microsoft Entra ID. This invalidates existing refresh tokens, preventing an attacker from requesting new access tokens. However, access tokens that have already been issued usually remain valid until they expire. Therefore, a detailed investigation of the cloud environment should be conducted afterward to trace any potential access to cloud resources and determine the scope of the compromised identity. If needed, our Incident Response Team can also assist with this.

Preventive measures

However, securing the environment proactively is far more effective than simply reacting to security incidents. As mentioned at the outset, this requires implementing a combination of technical and organizational measures.

Technical measures include particularly restricting device code authentication via conditional access policies in Microsoft Entra ID. In addition, further hardening measures based on established standards, such as the Center for Internet Security (CIS) benchmarks, should be implemented to significantly reduce the underlying attack surface. Furthermore, continuous monitoring of authentication events can help identify anomalies early on and narrow the detection window to enable timely intervention.

In addition to technical measures, raising employee awareness remains a key component of the defense strategy. Whether the threat involves device code, MFA, or other types of phishing, the human factor remains the decisive element in many cases.

Our Technical Security Consulting team can assist with strategic planning and the implementation of appropriate security measures in Microsoft cloud environments.

Ultimately, device code phishing demonstrates that not only credentials but also legitimate authentication processes themselves can pose a serious risk.


1 Microsoft Entra ID (formerly Azure Active Directory or Azure AD) is Microsoft's cloud-based identity and access management (IAM) service. It serves as a central directory for securely managing user accounts, devices, and access permissions for Microsoft services (such as Microsoft 365, Azure, and Dynamics 365) as well as other cloud applications.

This article was written by