Phishing-Kit mit selektiver Auslieferung : Wazza: Wie Phishing hinter Browserprüfungen und Sitzungstokens verschwindet

ANY.RUN meldet Aktivitäten von Wazza gegen Banken, Behörden und Fertigungsunternehmen in den USA, Europa und Australien. Das Kit kombiniert eine kontrollierte Auslieferung mit einer Phishing-Seite im Adobe-Design. Die dokumentierte Analysesitzung zeigt dabei mehrere Stationen zwischen Einstiegsadresse und Gerätecode-Köder.

Die Angriffskette prüft Besucher vor der Weiterleitung

Der beschriebene Ablauf umfasst sechs Schritte:

1. Einstieg über eine Subdomain: Ausgangspunkt ist *.boegl-krysl[.]eu.
2. Kampagnenprüfung: /api/wazza-config prüft, ob der angefragte Hostname zu einer aktiven Kampagne gehört.
3. Zuordnung des Besuchs: beacon-surge-sync[…]workers[.]dev liefert eine Client-Markierung.
4. Sitzungsfreigabe: /api/mint-token erzeugt ein kurzlebiges, signiertes Sitzungstoken.
5. Besucherfilterung: check[.]boegl-krysl[.]eu validiert Token und Browsertelemetrie.
6. Auslieferung des Köders: Über boegl-krysl[.]eu/r und /meline folgt die Phishing-Seite im Adobe-Design.

Wazza prüft zunächst, ob ein Besucher die Phishing-Seite überhaupt sehen darf. Das Sitzungstoken dient dabei als vorübergehender Zugangsnachweis. Seine digitale Signatur hilft, nachträgliche Veränderungen zu erkennen. Da das Token nur kurz gültig ist, lässt es sich später nicht beliebig erneut verwenden. Welche Signaturtechnik Wazza nutzt, wie lange das Token gilt und welche Browsermerkmale geprüft werden, geht aus der Beschreibung nicht hervor.

Wer bei der Analyse eine spätere Seite direkt öffnet, überspringt möglicherweise notwendige Prüfungen oder hat kein gültiges Token. Dann bleibt die Phishing-Seite verborgen, obwohl sie einem anderen Besucher angezeigt wird. Ein unauffälliger Test bedeutet deshalb noch nicht, dass der Link ungefährlich ist.

Gerätecode-Phishing missbraucht eine legitime Freigabe

Der Geräteautorisierungsablauf von Open Authorization 2.0 (OAuth) wurde für Geräte mit eingeschränkter Eingabemöglichkeit entwickelt. Ein Fernseher kann beispielsweise einen Code anzeigen, den der Nutzer auf einem anderen Gerät bestätigt. Der Standard RFC 8628 unterscheidet dabei zwei Werte: den für den Nutzer bestimmten user_code und den vom anfragenden Client verwendeten device_code.

Beim Gerätecode-Phishing initiiert ein Angreifer die Anfrage und bringt das Opfer dazu, den zugehörigen Nutzercode einzugeben und den Zugriff zu bestätigen. Anschließend kann der anfragende Client ein Zugriffstoken erhalten; abhängig vom Dienst ist zusätzlich ein Refresh-Token möglich.

Das Passwort muss dabei nicht auf einer gefälschten Seite landen. Auch eine echte Anmeldeseite kann Bestandteil der Täuschung sein, wenn der Nutzer dort eine fremde Anfrage autorisiert. Der Standard behandelt dieses Risiko ausdrücklich als „Remote Phishing“. Diese Erklärung beschreibt das allgemeine Verfahren; sie belegt weder einen bestimmten Identitätsanbieter noch konkrete Tokenrechte für Wazza.

Eine interaktive Untersuchung braucht nachvollziehbare Ergebnisse

Eine Sandbox ist eine abgeschirmte Testumgebung. Dort lassen sich verdächtige Links öffnen und untersuchen, ohne dafür den normalen Arbeitsplatzrechner zu verwenden. Bei mehrstufigen Angriffen sollte die Analyse festhalten, welche Webseiten der Browser aufgerufen hat, wohin er weitergeleitet wurde und wo der Aufruf abbrach. Bildschirmaufnahmen zeigen, was der Besucher zu sehen bekam. Aufzeichnungen der Netzwerkverbindungen machen den Weg zu diesen Seiten nachvollziehbar.

Auch solche Tests bringen die Phishing-Seite nicht immer zum Vorschein. Möglicherweise ist die Sitzung bereits abgelaufen, die Angriffskampagne nicht mehr aktiv oder der Testbrowser besteht die Besucherprüfung nicht. Der Analysebericht sollte deshalb klar benennen, was beobachtet wurde und welche Fragen offenbleiben.

