In This Article
- The attack that bypasses MFA without breaking it
- How EvilTokens weaponized a legitimate OAuth feature
- The escalation timeline: from 3 cases to hundreds per day
- Why financial institutions are uniquely exposed
- The detection signals your Entra ID logs already hold
- The Conditional Access policy that shuts this down
- When prevention misses: the reactive revocation layer
- How ABT hardens financial institution tenants
- Frequently Asked Questions
A Microsoft 365 phishing campaign has been running since mid-February, and the number that matters is not the one most headlines have been citing. Huntress reported 340+ compromised organizations through March 19. By April 6, Microsoft Defender Security Research described the same campaign as "10 to 15 distinct campaigns launching every 24 hours, with hundreds of organizations being compromised daily." That is not a trend. That is an active, accelerating incident.
The attack is not clever in the way that zero-days are clever. It does not exploit a software bug. It abuses a feature of OAuth 2.0 that was designed to help printers and smart TVs sign in to Microsoft 365. The user who gets phished enters a short code on the real Microsoft login page, from their real browser, using their real password and real multifactor authentication. Everything works the way it is supposed to work. The tokens Microsoft issues at the end of that flow go to the attacker instead of the user.
If you run a credit union, community bank, or mortgage company on Microsoft 365, the fix is closer to a toggle than a project. Microsoft now ships a pre-built Conditional Access managed policy called "Block device code flow" that blocks this attack tenant-wide with a single click. Most financial institution tenants have no legitimate device code flow usage at all, so flipping the policy on is a few-minute operation. This article walks through what is happening, why multifactor authentication does not stop it, what "legitimate device code use" actually looks like when you audit your own tenant, and the specific sequence of prevention, detection, and reactive revocation we recommend this week.
The attack that bypasses MFA without breaking it
Multifactor authentication is doing its job. That is the part that makes this attack different from the credential-stuffing campaigns most financial institution defenders have been training against for a decade. The phishing kit behind the current wave, called EvilTokens, does not try to capture a password. It does not intercept an MFA code. It does not man-in-the-middle the login page. It asks the user to do exactly what Microsoft's own documentation says to do.
Here is what a victim sees. An email arrives from a vendor the user has done business with, often through a real email security gateway redirect such as Cisco SafeLinks, Trend Micro URL Protection, or Mimecast URL Protection. One observed attack chain was triple-wrapped through all three of those redirect services in sequence before landing on the final page. The lure is usually a document the user needs to review or sign: a construction RFP, a DocuSign envelope, a SharePoint file, an Adobe Acrobat Sign request, a voicemail transcript. The user clicks. The page loads on Cloudflare's workers.dev platform, which passes every DNS and web filter because Cloudflare is trusted globally. The page shows a short code and a "Continue to Microsoft" button.
The user clicks the button. Their browser opens microsoft.com/devicelogin. That is the real Microsoft page with a real SSL certificate. The user enters the code, enters their password, completes their MFA challenge, and sees a success screen. Every security control that was supposed to protect the identity layer did its job correctly. Microsoft then issues an access token and a refresh token, and hands both to the attacker's polling script running on Railway.com infrastructure.
A legitimate Microsoft login page, asking for a short code they were instructed to enter. They sign in with their real password, complete MFA, and see a confirmation screen. Nothing looks wrong because nothing is wrong on their side.
Microsoft issues a valid access token and a valid refresh token bound to the session the attacker started, not the session the user thinks they just authenticated. The attacker polls Microsoft's token endpoint on a 5-second loop. The moment MFA completes, they have a working session.
Device code flow is defined in RFC 8628. It is the protocol Microsoft uses to let devices that cannot display a browser, such as conference room Teams panels and some IoT sensors, get users signed in from a different device. The flow assumes the user and the device that requested the code are the same trust boundary. EvilTokens breaks that assumption by tricking the user into entering a code that an attacker generated instead of a code their own device generated.
MFA is not the control that stops this attack
Multifactor authentication validates the user during the sign-in event. The tokens Microsoft issues after a successful sign-in are bearer tokens: whoever holds them can use them. In device code phishing, MFA runs correctly, and then the tokens are handed to the attacker's session. Adding a second factor, a third factor, or passkey-based authentication does not change the outcome. The fix is to remove device code flow from the attack surface, not to add more authentication layers on top of it.
How EvilTokens weaponized a legitimate OAuth feature
The EvilTokens Phishing-as-a-Service platform first advertised itself on the NOIRLEGACY GROUP Telegram channel on February 16, 2026. Huntress observed the first compromises from Railway-hosted infrastructure on February 19 and February 24. By March 2 the operation had scaled up, and by March 19 Huntress had confirmed 344 compromised organizations across the United States, Canada, Australia, New Zealand, and Germany. By March 23, Huntress had blocked an additional 113 attempts on top of that figure.
The kit sells for $1,500 as a one-time fee plus a $500 monthly license for the active phishing page code and backend API key. Affiliates can also buy a $600 B2B Sender product and a $1,000 SMTP Sender. Payment goes through NOWPayments in cryptocurrency. This is not a niche nation-state tool. It is a commoditized subscription service with a Telegram support bot, role-based dashboards for affiliate operators, and customer-facing documentation. Anyone with $2,000 and a little patience can run this campaign.
What made the older version of device code phishing hard to operate at scale was the 15-minute timer on device codes. An attacker had to pre-generate a code, send a phishing email, and hope the victim clicked, navigated through the redirects, and completed authentication all before the clock ran out. EvilTokens solved that timing problem with dynamic device code generation. The code is not generated until the victim arrives on the phishing page. A background script calls Microsoft's /api/device/start endpoint in real time, receives a fresh user code, and displays it on the page. The 15-minute countdown only begins at the moment the victim sees the page. The script also auto-copies the code to the victim's clipboard with navigator.clipboard.writeText, so all the victim has to do is paste and confirm.
Attacker queries Microsoft's GetCredentialType API 10 to 15 days before delivery to confirm target email addresses are active.
Phishing email arrives wrapped in a real email security vendor redirect, often triple-wrapped through SafeLinks, Trend Micro, and Mimecast.
Cloudflare workers.dev page loads. Script generates a fresh device code on demand and auto-copies it to the victim's clipboard.
Victim pastes the code into microsoft.com/devicelogin, enters password, completes MFA. Every security control runs correctly.
Microsoft issues access and refresh tokens to the attacker's polling script on Railway. The attacker now has a valid session bound to the user account.
The attacker then replays those tokens from a narrow set of Railway IP addresses that have no reputation penalty in Microsoft Identity Protection. Three IPs handle 84 percent of observed events: 162.220.234.41 with 254 events, 162.220.234.66 with 132, and 162.220.232.57 with 97. The dominant technique is Common Model Session Interface session replay, which accounts for 87.4 percent of observed attacks. Because the traffic originates from a PaaS provider with clean IP reputation, Microsoft's risk scoring does not flag it as anomalous.
The escalation timeline: from three cases to hundreds per day
Underneath the escalation is a familiar pattern for how cybercriminal tools mature. A technique starts with nation-state actors. Microsoft has been tracking a Russia-aligned group, Storm-2372, running device code phishing campaigns since August 2024. In February 2025 the group added a specific Microsoft Authentication Broker client ID to its rotation, which let them register attacker-controlled devices inside victim tenants and pull Primary Refresh Tokens for ongoing persistence. Volexity found at least one additional Russian actor, UTA0307, building rapport with targets through multi-message conversations before sending the phishing link so the target would be engaged and actively clicking within the 15-minute window.
Then the technique becomes a product. EvilTokens is the commoditization event. Proofpoint has now tracked financially motivated threat actors such as TA2723 using SquarePhish and Graphish tooling to automate device code phishing at volume. Scattered LAPSUS$ Hunters, formed from the August 2025 merger of Scattered Spider, LAPSUS$, and ShinyHunters, runs device code phishing as part of broader extortion-as-a-service operations. Sixteen Telegram channels promote their offerings. Over 1,000 organizations have been compromised, with more than 1.5 billion stolen records claimed across their campaigns. Some of those operations are targeting Salesforce. Some are targeting Microsoft 365. The same technique works against both.
Why financial institutions are uniquely exposed
The Huntress victim breakdown for the March 2 through March 19 window covered every industry vertical the attackers could reach. Construction and Trades led numerically with 26 organizations, because the construction RFP lure was the workhorse of the campaign. Law firms came next with 18, ranking first in sensitivity because compromised attorney-client privileged communications, wire instructions, and mergers and acquisitions data are the crown jewels of law firm data. The Finance and Insurance category covered 12 organizations, including private equity firms, pension administrators, and insurance claims operations.
| Sector | Orgs compromised | Sensitivity of compromised data |
|---|---|---|
| Construction and Trades | 26 | Medium (project RFPs, vendor wire info) |
| Law Firms | 18 | Critical (privileged communications, M&A data) |
| Nonprofit & Social Services | 15 | Medium (donor records, beneficiary PII) |
| Real Estate | 14 | High (transaction records, closing wire instructions) |
| Manufacturing | 14 | Medium (vendor invoices, purchase orders, BEC fuel) |
| Finance & Insurance | 12 | High (PE transactions, pension admin, insurance claims) |
| Healthcare | 11 | High (PHI, HIPAA exposure) |
| Government & Public Safety | 8 | Medium (DA offices, police, fire, tax) |
| Indigenous & First Nations | 4 | Medium (member rolls, enrollment records) |
| Labor Unions | 2 | Medium (member data, benefits admin) |
Public reporting did not specifically name compromised credit unions, community banks, or mortgage companies in the Huntress data. That absence is almost certainly a reporting artifact rather than a threat model difference. Device code phishing exploits a protocol feature that exists in every Microsoft 365 tenant. A credit union tenant is the same attack surface as a law firm tenant. The only meaningful difference between a financial institution and the sectors already documented is how much damage an attacker can do once they have a token.
Why the financial institution outcome is worse
A compromised user account inside a bank, credit union, or mortgage company does not just leak data. It can initiate wire transfers through treasury workstations that share a network trust boundary with the compromised endpoint. The Stryker cyberattack showed how quickly that blast radius expands once tokens are in attacker hands. EvilTokens has a built-in Business Email Compromise automation module that analyzes captured mailboxes for finance-related threads and auto-drafts wire fraud messages. The average attacker dwell time between initial compromise and first BEC attempt in the finance vertical has been trending down, and Push Security reports the automation cuts it to minutes. One compromised credential in a mortgage company can also authorize fraudulent loan products or forward sensitive borrower PII to external accounts.
There is also a regulatory overlay. A device code phishing compromise affecting treasury, operations, or compliance personnel at a federally supervised institution may trigger mandatory incident notification under current FFIEC Cybersecurity Assessment Tool and NIST CSF 2.0 guidance, depending on the institution's size and primary regulator. Mortgage companies that service loans on behalf of Fannie Mae and Freddie Mac carry additional GSE-level fraud detection and loss mitigation obligations. The blast radius of a single compromised credential is not the same as the blast radius outside financial services.
Financial institutions also carry a specific self-inflicted wound in how they use Microsoft 365. Treasury and operations teams frequently rely on command-line interfaces and PowerShell scripts to interact with Azure key management, payment processor APIs, and internal banking systems. Those workflows often use device code flow as the authentication method because it works on systems without interactive browsers. Legitimate device code usage creates policy exceptions. Policy exceptions, if not carefully managed, become the entry points attackers probe for. The solution is not to disable the legitimate workflows. The solution is to scope the Conditional Access policy correctly, with an exclusion group that contains only the specific user accounts tied to documented, approved device code use cases, and to audit that list on a recurring schedule.
A credit union tenant is the same attack surface as a law firm tenant. What changes is how much damage the attacker can do once they have a token.
Not sure if your Conditional Access policies block this?
Our Security Grade runs a read-only audit of your Microsoft 365 tenant, including the specific Conditional Access gaps that let EvilTokens-style attacks through. You get a report that names the users, the flows, and the fix order by severity.
Get Your Security Grade Talk to a Security SpecialistThe detection signals your Entra ID logs already hold
Device code phishing is invisible in the moment. It becomes visible when you correlate three signals that appear in Microsoft Entra ID sign-in logs and the Microsoft Graph Activity Log. Every Microsoft 365 tenant with at least a P1 Entra ID license has these logs. Most financial institution tenants are not reviewing them against the specific patterns this campaign leaves behind.
The first signal is the authentication protocol field itself. Sign-in log entries for device code authentication carry authenticationProtocol: deviceCode and originalTransferMethod: deviceCodeFlow. If your institution does not use device code flow for any legitimate operational purpose, every one of these events is an immediate investigation candidate. Most financial institution tenants have fewer than a dozen legitimate device code events per month, and they all come from known service accounts or Teams Room Android panels. Anything outside that short list is a red flag.
The second signal is an error code sequence. A pause in device code authentication produces Microsoft error code 50199, which reads "For security reasons, user confirmation is required for this request. Please repeat the request allowing user interaction." When a victim completes the flow, error code 50199 is immediately followed by success code 0 within a 5-minute window. That sequence is not consistent with normal user behavior, and it is the strongest single detection pattern for this campaign. The Microsoft Defender XDR hunting query that returns these pairs is documented in the Microsoft Security Blog April 6 update.
The third signal is session correlation. Successful device code phishing produces three sign-in events that share a single Session ID but have inconsistent Location and UserAgent fields. The victim signs in from their real browser in their real location. The attacker's token replay comes from a Railway.com IP (most often in 162.220.232.0/22 or 162.220.234.0/22) with a synthetic user agent such as BAV2ROPC, a nonexistent iPhone version, or Linux Chrome 146 (X11; Linux x86_64). That user agent combination is impossible on any real client device. The third event is usually token refresh traffic.
Dsreg/10.0 or DeviceRegistrationClient indicate automated registration tooling.The Conditional Access policy that shuts this down
Microsoft has been direct about the recommendation: block device code flow wherever it is not actively needed. There are two ways to do it, and most financial institution tenants should pick the first one. In early 2026 Microsoft shipped a pre-built managed Conditional Access policy called "Block device code flow." Open the Microsoft Entra admin center, go to Protection, Conditional Access, Managed Policies, find the policy in the list, and enable it. That is the whole deployment. Microsoft provides the policy pre-scoped, pre-configured, and pre-tested. No exclusion group to build, no conditions to author, no session controls to tune. For an FI tenant that does not use device code flow for any legitimate workflow, the managed policy is the correct answer and it takes about a minute.
What "legitimate device code use" actually looks like in your tenant
If you want to audit your own environment before flipping the policy on, or if you suspect you have a few legitimate device code flow users and want to preserve them, the realistic legitimate-use list in a financial institution tenant is short. Microsoft Teams Room Android panels in branch conference rooms need device code flow because the room hardware cannot display a sign-in browser. Microsoft Teams Panels, which are the schedule screens mounted outside conference rooms, use the same pattern. Universal Print printers authenticate to the print service through device code flow when they first join the tenant. Digital signage and IoT devices signing into Microsoft 365 for content delivery use device code flow. Administrators occasionally run the Azure CLI from a jumpbox with no browser using az login --use-device-code. Smart TVs installed in lobbies or training rooms use it to sign into Microsoft services. That is the complete realistic list, and most credit unions and community banks surface zero or one or two of these when they audit. Most institutions we onboard have none.
The manual policy, configured location-first
For institutions that have confirmed legitimate device code flow users and need to keep them working, the manual policy path gives you the granular control. The architecture here matters. The naive version of this policy adds legitimate service accounts to an exclusion list and lets them use device code flow from anywhere on the internet. That configuration has a failure mode: if any of those excluded accounts ever gets phished, the attacker has global access to device code flow through a trusted identity. The exclusion list is only as safe as the accounts on it, and attackers know which accounts tend to end up on exclusion lists. Microsoft's own Conditional Access documentation recommends against that pattern.
The stronger pattern, and the one Microsoft recommends, is to flip the architecture. Do not exclude accounts. Exclude network locations. Create a Named Location in Conditional Access that contains only the trusted IP ranges where legitimate device code flow sign-ins actually originate: the conference room subnet where Teams Room Android panels operate, the printer VLAN where Universal Print devices sit, the static IP of your administrative jump server. Build the block policy to apply to all users and all workload identities, with no user-level exclusions, and exclude the Named Location from the block. The result: device code flow is blocked from the entire public internet, and allowed only when the request originates from one of your trusted internal networks. Any user or service account that gets phished cannot replay the token from outside those networks because the policy rejects it at the sign-in event.
One implementation note worth flagging before you start: the Microsoft-managed "Block device code flow" policy is read-only. You cannot add a Named Location, a device platform filter, or any other condition to it directly. The managed policy is a one-click toggle and Microsoft owns its configuration. To layer location-based exclusions or device-attribute filters, you author your own custom Conditional Access policy that runs alongside the managed one. The policy recipe runs from the Microsoft Entra admin center under Protection > Conditional Access > Policies. Create a new policy. Under Assignments, select all users and all workload identities under Include with no exclusions. Under Target resources, select all resources. Under Conditions > Authentication Flows, set Configure to Yes and select Device code flow. Under Conditions > Locations, set Include to Any location and Exclude to the Named Location you built for the trusted ranges. Under Access controls > Grant, select Block access. Set Enable policy to Report-only mode for the first week. For Microsoft Teams Room Android panels specifically, Microsoft recommends layering a Device platform filter for Android on top of the location rule, so only Android devices connecting from the conference room subnet are allowed the flow. That precision stops even a compromised workstation inside the office from abusing the exception.
Report-only mode is not a compromise. It is the correct deployment pattern. The policy evaluates every sign-in against the block rule without enforcing it, and writes the would-have-been-blocked outcome to the sign-in logs. Review those logs daily for the first week. Any sign-in showing up as "would have been blocked" tells you one of two things. If it is a legitimate workflow originating from a source IP range you did not anticipate, you add that range to your Named Location. If it is not legitimate, you investigate. In our experience deploying this on financial institution tenants, the report-only week typically surfaces two to five legitimate workflows the institution did not know were using device code flow. Once their network ranges are in the Named Location allow list, flip the policy from Report-only to On and the attack path closes.
Two real-world considerations worth naming. First, if your organization routes traffic through a VPN, a ZTNA edge, or an SD-WAN appliance, the source IP Microsoft observes at the sign-in event is the egress IP of that appliance, not the original client IP. Define your Named Locations based on what Microsoft actually sees, which you can confirm from the sign-in log. Second, Teams Rooms behind variable or rotating SD-WAN egress may not have a stable public IP. If that is your environment, broader subnet ranges or a combination with device compliance signals may be required. Neither gotcha changes the architectural recommendation. It just means the Named Location definition needs to match the network reality of your tenant.
One pushback we hear from sophisticated IT directors at this point is whether existing "require compliant device" Conditional Access already blocks this attack. It does not, and the reason is structural. Microsoft evaluates the compliant device requirement at the user's sign-in event, against the user's compliant laptop where the device code is entered. The tokens are issued as a result of that legitimate user authentication and are not bound to the user's device. The attacker's polling server retrieves the tokens, and when it later replays them against Microsoft Graph or other resources, Conditional Access does not re-evaluate device compliance against the requesting client. Token Protection, the newer Microsoft feature that does bind tokens to a specific issuing device, has a narrower scope than the name suggests. It only binds Primary Refresh Tokens (not the OAuth access and refresh tokens that device code flow issues), only enforces against Exchange Online, SharePoint Online, and Microsoft Teams (not Microsoft Graph, which is what the attacker uses to read the mailbox), and only applies to native applications (not the server-side scripts that attacker infrastructure runs). It hardens token replay for users working in Outlook desktop and Teams desktop, but it does not cover the device code flow attack path. Continuous Access Evaluation does not re-evaluate static device compliance signals on token use either, and refresh tokens compound the gap because they generate new access tokens for up to ninety days without triggering CA re-evaluation. The control that actually closes this attack path is blocking device code flow itself. Compliant-device enforcement remains an excellent defense against AiTM phishing and unmanaged-device access, but it is not the right control for this specific attack class.
There is a parallel control that matters when the primary policy is delayed by a business process objection. You can add a separate Conditional Access Named Location containing the Railway CIDR ranges 162.220.232.0/22 and 162.220.234.0/22, then configure a block rule that targets that named location specifically for device code flow. This does not stop the attack in general, but it does stop the specific EvilTokens campaign from replaying tokens out of Railway infrastructure while the broader device code flow block is being negotiated internally.
Microsoft Security Research, April 6, 2026
What Microsoft's device code phishing detection already covers
Microsoft Defender for Office 365 provides pre-delivery detection that blocks device code phishing emails based on campaign-level signals, sender behavior, and message content rather than URL reputation alone. Microsoft Entra ID Protection surfaces anomalous device code authentication using authentication patterns and post-auth token acquisition. Microsoft Defender XDR issues alerts named "Suspicious Azure authentication through possible device code phishing" and "User account compromise via OAuth device code phishing" when the telemetry crosses the confidence threshold. Starting April 20, 2026, Security Copilot is included with every Microsoft 365 E5 license at no additional cost, and one of the twelve agents it runs is a Conditional Access optimization agent that can recommend the exact policy configuration to block device code flow for your tenant. Most financial institutions on E5 already have every detection control this article recommends. The question is whether the alerts are being reviewed and whether the recommended policies have been deployed.
When prevention misses: the reactive revocation layer
The managed Conditional Access policy stops the attack from getting a token in the first place. That is the right primary control, and for most financial institution tenants it is sufficient. But a serious defensive architecture also plans for the case where prevention fails, whether because the policy has not been deployed yet, the exclusion list got abused, a user workflow was grandfathered in for business reasons, or the attacker got a token before the policy was flipped from Report-only to On. When that happens, the question stops being "how do we block this" and becomes "how fast can we kill the token."
The reactive layer has three components that work together. The first is the Microsoft Graph API call revokeSignInSessions, which invalidates every refresh token for a specified user account. The call itself is a single HTTP POST. The second is Continuous Access Evaluation, a setting in Entra ID that tells Microsoft identity services to honor revocation signals in near real time rather than waiting for the default access-token expiration, which is typically an hour. With CAE enabled, the attacker's access tokens are invalidated within seconds of the revoke call. Without CAE, the attacker has up to sixty minutes of valid access after the revoke command lands. The third component, added to Entra ID admin center in February 2026, is a new "Revoke sessions" button that fires both actions from a single click by an administrator and invalidates MFA claims at the same time.
Those three controls are available in any tenant with Entra ID P1. The question for financial institutions is not whether to use them, but how quickly they fire after a detection signal lands. Manual revocation by a human admin reviewing the Entra sign-in log is too slow. By the time a human sees a suspicious 50199-then-success pattern in the logs, the attacker has already used the token for mailbox enumeration, bulk financial-keyword queries, and potentially an outbound wire-fraud draft. The gap that matters is the gap between detection and revocation, and automating it is what separates a tenant that survives device code phishing from a tenant that becomes an incident report.
This is where ABT's Tokenator sits in the stack. Tokenator is the automation layer that watches Entra ID sign-in telemetry for the specific device code phishing signal patterns documented in the detection section above, and when any of them fire, it calls revokeSignInSessions for the affected user without waiting for a human to click anything. With CAE enabled in the tenant (which Tokenator enforces as a baseline), the attacker's tokens die in seconds. Tokenator handles the followup too: disables the affected account pending investigation, removes any unauthorized device registrations that appeared during the compromise window, and raises the incident to the Guardian managed service for forensic review. The combination of the managed Conditional Access policy as prevention, the Entra ID sign-in log signals as detection, and Tokenator plus CAE as reactive revocation is what we deploy as the defense-in-depth baseline for every financial institution tenant on Guardian.
How ABT hardens financial institution tenants
Guardian is the managed security operating model ABT runs for financial institution tenants. For this specific attack, the Guardian baseline includes device code flow blocked by Conditional Access through a location-first Named Location pattern, continuous monitoring of Entra ID sign-in logs for the 50199-then-success pattern, network-level blocking of the Railway CIDR ranges, and Continuous Access Evaluation enabled across the tenant. None of that is proprietary. The configurations are public in Microsoft Learn. The reason financial institutions still get hit is not that the controls are unknown. It is that nobody has had the time to run the deployment, test it, and maintain the exclusion list.
Our hardening sprint for a new financial institution tenant takes the first 90 days after onboarding. During that window we deploy the device code flow block in report-only mode during week one, clear the exclusion list during week two, enforce the policy during week three, and establish the daily review cadence for the 50199 pattern during week four. For institutions already on an Entra ID security assessment, this is one of the checks our read-only scan runs, and it is one of the findings we fix before handing the tenant back.
The underlying pattern here matters more than the specific attack. Most Microsoft 365 identity attacks in 2026 are not password attacks. They are OAuth authorization attacks, consent phishing attacks, or protocol feature abuse. Each of them works because of a legitimate feature that most tenants never turn off because nobody ever told them the feature was optional. A Conditional Access posture that blocks every authentication flow not actively in use is the defensive equivalent of disabling legacy authentication in 2020. It is not clever. It is the baseline.
The difference between a tenant that survives the current wave and a tenant that becomes an incident report is almost always a timing problem. An unmanaged tenant reads the advisory, routes it to a ticket, drafts a policy, tests it in a dev tenant, schedules a change window, and rolls the policy out over the next thirty to ninety days while the attacker is still inside. A Guardian-managed tenant handles the same advisory through a different workflow. Significant Microsoft advisories get monitored continuously. When something rises to the significance level of the current EvilTokens wave, the first response is not to flip Conditional Access policies across the book, because flipping the policy is the blunt instrument that carries user-disruption risk. The first response is a targeted Tokenator detection signal that watches for the attack pattern in real time. When the signal fires, Tokenator revokes the stolen tokens the moment it discovers one. With Continuous Access Evaluation enabled, the attacker's session dies in seconds. The broader managed Conditional Access policy sweep follows the same week when the signal warrants it.
That time gap is the real story of the current wave. Every control named in this article is available to every tenant with an Entra ID P1 license. Microsoft ships the managed Conditional Access policy for free. The Entra ID sign-in logs, Continuous Access Evaluation, and the revokeSignInSessions Graph API call are all included. Internal IT teams are not missing a tool. They are missing a calendar, a runbook, and the organizational pressure to deploy the controls today instead of scheduling them for the next change window. Guardian is ABT's answer to that gap: a runbook that applies consistently across our financial institution tenants, a coordinated sweep when a new attack like EvilTokens rises to significance, and the Tokenator detection layer that revokes stolen tokens the moment suspicious telemetry matches the attack pattern, without waiting for a daily log sweep to catch it.
What to do this week
1) Deploy a Conditional Access policy that blocks device code flow in report-only mode. 2) Review the report-only output daily for seven days and build the exclusion group from the actual legitimate users it surfaces. 3) Flip the policy from Report-only to On. 4) Add a Named Location containing 162.220.232.0/22 and 162.220.234.0/22 and block those IPs at the Conditional Access layer. 5) Enable Continuous Access Evaluation if it is not already on. 6) Set up an alert on the Entra ID sign-in pattern of error code 50199 followed by success code 0 within 5 minutes for the same user. Most tenants with E3 or E5 already have every control needed to execute all six steps.
Frequently Asked Questions
Device code phishing tricks a user into entering a short authentication code on Microsoft's real sign-in page rather than a fake one. The user's password and multifactor authentication both run correctly on genuine Microsoft infrastructure. When authentication completes, Microsoft issues tokens bound to the attacker's session rather than the user's. Because the attack abuses a legitimate OAuth 2.0 protocol feature designed for input-constrained devices, traditional phishing defenses that look for fake domains, expired certificates, or credential harvesting pages do not catch it.
Multifactor authentication validates the user's identity during the sign-in event. The tokens Microsoft issues after a successful sign-in are bearer tokens that grant access to whoever holds them. In device code phishing, MFA runs correctly, and Microsoft then hands the tokens to the attacker's polling script rather than to the victim's device. Adding more authentication factors to the flow does not change the outcome because the vulnerability is in how tokens are delivered, not in how identity is verified. The correct mitigation is to block device code flow entirely through Conditional Access for users and applications that do not need it.
Huntress documented 344 compromised organizations in the March 2 to March 19, 2026 window across construction, law firms, nonprofits, real estate, manufacturing, finance and insurance, healthcare, government, Indigenous and First Nations organizations, and labor unions. The victim geography spans the United States, Canada, Australia, New Zealand, and Germany. By April 6, Microsoft Defender Security Research reported the broader device code phishing ecosystem compromising hundreds of new organizations per day. Financial services institutions of every size are in scope because the attack exploits a Microsoft 365 protocol feature rather than a vertical-specific weakness.
The simplest path is the pre-built managed Conditional Access policy Microsoft shipped in early 2026. Open the Microsoft Entra admin center, go to Protection, Conditional Access, Managed Policies, and enable "Block device code flow." That single toggle is the complete deployment for tenants that do not use device code flow for any legitimate workflow. For institutions that need to preserve device code flow for specific hardware like Microsoft Teams Room Android panels or Universal Print printers, author the policy manually with a location-first architecture: instead of excluding specific user or service accounts, create a Conditional Access Named Location containing only the trusted internal network ranges where that hardware operates, then build the block policy to apply to all users and workload identities and exclude the Named Location from the block. Microsoft recommends this pattern over account-level exclusions because an excluded account that gets phished is still globally trusted, while an excluded network location is scoped to physical reality. Start the policy in Report-only mode for one week to surface any legitimate workflows whose source IP ranges need to be added to the Named Location, then flip to On. No additional Microsoft licensing is required beyond Entra ID P1.
No. Microsoft evaluates the compliant device requirement at the user's sign-in event, against the user's compliant laptop where the device code is entered. The tokens are issued as a result of that legitimate authentication and are not bound to the user's device. The attacker's polling server retrieves those tokens and replays them against Microsoft 365 resources, and Conditional Access does not re-evaluate device compliance on token use. Token Protection, the newer Microsoft feature that does bind tokens to a specific device, only applies to a narrow set of supported native applications and does not cover the device code flow scenario. Refresh tokens compound the gap because they generate new access tokens for up to ninety days without triggering re-evaluation. The control that actually blocks this attack is blocking device code flow itself, either via Microsoft's pre-built managed policy or a manual location-first Conditional Access policy. Compliant-device enforcement remains valuable defense-in-depth against other attack classes, but it is not the right control for device code phishing.
No. Token Protection is a newer Conditional Access session control that binds tokens to the device they were issued on, but it has a narrow scope that does not cover the device code flow attack path. Microsoft's documentation is specific on three points. First, Token Protection only binds Primary Refresh Tokens, not the OAuth access tokens and refresh tokens that device code flow issues. Second, Token Protection only enforces against Exchange Online, SharePoint Online, and Microsoft Teams. Microsoft Graph, which is what the attacker uses to read the mailbox and set up business email compromise, is not in the supported resource list. Third, Token Protection only applies to native applications, not to the browser-based or server-side clients that attacker infrastructure uses. The net effect is that Token Protection hardens token replay for users working in Outlook desktop, OneDrive sync, and Teams desktop, but it does not interrupt the EvilTokens attack path. Blocking device code flow with Conditional Access is the control that closes the path.
Query the Entra ID sign-in logs for entries where authenticationProtocol equals deviceCode over the last 30 days. Correlate those events by Session ID and look for pairs where error code 50199 is followed by success code 0 within a 5-minute window. Check the originating IP addresses for the Railway CIDR ranges 162.220.232.0/22 and 162.220.234.0/22. Search the Microsoft Graph Activity Log for bulk mailbox queries containing terms like "wire transfer" or "invoice" within minutes of those authentication events. Look for new device registrations in Entra ID within 48 hours of suspicious sign-ins. If any of those signals appear for a user, treat the account as compromised, revoke refresh tokens through the Microsoft Graph API, and initiate the standard response procedure.
ABT configures the device code flow Conditional Access block during the 90-day hardening sprint at the start of every financial institution tenant engagement. The deployment runs in report-only mode for the first week so the exclusion group reflects the institution's actual legitimate use, then enforcement activates in week three. We also deploy Named Location blocks for the Railway CIDR ranges, enable Continuous Access Evaluation, and set up daily review of Entra ID sign-in logs for the 50199-then-success pattern that indicates device code phishing. For institutions already on the Guardian managed service, these controls are maintained and audited continuously. For institutions not yet onboarded, the Security Grade assessment surfaces the specific gap and the fix recommendation before any engagement begins.
Is your Microsoft 365 tenant hardened against device code phishing?
Our Security Grade is a read-only audit that runs against your tenant and reports the specific Conditional Access gaps, including device code flow, that let EvilTokens-style attacks through. No calls until you see the report.
Get Your Security Grade Talk to a Security Specialist