A New Era Of Social Engineering: The Device Code Phishing Boom

The FBI recently published a public service announcement on an emerging Phishing-as-a-Service (PhaaS) platform that enables attackers to circumvent multi-factor authentication (MFA) by obtaining Microsoft 365 access tokens. 

This tactic, also known as device code phishing, is skyrocketing in popularity among threat actors. 

Once an obscure technique, it’s now highly accessible to attackers of all skill levels due to the rise of publicly released toolkits. In June and July 2026 alone, Coalition Incident Response (CIR)* handled multiple business email compromise (BEC) cases stemming from this method. Its newfound prevalence in the threat landscape raises several red flags:

• Traditional defenses may not detect the activity. The victim completes MFA normally and the attacker accesses a token that carries mfaAuthenticated=true.

• The sign-in looks legitimate. Victims are funneled to a real Microsoft URL with no obvious identity compromise signs, such as multiple failed logins or compromised credentials.

• Attackers are executing at scale. Several different toolkits are available, including AI-enabled PhaaS platforms that can automate the entire process from end to end.

Below, CIR shares insights and guidance from its investigations to help security teams defend against the latest era of social engineering.

Abusing the device code flow 

OAuth 2.0 Device Authentication was built for internet-connected devices that either lack a web browser or have limited input mechanisms, like smart TVs, gaming consoles, command-line interfaces, or IoT devices (AKA secondary devices). The device flow offloads the authentication to a separate (authorized) device with an accessible browser or keyboard. How it works:

1. The (secondary) device requests connection to an authorization server.

2. The server responds with three key pieces of information: device code (used internally by the device), user code (easy-to-read code to enter), and a verification URL (where to enter the user code).

3. The user opens the URL, enters the user code, and completes sign-in with MFA. 

4. The original device polls the authorization server in the background and receives an access token and refresh token when the user approves. 

The device code flow has drastically improved the user experience when logging into an app on a smart TV. But there’s no rose without its thorn: the device code flow is also highly exploitable.

The authorization server uses an assumed trust for the request and doesn’t perform a secondary verification that the person entering the user code is the same person operating the polling device. And with available toolkits, it’s surprisingly easy for attackers to get their hands on the device code — which is the only connection between the polling device and the authenticating user — to jumpstart a social engineering campaign. 

Some devices, such as Microsoft devices, regularly use device code flow during first-time registration or reprovisioning, making them particularly vulnerable to attacks. 

When targeting Microsoft, an attacker sends a POST request to Microsoft's device code authorization endpoint, using the client ID of an application that supports the device code flow (which is publicly available information). The endpoint then returns a user code, device code, and verification URL. 

The attacker can then craft a convincing phishing email that instructs the recipient to visit the legitimate Microsoft sign-in page and enter the attacker-provided code. See below:

Device code phishing chain

The victim receives a traditional phishing email driving them to view a PDF attachment.

The victim clicks “View Document,” which drives them from a Microsoft SharePoint page to DocuSign. Many of the PhaaS platforms come with various landing pages and themes, allowing attackers to easily build out entire campaigns from start to finish. Because victims aren’t asked to enter their credentials, many security tools won’t catch the phishing attempt.

The attacker provides the user code as if it were a one-time password or verification token. When the victim clicks “Copy Code,” a legitimate Microsoft device login page opens in a new window and the user code is saved to the victim’s clipboard.

The victim enters the code and completes MFA.

Once the victim enters the code and completes the sign-in request, Microsoft returns an access token to the attacker. The attacker can then use the token for continued access to the victim’s Microsoft account.

The detection dilemma

Following a BEC, many businesses don’t recognize the incident or reach out for assistance until after the fraudulent transfer of funds triggers alarm bells.

At that point, they may have no idea how long the attacker had access, who the impacted user was, or how the attacker got inside in the first place. But the rest of the story can likely be found inside the business’s email logs. 

Microsoft Entra Sign-In Logs

Standard security advice surrounding device code phishing points to unpacking Azure logs, which show entries for device code authentication and user-agent mismatches. When available, the logs will show that a user signed-in used “deviceCode” as the authentication protocol. This record, coupled with reviewing additional data connected to the sign-in, such as IP addresses and client applications requesting the code, can be used to determine if the authentication was legitimate. 

However, the default retention period for Microsoft Sign-In logs is usually 7-30 days. What happens when the Entra Sign-In logs have rolled over?

Unified Audit Logs (UAL)

