SkyW4lker Phishing: How a Legitimate Microsoft Login Can Become a Trap

Most employees have learned to be suspicious of fake login pages. But what happens when the login page is real, and the authentication request itself is the trap? That is the danger highlighted by research into SkyW4lker (spelled with a "4"), a phishing operation that abuses Microsoft's legitimate device code authentication process to take over Microsoft 365 accounts.

According to analysis published by the security firm ANY.RUN through its Interactive Sandbox, SkyW4lker has primarily targeted U.S. organizations in manufacturing, technology, and healthcare. The findings are especially relevant to small and midsize businesses that rely on Microsoft 365 for email, documents, and collaboration, because the attack is designed to slip past the exact advice most employees have been taught.

What is SkyW4lker?

SkyW4lker is a phishing kit built to trick Microsoft 365 users into completing an authentication request that grants access to an attacker-controlled session. Instead of relying on a convincing fake of a Microsoft password page, it abuses a legitimate Microsoft feature called device code flow.

Device code flow normally lets you sign in on devices with limited input, such as certain shared devices, smart TVs, or conference-room systems: the device shows a short code, and you type it in on a normal computer or phone to authorize the sign-in. The problem is that an attacker can start that flow themselves and then convince an employee to complete the authorization. The employee sees a genuine Microsoft sign-in page and completes a normal login, without realizing the request originated from someone else.

How the attack works

According to ANY.RUN, SkyW4lker campaigns use business documents as the lure, often password-protected files presented as contracts or business proposals (the password adds a veneer of legitimacy and can help the file evade automated scanning). The sequence generally runs like this:

1. The employee receives a convincing document. It looks like a legitimate contract or business request.
2. The document leads through a redirect chain. Some variants use trusted hosting such as Google Sites along the way, so the links look benign.
3. The employee is asked to complete a Microsoft device code login. The Microsoft authentication page itself is genuine.
4. The attacker captures access. Because the victim authorized the attacker's device-code request, the attacker obtains authentication tokens for the account.

The key deception is not a stolen password. It is convincing the victim to authorize an authentication flow they did not start.

How widespread is SkyW4lker?

Security researchers at ANY.RUN identified 618 sandbox analyses associated with SkyW4lker between June and October 21, 2026, with roughly 46 percent of the submissions coming from the United States and activity rising from about 20 analyses in June to 200 in September. One important caveat: these figures reflect analyzed phishing samples, not the number of businesses or Microsoft 365 accounts that were actually compromised. They show the campaign is active and growing, not a confirmed victim count.

Researchers also found that SkyW4lker closely resembles another phishing kit known as Gabagool, sharing technical components and infrastructure, and assessed with high confidence that the two came from the same creator. That matters because it points to an actively maintained toolkit rather than a one-off: the same operators can retool and relaunch, which is exactly why defenses that depend on spotting a specific fake page do not hold up over time.

Why this differs from traditional phishing

Traditional credential phishing asks a victim to type a password into a fraudulent website, so the classic defense is "check that the page is really Microsoft." Device code phishing breaks that advice, because the page really is Microsoft. A legitimate login page does not guarantee a legitimate request. Employees also have to understand why they are being asked to sign in, which application is requesting access, and whether they initiated the process at all.

It is worth distinguishing this from the Microsoft 365 token replay attacks we covered recently. Both end in unauthorized Microsoft 365 access without a stolen password doing the work, but the mechanism differs: token replay intercepts and reuses an already-authenticated session (adversary-in-the-middle), while device code phishing tricks the victim into authorizing an attacker's sign-in request. The defenses overlap, but they are not identical.

Does MFA protect against SkyW4lker?

MFA remains essential, and you should keep it on. But device code phishing can sidestep the instinct MFA is meant to protect, because the employee completes a genuine MFA challenge while unintentionally authorizing access the attacker initiated. The attacker is not defeating the MFA mechanism; they are riding along on an authorization the victim approved. Even strong authentication does not automatically make an unwanted authorization request safe. (If MFA is not yet on everywhere, start with two-factor authentication for small business.)

How to protect your Microsoft 365 environment

Microsoft's general guidance for this class of attack is to restrict the device code flow where it is not needed and to watch for unexpected authorizations. Practical steps:

