Security researchers have uncovered a new phishing toolkit named Wazza that is hitting banking, government, and manufacturing sectors across the U.S., Europe, and Australia with a highly evasive multi-stage delivery system. Rather than show its malicious payload immediately, Wazza uses layered routing, token-based session checks, and browser telemetry validation before delivering an Adobe-style Device Code phishing page. This makes it much harder for defenders and automated systems to detect or analyze the threat.
How Wazza’s Attack Chain Works
The Wazza campaign starts with a wildcard domain—something like [.]boegl-krysl[.]eu—that redirects visitors to an /api/wazza-config endpoint. This first stage checks whether the domain is part of an active campaign. From there, the visitor is routed to a domain that assigns a unique client marker and to another endpoint that issues a short-lived signed session token. Only after these initial conditions are satisfied does Wazza validate the session using telemetry and browser data via another subdomain. If all checks pass, the victim is finally shown the phishing page, styled to mimic Adobe’s Device Code flow.
Using an Adobe-themed Device Code flow is more than just an aesthetic choice. It’s designed to mimic legitimate account authentication requests, making it more convincing. And unlike usual credential harvesting, it may allow attackers to gain authenticated sessions or access without needing passwords. The multi-stage logic hides this final lure until just the right moment.
Why Wazza Is A Serious Problem For Service Providers
Managed Security Service Providers (MSSPs) face new challenges with Wazza. A threat URL might appear harmless at first because the phishing page isn’t delivered immediately. Automated scanners and analysts working in environments without full context may see only preliminary stages, lacking enough evidence to take action. That uncertainty often results in unnecessary escalation or delays. To counter this, analysts rely on tools that simulate real user interactions, trace routing chains and redirect behavior, and inspect the final payload under realistic conditions.
Another concern is that Wazza’s infrastructure generates many indicators of compromise (IOCs): domains, endpoints, redirect paths, behavioral patterns, session tokens, etc. Blocking just the final phishing URL won’t dismantle the campaign. Proper defense requires collecting and correlating those IOCs to rebuild the full picture of the threat.
Mitigation: Intelligence, Automation, and Scale
Detection isn’t enough—defenders need real-time threat intelligence and infrastructure that integrates this data into their workflows. Tools that can detonate suspicious URLs in virtual sandboxes provide witnesses into the full chain: what domains are involved, what traffic routing is used, and what the final payload looks like. Continuously updated threat feeds, support for formats like STIX/TAXII, and integrations with SIEM and SOAR platforms help institutions and MSSPs scale up their defenses.
Wazza demonstrates that phishing is no longer just about design. It’s become an engineering exercise in bypassing defenses. Its ability to screen, filter, and validate visitors before exposing the lure pushes defenders to rethink what counts as suspicious behavior.
On its own, an Adobe themed phishing page is just one piece. Wazza’s value to attackers comes from how quietly it controls the path to that page. For defenders, the lesson is that what happens behind the link is as crucial as what’s visible after clicking.
