A password-protected contract attachment does not need to steal your password when the next screen is Microsoft’s own device authorization page. According to ANY.RUN, the SkyW4lker phishing kit active from June 2026 coached workforce Microsoft 365 users to enter attacker-generated device codes on genuine login.microsoftonline.com pages, then collected OAuth access and refresh tokens for attacker-controlled sessions after victims finished legitimate sign-in, including whatever MFA the real Microsoft flow required. Public reporting has not named specific victim organizations or exact account counts.
Password-protected contracts that never needed the password
Operators framed the opening move as ordinary business mail. According to ANY.RUN’s analysis published 27 October 2026, lures arrived as password-protected PDF, DOCX, or XLSX files styled as contracts, invoices, or service proposals, with the document password sitting in the email body so the attachment felt routine rather than hostile.
After the file opened, coaching continued off the corporate mail path. Decoy pages, including Google Sites and similar holding pages, walked the user toward a device code and instructions to approve access on Microsoft’s real device authorization endpoint. The social engineering goal was not a lookalike password form. It was compliance with a flow many employees already associate with printers, meeting-room gear, and other headless clients.
That framing matters for detection teams. Filters that only hunt for fake login.microsoftonline.com hostnames miss the point when the final ceremony is the real hostname. The malicious work sits in who started the device-code session and who polls for the resulting tokens, not in a spoofed password field.
Sandbox telemetry shows the campaign was not a one-week spike. ANY.RUN logged 618 related sandbox submissions between June and 21 October 2026. Volume rose from roughly 20 analyses in June to about 200 in September. Roughly 46 to 47 percent of submissions came from the United States, with manufacturing, technology, and healthcare called out as primary industry interest in the public write-up.
How the real OAuth device-code flow issued attacker tokens
Microsoft’s OAuth 2.0 device authorization grant is built for clients that cannot comfortably host an interactive browser login. One side displays or delivers a short user code. The human signs in on a full browser at Microsoft’s legitimate device login pages. When sign-in succeeds, Microsoft issues tokens to the client that initiated the device-code request.
SkyW4lker abused that design. The attacker’s tooling created the device-code session. The victim completed authentication on the real Microsoft pages. Tokens therefore bound to the attacker-controlled client. ANY.RUN’s assessment is blunt on the outcome: by abusing Microsoft’s legitimate authentication process, the kit can give attackers access to corporate accounts without stealing passwords or bypassing MFA.
Victims who had MFA enabled still finished the real Microsoft ceremony. The kit’s JavaScript even logged MFA status among other fields. Completing MFA on the genuine IdP did not stop token delivery to the wrong client, because the grant is doing what it was written to do: hand access and refresh tokens to the party that started the device code.
Kit plumbing supported live coaching at scale. A PHP backend plus obfuscated JavaScript (built with patterns consistent with obfuscator.io) created sessions, collected IP and geolocation context, and polled /session_public.php?action=poll until authentication completed. An endpoint.js module logged email, password when captured on earlier steps, browser details, MFA status, country, and related fields back to the operator backend. Password capture was not required for the successful token path. The decisive artifact was the OAuth pair issued after the victim finished the real flow.
Once those tokens exist, Microsoft 365 resource access no longer asks the human for another interactive proof at every app. Mail, files, and other integrated workloads become reachable from attacker-controlled sessions for as long as the access and refresh tokens remain valid and unreoked. ANY.RUN does not publish a detailed post-token playbook or named mailbox counts for this kit. The public risk statement stays at potential unauthorized access to Microsoft 365 resources after tokens issue to attacker sessions.
The same device-code pattern has already hurt high-value workforce tenants in other campaigns, including state-linked operations that steered staff to enter attacker-supplied codes on the real Microsoft sign-in experience. SkyW4lker is a kit brand with industrial packaging, not a claim that every historical device-code incident shared one operator. The authentication failure mode is shared: an allowed grant plus a coached human on legitimate pages.
Kit lineage, logged MFA status, and what sources leave open
ANY.RUN assesses with high confidence that SkyW4lker and the earlier Gabagool credential phishing kit were built by the same developer. Gabagool activity was first observed around April 2026. The kits share JavaScript modules (including patterns around endpoint.js, url_helper.js, and client_geo.js), landing-URL shape, and portions of hosting infrastructure. Shared lineage helps defenders cluster detections. It does not mean every Gabagool lure used device-code token delivery the same way SkyW4lker did.
| Piece of the stack | What sources show here | What it did not require |
|---|---|---|
| Business document lure | Password-protected contract or invoice style files | Malware on the endpoint to start |
| Coaching pages | Decoys directing users to a device code | A fake Microsoft password host |
| Final authentication | Real login.microsoftonline.com device pages | Attacker knowledge of the password |
| MFA on the real flow | Status logged; flow can complete with MFA on | Stopping tokens to the attacker client |
| Operator prize | OAuth access and refresh tokens | A separate AiTM cookie proxy step |
Several high-interest facts remain unpublished. No specific victim companies are named in the primary analysis. Exact account or record compromise counts are not given. The MFA method is not broken out beyond completion of the real Microsoft flow and logged MFA status. Operator identity beyond the SkyW4lker kit branding (including “SkyW4lker x365 Sentinel” styling in reporting) is not established in the source material. Post-token actions inside mailboxes or SharePoint are described only at the level of potential Microsoft 365 resource access.
For identity teams, the uncomfortable lesson is mechanical. Classical “MFA is on” dashboards can stay green while device-code phishing still mints usable cloud sessions, because the human really did authenticate to Microsoft. The failure sits in allowing a grant that delivers tokens to a client the user never intended to trust, after a coached business-document path that never had to defeat a phishing-resistant login ceremony on a spoofed origin.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: restricting Microsoft 365 device-code OAuth grants against SkyW4lker-class phishing.
FAQ
Did SkyW4lker bypass Microsoft 365 MFA?
SkyW4lker did not need to bypass Microsoft 365 MFA in the usual sense. According to ANY.RUN, victims completed Microsoft’s legitimate authentication process on real device authorization pages, and device-code phishing can succeed even when MFA is enabled. Tokens issued to the attacker-controlled device-code session after that real sign-in. Public reporting does not name a specific MFA method beyond completion of the real Microsoft flow and kit logging of MFA status.
How did SkyW4lker get Microsoft 365 tokens without stealing passwords?
SkyW4lker got Microsoft 365 tokens by abusing the OAuth 2.0 device authorization grant on genuine Microsoft pages. Attackers started a device-code session, coached the user via password-protected business documents and decoy sites to enter the code at login.microsoftonline.com, and received access and refresh tokens when the victim finished sign-in. ANY.RUN states the kit can give attackers access without stealing passwords because token issuance follows the legitimate grant, not a captured password replay.
What scale did researchers document for SkyW4lker?
Researchers at ANY.RUN documented 618 related sandbox analyses for SkyW4lker between June and 21 October 2026, with monthly volume rising from about 20 in June to about 200 in September, and roughly 46 to 47 percent of submissions from the United States. The public analysis does not publish named victim organizations or exact compromised-account totals.
How is SkyW4lker connected to the Gabagool kit?
According to ANY.RUN, SkyW4lker and Gabagool share JavaScript modules, landing-URL patterns, and part of their hosting infrastructure, and analysts assess with high confidence that both kits were built by the same developer. Gabagool was observed from April 2026 as a credential phishing kit family. Shared tooling lineage is not the same as proving identical victims or identical final-stage token theft in every Gabagool case.
What could defenders still not see from public SkyW4lker reporting?
Public SkyW4lker reporting still does not identify specific victim companies, exact mailbox or account compromise counts, the precise MFA products users completed on Microsoft’s pages, or a detailed post-token action chain inside Microsoft 365 beyond potential access to email, documents, and other apps once OAuth tokens were issued to attacker sessions.
