Identity

A phishing kit called Wazza is stealing Microsoft 365 sessions with device code phishing, and it puts unusual effort into hiding the page that does it. ANY.RUN, which identified the kit and published its findings through The Hacker News on October 8, says it targets banking, manufacturing and government organizations in the US, Europe and Australia. LevelBlue SpiderLabs followed on October 20 with a deeper teardown and puts the kit's activity back to at least early July 2026.

We covered how device code phishing works when Microsoft took down EvilTokens. Wazza uses the same trick: the victim types a code on the genuine Microsoft page, passes their own MFA, and the attacker's waiting session receives the tokens. The difference is the routing chain in front of it, which is built so that email scanners and sandboxes never reach the lure. If your Entra ID tenant still allows the device code flow for ordinary users, this kit can work against you.

How the routing chain works

Most phishing pages sit at one URL. Paste that URL into a sandbox and you see the fake login. Wazza splits the journey into hops, and each hop decides whether the visitor deserves the next one.

The first hop is a wildcard landing domain, meaning any subdomain of it resolves, so every email can carry a different hostname. The page calls /api/wazza-config, which checks whether that hostname belongs to an active campaign. LevelBlue found the config also returns settings such as WILDCARD_ROUTING_ACTIVE and a list of 14 allowed subdomain prefixes. A request that fails is redirected to a decoy page; LevelBlue saw six fake corporate personas used this way, rotated hourly.

Next, the page contacts a Cloudflare Workers host (ANY.RUN and LevelBlue both name beacon-surge-sync on workers.dev) to get a marker that ties the visit together. /api/mint-token then issues a short-lived signed token, and the visitor is sent with it to a routing subdomain such as check. on the same domain. That gate validates the token and browser telemetry. LevelBlue lists what the gate looks for: Cloudflare Turnstile first, then Selenium and WebDriver properties, Puppeteer and Playwright artifacts, PhantomJS, "headless" in the user agent, WebGL renderer data and signs that DevTools is open. The results are encrypted and sent back as a challenge.

Visitors who pass go through /r and /meline to the final page on a workers.dev host. It shows an Adobe and Microsoft branded "Preparing your document" screen with a fake progress bar while the backend requests a real device code from Microsoft, which LevelBlue saw arrive in about 9 seconds. The page polls every 2 seconds. When the victim finishes signing in, it shows "Access Verified" and redirects; if the code expires, it quietly fetches a new one.

The point of all this is the gap between what a scanner sees and what a person sees. A URL rewriter or detonation sandbox that opens the first link gets either a decoy or a challenge it cannot pass. Only a real browser driven by a real person reaches the code.

What the campaigns look like

LevelBlue's samples arrived from compromised email accounts, carrying PDF attachments posing as invoices, contracts or documents waiting for review, with SharePoint branding. Some file names included the compromised sender's company name, which makes the lure look like ordinary business mail. Links in the PDFs led either to a Google Sites page that loads the attacker's content in an iframe, or straight to the kit's .eu domains, sometimes through URL rewriting services.

The kit is built for reuse. LevelBlue counted 19 themes selected by a URL parameter, covering file sharing, banking, document management, payments, HR, cloud services and the AdobeSign theme. Alternate service modes impersonate Microsoft OneDrive and DocuSign. It listed 21 .eu domains and two .com domains tied to the kit, plus nine workers.dev hosts, many with long, random-looking subdomains built from Microsoft service names.

The operators also adapt. In a second wave the routing subdomains changed from check, id and gate to portal, hub and svc, the beacon host and redirect endpoints were renamed, and LevelBlue reports that the routing checks were removed in the latest wave. Neither report names a specific actor or describes what was done inside compromised mailboxes, so treat any device code sign-in from this kit as full mailbox access.

What to do

Block the device code flow. In the Microsoft Entra admin center, go to Entra ID, Conditional Access, Policies, and create a new policy. Include all users and all resources, exclude your break-glass accounts, then under Conditions, Authentication flows, set Configure to Yes and select Device code flow. Set Grant to Block access and start in Report-only. Microsoft's guidance is to get as close as possible to a full block and allow the flow only for documented cases. Once the report-only results show who still needs it, put those accounts in a small exclusion group and switch the policy On.

Hunt for sign-ins that already happened. In the Entra sign-in logs, filter Authentication Protocol to Device code. In Log Analytics or Sentinel the same filter is SigninLogs | where AuthenticationProtocol == "deviceCode" and ResultType == 0, which keeps only successful sign-ins. Meeting-room devices and a few admin tools will show up; a finance user will not, unless something is wrong. LevelBlue suggests alerting on a device code sign-in shortly after the user opened an email attachment or a document-sharing page.

Hunt the web side. Search proxy, DNS and secure web gateway logs for the kit's paths: /api/wazza-config, /api/mint-token, /api/fire-mint, /meline, /bb-landing and /api.php?svc=. Flag long, randomized workers.dev subdomains and sites.google.com links in external mail that lead on to unfamiliar .eu domains. LevelBlue's report has the full domain list to load into your blocklists.

If someone entered a code. Changing the password does not end a session the attacker already holds. In the Entra admin center, open the user and select Revoke sessions, or run Revoke-MgUserSignInSession -UserId <id> in Microsoft Graph PowerShell. Then review the mailbox for new inbox rules and forwarding, and check the account for new authentication methods and app consents added after the sign-in.

Tell users what the code means. A code entered at microsoft.com/devicelogin signs a device into their account. If they did not just switch on a TV, printer or room system, a code that arrives with a document is an attack, and the help desk should hear about it.

Why sandbox verdicts are not enough here

Wazza is a good example of why a clean verdict from an email link scanner says little about device code phishing. The kit is built to show scanners nothing and show people the lure, and the final step happens on a genuine Microsoft page. Detection has to come from the identity side, where the sign-in itself is logged with its protocol, and from correlating that sign-in with the mail and web activity just before it.

Blocking the device code flow and checking who still uses it is part of our safeguarding and hardening work, and our security operations team builds the sign-in and proxy detections described above. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: The Hacker News (ANY.RUN), SC World, LevelBlue SpiderLabs, Microsoft Learn: block authentication flows, Microsoft Learn: revoke user access.