As reported by The Hacker News, security research from ANY.RUN has exposed Skyw4lker, a device code phishing campaign actively targeting American organizations across manufacturing, technology, and healthcare sectors. This is not another credential-harvesting operation with a fake OWA login page. It is something more insidious: an abuse of legitimate authentication infrastructure that renders traditional MFA checkboxes effectively meaningless.
Why Device Code Phishing Slips Past Traditional Defenses
Most organizations have spent years hardening against credential phishing — training users to check URLs, deploying anti-phishing policies in email gateways, and mandating MFA enrollment. Skyw4lker sidesteps all of it by triggering a legitimate Microsoft device authorization flow rather than spoofing one. The victim isn't typing their password into a lookalike form. They're entering a valid device code into the real Microsoft sign-in experience. The resulting access token is genuine, issued by Microsoft's own identity platform, and grants the attacker exactly what a compromised user would have — without triggering impossible-travel alerts, failed login throttling, or other controls designed to detect brute-force credential attacks.
When the authentication itself is legitimate, your detection strategy must shift from detecting the login to detecting the authorization context and what that token subsequently touches.
Infrastructure Abuse: Why Google Sites Matters
The campaign's use of sites.google.com as a redirect layer is a deliberate defensive-evasion choice. Google Sites is a trusted Google-owned domain that most URL reputation engines, secure web gateways, and browser-based protections treat as benign by default. Blocking it wholesale is often politically and operationally impossible inside enterprises that use Google Workspace. Attackers understand this asymmetry: they need only one layer of trusted infrastructure to bridge the victim from a phishing email to the Microsoft authentication flow.
The password-protected document lure — presented as a contract or service proposal — is equally calculated. Manufacturing and healthcare organizations routinely exchange vendor agreements, statements of work, and procurement files in exactly this format. The lure survives because it matches the victim's daily workflow rather than standing out as anomalous.
Who Is Most Exposed
Shield53 Recommendations
Defending against device code phishing requires controls at the identity layer, not just the email perimeter:
- Restrict or disable device code flow in Entra ID where it is not operationally required. Microsoft provides conditional access controls for the device code flow that can limit it to compliant managed devices only.
- Implement conditional access policies requiring managed device compliance, hybrid join, or app protection policies before token issuance — regardless of authentication method.
- Monitor Entra ID sign-in logs for the
authenticationProtocolindicating device code flow usage, especially from unmanaged devices or unfamiliar geographies. - Alert on anomalous token grant events where a device code flow results in access from a non-corporate IP or a new device fingerprint.
- Block or reproxy Google Sites traffic for users who do not have a business need, or use browser isolation for untrusted external document links.
- Train finance, procurement, and vendor management teams specifically on device code phishing — they are the natural targets for contract-themed lures and are often outside general security awareness programs.
- Feed ANY.RUN's published indicators into your SIEM and email security platform — this campaign is active and targeting U.S. organizations right now.
The broader lesson is that attackers no longer need to defeat your authentication — they need only to convince your users to complete it for them. Identity-centric defense means assuming the login itself can be weaponized and building guardrails around what a freshly minted token is permitted to reach.