• Review where device code flow is used. Microsoft Entra administrators can inspect sign-in logs to see whether and where device code authentication actually happens in your tenant.
• Block unnecessary device code flow. Use Conditional Access policies to restrict it. Start in report-only mode to find legitimate dependencies before you enforce a block.
• Limit exceptions. Some Teams devices and similar tools genuinely need device code flow. Allow it only for documented use cases rather than for everyone.
• Educate employees. Tell staff never to enter a Microsoft device code that arrived through an unexpected email, document, or message. (Our guide on spotting phishing emails helps here.)
• Investigate suspicious sign-ins. Review authentication activity, application access, and any unexpected consent or account changes.
• Respond to suspected compromise. Restrict affected accounts, revoke sessions where appropriate, investigate application access, and assess what may have been exposed. The playbook in our Microsoft 365 compromise response applies directly.

What small businesses should remember

You do not need a large security team to improve your odds. Start by identifying who manages your Microsoft 365, checking whether device code flow is even needed, and documenting how employees should report suspicious authentication requests. If a staff member says a document instructed them to enter a Microsoft device code, treat it as a potential security incident until it has been reviewed. The instinct you want to build is simple: a sign-in prompt you did not start is a red flag, even on a real Microsoft page.

Red flags employees can watch for

Because the Microsoft page is real, the warning signs are about context, not the login screen itself. Teach staff to pause when:

• A document, especially a password-protected one, pushes them to "sign in," "verify," or "authorize" in order to view its contents.
• They are shown a short code and told to enter it at a Microsoft page they did not navigate to themselves.
• A sign-in prompt appears that they did not initiate, even if it looks completely normal.
• An email creates urgency around a contract, invoice, or proposal and routes them through several links to get there.
• The request arrives out of the blue from an unfamiliar sender, or from a familiar one in an unusual way.

The single most useful habit is this: if you did not start a sign-in, do not complete one, no matter how legitimate the page looks. When in doubt, close everything and reach the service directly through a bookmark or by typing the address yourself.

Just as important is making it easy to report. Employees should have one obvious place to flag a suspicious authentication prompt, an email alias, a chat channel, or a named person, and they should never feel they will be blamed for raising a false alarm. The faster an unexpected device code request is reported, the sooner an administrator can revoke sessions and shut down access before an attacker settles in.

How GuardPilot fits into the response

SkyW4lker is an identity-security threat, and Microsoft Entra is the right place to investigate suspicious authentication activity. To be clear about the boundary: GuardPilot does not detect live device code phishing sessions or revoke Microsoft authentication tokens. GuardPilot is the AI Incident Response Platform for Credential Exposure, and it focuses on a complementary problem: identifying known exposed business credentials and guiding remediation. If a phishing investigation also turns up exposed passwords or infostealer-related credential leaks, GuardPilot explains what was exposed and walks you through fixing it. Pairing identity controls in Microsoft 365 with ongoing dark web monitoring covers both the live-session risk and the leaked-credential risk.

Worried your business credentials have been exposed? Check for known credential exposure with GuardPilot and get clear steps to protect affected accounts. Check your credential exposure.

Frequently asked questions

Is SkyW4lker the same as the Microsoft 365 token replay campaign?

No. Both involve unauthorized Microsoft 365 access, but SkyW4lker abuses device code authorization, convincing a victim to approve the attacker's sign-in, while adversary-in-the-middle token replay intercepts and reuses an already-authenticated session.

Can a real Microsoft sign-in page be part of a phishing attack?

Yes. Attackers can abuse legitimate authentication workflows by convincing victims to authorize requests the attacker initiated. The page being genuine is exactly what makes it convincing.

Should businesses disable MFA?

No. MFA remains important. The goal is to strengthen authentication while restricting unnecessary device code flows and teaching employees to question unexpected sign-in requests.

What should I do if an employee entered a device code from a suspicious document?

Treat it as a potential incident: review the account's recent sign-ins and app consents, revoke sessions, reset the password, and check for attacker-added MFA methods or mailbox rules, the same steps in our Microsoft 365 compromise response guide.

Sources and further reading

• The Hacker News: U.S. organizations under attack by the SkyW4lker device code phishing campaign.
• ANY.RUN Cybersecurity Blog (original SkyW4lker research).
• Microsoft Entra: Conditional Access and authentication flows (device code flow).

The takeaway

SkyW4lker shows why businesses must evaluate the authentication request, not just the login page. A genuine Microsoft website can still be part of a malicious authorization flow. Restricting risky authentication methods such as device code flow, reviewing sign-in activity, and teaching employees to question unexpected device code requests can meaningfully reduce exposure, while credential exposure monitoring covers what leaks when an attack does get through.