The attack starts with an employee opening a link to a shared file. A Microsoft Copilot logo appears, along with a short code and a button labeled “Copy & Open.” That button takes them to Microsoft’s real sign-in page, where they enter the code, complete MFA, and land in their Outlook inbox.
Nothing looks wrong, but the employee has just approved an attacker’s access to their Microsoft 365 account. The attacker never sees a password, and the employee’s MFA does exactly what it was built to do.
Our Security team took apart the phishing kit behind this attack. Here’s what we found and what we recommend doing about it.
How the Phishing Kit Works
The kit involves a malicious web page that targets Microsoft Entra ID and Microsoft 365 accounts. The one we encountered uses Copilot branding, but its code also appears to support other themes, with a SharePoint-style lure likely set as the default.
The attack exploits a Microsoft feature called device code sign-in. This feature exists for devices without keyboards, such as conference room displays. You see a code on one screen and enter it on another device to complete authentication.
Here’s how the kit abuses that process:
- The phishing page displays a short code and a QR code, both pointing to Microsoft’s actual device sign-in page.
- A “Copy & Open” button copies the code and opens the Microsoft page in a pop-up.
- The employee enters the code, signs in, and completes MFA, unknowingly approving the attacker’s session.
- The attacker’s server generates a fresh code each time the phishing page loads, avoiding the 15-minute expiration window associated with codes sent by email.
- The page checks with the attacker’s server every second. Once the employee approves the sign-in, they’re redirected to their Outlook inbox.
The phishing kit we examined is built to evade security analysis. Its code is heavily scrambled, it blocks common inspection tools, and it redirects visitors when it detects attempts to examine the page. It also appears to be under active development.
Why Your Current Defenses May Not Catch It
Employees are taught to check web addresses before entering their credentials. That’s good advice, but it won’t expose this attack. The sign-in happens on Microsoft’s real website.
MFA may not stop it either. Phishing-resistant methods like FIDO2 security keys and passkeys are built to defeat fake login pages, but this attack doesn’t use one.
The technique itself isn’t new. In February 2025, Microsoft Threat Intelligence reported that a group it tracks as Storm-2372 had been conducting device code phishing since August 2024, targeting government agencies, healthcare, higher education, telecommunications, defense, and other sectors.
In September 2026, Microsoft reported that the EvilTokens phishing service had been linked to more than 12,000 compromised inboxes across over 10,000 organizations before Microsoft and its partners disrupted the operation.
While we haven’t tied the kit we analyzed to either Storm-2372 or EvilTokens, both campaigns show how widely attackers have adopted device code phishing.
Rogue Device Registration and Long-Term Access
The kit also appears designed to register an attacker-controlled device inside your Microsoft environment.
It requests access through a trusted Microsoft app called the Microsoft Authentication Broker, targeting the service responsible for registering devices in your tenant. The kit is configured to register an attacker’s computer as a Windows 11 device and, most likely, enroll that device in Windows Hello for Business.
Microsoft has documented this technique in previous attacks. In its investigation of Storm-2372, Microsoft described attackers using the Authentication Broker to register their own devices and obtain a Primary Refresh Token (PRT). Think of a PRT as a long-lived authentication key that lets the device continue signing in as the employee without requiring the usual MFA process.
In September 2026, Microsoft reported that in some cases, attackers registered new devices within 10 minutes of the initial compromise.
If this works:
- Access can survive a password reset.
- The attacker’s device can appear to be a trusted company device.
- The attacker may be able to operate for weeks before anyone notices.
We haven’t seen what happens on the attacker’s servers, so we can’t confirm that device registration has occurred. But based on the kit’s configuration, we’re highly confident this is what it’s designed to do.
When an Attacker Gets into the CFO’s Inbox
Picture an attacker with lasting access to your CFO’s or managing partner’s mailbox. They could:
- Redirect wire transfers and vendor payments through business email compromise.
- Read deal terms, investor updates, and board materials.
- Steal research data, client records, or sensitive technical information.
- Trigger regulatory reporting obligations.
For registered investment advisers, a breach like this may trigger incident response and customer notification requirements under SEC Regulation S-P. HIPAA may apply to life sciences and healthcare organizations. Defense contractors may face contractual cyber incident reporting requirements.
Private equity firms should consider the risks across their portfolios. A compromised inbox at one company could become a starting point for fraud targeting other companies in the portfolio.
Why Attackers Impersonate AI Tools
Employees are still getting familiar with Microsoft Copilot and other AI tools, including what their interfaces look like and how they’re supposed to work. A Copilot-branded page asking for a sign-in code can seem like one more unfamiliar step in a new application.
That’s what makes trusted branding useful to attackers. The kit uses Copilot visuals to make the request appear legitimate, then exploits Microsoft’s device code sign-in process. It has nothing to do with any vulnerability in Copilot itself.
Give employees one rule: Don’t enter a device sign-in code supplied through an unexpected email, chat message, or web page to open a document or use an AI tool.
If someone encounters this type of request, they should stop immediately and report it to IT or security.
How to Protect Against Device Code Phishing
Start with your existing security policies and controls. Note: Conditional Access requires a Microsoft Entra ID P1 license or higher.
1. Restrict Device Code Sign-In
Use a Conditional Access policy to block device code sign-in, allowing it only for a small, documented exception group. Microsoft recommends getting as close as possible to a full block. Tenants created on or after July 1, 2026 block this flow by default, but tenants using custom Conditional Access policies should confirm their settings.
Before enforcing the block, take a look at your sign-in logs to see who’s using device code authentication and why. Teams Rooms devices, shared displays, and some administrative tools may rely on it. Consider testing the policy in report-only mode to identify potential disruptions.
One big caution: Microsoft’s guidance for Teams devices recommends excluding the Device Registration Service from the block so device enrollment keeps working. That exclusion applies to every user covered by the policy, and it’s exactly the service this phishing kit targets. If you need the exception, use a separate policy scoped to specific Teams device accounts.
2. Limit Who Can Join or Register Devices
Allow only authorized admins or designated groups to add devices to your tenant. This gives you a backstop if a registration request slips past the device code block.
3. Require Managed, Compliant Devices
Require employees to use devices that your team manages and that meet your security baseline before they can access company data. That way, an attacker’s device gains little even if it gets registered.
4. Hunt for Past Exposure
Review sign-in logs for unexpected device code activity. Check device registration logs for new Windows devices nobody ordered. Start with executives and finance staff.
If you use Microsoft Defender, confirm that device code phishing and suspicious device registration detections are enabled.
5. Update Your Incident Response Plan
A password reset alone probably won’t remove this attacker.
Revoking sessions often only invalidates refresh tokens. Existing access tokens, on the other hand, can remain active for up to an hour. For a confirmed compromise, Microsoft recommends temporarily disabling the employee’s account for immediate containment.
From there, you should identify and disable any rogue devices, revoke refresh tokens, delete the associated device objects, and remove any unauthorized Windows Hello for Business keys or new sign-in methods. Reset the password last.
6. Brief Your Employees
Show employees an example of the lure and explain how device code phishing works. Reinforce the rule about unexpected sign-in codes, and make it easy for people to report suspicious requests without fear of blame.
Request the Full Technical Report
The Copilot branding is one part of this attack. The kit we analyzed already has a SharePoint version built in, and EvilTokens offered its customers 44 themes to choose from. Blocking unnecessary device code sign-ins closes off this attack path, no matter which logo the next lure wears.
Coretelligent’s Security team has prepared a detailed technical report on the phishing kit, including technical indicators and additional findings. Because of what it contains, we’re sharing the report directly with security and IT leaders.
If you’d like a copy, or want to review your Microsoft 365 sign-in policies, reach out to our Security team. We’d be happy to talk.