Cybersecurity

Device-Code Phishing Gets Microsoft Access Without Stealing a Password

The attack asks victims to approve a sign-in on Microsoft's real page, and the SkyW4lker kit is the latest tool built around it.

12 min read
Paper collage of layered sign-in cards, one slightly offset in ochre, all nearly identical in slate and cream.
AI-generated illustration

Device-code phishing tricks a person into approving the attacker's own sign-in request on Microsoft's genuine login page, so the attacker receives tokens rather than a password. Microsoft has tracked the technique from a 2024 espionage campaign to mass-market kits in 2026, and a kit called SkyW4lker is the newest reported example.

Device-code phishing is an attack in which a criminal starts a legitimate Microsoft sign-in request and then persuades the victim to approve it. The approval happens on Microsoft's own login page, so the attacker never sees the victim's password. What the attacker receives is the set of tokens that the victim's sign-in authorizes, and those tokens can open the account.

The technique matters because it sidesteps the defenses most people rely on. Microsoft Threat Intelligence first publicly described a successful campaign in February 2025, tied to a cluster it calls Storm-2372. By 2026, according to Microsoft, Huntress, Proofpoint and others, it had spread into rented criminal kits. The newest to draw attention is SkyW4lker, which the security vendor ANY.RUN analyzed in late October 2026.

What the device-code flow is for

The device-code flow, formally the OAuth 2.0 device authorization grant, exists for gadgets that cannot easily accept a login. A television, a printer, conference-room hardware or a command-line tool may have no keyboard or no browser. Instead, the device displays a short code, and the user enters that code in a browser on a second device, such as a phone or laptop. Push Security and Help Net Security, the latter summarizing Microsoft Defender research, both describe this purpose.

The standard was published in August 2019 as RFC 8628. The document includes a section on remote phishing. It says the authorization server should show the user that they are authorizing a device, and it suggests asking for confirmation to disambiguate devices, described as a remote phishing mitigation. A secondary reading from the vendor Dark Atlas says the RFC recommends showing device information and asking the user to confirm that the same code appears on a device they possess.

Two kinds of tokens matter in what follows. An access token is what a service issues after sign-in to let a client reach an account's data. A refresh token can be used to obtain new access tokens, which is why stealing one is more valuable than a single session. The flow is not unique to Microsoft: according to Push Security and a GitHub defense repository, any identity provider that implements RFC 8628 can be exposed to the same pattern. This article focuses on Microsoft 365 and Entra ID, where the reported campaigns have concentrated.

How the attack gets a token without a password

The sequence of events

The sources agree on the core mechanism, and Microsoft, the RFC and several independent security teams describe it consistently. The steps run as follows.

  1. The attacker asks the identity provider for a device code through its legitimate programming interface, according to The Hacker News.
  2. The victim is lured into entering that code on Microsoft's real sign-in page and confirming the request.
  3. Microsoft then issues tokens for that session to the attacker's waiting client, as Help Net Security describes it.
  4. The attacker uses the captured tokens to reach the account and whatever data and services it can access, according to Microsoft Threat Intelligence.

Nothing in this sequence requires a fake login form. The page that collects the victim's credentials is genuine, which removes the usual tell of a lookalike web address. The deception lies in the story that brings the victim there and in the fact that the code belongs to someone else's request.

Why MFA does not stop it

Several sources, including CybersecurityNews and a GitHub defense repository, make the same point: the victim completes MFA personally, but for the attacker's request. The attacker therefore does not defeat the second factor so much as borrow the result of it. A completed MFA prompt hands the attacker an authorized refresh token. That reasoning is consistent across sources, though it is a vendor inference about how the flow behaves rather than a measured experiment.

Phrases such as “bypasses MFA” are therefore imprecise. Push Security, a vendor that sells a product in this area, goes further and claims the technique also defeats passkeys because it targets the authorization layer. The research behind this article found no independent test of that claim, so it remains unresolved whether phishing-resistant sign-in methods change the outcome.

What a stolen token can do

In the Storm-2372 campaign, Microsoft observed the actor using Microsoft Graph to search the compromised account's messages. On February 14, 2025, Microsoft saw the actor switch to the Microsoft Authentication Broker client ID. According to Cybersecurity Dive, this produces a refresh token that can register an attacker-controlled device in Entra ID, and Microsoft saw that connected device used to collect email.

