Wazza phishing kit screens visitors before showing lure
Wazza phishing infrastructure screens visitors before showing them an Adobe-themed authentication lure, according to an analysis by ANY.RUN. The company reports activity targeting banking, manufacturing and government organizations in the US, Europe and Australia. Its findings describe a phishing kit, a collection of components used to build deceptive websites, that manages access to the trap rather than simply displaying a fake login page to everyone.
ANY.RUN presented the findings in a contributed partner article published by The Hacker News. The account includes an investigation performed in ANY.RUN’s Interactive Sandbox, an isolated computing environment for examining suspicious content. It describes the delivery sequence but does not identify affected organizations, count successful account compromises or establish how many people encountered the lure. The reported targeting should therefore not be read as confirmation that those organizations suffered breaches.
The sequence starts at a landing domain that accepts multiple subdomains under boegl-krysl[.]eu. A request to /api/wazza-config checks whether the hostname, the specific internet address being visited, belongs to a currently active campaign. That first check determines whether the visit fits the operation before the infrastructure proceeds with the rest of its screening.
Next, the infrastructure contacts beacon-surge-sync[...]workers[.]dev to obtain a client marker, an identifier that can connect activity to the same visit. The /api/mint-token endpoint, an address used by software to request a particular function, then produces a short-lived signed session token. This is a temporary digital pass whose signature allows the receiving system to check its authenticity. Wazza passes it to check[.]boegl-krysl[.]eu, where the infrastructure checks both the token and browser telemetry, information supplied by the visitor’s browser, to exclude unwanted traffic.
Visitors accepted by that gate continue through boegl-krysl[.]eu/r and /meline before reaching the Adobe-themed page. ANY.RUN describes the destination as Device Code phishing, an attack that tricks someone into completing an authentication action that can grant access to an account or session. The objective is therefore not limited to collecting a password typed into a counterfeit form. Familiar branding supports the deception, but the screening infrastructure has already decided whether to expose the visitor to it.
This selective delivery is the central difficulty for investigators. An automated link checker may not receive the same content as a person using a browser. Likewise, opening only the starting address may not reveal the final page if the visit fails a campaign, session or browser check. A result that does not display phishing content is not, by itself, evidence that the original link is safe. ANY.RUN’s analysis illustrates why the sequence of requests matters alongside the appearance of the final page.
For managed security service providers (MSSPs), businesses that monitor and investigate threats for customers, those differences can complicate work across multiple environments. The source argues that difficulty reproducing the complete sequence may lengthen investigations and push cases to more senior analysts. These are operational risks, not measured Wazza-specific outcomes in the account. Interactive examination in an isolated environment can help investigators observe redirects, the automatic transfers between web addresses, and the network activity that connects the stages.
The routing chain also gives defenders more evidence than a single address to block. Domains, request endpoints, redirect paths and recurring behavior can become indicators of compromise (IOCs), clues used to search for malicious activity. A finding from one customer’s investigation can provide a starting point for checking other environments. However, individual addresses can be replaced and routing behavior can change, so a static list of blocked domains is not a complete response.
ANY.RUN describes its Threat Intelligence Lookup as a way to investigate related activity and follow query updates, and its Threat Intelligence Feeds as a way to distribute updated indicators into security workflows. The company also lists integrations with Microsoft Sentinel, Microsoft Defender, Splunk, Cortex XSOAR, IBM QRadar, MISP, TheHive, ThreatConnect, Tines and Torq. These are the supplier’s descriptions of its products, not evidence that a particular integration has stopped Wazza. The article’s promotional performance claims do not establish the campaign’s scale or the effectiveness of protection against it.
For businesses and website owners, the immediate concern is account access. ANY.RUN identifies account or session compromise as a possible outcome, followed potentially by misuse of that identity to contact colleagues, partners or customers and send further phishing messages. It does not report those follow-on events as confirmed incidents. The practical distinction is important: an apparently routine authentication request can be the attack itself, even when it does not ask the user to disclose a password directly.
For organizations reviewing their handling of suspicious authentication requests, AEU-I offers security-first IT, infrastructure and consulting services, a relevant area of support rather than a claim of Wazza-specific protection. The reporting points to a clear investigative priority: assess the complete path behind a suspicious link, preserve the associated evidence and avoid treating a hidden or unreproduced landing page as proof of safety.