Device code phishing abuses a real Microsoft 365 sign-in flow. The OAuth device authorization flow exists so that devices with limited input options (smart TVs, conference room displays, CLI tools) can let a user authenticate on a second device by entering a short code. An attacker starts that flow, sends your user the code with a plausible pretext, and the user completes authentication on a genuine Microsoft page. Original reporting for this article comes from Huntress.

There is no fake login portal to spot and no password to phish. MFA may still fire, and the user may still approve it, because the sign-in is legitimate from Microsoft's perspective. What the attacker walks away with is a token, which is what actually grants access to mail, files, and Teams data.

Huntress reports a notable influx of these attacks in 2026. An earlier wave ran through Railway, a platform-as-a-service, and was attributed to the EvilTokens phishing-as-a-service platform. A second wave came from IP addresses tied to a VPS reseller called BL Networks, starting April 13, 2026 and continuing as of the report's writing.

The volume is concrete. Between April 13 and April 30, Huntress identified 533 authentication events tied to BL Networks from a single address, 216.203.20[.]95.

113 successful logins originated from BL Networks in a 48-hour window between April 20 and April 21.

By May the activity had spread across several IPs and subnets, including 193.149.176[.]151 and 45.61.136[.]129. Between July 3 and July 27, Huntress recorded 26 critical-severity incidents across 23 identities.

The service model is the part that changes your exposure math. When kits like EvilTokens, and reportedly Kali365-aligned tooling, package the lure, the hosting, and the token handling for paying customers, the attacker no longer needs to understand OAuth to run the attack. Multiple unrelated operators can run the same technique against your tenant at the same time, and each one rotates infrastructure faster than reputation-based controls update.

How EvilTokens and Kali365 Abuse Device Code Flows

The two waves differ mainly in where the operator sits. The earlier EvilTokens phishing-as-a-service activity ran through Railway, a platform-as-a-service marketed for vibe coding, which meant the sign-in traffic arrived from a cloud provider most commercial controls treat as normal developer infrastructure. The second wave arrives from BL Networks (also tracked as BitLaunch or BLNWX), a VPS reseller operating under AS399629 since at least 2017 according to Bushido Token Threat Intel.

That hosting choice is the operational core of the technique. A reseller sells Linux and Windows instances to anyone, so the same autonomous system carries small hosting companies serving local businesses alongside spam infrastructure, botnet nodes, and phishing pages. An access token replayed from that ASN does not stand out on reputation alone.

The chain, as Huntress observed it, runs through steps that are individually legitimate:

• The operator provisions a disposable VPS instance and initiates the authorization request against Microsoft's own endpoints.
• The resulting short code is delivered to the target with a pretext, and the victim completes the sign-in on a genuine Microsoft page.
• The operator's host polls for completion and receives access and refresh tokens issued to the app the operator selected.
• Subsequent mailbox and Graph activity originates from the VPS, appearing in tenant logs as ordinary UserLoggedIn events tied to a real identity.

Mapped to MITRE ATT&CK, this is Acquire Infrastructure: Virtual Private Server (T1583.003) feeding Steal Application Access Token (T1528), followed by Use Alternate Authentication Material: Application Access Token (T1550.001) and Valid Accounts: Cloud Accounts (T1078.004). For your business, that sequence means the intrusion is recorded as a successful, compliant login by a legitimate employee rather than as an attack.

The infrastructure progression is documented and worth keeping in your indicator set. Huntress first saw suspicious Microsoft 365 authentication tied to BL Networks on April 13, 2026, with every early incident tracing to a single address, 216.203.20[.]95. By May the activity spread across several IPs in different subnets, including 193.149.176[.]151, 193.149.176[.]238, and 45.61.136[.]129.

Volume from that first address shows how quickly token abuse converts into account access.

Activity has since declined without stopping. Between July 3 and July 27, Huntress recorded 26 critical-severity incidents linked to BL Networks spanning 23 identities. Cross-tenant clustering at that scale is what pushed the team to discuss classifying the provider as adversary infrastructure, with the disproportionate share of device code logins cited as the deciding factor.

What separates this from earlier credential phishing is the post-authentication half. There is no captured password to rotate and no attacker-controlled login page to take down, so containment turns on token and session lifetime rather than on removing infrastructure. Operators rotate lures, hosting, and redirect chains faster than block lists get updated, which is why the same tradecraft resurfaces under different names.

Whether an internal team files this activity under EvilTokens, Railway, or Kali365, the components stay constant: legitimate cloud services for hosting, Microsoft's real authentication pages for the sign-in, disposable lure infrastructure, and token-centric tradecraft after access is granted. Treating it as a stable attack pattern is more useful for investigation than tracking each brand separately.

Business and Compliance Risk from Compromised OAuth Tokens