Mögliche Folgen und Erkenntnisse für die Abwehr

Die Beschreibung nennt fünf mögliche Auswirkungen beziehungsweise Untersuchungsergebnisse:

• Kontokompromittierung: Zugriff auf angegriffene Konten oder Sitzungen.
• Missbrauch vertrauenswürdiger Identitäten: Kommunikation mit Kollegen, Partnern oder Kunden über ein kompromittiertes Konto.
• Weitere Phishing-Angriffe: Nutzung übernommener Geschäftsidentitäten für neue Täuschungsversuche.
• Aufdeckung der Infrastruktur: Zusätzliche Domains, Endpunkte und Verhaltensmerkmale aus der Weiterleitungskette.
• Höherer Analyseaufwand: Zusätzliche Arbeit für Reproduktion und Eingrenzung des Angriffs.

Die Infrastrukturaufdeckung ist dabei ein Nutzen für die Verteidigung, keine Schadensfolge. Die übrigen Punkte beschreiben mögliche Konsequenzen; daraus lässt sich keine Zahl erfolgreicher Kontoübernahmen ableiten.

Indikatoren brauchen Kontext und laufende Pflege

Kompromittierungsindikatoren (Indicators of Compromise, IOCs) helfen, bereits beobachtete Spuren wiederzufinden. Ihre Aussagekraft steigt, wenn Herkunft, Beobachtungszeitpunkt und Zusammenhang erhalten bleiben. Eine Domain allein erklärt weder den Ablauf noch den Erfolg eines Angriffs.

Threat Intelligence Lookup unterstützt die Suche nach zusammenhängenden Befunden, etwa über Domains, Adressen, Dateihashes und Ereignismerkmale. Solche Verbindungen liefern Ansatzpunkte für weitere Untersuchungen. Gemeinsam genutzte Infrastruktur sollte allerdings nicht automatisch als Beleg für denselben Täter gelten.

Threat Intelligence Feeds können aktualisierte Daten in bestehende Sicherheitsumgebungen übertragen. Unterstützte Austauschwege umfassen Structured Threat Information Expression (STIX), Trusted Automated Exchange of Intelligence Information (TAXII), eine Programmierschnittstelle (Application Programming Interface, API) und ein Software Development Kit (SDK).

Für einen Sicherheitsdienstleister (Managed Security Service Provider, MSSP) ist die Wiederverwendung geprüfter Erkenntnisse über mehrere Kundenumgebungen hinweg besonders relevant. Kundenspezifische Daten und Berechtigungen müssen dabei getrennt bleiben.

Integration verbindet Analyse und Reaktion

Analyseergebnisse lassen sich über Schnittstellen in bestehende Sicherheitsplattformen einbinden. Dazu zählen Systeme, die Sicherheitsmeldungen sammeln und auswerten, Endgeräte schützen, Bedrohungsinformationen austauschen oder Reaktionen auf Vorfälle automatisieren. Beispiele für Plattformanbindungen sind etwa:

• Microsoft Sentinel
• Microsoft Defender
• Splunk
• Cortex XSOAR
• IBM QRadar
• Malware Information Sharing Platform (MISP)
• TheHive
• ThreatConnect
• Tines
• Torq

Der Nutzen hängt davon ab, welche Informationen übertragen werden und was die angebundenen Systeme damit tun. Zusätzliche Angaben zu einer verdächtigen Adresse können beispielsweise helfen, einen Alarm besser einzuschätzen. Soll daraus automatisch eine Sperre entstehen, müssen die Hinweise ausreichend zuverlässig und der Grund für die Sperre nachvollziehbar sein.

 Gerätecode-Verfahren gezielt einschränken

Die Abwehr sollte auch dort ansetzen, wo Kontozugriffe freigegeben werden. Microsoft dokumentiert für Microsoft Entra ID eine Richtlinie zum Blockieren des Gerätecode-Verfahrens. Unternehmen sollten zunächst legitime Nutzungen erfassen, die Richtlinie im Berichtsmodus prüfen und erforderliche Ausnahmen begrenzen.

Für Nutzer gilt eine konkrete Prüffrage: Wurde die Geräteverbindung selbst gestartet, und passt die angezeigte Anwendung zur beabsichtigten Aktion? Eine unerwartete Aufforderung zur Codeeingabe sollte abgebrochen und gemeldet werden.

Damit ergänzen sich zwei Schutzebenen: Die Webseitenanalyse untersucht die Auslieferung des Köders, während Identitätsrichtlinien die missbrauchbare Freigabe begrenzen. Belastbare Abwehr braucht Erkenntnisse aus beiden Bereichen.