A Microsoft Q&A answer from a Microsoft-affiliated moderator adds that this path could lead to a Primary Refresh Token. That answer is not a formal advisory, so it is best read as a pointer to how far the access could extend rather than as an established finding.

From espionage tool to criminal kit

Early research and Storm-2372

Abuse of the flow was not new in 2025. Secureworks researchers described it around 2020 and released a tool called PhishInSuits, according to a Sophos write-up of their work; the exact date was not confirmed in the research for this article.

Microsoft Threat Intelligence reported on February 13, 2025 what it called an “active and successful” campaign by Storm-2372, active since August 2024. Microsoft assessed with medium confidence that the cluster aligns with Russian interests, victimology and tradecraft. A Cloud Security Alliance note says “high confidence,” which overstates what Microsoft said.

Reported targets included governments, nongovernmental organizations, IT services, defense, telecommunications, health, higher education and energy in Europe, North America, Africa and the Middle East. The lures imitated WhatsApp, Signal and Microsoft Teams. Microsoft's May 2025 post called the approach a relatively new technique used by multiple actors and named Storm-1249, a China-based espionage actor that used generic lures such as taxes and civil service.

Microsoft also noted a built-in limit: the payloads work only for 15 minutes. After compromise, it said, the actor sent internal “Document to review” phishing messages from hijacked accounts in repeated waves, which turns one victim into a launchpad for more.

Automation and phishing-as-a-service in 2026

The 15-minute window stopped being a reliable constraint in 2026. In an April report summarized by Help Net Security, Microsoft Defender Security Research described a campaign that got around the expiry through automation and dynamic code generation, using AI-assisted infrastructure. According to The Register, in the final stage of the redirect chain the code is generated only when the victim lands on the page, so the clock starts then. Lures included document-access requests, e-signing prompts and voicemail notices, and a script may copy the code to the clipboard for the victim to paste into the real login page.

Since March 15, 2026, we have observed 10 to 15 distinct campaigns launching every 24 hours.

A Microsoft vice president, speaking to The Register

Criminal kits followed. The Register reported that EvilTokens, a turnkey device-code kit, had been sold as a service since mid-February 2026. In a September 22, 2026 post, Microsoft said it had become one of the most widely used phishing-as-a-service platforms since February, offering templates and an AI assistant for writing target-specific emails.

Huntress reported a campaign starting March 2, 2026 that targeted 344 organizations across the United States, Canada, Australia, New Zealand and Germany. The Hacker News reported “340+” organizations with the earliest observation on February 18, 2026. The two figures come from the same underlying research and are not independent confirmation. Other activity includes TA4903, which Proofpoint says began device-code phishing in March 2026, and Tycoon 2FA operators who, per eSentire in May 2026, repurposed their kit for it. Huntress also says a kit called Kali365 is building in the technique.

Device-code phishing milestones, 2019 to 2026
Date Event Source
Aug 2019 RFC 8628 published RFC Editor
Aug 2024 Storm-2372 campaign begins Microsoft
Feb 13–14, 2025 Microsoft discloses Storm-2372 and later adds the Authentication Broker update Microsoft
Feb 2025 Rollout begins for the managed policy that blocks device-code flow Microsoft Tech Community
Mid-Feb 2026 EvilTokens kit sold as a service The Register
Mar 2, 2026 Huntress-observed campaign hits 344 organizations Huntress
Mar 2026 TA4903 starts device-code phishing Proofpoint
Mar 15, 2026 onward 10 to 15 distinct campaigns launched every 24 hours Microsoft, via The Register
Oct 27, 2026 SkyW4lker analysis reported Mallory.ai, summarizing ANY.RUN

SkyW4lker: what is reported so far

ANY.RUN, a sandbox vendor, describes SkyW4lker, also called SkyW4lker x365 Sentinel, as an active device-code phishing kit aimed at Microsoft 365 users in the United States, Europe and elsewhere. An aggregator summarizing the analysis dates reports to October 27, 2026. The Hacker News, in content authored by ANY.RUN, says the campaign has focused on manufacturing, technology and healthcare and uses Google-hosted infrastructure.