A valid OAuth token is a bearer credential. Whoever holds it is treated as the user until it expires or someone revokes it, which means the attacker does not need your user's password and never has to enter it again.

That changes what a compromise looks like in your environment. A password reset, the first reflex for most help desks, does not invalidate an already-issued refresh token, so the intruder keeps reading mail and files while your ticket shows the incident as resolved. Conditional access policies are evaluated when the token is issued, not on every subsequent API call, so a session that passed your checks once can keep operating from infrastructure your policy would have blocked.

What the token unlocks depends on the scopes granted during that sign-in, and in Microsoft 365 that typically covers mail, files, chat, and directory reads. In practice that means an attacker with a working session can enumerate your SharePoint and OneDrive content, pull mailbox history, read Teams conversations, and map your org chart to pick the next target. Huntress described this as token-centric post-compromise tradecraft, and the important part for you is that every one of those actions is performed by an authenticated, authorized identity.

The volume in this campaign shows how quickly that scales past a single victim.

Twenty-three separate identities means twenty-three separate scope reviews, mailbox audits, and potential notification decisions. If those identities sit in finance, the exposure is payment instructions, vendor banking details, and invoice threads that support business email compromise. If they sit in a clinical or claims workflow, the exposure is patient records. High-privilege accounts (global administrators, helpdesk operators, anyone with delegated mailbox access) widen the blast radius because their tokens carry the permissions attached to those roles.

Your compliance obligations attach to access, not to whether files were copied. Most breach notification regimes trigger on unauthorized access to regulated data, and a valid token that touched a mailbox containing protected health information, cardholder data, or client financial records is unauthorized access by an outside party. Proving otherwise requires audit logs granular enough to show which objects the session read, and if you cannot produce that evidence, the conservative reading is that everything reachable was reached.

There is a second compliance problem underneath the first. Regulators and cyber insurers increasingly treat token compromise as evidence of an access governance gap rather than a user error, because the sign-in was permitted by your own configuration. Auditors will ask why the device authorization flow was enabled for accounts that had no device needing it, and why sessions from a VPS reseller's autonomous system were acceptable for a user who works from one country and one office.

The cost profile differs from ransomware. You may face no encryption event and no downtime, and instead absorb forensic hours across dozens of identities, outside counsel review, regulator correspondence, and client notification. For firms holding money or health data on behalf of others, contractual notification duties to those clients often arrive before the statutory ones do.

Assume MFA on its own did not stop this. The attacker used a legitimate Microsoft flow, and your user approved it.

Detection and Immediate Response for Device Code Phishing

The first thing to do today is pull your Microsoft 365 sign-in logs and filter on device code authentications, then check the source IP and hosting provider behind every success. In the campaign Huntress tracked, 533 events tied back to a single address (216.203.20[.]95) between April 13 and April 30, including 113 successful logins in a 48-hour window on April 20 and 21. If your tenant shows even a handful of device code sign-ins from hosting infrastructure your staff has no reason to use, treat those identities as compromised and move to containment.

Containment here means revoking refresh tokens and active sessions for the affected accounts, not resetting the password and closing the ticket. Do the revocation first, then investigate, because every minute the token stays valid is another minute of mailbox and file access under a legitimate identity.

Today

• Search sign-in and unified audit logs for clusters of successful UserLoggedIn events sharing one autonomous system or hosting provider across multiple users, even when the risk score is low.
• Add the published campaign addresses (193.149.176[.]151, 193.149.176[.]238, 45.61.136[.]129) to your hunting queries and block lists, understanding that operators rotate subnets.
• Revoke sessions and tokens for any identity that authenticated through a device code flow from unexpected infrastructure, and review mailbox rules, forwarding, and OAuth app grants created after that sign-in.
• Check for the same identity appearing across your other tenants or client environments, since this pattern showed up in 26 critical-severity incidents across 23 identities between July 3 and July 27.

Adlumin ITDR watches authentication behavior across the environments Capstone manages, correlating successful logins against the identity's normal locations and providers so device code sign-ins from a VPS reseller surface as an anomaly instead of a clean login.

This week

Audit which applications in your tenant are actually permitted to use the device authorization grant. Most organizations find the answer is a small set of CLI tools and conference room hardware, which means you can block the flow everywhere else with a conditional access policy targeting the device code authentication flow. That single policy removes the pretext an attacker needs, because a code sent to your user no longer completes an authentication.

While you are in conditional access, review how your policies handle token reuse. Policies evaluated only at issuance leave a gap once a token is in the attacker's hands, so require compliant or hybrid-joined devices for the applications holding your most sensitive mail and document stores. Also set an alert threshold your team will actually honor: repeated device code successes from one provider is enough evidence to contain, and waiting for confirmed attribution costs you access time.

