As reported by The Hacker News, ANY.RUN has surfaced details on Wazza, a phishing kit targeting banking, government, and manufacturing sectors across the US, EU, and Australia. What sets Wazza apart from commodity phishkits is not the lure itself — it is the infrastructure layer beneath it.

Threat Alert: Attackers abuse this by generating the code themselves and social-engineering the victim into completing the approval.

Why This Matters Beyond a Single Campaign

For the past several years, the phishing arms race has centered on the landing page: better lookalikes, better evasion, better credential capture. Wazza represents a maturation of that model. The kit treats the entire delivery path — from initial DNS contact to final payload — as a programmable, filterable pipeline. This is infrastructure-as-product thinking.

The implications for defenders are significant:

Why This Matters Beyond a Single Campaign
Initial URLs are no longer the phishing page. The landing domain at [.]boegl-krysl[.]eu is functionally a traffic router, not a credential harvester. URL reputation systems and inline proxy scanners that evaluate the initial redirect will see benign-looking infrastructure.
Anti-analysis is built into the chain. By validating browser telemetry, issuing short-lived signed tokens, and filtering automated traffic at intermediate hops, Wazza actively denies sandbox detonation and crawler indexing. This means threat intel feeds that rely on automated scraping will likely miss the final payload.
Device Code Authentication abuse raises the stakes. The final Adobe-themed lure leverages OAuth Device Code flow — a vector that can bypass MFA entirely by requesting a device authorization token that the victim inadvertently approves. This is not credential theft; this is session hijacking with persistence potential.

The Device Code Flow Problem

Device Code Authentication was designed for input-constrained devices — smart TVs, IoT appliances, CLI tools. The flow asks a user to visit a URL and enter a short code. Attackers abuse this by generating the code themselves and social-engineering the victim into completing the approval. Once the victim authenticates through their legitimate identity provider, the attacker holds a refresh token — often valid for hours or days — without ever touching a password or MFA prompt.

The most dangerous aspect of Device Code phishing is that it piggybacks on the victim's own trusted identity provider. The authentication is real. The MFA challenge, if any, is satisfied by the legitimate user. The attacker simply receives the resulting token.

For organizations using Azure AD / Microsoft Entra ID, Okta, or Google Workspace, this means conditional access policies and MFA enrollment do not automatically protect against this vector unless Device Code flow is explicitly restricted or conditional access is configured to block non-compliant device authorizations.

Who Is Most at Risk

  • Banking and financial services — token theft enables transaction fraud and account takeover at scale
  • Government agencies — federated identity environments with broad OAuth integrations amplify blast radius
  • Manufacturing — often under-instrumented for identity telemetry, with legacy OT-adjacent systems using device code flows legitimately
  • MSSPs and MDR providers — multi-stage routing increases investigation time per alert and complicates cross-tenant correlation

Shield53 Recommendations

Immediate Actions

  • Restrict Device Code flow where it is not operationally required. In Microsoft Entra ID, disable or conditionalize the DeviceCode authentication method via conditional access policies. In Okta, review the urn:okta:...:device grant type policies.
  • Block the known Wazza infrastructure at email gateway, web proxy, and DNS resolver layers: *.boegl-krysl.eu, check.boegl-krysl.eu, beacon-surge-sync.workers.dev. Treat wildcard Cloudflare Workers subdomains with heightened scrutiny.
  • Alert on Device Code grant events in your IdP audit logs. Any successful device code token issuance originating from an unfamiliar IP or outside expected geographic regions should trigger an immediate investigation and token revocation.

Strategic Hardening

  • Implement phishing-resistant MFA — FIDO2/WebAuthn or Windows Hello for Business. These protocols are cryptographically bound to the legitimate origin and cannot be relayed through a Device Code flow.
  • Deploy mid-flow traffic analysis rather than relying solely on initial URL reputation. Inspect redirect chains, token generation patterns, and cross-domain beaconing at the proxy layer.
  • Train SOC analysts on Device Code phishing specifically — not just credential harvest pages. The indicators of compromise are in identity provider logs, not necessarily in web proxy logs.
  • Monitor for refresh token anomalies — tokens issued via device code flow that subsequently access APIs from unexpected geographies or client IPs are a strong post-compromise signal.

Wazza is not the most sophisticated kit we will see this year, but it is a clear signal of where phishing infrastructure is heading. The defenders who win this fight will be those who treat the delivery chain as the attack surface — not just the landing page.