SkyW4lker: A Device Code Phishing Kit That Hands Attackers a Microsoft 365 Token Behind a Password-Protected Contract
SkyW4lker emails a password-protected contract, gates it behind a CAPTCHA and sends the recipient to the real Microsoft device code page to hand over a Microsoft 365 token.
AegisAI Threat IntelligenceAegisAI Threat Watch · Device code phishing
SkyW4lker: A Device Code Phishing Kit That Hands Attackers a Microsoft 365 Token Behind a Password-Protected Contract
A kit seen in 618 sandbox analyses emails password-protected contracts, hides the page behind a CAPTCHA and sends the recipient to Microsoft’s real device code page.
Analysis based on 27 October 2026 research by ANY.RUN, with The Hacker News for the sector list in its contributed summary of that research.
SkyW4lker is a device code phishing kit that sends a password-protected contract by email, then walks the recipient into a real Microsoft sign-in that hands the attacker a token.
ANY.RUN counted 618 sandbox analyses tied to the kit between June and 21 October 2026. The recipient never sees a fake login page. The page that asks for the code is Microsoft's own, so the only forged element is the reason for entering it.
Source: ANY.RUN. The first two figures count sandbox submissions, not confirmed victims.
Key judgments
- The delivery chain is built to defeat inspection at each step. ANY.RUN reports a password-protected attachment, a CAPTCHA placed in front of the phishing page to hide it from automated scanners, and lure pages on legitimate services to pass email reputation checks. By the time a scanner could read the page, it is looking at a gate.
- The sign-in page is genuine, so there is nothing on it to classify as forged. The victim enters a code on Microsoft's own device page and completes MFA as usual, which authorises a session the attacker started. ANY.RUN states the kit gives access without stealing passwords or bypassing MFA.
- The phishing page stays connected to the attacker's backend. It registers a session, sends the visitor's IP address and location, and then polls every few seconds to learn whether the victim has authenticated. This is a repeating network pattern that defenders can search for.
- The campaign is growing, not fading. Monthly submissions rose from 20 in June to 200 in September, and the kit appeared in 520 analyses tagged for obfuscated JavaScript. AegisAI reads this as an established kit with steady use rather than a one-off lure.
- The kit is one mode of a wider platform. ANY.RUN assesses with high confidence that SkyW4lker and the Gabagool credential kit were built by the same developer, and says the data cannot show whether one operator or several customers run them. Blocking one lure domain addresses one customer of a shared tool at most.
Who does SkyW4lker target, and how large is the campaign?
ANY.RUN describes an active kit aimed at Microsoft 365 users in the United States, Europe and other regions. The sandbox submissions it counted came mainly from organisations in technology, manufacturing and government, most often in the United States, India, Canada and the United Kingdom. The post gives the United States share as 46% in its summary and 47% in its United States section.
Submissions, not victims
The 618 analyses are samples that analysts and automated systems uploaded to a sandbox. They show that the kit is in use and that it is spreading across hosting; they do not count compromised accounts. ANY.RUN gives no victim total and gives "possible financial" as the motive.
Three months of growth
Monthly submissions grew from 20 in June to 200 in September, according to ANY.RUN. The first sighting it records is 23 June 2026, and the indicators it lists were all observed between 23 June and 21 October.
What does device code phishing abuse?
It abuses the OAuth 2.0 device authorization grant, a standard flow for devices that cannot show a normal sign-in page. The standard, RFC 8628, describes devices that lack a browser or are input constrained, such as smart televisions and printers. The device shows a short code, and the user enters it on a second device to approve the request.
Device code phishing starts the same flow on the attacker's side. The attacker holds the device, the victim holds the code, and the approval the victim gives belongs to the attacker's session. Microsoft's sign-in page behaves correctly throughout. The standard itself lists remote phishing among its security considerations.
The sign-in is real, the MFA is real and the approval is real. What is false is who asked for it.
AegisAI Threat IntelligenceHow does a password-protected contract lead to a Microsoft 365 token?
The recipient opens a protected document, passes a CAPTCHA, optionally lands on a lure page, and then meets a page that asks for a Microsoft device code. ANY.RUN describes the chain in four stages.
- A phishing email carries a password-protected attachment (PDF, DOCX or XLS and XLSX), and the password is in the email body.
- The document contains a link to a CAPTCHA page. ANY.RUN names Cloudflare Turnstile and a self-hosted widget.
- Some variants add a lure page on a legitimate service. ANY.RUN names Google Sites among others, with Google Maps, Google Images, Axure Cloud and Smartsheet pages in its technique notes.
- The phishing page tells the victim to enter a device code on Microsoft's legitimate authentication page, which can grant the attacker access to the Microsoft 365 account.
What the lures look like
The operator imitated routine business correspondence. ANY.RUN lists subjects such as "New Submission From", "Approved Statement" and "Fedwire Funds Service Processed", and file names ending in "-protected.pdf". The theme is a business document that a finance or procurement team expects to open.
Google Sites is one of several hosts
A page on sites.google.com appears in ANY.RUN's examples, but the post presents the lure pages as optional and lists many host types. Treating Google Sites as the defining feature would miss the others. The constant parts of the chain are the protected document, the CAPTCHA gate and the Microsoft device page.
What does the SkyW4lker backend do while the victim is signing in?
It keeps the victim's browser tied to an attacker session. The kit is a PHP backend with obfuscated JavaScript, and ANY.RUN found 520 of its 618 analyses carry the obfuscated JavaScript tag.
Session and polling
The page sends a request to session_public.php with action=start, passing the visitor's IP address and geolocation, and receives a session ID. It then sends action=poll every few seconds to check whether the victim has authenticated. Location comes from one of three public lookup services or from the kit's own endpoint.
The administration panel
ANY.RUN located an administration panel at /admin/index.php. Its style sheet suggests MFA through Telegram, a victim statistics dashboard, server management, link generation and live notifications about new visits. These capabilities are inferred from the style sheet by ANY.RUN, not observed in use.
Is SkyW4lker related to the Gabagool kit?
ANY.RUN says yes, with high confidence. The two kits share JavaScript modules (client_geo.js, url_helper.js and endpoint.js), a landing URL format, the same self-hosted CAPTCHA and some hosting. Gabagool was first seen on 23 April 2026 and has 458 analyses in six months; SkyW4lker was first seen on 23 June 2026 and has 618.
Two attack modes of one platform
The difference is the endpoint. Gabagool harvests logins and passwords through accounts.php, while SkyW4lker uses session_public.php for device code abuse. ANY.RUN regards them as two attack modes of one platform, and notes that SkyW4lker's own script also logs email, password, browser, MFA status and country through the shared module. The post does not say how often that path is used against victims.
How do organisations protect Microsoft 365 from device code phishing?
The main control is to restrict the device code flow in Microsoft Entra Conditional Access wherever it is not genuinely required. ANY.RUN recommends reviewing where the flow is needed and restricting or blocking the rest. Where the flow must stay, the exception should cover only the accounts and resources that need it.
What the control leaves open
A block stops new device code approvals from the accounts it covers. It does not remove the lure from the mailbox, and it does not help the exceptions. This section is AegisAI's analysis. Because the authentication step is genuine, the earlier steps (the message, the attachment, the gate) are the only places where intent is visible, and ANY.RUN also advises connecting suspicious attachments, phishing infrastructure and unusual sign-ins across email and identity systems.
Why standard controls miss it
The chain gives each common control a reason to see nothing wrong. This section is AegisAI's analysis of the reported mechanism, not a finding from the sources.
- A password-protected attachment cannot be read by a gateway that does not have the password, and here the password is in the same message. A rule that treats the file as opaque sees no link.
- The CAPTCHA is placed in front of the phishing page to hide it from automated scanners, so a URL scanner that follows the link reaches a challenge and not the device code page.
- Lure pages sit on legitimate services, which carry a good reputation by default, and the final step is Microsoft's own domain. A reputation filter has little to hold on to.
- The sign-in is valid. Identity logs record a completed device code authentication, with MFA satisfied, and the harmful context lies in an earlier email.
How AegisAI protects against it
ANY.RUN reports email as the delivery channel, so the first control point is the message. The approach below applies to the protected attachment, before the recipient reaches any lure page or the Microsoft device code page.
Aegis does not classify infrastructure. It classifies intent. A lure with no attacker-owned infrastructure still has to ask the recipient to do something on the attacker's behalf, and that request is what gets classified, independent of how clean the destination URL is.
AegisAI's agents evaluate the message and the destination it points to together, and pull a malicious message out of mailboxes before users see or click it.
When a lure or a compromised session is caught, the response compounds: the message is withheld at classification, copies already delivered are retracted, rewritten links refuse a late visit, the account's outbound and internal mail gets rescanned, and lateral phishing attempts to colleagues are blocked at the same bar rather than treated as a fresh, unrelated message.
More on how that works: inbound email security.
What the reporting does not tell us
Scale. The figures are sandbox submissions, not confirmed compromised accounts, and ANY.RUN gives no victim count or loss figure.
Sectors. ANY.RUN names technology, manufacturing and government as the main submitting sectors. The Hacker News carried a contributed summary of the research on 28 October that names manufacturing, technology and healthcare. The two lists differ, and this article uses ANY.RUN's.
Country share. The United States figure is given as 46% in one place and 47% in another in the same post.
The operators. ANY.RUN cannot tell one operator from several customers of the same platform, and gives no actor name beyond the kit's own name.
Password use. The kit contains code that logs passwords and MFA status. Whether it does so during device code attacks is not stated.
Longevity. Landing tokens and host directories change within weeks. Treat any single domain as short-lived; the session and poll pattern and the module names are likelier to persist.
Indicators of compromise
| Indicator (defanged) | Type | Reported use |
|---|---|---|
/assets/php/endpoints/session_public.php?action=start, ?action=poll&session_id= | URL paths | Session registration and polling of device code status, seen 23 June to 21 October 2026 |
/assets/js/client_geo.js, /assets/js/endpoint.js, /assets/js/url_helper.js | URL paths | Kit modules for geolocation, session state and URL handling |
/it[A-Za-z0-9]{32}us | URL pattern | Landing page token, seen 10 August to 19 October 2026 |
/zt[A-Za-z0-9]{32}op | URL pattern | Earlier landing page token, seen 25 June to 28 September 2026 |
162.243.64[.]121, 67.205.154[.]32 | IP addresses | Backend servers on DigitalOcean hosting (ANY.RUN examples) |
172.86.85[.]51 | IP address | Shared with Gabagool (priorispace[.]biz) |
5200m[.]com/kvme2/, torvion[.]life/ofulium/, ghethim[.]com/hyllen/ | Host directories | Same directory used on shared hosts by both kits, October 2026 |
9aa0b87974b9b4cd42603833b7ad44257578467d279b315a071108a5ed02c268 | SHA256 | One password-protected lure document ANY.RUN cites as an example |
ANY.RUN lists 173 domains that host the kit; the full list is in its post. Match whole paths and patterns; the Microsoft addresses the victim reaches at the end (the device sign-in page) are genuine and are not indicators. Treat the list as historical, not as a live blocklist. Domains and IP addresses are defanged with [.].
MITRE ATT&CK mapping
This mapping is AegisAI's own reading of the reported behaviour. ANY.RUN publishes its own mapping in the post.
| ID | Name | Use in this campaign |
|---|---|---|
T1566.001 | Phishing: Spearphishing Attachment | Password-protected PDF, DOCX or XLS lures deliver the link |
T1566.002 | Phishing: Spearphishing Link | Links on legitimate services pass email reputation checks |
T1204.001 | User Execution: Malicious Link | The recipient opens the landing link, which starts a phishing session |
T1656 | Impersonation | Subjects and file names imitate routine business correspondence |
T1497 | Virtualization/Sandbox Evasion | A CAPTCHA hides the phishing page from automated scanners |
T1027 | Obfuscated Files or Information | Obfuscated JavaScript hinders analysis |
T1528 | Steal Application Access Token | The OAuth 2.0 device code flow yields the victim's access tokens |
T1056.003 | Input Capture: Web Portal Capture | Shared module logs email, password, browser, MFA status and country |
Recommendations for defenders
- Restrict the device code flow in Microsoft Entra Conditional Access for all users, and scope any exception to the specific accounts and resources that need it. Review existing device code sign-ins first, so that legitimate uses are known before the policy is enforced.
- Alert on device code authentication events in Entra ID sign-in logs, especially those that follow a suspicious attachment or document-sharing request by a short interval.
- Search web, proxy and DNS logs for the
session_public.phpstart and poll pattern and the three module names, and treat a repeating poll from a user's browser as a high-priority lead. - Set a mail policy for password-protected attachments from external senders where the password is in the same message: hold them, or route them to analysis with the password supplied, instead of delivering them unread.
- Write the response plan for a completed device code approval before it is needed: revoke the user's sessions and refresh tokens, review subsequent Microsoft 365 activity on the affected resources, and check for onward phishing to colleagues.
- Train finance, procurement and sales staff on the behaviour, not the look: a code is requested only by a device the person started, and a document that asks for a Microsoft code is a stop-and-report event.
FAQ
How do I protect Microsoft 365 from device code phishing?
Restrict the OAuth device code flow in Microsoft Entra Conditional Access wherever it is not genuinely required, and scope any exception narrowly, as ANY.RUN recommends. Pair that with detection across email and identity: alert on device code sign-ins that follow a suspicious attachment, and stop the lure at the message before the Microsoft page is reached.
What is device code phishing?
Device code phishing abuses the OAuth 2.0 device authorization grant, a flow built for devices that cannot show a normal sign-in page. The attacker starts the flow and gives the victim the code through a lure. When the victim enters it on the real Microsoft page and completes MFA, the approval belongs to the attacker's session and the attacker receives tokens without needing the password.
Can multi-factor authentication stop device code phishing?
Not on its own. The victim completes MFA normally on Microsoft's genuine page; the problem is that the session being authorised belongs to the attacker. ANY.RUN states that SkyW4lker gives access without stealing passwords or bypassing MFA, so the control that helps is restricting the device code flow, not adding another factor.
How does a password-protected document lead to a stolen Microsoft 365 token?
The email carries a protected PDF, DOCX or XLS file with the password in the message body. The document links to a CAPTCHA page, sometimes through a lure page on a legitimate service, and then to a page that asks for a Microsoft device code. Entering it on Microsoft's page authorises the attacker's session, and the kit's backend polls until authentication completes.
References
- ANY.RUN (27 Oct 2026). SkyW4lker Exposed: A Growing Microsoft 365 Phishing Threat to American Enterprises. any.run
- The Hacker News (28 Oct 2026). American Organizations Under Attack: Skyw4lker Device Code Phishing Campaign Exposed. thehackernews.com
- IETF (August 2019). RFC 8628, OAuth 2.0 Device Authorization Grant. datatracker.ietf.org
- MITRE ATT&CK. Techniques T1566.001, T1566.002, T1204.001, T1656, T1497, T1027, T1528 and T1056.003. attack.mitre.org
Every email, investigated.
Related posts
More from the AegisAI blog.