Phishing is allang niet meer “een link die je naar een nagemaakte inlogpagina stuurt”. Met de Wazza phishkit zien we hoe aanvallers de hele route naar de uiteindelijke lure beheren: wie er wel (en wie er niet) wordt doorgelaten, welke sessie wordt gebruikt en wanneer de echte pagina wordt getoond.
In dit artikel leggen we uit hoe de campagne bezoekers filtert via een keten van tussenstappen en waarom dit security teams en vooral MSSP’s voor extra onderzoeks- en escalatievragen zet.
Wat is de Wazza phishkit?
De Wazza phishkit wordt gekoppeld aan phishingactiviteiten richting bankinstellingen, overheidsorganisaties en bedrijven in de maakindustrie in de VS, Europa en Australië. De campagne gebruikt een op Adobe geïnspireerde uitstraling, maar de kern zit in de manier waarop de phishingpagina wordt afgeleverd.
In plaats van één directe route naar een frauduleuze pagina, bouwt de infrastructuur controles in voordat een bezoeker de eindbestemming ziet. Voor verdedigers betekent dat: de “eerste URL” zegt minder dan je zou verwachten, omdat het uiteindelijke gedrag pas later in de keten zichtbaar wordt.
Multi-stage routing: zo verbergt Wazza de uiteindelijke lure
Een belangrijk kenmerk van de Wazza phishkit is de zogenoemde multi-stage routing. Concreet: niet iedere bezoeker krijgt meteen de phishingpayload. De server bepaalt eerst of een request past binnen een actieve campagne en of het verkeer “bruikbaar” is.
Van wildcard-domein naar configuratie-endpoint
De analyse start bij een wildcard landing domein, aangeduid als [.]boegl-krysl[.]eu. Daar komt een bezoeker terecht op een pad zoals /api/wazza-config. Dat endpoint controleert of de hostnaam onderdeel is van een actieve campagne.
Wie past in de juiste campagnelogica, gaat daarna door naar een volgende controlelaag.
Client markers en korte sessietokens
Vervolgens communiceert de infrastructuur met een extra component, omschreven als beacon-surge-sync[…]workers[.]dev. Daarbij wordt een client marker uitgegeven die kan dienen om bezoeken aan elkaar te koppelen.
Daarna volgt de stap /api/mint-token, waar een kortlevend ondertekend sessietoken wordt gegenereerd. Dat token wordt gebruikt om de volgende stap te “bewijzen”.
Validatie met browser telemetry en filtering
Het token gaat terug naar een controledomein, wederom [.]boegl-krysl[.]eu. Daar worden tokenvalidatie en browser telemetry uitgevoerd om ongewenst verkeer te filteren.
Pas als deze checks kloppen, krijgt de bezoeker toegang tot de volgende paden, waaronder routes die leiden naar de eindpagina (zoals boegl-krysl[.]eu/r en verder richting /meline).
Waarom de Adobe Device Code-page belangrijk is
Het eindresultaat is een phishingpagina met een Adobe-thema, maar de aanval speelt zich niet alleen af in het visuele aspect. De campagne maakt gebruik van een Device Code-stroom. Dat is relevant omdat het de aanvaller helpt om authenticatie te beïnvloeden, in plaats van alleen te vertrouwen op klassieke wachtwoord-templates.
Met andere woorden: de phishingpagina is slechts één fase. De Wazza phishkit zorgt er eerst voor dat de “juiste” bezoeker op het juiste moment bij de lure komt.
Gevolg voor detectie: aanvankelijke URL’s lijken vaak onschuldig
Voor defenders is dit type opzet lastig. Een URL kan er aanvankelijk relatief normaal uitzien, terwijl de uiteindelijke phishingpagina pas later in de keten verschijnt. Daarbij kan de content die automatische systemen zien, verschillen van wat een mens in een echte browsersessie te zien krijgt.
Dat verschil heeft twee praktische effecten:
- Reproductie wordt moeilijker: zonder het volledige routingpad te doorlopen, kun je mogelijk niet zien wat de pagina echt doet.
- Onderzoek schuift sneller door: als een analyst de keten niet kan reconstrueren, kan escalatie nodig zijn om scope en impact vast te stellen.
Voor MSSP’s wordt dit extra zichtbaar, omdat zij alertanalyse over meerdere klantomgevingen moeten beheren binnen strakke responstijden.
Waarom MSSP’s extra worden geraakt
Een standaard kwaadwillende URL kun je doorgaans vrij eenduidig onderzoeken. Bij de Wazza phishkit ligt de uitdaging anders: je behandelt niet één omgeving, maar vaak meerdere klanten, verschillende security stacks en een grote hoeveelheid meldingen.
De onzekerheid zit hem in het feit dat een verdacht domein in eerste instantie niet direct toont wat het uiteindelijk levert. Als je niet kunt aantonen welke payload er achter de link schuilgaat, kost de casus meer tijd—en daarmee gaat capaciteit naar minder complexe, maar wel tijdrovende triage.
Dit maakt sandbox-onderzoek en context belangrijker dan “alleen blokkeren op basis van één indicator”.
Sandboxing: onderzoek dat de volledige keten blootlegt
Een effectieve aanpak is een gecontroleerde analyse waarin je het verdachte verkeer door de redirect- en routeringslagen heen laat lopen. In de bron wordt hiervoor een interactive sandbox beschreven waarin analysten verdachte URL’s kunnen openen met virtuele machines die snel opstarten, vervolgens klikken/scrollen en redirects volgen.
Het doel is niet alleen “wat is de eindpagina”, maar ook: welke netwerk- en gedragsindicatoren verschijnen gedurende de route? Denk aan rapportage voor Tier 1, screenshots, procesoverzichten, IOC’s en mapping naar MITRE ATT&CK.
Voor de Wazza phishkit geldt daarbij een praktische regel: hoe sneller je de aanvalsketen reproduceert, hoe sneller je een betrouwbare uitkomst kunt geven en hoe minder je doorstroom naar senior resources hoeft te gebruiken.
Meer dan één IOC: de routingketen levert extra inzichten op
Het is verleidelijk om de Wazza phishkit te reduceren tot een lijstje domeinen dat je kunt blokkeren. Maar door de multi-stage opzet ontstaat juist meer context.
Door één verdacht startpunt te analyseren, kun je extra domeinen, endpoints, redirectpaden en gedragskenmerken ontdekken die bij dezelfde campagne horen. Dat helpt bij threat hunting, omdat aanvallers later individuele indicatoren kunnen vervangen, terwijl delen van de infrastructuurlogica behouden blijven.
In de bron wordt ook gesproken over het pivoten van IOC’s via threat intelligence lookup en het inzetten van query-updates om veranderingen in de tijd te volgen.
Continue monitoring: waarom een statische blocklist niet genoeg is
Zelfs als je één set indicators blokkeert, kan de campagne doorlopen. Phishinginfrastructuur kan veranderen: domeinen worden vervangen en routeringslogica wordt aangepast. Daarom heeft een statische IOC-lijst een beperkte houdbaarheid.
Continue dreigingsintelligentie kan helpen door gevalideerde indicatoren en gedrag te streamen richting securityomgevingen. Zo wordt een detectieproces minder afhankelijk van “eenmalige blokkade” en meer van doorlopende verrijking.
Integraties maken dreigingsdata bruikbaar in SOC-workflows
Intelligentie is pas waardevol als het aansluit op de tools die analysts al gebruiken. In de bron wordt genoemd dat dreigingsintelligentie kan worden geïntegreerd met onder meer Microsoft Sentinel, Microsoft Defender, Splunk en meerdere SOAR- en case-managementomgevingen.
Het voordeel is dat onderzoeksresultaten niet in een geïsoleerd rapport blijven hangen, maar kunnen doorstromen naar detectie, verrijking en (waar passend) response-acties. Voor MSSP’s is dat extra belangrijk, omdat je zo dezelfde kennis efficiënter kunt hergebruiken over meerdere klantomgevingen.
Mogelijke impact van een Wazza-aanval
De directe bedoeling is het leveren van een Device Code phishingpagina, maar succesvolle authenticatie kan verder reiken. Mogelijke uitkomsten die in de bron worden beschreven:
- Accountcompromittering: een succesvolle Device Code flow kan toegang geven tot accounts of sessies.
- Misbruik van een vertrouwde identiteit: een gecompromitteerde account kan communiceren alsof de aanvaller “normaal” is.
- Follow-on phishing: met een businessidentiteit kunnen nieuwe pogingen worden opgezet.
- Ontdekking van infrastructuur: door de routeringsketen komen extra indicatoren en endpoints naar voren.
- Meer responstijd: omdat de aanval achter meerdere checks kan verschuilen, kan onderzoek langer duren.
In de kern is de boodschap: dit is niet alleen “een phishingpagina”, maar een gecontroleerde leveringsketen met filtering en tokenvalidatie.
Zo maak je van één onderzoek schaalbare bescherming
De sterkste reactie op de Wazza phishkit is niet uitsluitend het blokkeren van één domein. De bron benadrukt dat je een verdachte URL kunt gebruiken als startpunt voor een herhaalbaar proces:
- Detoneer de verdachte link in een sandbox om gedrag en context zichtbaar te maken.
- Gebruik threat intelligence lookup om gekoppelde indicatoren te onderzoeken.
- Turn gevalideerde inzichten om in continue monitoring via intelligence feeds en relevante integraties.
Zo verschuift je aanpak van “reactie op één incident” naar “bescherming die meegroeit” met de campagne, terwijl je tijd vrijmaakt voor echt complexe zaken.
Vergelijkbare phishingmechanismen: extra context helpt
Deze manier van phishing—waarbij de gebruiker pas later de echte lure ziet—past in een breder patroon van aanvallen die zich voordoen als iets herkenbaars maar onder water complex blijven. Als je wilt zien hoe phishing zich ook via misleiding in browser- of identity-stappen kan uiten, lees dan ook eens fake decryptietools en ransomwareherstel: fraude en hoe zulke campagnes slachtoffers naar acties sturen die op het eerste gezicht plausibel lijken.
Ook interessant in dezelfde verdedigingspraktijk is aandacht voor hoe je content in de praktijk moet kunnen reproduceren en valideren—niet alleen op basis van één zichtbare URL.
Conclusie
De Wazza phishkit laat zien dat moderne phishing meer is dan een lokpagina. Met multi-stage routing, sessietokens, browservalidatie en filtering stuurt de aanvaller wie de eindfase ziet. Dat maakt detectie lastiger, omdat de startlink minder informatief kan zijn dan het lijkt en automatische systemen mogelijk niet dezelfde content zien.
Voor security teams en MSSP’s draait de oplossing om context: sandboxing om de keten volledig te doorlopen, het pivotten op extra indicatoren en het inzetten van continue threat intelligence met integraties. Zo wordt één onderzoek een bouwsteen voor bescherming die ook werkt wanneer de campagne onderweg indicatoren aanpast.
Bron: https://thehackernews.com/2026/10/wazza-phishkit-targets-banking.html