In many cases, businesses report an incident long after that window for using Entra Sign-In logs has closed. In these cases, the logs have rolled over and cannot be used in a forensic investigation. When this happens, analysts rely on the UAL, which by default and when enabled, contains up to 180 days of logging data and can contain evidence that analysts need to confirm whether an account was compromised using device code phishing. 

In the event of a successful device code phish, a consistent way to find evidence of who was compromised and how is by analyzing the AuditData JSON. 

Within the UAL, the “add registered owner to device” operation may not be associated with the compromised user, which is stored in the UserID field. Instead, the UserID is cataloged as ServicePrincipal, which refers to a non-human identity performing an action. Evidence of the associated user lives strictly in the AuditData JSON.

Observations from attack activity 

CIR has observed that attacker dwell time — the window between initial device registration and subsequent malicious activity — has varied greatly. In one event investigated by CIR, malicious activity began the same second that the device was registered. In another case, malicious activity didn’t occur until 12 days and 18 hours after the original device registration. What does this mean for security teams?

In one event investigated by CIR, malicious activity began the same second that the device was registered.

Quick action is critical

Attackers are leveraging automated toolkits which enable them to act in seconds. To limit the blast, security teams should keep an eye on interactive sign-in logs to capture IP or user-agent mismatches and abnormal device code usage patterns. Delays in action or reporting are often caused by IT teams focusing solely on standard signs of identity compromise. 

But threat actors can linger for a while

Using this technique, attackers can receive two tokens after the victim completes the sign-in request: access and refresh tokens. Access tokens are short-lived, but refresh tokens can remain valid for weeks or months and survive password resets. Maintaining a device inventory and clear ownership records is essential for identifying unauthorized device registrations that mimic legitimate organizational naming conventions.

It’s time to adapt and harden defenses 

Device code phishing is, like so many things in the threat landscape, a result of creative attackers finding new ways to circumvent tried-and-true defenses. The latest “fad” in social engineering exploits structural blind spots in how security tools evaluate risk, uses the victim as an unwitting proxy, and masquerades as an expected login. 

Threat actors can push the boundaries. In turn, defenders will respond as they always do — building a deeper, more specific moat. Here are immediate steps businesses can take:

Restrict or block the device code flow Businesses that do not rely on device code flow for legitimate business use cases can universally block the flow entirely by creating a new policy in the Entra admin center. If there are legitimate use cases, businesses can modify the policy to exclude certain users or groups. 

Have a plan to respond to token theft Plan for when, not if. In the event that a device-code phish is successful, security teams should know the steps necessary to revoke an attacker’s access. Password resets aren’t enough! If a user has been compromised, reset the password, revoke all sessions, and reset all MFA devices associated with the account.

Wirespeed Automated Detection & Response (ADR): Built for the new era of social engineering

Wirespeed ADR catches threats in milliseconds by automating detection, investigation, and containment instead of routing alerts through a human review queue or LLM thinking loop. 

Wirespeed detected device-code authentication used to register multiple Azure AD devices under the same account and the creation of a suspicious mailbox rule.

By using if-then logic as a primary decision engine, Wirespeed delivers fast, repeatable detections. This includes monitoring for known signs of device code phishing — and containing threat actors before the attack escalates. 

Wirespeed detected device-code authentication used to register multiple Azure AD devices under the same account and the creation of a suspicious mailbox rule. Both behaviors indicate suspicious activity, so Wirespeed automatically disabled the account, revoked user sessions, and notified the client of next steps.

LIGHTNING-FAST SPEED. LASER PRECISION.

Wirespeed Automated Detection & Response 

Start your free 30-day trial >

* Incident response services are provided by Coalition Incident Response, Inc. (or one of it’s affiliates), dba Coalition Security, an affiliate of Coalition, Inc. Subject to availability.

This blog post is designed to provide general information on the topic presented and is not intended to construe or render legal or other professional services of any kind. If legal or other professional advice is required, the services of a professional should be sought. Neither Coalition nor any of its employees make any warranty of any kind, express or implied, or assume any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed. Any action you take upon the information contained herein is strictly at your own risk. Coalition and its affiliates will not be liable for any losses and damages in connection with your use or reliance upon the information. The blog post may include links to other third-party websites. These links are provided as a convenience only. Coalition does not endorse, have control over, nor assumes responsibility or liability for the content, privacy policy, or practices of any such third-party websites.

Copyright © 2026. All rights reserved. Coalition, Wirespeed and their associated logos are trademarks of Coalition, Inc.