The attack chain, as summarized from ANY.RUN, combines password-protected business documents, intermediary pages, CAPTCHA gates and Microsoft's legitimate authorization pages. Lures are invoice and contract emails. The victim sees a branded page displaying a device code and is told to enter it on Microsoft's real sign-in page. The CAPTCHA and the password-protected file add a veneer of legitimacy, and may also hinder automated scanners, though the sources reviewed do not say so explicitly.

ANY.RUN also links SkyW4lker to Gabagool, a credential-phishing kit. Gabagool harvests logins through a file named accounts.php, while SkyW4lker abuses the device-code flow through session_public.php. ANY.RUN lists 173 domains hosting the kit and regards the two as attack modes of one platform. The link rests on shared infrastructure and code, according to OffSeq, whose page says its text is machine-generated.

Warning signs for users and administrators

The lures are well documented across the sources, but no source states a simple rule for spotting an attack. The signs below draw on those lure descriptions. The first is an inference from how the flow works: a legitimate device-code sign-in is one the person starts, on a television, printer or command-line tool.

  • An unsolicited message that asks for a code to be entered on a Microsoft page, when no device is waiting for sign-in.
  • A pretext involving an invoice, contract, voicemail, shared folder, e-signature request or Teams invitation, all of which appear in the reported campaigns.
  • A page that displays a code, or copies it automatically, for pasting into a login page.
  • A CAPTCHA or a password-protected attachment standing between the email and the code step, as in the SkyW4lker chain.
  • Pressure to act quickly. The original payloads lasted only 15 minutes, though newer kits generate the code when the victim lands on the page.

For administrators, Microsoft Learn says sign-in logs can be filtered for the authentication protocol value Device code flow. Vendors suggest alerting on such sign-ins and routing them to a security monitoring system. Device-code sign-ins by accounts that never use them, or occurring minutes after a suspicious email, are the clearest anomalies.

Defenses and what they cost

Microsoft's guidance is to block device-code flow wherever possible. Its Conditional Access documentation recommends getting as close as possible to a unilateral block, auditing existing use first, and allowing the flow only in well-documented, secured cases such as legacy tooling. The documentation says customers rarely use the flow while attackers use it frequently, which is why a block costs most organizations little.

Microsoft also announced a managed Conditional Access policy that blocks the flow by default for customers that have not used it in the past 25 days, with rollout beginning in February 2025. Administrators can edit these policies, for instance to exclude users or turn them off, though organizations cannot rename or delete them. The default does not help organizations that use the flow or have changed or disabled the policy. None of the sources reviewed says whether the 2026 victims had the policy off, so its real-world effectiveness is unmeasured.

Blocking has side effects. A Microsoft Teams support page says the policy signed out some Teams Android devices that were not excluded, and Microsoft Learn documents exceptions for Teams device resource accounts. An AdminDroid blog notes the block may also stop legitimate mobile requests. One vendor, Dark Atlas, also says that per Microsoft, managed-device and device-state conditions do not work for this flow because the browser completing authentication cannot report the requesting client's state. That claim comes from a single secondary source and was not checked against Microsoft's documentation.

When compromise is suspected, Microsoft advises revoking the user's refresh tokens by calling revokeSignInSessions. A weak source says resetting a password alone may not end access. Microsoft's emphasis on revoking tokens is consistent with that, but the research did not find an explicit Microsoft statement on password resets. The Cloud Security Alliance additionally suggests continuous access evaluation and token-lifetime policies.

What it means and what to watch

Device-code phishing shows a weakness that no password rule can fix: a sign-in can be perfectly genuine and still serve the wrong party. The page is real, the MFA is real and the user is real, yet the session belongs to the attacker. The feature itself is not broken. It simply trusts that the person entering a code is the person who started the request.

The trajectory from one espionage cluster to rented kits suggests the technique will keep appearing, though exact volumes are uncertain and vendor counts are lower bounds from their own telemetry. SkyW4lker's reach is the open question. A second independent analysis or a Microsoft report would show whether it is a major threat or one more entrant. In the meantime, the available evidence points to a practical default: treat any request to enter a code that the person did not start as suspect, and block the flow where an organization has no need for it.

Frequently asked questions

What is device-code phishing?

It is an attack where a criminal starts a legitimate device-code sign-in request and tricks the victim into entering the code on Microsoft's real login page. Microsoft then issues tokens to the attacker's waiting client. The attacker gets access without ever seeing the password.

