Skyw4lker campaign targets US firms through Microsoft device codes

ANY.RUN has identified Skyw4lker, a device code phishing campaign aimed primarily at US manufacturing, technology and healthcare organisations. The campaign uses password-protected documents styled as contracts or service proposals, Google-hosted pages and Microsoft authentication flows to obtain access to Microsoft 365 tokens.

The investigation illustrates a phishing method that does not depend on a counterfeit Microsoft sign-in page or direct password collection. Instead, the attacker initiates a legitimate device authorisation process and persuades the recipient to complete it. Once the process is approved, the resulting tokens can give the attacker access to resources available to the compromised account.

Legitimate authentication used as the lure

The FBI’s Internet Crime Complaint Center recorded 193,407 phishing and spoofing complaints in 2024. In 2025, the FBI recorded more than one million internet crime complaints and $20.9 billion in reported losses, a 26% rise in losses from the preceding year. Skyw4lker shows how phishing operators are adapting as organisations invest more heavily in identity controls and multifactor authentication.

In the observed chain, a recipient opens a document that resembles routine commercial correspondence. The document directs the victim to a page hosted on sites[.]google[.]com, which ultimately leads to a Microsoft 365 authentication flow. The authentication can be genuine; the deception lies in getting the victim to authorise a request created by the attacker.

That distinction complicates triage. Identity telemetry may show a valid authentication event without showing the document, redirects and web activity that prompted it. Establishing the full sequence requires investigators to correlate the lure, browser behaviour, authentication flow and supporting infrastructure rather than assess a single login in isolation.

Infrastructure and behavioural evidence

ANY.RUN found obfuscated JavaScript and a PHP backend in the campaign infrastructure. The backend was used to create a victim session, collect information including IP address and geolocation, and repeatedly poll while the authentication process was awaiting completion. Those details are not necessarily visible from a static inspection of the initial document.

Following the campaign in an isolated browser environment can expose JavaScript execution, redirects, backend communications and network activity. This produces evidence such as URLs, domains, IP addresses, screenshots and behavioural indicators that can be used to validate an alert and develop detections.

Turning one investigation into broader detection

ANY.RUN states that 99% of unique, high-confidence indicators are added to its Threat Intelligence Feeds after validation. Its internal analysis also found that up to 30% of unique malicious indicators discovered during Interactive Sandbox sessions had already been observed by the company and were present in those feeds.

For an internal SOC, an indicator found in a reported phishing document can be compared with historical telemetry to identify other potentially affected users. For an MSSP, the same indicators can be searched across customer environments. ANY.RUN supports this workflow through API/SDK, STIX/TAXII, SIEM, TIP and XDR integrations.

The practical business implication is that teams should investigate device-code phishing as an end-to-end chain: correlate the initial file, web redirects, authentication activity and infrastructure, then apply confirmed indicators across relevant telemetry to find related activity sooner.