Longer term

Move your high-value applications to phishing-resistant authentication such as FIDO2 security keys or Windows Hello for Business, and disable the device code grant on those applications outright. Where the flow must stay enabled, shorten refresh token lifetimes and require continuous access evaluation so revocation takes effect in near real time rather than at the next token refresh.

Finally, write the containment steps into your incident response plan as a named procedure: revoke tokens, review app consents, check inbox rules, then reset credentials. Help desks that reset the password first tend to record the incident as closed while access continues.

Hardening OAuth Configuration Against PhaaS Kits

Start with a Conditional Access policy that blocks the device code flow for everyone, then add exclusions only for the accounts and devices that genuinely need it. In Entra ID this lives under the authentication flows condition of a Conditional Access policy, where device code flow can be set to Block. Most tenants discover that the only real consumers are shared-room video systems, a handful of CLI and PowerShell users, and provisioning workflows for headless devices.

That single change removes the flow the attacker needs. Because it is a policy toggle and not a code change, you can stage it in report-only mode first, read which users and applications would have been blocked over a week or two, and build your exclusion group from evidence instead of guesswork.

Once the block is live, narrow what the exclusions can do rather than leaving them open:

• Scope the exclusion group to named trusted network locations so a permitted device code sign-in only succeeds from your office ranges or a known egress IP, which is where a conference room display or a build server actually sits.
• Bind the exclusion to specific client applications instead of all cloud apps, so a permitted flow reaches the Teams Rooms or administrative tooling it was created for and nothing else.
• Require compliant or hybrid-joined devices for those exclusions where the hardware is managed, so a rented VPS cannot satisfy the policy even with a valid code.

Token lifetime is your second lever, and it changes how long a successful compromise stays useful. Turn on Continuous Access Evaluation for the workloads that support it so revocation events and policy changes are enforced against long-lived access tokens mid-session rather than at the next refresh. Pair that with a sign-in frequency requirement on high-privilege roles and on access from outside your trusted locations, which forces reauthentication on a schedule you control.

Consent controls close the follow-on path. Set user consent for applications so that end users can only approve permissions for apps from verified publishers, and route everything else through an admin consent request workflow with a named reviewer. Then audit existing service principals and OAuth grants for consents nobody remembers approving, particularly ones holding mail, files, or directory read permissions. An attacker who registers or consents to an app inside your tenant keeps access that survives credential changes, so this review matters as much as the flow restriction itself.

Risk-based policy gives you the behavioral layer. Configure Entra ID Protection sign-in risk and user risk policies to require reauthentication or block outright at medium and above, and set them to act on the signals that fit this pattern: anonymous IP address, unfamiliar sign-in properties, and impossible travel. Your goal is that a token issued from hosting infrastructure your staff never uses triggers an enforcement action without an analyst reading a log first.

If you still authenticate through AD FS or another on-premises identity provider in a hybrid setup, the device code condition does not apply the same way. Use AD FS access control policies to restrict extranet access by group and network, enable extranet smart lockout, and confirm which relying parties permit token issuance to non-interactive clients. Moving authentication to cloud-managed credentials where you can is what puts these accounts back under Conditional Access.

The trade-off is real and worth naming to your stakeholders. A full block breaks headless device enrollment and some CLI workflows, and your help desk will field tickets for a few days. Narrowing the flow to named applications and trusted locations keeps those workflows running while removing the open path an attacker can use, which is why most organizations land there instead of on a permanent global block.

Key Takeaway: Treat Device Code Flow as a High-Risk OAuth Grant

Device code phishing has moved from a niche technique to a repeatable service offering. Huntress recorded 26 critical-severity incidents across 23 identities between July 3 and July 27, 2026, following a pattern where the activity started from a single hosting address in April and spread across several subnets by May. Operators are renting and rotating infrastructure rather than inventing new tradecraft, which means any tenant using OAuth is a viable target regardless of size or industry.

The part that should change how you think about your own environment is how much weight infrastructure reputation carries in most defense stacks. When a sign-in arrives from a provider or autonomous system that commercial controls generally treat as normal, the attacker gets a working window. In token-centric operations that window does not need to be long to be useful.

The most important thing you can do is treat the device authorization grant as a high-risk OAuth grant in your own records. That means knowing where it is enabled across your tenant, which identities are permitted to complete it, and what data and applications a successful grant actually reaches. Most organizations have never documented any of the three, so the flow stays available to every account by default.

If you find no documented business need behind it, the answer is to turn it off. If a genuine need exists, keep the permitted population and the scopes it reaches as small as the use case allows.

Expect this attack class to keep spreading as phishing-as-a-service kits get cheaper and easier to operate. Campaign names will change, the hosting will change, and the underlying flow will stay the same until organizations narrow who can use it.