Does device-code phishing bypass multifactor authentication?

Sources say the victim actually completes MFA, but for the attacker's request, which is why MFA does not stop the attack. That is a vendor inference rather than a measured result. Whether passkeys and other phishing-resistant methods also fail rests mainly on a claim by Push Security that was not independently tested.

Is a device code ever legitimate?

Yes. The flow was designed for devices such as televisions, printers and command-line tools that cannot easily take a login. The sources do not state a rule, but it follows from how the flow works that legitimate use usually begins with the user starting a sign-in on such a device.

How can organizations block device-code phishing?

Microsoft recommends blocking device-code flow with Conditional Access wherever possible, after auditing existing use. It also offers a managed policy that blocks the flow by default for customers that have not used it in the past 25 days. If compromise is suspected, Microsoft advises revoking the user's refresh tokens.

What is the SkyW4lker phishing kit?

ANY.RUN describes it as an active device-code phishing kit targeting Microsoft 365 users, using invoice and contract lures, password-protected documents and CAPTCHA gates. The analysis is the main source for nearly all coverage, and no victim counts or independent confirmation were found.

Sources

  1. SkyW4lker Phishing Kit: Microsoft 365 Threat to US Firms , ANY.RUN (2026-10-27)
  2. American Organizations Under Attack: Skyw4lker Device Code Phishing Campaign Exposed , The Hacker News
  3. SkyW4lker Phishing Campaign Expands, Threatening US Enterprises with Microsoft 365 Account Takeovers , CybersecurityNews
  4. SkyW4lker Phishing Kit Abuses Microsoft Device Codes to Access Microsoft 365 Accounts , Mallory.ai
  5. SkyW4lker Phishing Kit: Microsoft 365 Threat to US Firms , OffSeq
  6. Microsoft device code phishing: October 2026 checks , SafetyBis
  7. Storm-2372 conducts device code phishing campaign , Microsoft Security Blog (2025-02-13)
  8. Microsoft Threat Intelligence on X: Storm-2372 device code phishing campaign , Microsoft Threat Intelligence
  9. Defending against evolving identity attack techniques , Microsoft Security Blog (2025-05-29)
  10. Unmasking EvilTokens: Getting to the root of device code phishing , Microsoft Security Blog (2026-09-22)
  11. Phishing campaign targets Microsoft device-code authentication flows , Cybersecurity Dive (2025-02-01)
  12. Validity of Article on Microsoft Device Code Authentication Threats , Microsoft Q&A
  13. OAuth Device Code Phishing Hits 340+ Microsoft 365 Organizations , Cloud Security Alliance (2026-03-25)
  14. RFC 8628: OAuth 2.0 Device Authorization Grant , RFC Editor (2019-08-01)
  15. AI-enabled device code phishing campaign exploits OAuth flow for account takeover , Help Net Security (2026-04-07)
  16. Hundreds compromised daily in Microsoft device code phishes , The Register (2026-04-07)
  17. Device Code Phishing Hits 340+ Microsoft 365 Orgs Across Five Countries via OAuth Abuse , The Hacker News (2026-03-25)
  18. DEBULL Tooling Abuses Microsoft Device-Code Flow to Target M365 Accounts , The Hacker News
  19. We Need to Talk About Device Code Phishing , Huntress (2026-06-22)
  20. Device Code Phishing is an Evolution in Identity Takeover , Proofpoint
  21. OAuth's Device Code Flow Abused in Phishing Attacks , Sophos
  22. Device code phishing: how to detect and stop it , Push Security
  23. Device Code Phishing Guide: OAuth, MFA, and Token Abuse , Dark Atlas
  24. Block authentication flows with Conditional Access policy , Microsoft Learn
  25. Microsoft-managed Conditional Access policies , Microsoft Learn
  26. Restrict device code flow for Microsoft Teams devices with Conditional Access , Microsoft Learn
  27. New Microsoft-managed policies to raise your identity security posture , Microsoft Tech Community
  28. Microsoft Teams Devices - Device Code Flow Sign-In Issue , Microsoft Tech Community
  29. Control Authentication Flows Using Conditional Access Policy , AdminDroid
  30. GitHub - IAMDevBox/oauth-device-code-phishing-defense , GitHub

Share this article

Back to list