Device code phishing: Account theft without passwords

A genuine Microsoft sign-in page can still hand an attacker corporate account access. Device code phishing campaigns from October 2026 abused legitimate authentication without ever touching a password. The fix is to restrict unnecessary device-code use and revoke compromised sessions; the checks below also cover fake AI downloads and Microsoft Defender tampering.

October's enterprise threats report describes five campaigns investigated by ANY.RUN researchers. They span Microsoft 365 account compromise, deceptive AI applications, and a Python-based infostealer. For enterprise IT teams, the risks include financial loss, stolen business data, and operational disruption. Across these cases, trusted services and ordinary business workflows became part of the attack path.

Device code phishing abuses trusted sign-in flows

Password theft isn't a necessary step in these Microsoft 365 campaigns. SkyW4lker, GeorgeGinx, and Mir0Auth abuse legitimate device-code authentication to seek account access. A victim can reach a real authentication service after following an attacker-controlled invitation, document, or redirect.

The shared failure is treating a familiar destination as proof that the whole journey is legitimate. GeorgeGinx uses a document-sharing service; SkyW4lker eventually presents Microsoft's own authentication page. A trusted domain does not validate the request that brought the user there.

ANY.RUN researchers identified 618 SkyW4lker-related sandbox analyses between June and October 21, 2026, with 46% coming from the US. During that investigation, researchers examined the IP address 198.23.223.185 and found related URLs and threat activity. That provides a concrete example of investigating beyond the first phishing address.

Start triage with the authentication request, not the page's appearance. For device code phishing, the useful questions are whether the flow was expected, whether it was necessary, and whether the resulting account session is compromised. The report recommends restricting unnecessary device-code authentication through Microsoft Entra Conditional Access.

A genuine AI installer can hide cookie theft

A working installer doesn't mean the download was safe. In one campaign the researchers describe, a genuine Claude installer ran while hidden processes stole browser session cookies. Those cookies could potentially let attackers access business accounts without another MFA prompt.

ANY.RUN researchers linked 1,258 sandbox analyses to fake AI campaigns, with the US ranking second worldwide for submissions. The campaigns impersonated ChatGPT, Claude, and other services, using fraudulent downloads to distribute malware and fake event invitations to steal account access.

This creates two investigation paths. A suspicious download calls for examining what executed alongside the advertised application. An unexpected event invitation calls for checking where its authentication journey leads. Both may arrive wrapped in a recognizable AI brand, but the route to compromise differs.

The report's practical advice is to approve trusted AI applications, restrict unauthorized installations, and verify unexpected invitations. That puts a decision before the risky action, rather than relying on whether the download or invitation looks convincing afterwards.

WKLP weakens endpoint protection and retains access

WKLP moves the problem from a sign-in workflow to the endpoint itself. The report describes it as a Python-based infostealer and remote access trojan targeting government organizations. It steals credentials, browser data, and sensitive files while allowing attackers to maintain access to compromised systems.

The malware uses PowerShell and a legitimate Python runtime to execute malicious code. Its reported behavior includes adding Microsoft Defender exclusions, terminating security processes, and creating disguised firewall rules. These changes weaken endpoint protection while the malware pursues theft and continued access.

For a managed laptop fleet, this makes security configuration changes part of the investigation, not merely background administration. An exclusion or firewall change needs attention alongside the suspicious process that prompted the alert. The report specifically recommends monitoring those changes and suspicious PowerShell activity.

WKLP combines data theft with interference in endpoint defences. That distinguishes it from the account-focused phishing kits. The response priorities therefore differ: the report recommends enabling Microsoft Defender Tamper Protection for WKLP, while its Microsoft 365 advice centers on authentication restrictions and compromised-session revocation.

Turn the reported behaviors into assignable checks

The useful response is to turn the reported behaviors into checks your team can actually assign. I'd start with unnecessary device-code authentication in a Microsoft 365 environment, then give the download and endpoint checks their own owners rather than folding everything into a generic phishing review.

1. Review unnecessary device-code access. Establish which business workflows need it, then use Microsoft Entra Conditional Access to restrict unnecessary authentication. The report names this control for SkyW4lker but doesn't provide a policy template.

2. Investigate suspicious authentication and revoke compromised Microsoft 365 sessions. Mir0Auth's reported objective is access-token theft, so the report's response isn't limited to looking for stolen passwords. Review the email, attachment, and redirect sequence alongside the suspicious device-code activity to understand how the user reached the authentication request.

3. Extend the investigation beyond the first indicator. Use associated malicious URLs and domains to enrich detection and hunt for connected activity, as the report recommends. The SkyW4lker investigation illustrates this approach: researchers expanded from an IP address into related URLs and threat activity rather than stopping at the original phishing link.

4. Put approval checks in front of AI downloads and unexpected invitations. Restrict unauthorized installations and verify invitations before proceeding. When investigating a suspicious installer, account for the Claude case: the genuine application running doesn't exclude hidden cookie-stealing processes. When investigating document links, examine redirects, page scripts, and network requests rather than trusting the sharing domain alone.

5. Enable Microsoft Defender Tamper Protection and review unauthorized exclusions, suspicious PowerShell activity, and firewall changes. These are the specific defensive checks the report associates with WKLP. Keep the investigation tied to those observed behaviors instead of treating the presence of a legitimate Python runtime as sufficient evidence either way.

Sandbox submissions do not measure confirmed breaches

Sandbox submissions do not measure confirmed breaches

The report provides investigation counts, not a count of successfully breached enterprises. The 618 SkyW4lker-related analyses and 1,258 fake-AI analyses describe sandbox activity. They shouldn't be presented as unique victims, compromised accounts, or successful intrusions.

Geography needs the same care. A US share of submissions or a ranking among submitting countries doesn't establish the compromise rate for that country. I wouldn't use those US-heavy figures to dismiss the authentication and download checks for an organization elsewhere.

The cookie-theft finding also has a boundary: the report says stolen cookies could potentially allow access without another MFA prompt. It doesn't establish that every stolen cookie produced a successful session. Likewise, GeorgeGinx's device-code route is described as potentially granting unauthorized account access.

There's an implementation gap, too. The report supplies defensive priorities, but not exact Conditional Access settings, command-line checks, or deployable detection rules. Those details need to come from the team's own configuration and investigation work; inventing them would make the advice look more complete than the evidence supports.

For a Microsoft 365 organization, my priority would be to remove unnecessary device-code exposure and act on compromised sessions, while separately checking for deceptive AI installations and Defender changes. That follows the strongest common lesson of these investigations: evaluate what a workflow authorizes and executes, not just the trusted name it displays.