Wazza phishing kit uses routing checks to conceal Adobe-themed lure

ANY.RUN has identified a phishing kit named Wazza targeting banking, manufacturing and government organisations in the US, Europe and Australia. Rather than sending every visitor directly to a credential-harvesting page, the campaign uses layered routing, session controls and browser validation before selectively delivering an Adobe-themed Device Code phishing lure.

The campaign illustrates a shift in phishing delivery: the visible page is only the final component. The infrastructure first decides whether a request meets its conditions, which can make a suspicious link appear harmless until its full sequence is reproduced in an appropriate environment.

Routing chain screens visitors before the lure

ANY.RUN traced the flow from the wildcard landing domain boegl-krysl[.]eu to the /api/wazza-config endpoint, which checks whether a hostname belongs to an active campaign. The infrastructure then contacts beacon-surge-sync[.]workers[.]dev to issue a client marker that can correlate a visit.

Next, /api/mint-token creates a short-lived signed session token. Wazza passes that token to check[.]boegl-krysl[.]eu, where it validates the token and browser telemetry while filtering unwanted traffic. Only then does the visitor proceed through boegl-krysl[.]eu/r and /meline to the final Adobe-themed Device Code page.

The use of a familiar brand can make an authentication request look routine. In this case, the Device Code flow is intended to target account authentication rather than depend solely on conventional password capture. The changing page branding is therefore less important than the delivery method: visitor filtering, session validation and selective presentation of the lure.

Why the campaign complicates phishing investigations

A straightforward malicious URL can often be assessed from the content it returns. Wazza may return different content to automated security systems and to a visitor who completes the expected routing sequence. An analyst unable to reproduce that chain may need more time simply to establish what the URL delivers.

This creates a particular operational issue for managed security service providers. Their analysts investigate alerts across multiple customers and security stacks while working within response and escalation requirements. When malicious behaviour is concealed by several checks, more cases may require senior review before a reliable verdict can be reached.

ANY.RUN says its Interactive Sandbox can open suspicious URLs in virtual machines, allow interaction with pages and redirects, and expose network and behavioural activity. The company states that its Tier 1 reports include indicators of compromise, screenshots, process graphs and MITRE ATT&CK mapping. Those capabilities are relevant because a Wazza investigation needs to capture the routing behaviour, not simply inspect the final URL.

Indicators can support wider detection

The campaign's infrastructure offers several investigation pivots, including domains, endpoints, redirect paths and behavioural indicators. ANY.RUN's Threat Intelligence Lookup is intended to let analysts pivot from indicators of compromise to related activity and track changes through query updates.

Blocking one Wazza domain may not stop a campaign whose domains and routing logic can change. ANY.RUN also offers Threat Intelligence Feeds with STIX/TAXII, API and SDK support, alongside integrations with platforms such as Microsoft Sentinel, Microsoft Defender, Splunk, Cortex XSOAR, IBM QRadar, MISP, TheHive, ThreatConnect, Tines and Torq.

The practical implication for security teams is to treat a suspicious phishing link as the start of an investigation into its delivery chain. Capturing and validating the associated routing, session and browser checks can turn one alert into indicators that support hunting and protection across affected environments.