Wazza Phishkit: Targets banks, governments and industry

The Wazza phishkit is a new, sophisticated phishing-as-a-service identified by ANY.RUN targeting organizations in the banking, industrial, and government sectors in the US, Europe , and Australia. Unlike traditional phishing kits that simply copy login pages, Wazza uses a multi-layered routing chain, anti-bot checks, and short-lived session tokens to reveal the final phishing page only to selected visitors. This discovery highlights a worrying evolution in the way attackers plan and execute credential theft attacks.

See also: N0va Phishkit targets businesses in the US and EU

Modern phishing kits are no longer limited to copying a well-known login page and waiting for credentials to be entered. Attackers are increasingly embedding filtering, session management, and traffic control mechanisms directly into the infrastructure that provides the phishing page. This trend makes automated detection significantly more difficult, as security tools may never “see” the malicious content.

The Wazza is part of a broader evolution of phishing, where tools are not just stealing passwords but are aiming to steal entire authenticated sessions. Tools like Tycoon2FA, Sneaky2FA , and Evilginx have been used to relay authentication traffic in real time and capture session tokens, allowing attackers to bypass many conventional MFA.

How Wazza phishkit works: The multi-stage chain

The Wazza phishkit does not send every visitor directly to the phishing page. Instead, it uses a multi-stage routing chain to determine which requests will reach the final payload. The flow starts from a wildcard landing domain, [.]boegl-krysl[.]eu, where the visitor is redirected to /api/wazza-config. This endpoint checks whether the hostname belongs to an active campaign. The infrastructure then contacts beacon-surge-sync[…]workers[.]dev, which issues a client marker to correlate the visit.

The next step involves generating a short-lived signed session token via /api/mint-token . This token is passed to check[.]boegl-krysl[.]eu , where Wazza validates the token and browser telemetry data, filtering out unwanted traffic. Only after all these checks pass does the visitor continue via boegl-krysl[.]eu/r and /meline , ultimately arriving at the Adobe Document Cloud -themed phishing page and Device Code authentication flow.

Using a recognizable brand like Adobe as a visual theme gives the final stage a familiar look, while the Device Code provides an attacker with a way to target account authentication rather than relying solely on conventional password collection. This approach is particularly dangerous because users may interpret an authorization or document sharing flow as a normal sign-in step.

See also: Phishing attack creates malicious pages in the browser

Wazza phishkit: Goals, impact and technical risks

ANY.RUN has detected Wazza phishkit activity in the US , Europe and Australia , with banking, industry and government sectors among the targeted industries. Financial institutions handle sensitive accounts and transactions, manufacturers depend on interconnected corporate environments, and government organizations manage critical information and services. These sectors are attractive targets due to the high value of the data and systems they manage.

Potential outcomes of a successful Wazza include full account takeover, access to email and cloud applications, theft or replay of browser session cookies, unauthorized access to banking or corporate systems, Business Email Compromise (BEC), creation of forwarding rules or OAuth grants, and privilege escalation via compromised administrator accounts. The absence of a confirmed number of victims should not be interpreted as an indication of limited activity — session-based filtering and theft can reduce visibility.

Wazza is part of a broader historical evolution: from simple credential phishing (cloned login pages) to MFA-bypass phishing (reverse proxies that record MFA-approved sessions), then to session hijacking (repeating cookies without reauthentication) and finally to traffic-controlled phishing, where filtering systems decide who sees the phishing page. Similar tools such as BlueKit, recently described by Malwarebytes, confirm the commercialization of these techniques.

Protecting against Wazza phishkit: Recommendations for organizations

To combat Wazza phishkit and similar threats, organizations should adopt phishing-resistant MFA , such as FIDO2 security keys or passkeys , especially for administrators and high-value users. Conventional MFA methods (push, SMS, one-time codes) can be intercepted or relayed during an Adversary-in-the-Middle (AiTM) attack . Implementing conditional access policies based on device compliance, connection risk, geography, and browser characteristics is also critical.

Security teams should monitor for session token reuse from a different IP address, user agent, device, or geographic region. In case of suspected AiTM, the response should be treated as a session compromise and not just a password breach — revoke active sessions and refresh tokens, check OAuth applications, mailbox forwarding rules, new registered devices, and recent privilege changes. Sandbox analysis should examine the entire redirect chain and browser activity, not just the original URL.

See also: Coyote banking trojan targets Windows users in Brazil

Additionally, organizations should enable email authentication checks — SPF, DKIM , and DMARC — and strengthen link scanning for external redirects. Educating users not to trust unexpected document sharing or cloud storage authentication prompts, and requiring users to navigate directly to known portals rather than clicking through links in spam emails, are key defenses. ANY.RUN’s core recommendation is to analyze the full browser flow — including redirects, scripts, network requests, and downstream content — rather than evaluating a URL based on its initial response.