Summary
- The Skyw4lker campaign abuses Microsoft’s legitimate device code authentication mechanism to gain persistent access to corporate Microsoft 365 accounts.
- Attackers leverage trusted cloud services and standard business workflows, making the attack harder to detect through conventional credential-monitoring controls.
- U.S. organisations are the primary targets identified in ANY.RUN’s analysis of this campaign.
- Because no password is captured or replayed, traditional credential theft indicators are largely absent from telemetry.
- Security teams should audit conditional access policies and restrict or monitor device code authentication flows where they are not operationally required.
What is happening
A phishing campaign tracked as Skyw4lker is actively targeting American organisations by abusing the device code authentication flow built into Microsoft’s identity platform. Rather than directing victims to a fake login page designed to harvest credentials, the campaign generates legitimate device code authentication requests and manipulates users into completing them. The result is that attackers receive a valid access token tied to the victim’s account — no password required.
How the attack works
Device code authentication was designed to help users sign in on devices with limited input capability, such as smart televisions or industrial terminals, by displaying a short code that is entered on a separate, more capable device. Skyw4lker weaponises this flow by initiating an authentication request and then socially engineering the target into entering the generated code on the legitimate Microsoft login page. Because every step occurs on genuine Microsoft infrastructure, there is no spoofed domain and no malicious attachment to flag. The access token issued at the conclusion of that flow is what the attacker collects and retains.
Why conventional defences fall short
The attack’s strength lies in how closely it mirrors normal business activity. Emails prompting users to authenticate a device arrive in inboxes that may already trust Microsoft-branded communications. The authentication itself takes place on Microsoft’s own pages, bypassing any browser-based phishing detection that relies on domain reputation or certificate anomalies. Credential monitoring tools have nothing to observe because no credential is transmitted to the attacker. The token, once issued, can provide persistent access to email, files, and connected services — including the ability to move laterally through integrated platforms.
Attribution and scope
ANY.RUN’s analysis identified Skyw4lker as the campaign identifier and confirmed that U.S. organisations represent the primary targets observed to date. The sources available do not provide further detail on the sector distribution of victims, the volume of organisations affected, or attribution to a specific threat actor or nation-state. What is clear is that the technique is not novel in concept but has been operationalised here at a campaign scale warranting executive attention.
The broader pattern
Skyw4lker fits a recognisable trend in which adversaries deliberately avoid the tradecraft most likely to trigger security alerts. By routing the attack through legitimate cloud services and authentication mechanisms, and by exploiting workflows that security teams themselves sanction for productivity purposes, campaigns of this type place pressure on the policy layer rather than purely the detection layer. The question is not whether the tools were misused — they were — but whether the organisation had restricted access to those tools in ways that would have reduced the attack surface.
Why it matters
For CISOs, this campaign illustrates the risk of treating legitimate platform features as inherently safe. Device code authentication is a Microsoft-supported capability, which means blanket trust in cloud provider infrastructure is insufficient as a control. The attack exploits the gap between what a feature is designed to do and how it can be abused at scale. If your organisation has not explicitly reviewed where device code flows are permitted — and who can initiate them — you have an untested exposure. Token-based access also tends to persist beyond the initial compromise event, so the window for harm extends well past the moment a user completes that authentication step.
What to do now
- Review and, where operationally viable, restrict device code authentication flows through conditional access policies in Microsoft Entra ID (formerly Azure AD).
- Audit existing conditional access policies to ensure device code grant types are explicitly scoped to legitimate use cases and approved device classes.
- Educate users — particularly executive assistants, IT staff, and finance teams — on the specific appearance and risk of device code phishing lures.
- Monitor for unusual token issuance events and access from unexpected locations or device profiles that follow a device code authentication grant.
- Review access logs for signs of persistent token use that may indicate a prior compromise through this method.
