In diesem Beispiel werden wir eine Phishing-Kampagne analysieren, die sich als Netflix tarnt und die Opfer in Echtzeit steuert. Es handelt sich hierbei nicht um ein gewöhnliches statisches HTML-Formular, sondern um einen vollwertigen Phishing-Dienst: Der Nutzer durchläuft mehrere Schritte, und der Betreiber entscheidet über das Kontrollpanel, wohin er als Nächstes weitergeleitet wird – zur Eingabe von Login-Daten, Kreditkartendaten, SMS-Code, PIN-Code oder zur Bestätigung in der App.
Wir haben die Funktionsweise separat bestätigt, indem wir uns Zugriff auf das Kontrollpanel dieser Phishing-Website verschafft und es untersucht haben.
In diesem Artikel beschreiben wir nicht, wie der Zugriff auf das Kontrollpanel erlangt wurde, sondern nutzen die bloße Tatsache seiner Existenz als Bestätigung des Betriebsmodells: Der Angriff wurde manuell oder halbautomatisch über eine Backend-Schnittstelle gesteuert.
0. Der Köder
Das Erste, was der Nutzer erhält, ist eine E-Mail mit einer Standard-Social-Engineering-Taktik, die zum Handeln auffordert. Die Angreifer hoffen, die Aufmerksamkeit des Nutzers darauf zu lenken, dass das Anschauen seiner Lieblingsfernsehsendungen möglicherweise unterbrochen wird. Um E-Mail-Filter zu umgehen und die endgültige Phishing-Domain zu verbergen, verwenden die Angreifer einen verkürzten Link über die Infrastruktur des sozialen Netzwerks X: https://t.co/XXXXXXX
Auf den ersten Blick handelt es sich um einen gewöhnlichen Link über t.co, weshalb er sowohl für den Nutzer als auch für einige automatische Filter weniger verdächtig wirkt.
Nach dem Klicken gelangt der Nutzer nicht sofort auf die eigentliche Phishing-Seite. Zunächst wird er auf eine Zwischenseite weitergeleitet.
1. Öffentlicher S3-Bucket als Zwischen-Redirect
Der Link führt zu einem öffentlichen S3-Bucket: https://access-authority-2faXXXXX.s3.eu-north-1.amazonaws.com/index.html
Dieser Schritt dient als Filter und Weiterleitungsstelle.
index.html Sie enthält eine Filterung nach Ländern und vorab bekannten IP-Adressen. Dadurch wird verhindert, dass die eigentliche Phishing-Website Forschern, automatischen Scannern, Sandboxen und Schutzsystemen angezeigt wird.
Nach Durchlaufen des Filters erhält der Nutzer eine einfache HTML-Weiterleitung:
<meta http-equiv="refresh" content="1;url=https://www.XXXXX.help/index.html">
Die Domain tarnt sich als Dienst zur CAPTCHA-Lösung. Das ist eine praktische Tarnung: Der Nutzer sieht den technischen Namen und könnte denken, dass es sich um eine Zwischenprüfung des Browsers, ein CAPTCHA oder eine Sicherheitsüberprüfung handelt.
In der Praxis handelt es sich um eine Phishing-Infrastruktur.
Bereits in dieser Phase wird ein Fingerprinting des Geräts durchgeführt. Der Code erfasst Benutzerereignisse:
- mousemove
- touchmove
- keyup
- Backspace
- deviceorientation
Das Skript analysiert nicht nur das Auftreten der Ereignisse selbst, sondern auch deren Parameter:
- Bewegungsgeschwindigkeit;
- Intervalle zwischen den Ereignissen;
- normalisierte Koordinaten;
- die Steilheit der Richtungsänderung;
- Tastaturverhalten;
- Geräteausrichtung;
- Touch-/Mausprofil.
Dies wird verwendet, um zu beurteilen, ob es sich bei dem Besucher um einen echten Menschen handelt.
Verschleierung und „Verschlüsselung“ der Telemetriedaten
Ein Teil der Telemetriedaten wird vor dem Versand mittels AES-CBC verschlüsselt: crypto.subtle.encrypt({ name: 'AES-CBC', iv: ... }, key, data)
Der Code enthält Anti-Debugging-Logik. Das Skript bildet ein Wort debugger aus einem Zahlenarray und ruft es über new Function(). Wenn die Ausführung verzögert wird, sendet die Seite eine Beacon-Anfrage an /misc/index.php?r=<random> mit dem Parameter bcl
Dies scheint ein Versuch zu sein, festzustellen, ob der Nutzer die DevTools geöffnet hat oder ob die Ausführung von JavaScript an einem Breakpoint angehalten wurde; das Backend kann das Verhalten ändern, den eigentlichen Ablauf verbergen und einen Fehler anzeigen oder den Nutzer auf die legitime Netflix-Website weiterleiten.
Nach erfolgreichem Bestehen des „Captcha“ erfolgt eine Weiterleitung zu main/prepare.php
2. Erste Phase: Erfassung von Benutzername und Passwort
Die erste eigentliche Phase des Angriffs – weder per Karte noch per SMS. Zunächst gelangt der Nutzer auf eine Seite, die den Login bei Netflix imitiert.
In dieser Phase sammeln die Angreifer die E-Mail-Adresse und das Passwort.
Wichtig: Der Angriff beginnt mit der Kompromittierung des Kontos und geht erst danach zu den Zahlungsdaten über.
Nach dem Absenden des POST-Formulars leitet die Seite den Nutzer zur nächsten Phase weiter – der „Kreditkartenüberprüfung“.
Selbst wenn die weiteren Zahlungsschritte nicht abgeschlossen werden, erzielen die Angreifer somit bereits ein wertvolles Ergebnis: den Zugriff auf das Konto.
3. Zweite Phase: Eingabe der Kartendaten
Nach Eingabe von Benutzername und Passwort wird der Nutzer auf die Seite zur Zahlungsüberprüfung weitergeleitet.
In dieser Phase täuscht das Szenario vor, dass die mit Netflix verknüpfte Karte bestätigt werden muss. Der Nutzer sieht eine Oberfläche, die dem legitimen Abrechnungsablauf ähnelt, und gibt seine Zahlungsdaten ein.
Ziel dieser Phase ist es, folgende Daten zu erfassen:
- Name des Karteninhabers
- Kartennummer
- Ablaufdatum
- CVV/CVC
Während des gesamten Vorgangs werden kontinuierlich Telemetriedaten gesendet:
4. Dritte Phase: Ladebildschirm und Warten auf den Mitarbeiter
Nach Eingabe der Kartendaten gelangt der Nutzer auf eine Warte-Seite. Genau diesen HTML-Code sehen wir in dem untersuchten Artefakt.
Auf der Seite steht:
Zur Vervollständigung Ihrer Kartenüberprüfung ist eine zusätzliche Validierung erforderlich
Sie erhalten eine Kurznachricht auf Ihrem Mobiltelefon...
Optisch sieht dies wie das übliche Warten auf eine Bestätigung durch die Bank aus. Technisch gesehen handelt es sich jedoch nicht einfach um einen „Wartebildschirm“, sondern um einen Punkt, an dem der Nutzer in der Sitzung verbleibt, während das Backend oder der Mitarbeiter entscheidet, welcher nächste Schritt angezeigt werden soll.
5. Echtzeit-Steuerung über WebSocket
Der wichtigste Steuerungsmechanismus ist WebSocket. Wir können einen offenen wss:// unten in den Anfragen. Die Seite stellt eine Verbindung zum WebSocket her und wartet auf einen Befehl vom Backend. Im HTML-Code ist die Logik integriert, mit der der Operator den Nutzer auf verschiedene Bildschirme weiterleiten kann:
| Code | Pfad | Beschreibung |
|---|---|---|
| 1 | ./app.php | Seite zur Bestätigungsanfrage in der Banking-App |
| 2 | ./payment.php | Erneute Aufforderung zur Eingabe der Kartendaten aufgrund eines Fehlers |
| 3 | ./sms.php | Seite zur Eingabe des Codes aus der SMS |
| 4 | ./pin.php | Seite zur Eingabe des PIN-Codes von der Karte |
| 5 | https://netflix.com | Weiterleitung zur echten Netflix-Website |
Die vom Nutzer eingegebene Karte wird automatisch oder halbautomatisch für Zahlungen in verschiedenen Shops verwendet. Höchstwahrscheinlich handelt es sich dabei um Händler, die von den Angreifern kontrolliert werden.
Genau hier wird die Echtzeitkomponente besonders gefährlich. Der Angreifer kann erkennen, welche Art von Bestätigung das Zahlungssystem angefordert hat, und die Phishing-Seite an den jeweiligen Zeitpunkt des Angriffs anpassen. Mal wird die Bestätigung in der App angefordert, mal der Code aus einer SMS oder der PIN-Code der Karte.
6. Bestätigung über das Admin-Panel
Nachdem wir die Funktionsweise der Phishing-Website untersucht hatten, beschlossen wir, nach Schwachstellen in diesem Panel zu suchen. Dabei stießen wir auf ziemlich seltsame „Easter Eggs“ des Entwicklers dieses Panels.
Anhand der Protokolle lässt sich feststellen, dass sich innerhalb von 24 Stunden mindestens vier verschiedene Administratoren des Panels im Abstand von 4 bis 7 Stunden in das Admin-Panel eingeloggt haben.
Außerdem haben wir weitere offene Ports im Panel entdeckt: 2082, 2095, 8880 und 1010. Diese ermöglichten es uns, die tatsächliche IP-Adresse zu ermitteln, da sich die Betrugswebsite hinter CloudFlare verbirgt.
Die Provider wurden benachrichtigt.
7. Anzeichen für eine Kompromittierung
Domains
*.solvecaptcha.help
8. Fazit
Diese Kampagne zeigt, wie moderne Phishing-Dienste eine gewöhnliche Anmeldeseite in eine in Echtzeit gesteuerte Operation verwandeln.
Die Angreifer erlangen zunächst den Benutzernamen und das Passwort, anschließend die Zahlungsdaten und halten den Nutzer danach auf einem Ladebildschirm fest. In diesem Moment entscheidet der Betreiber über das Backend bzw. das Admin-Panel, welcher nächste Schritt angezeigt werden soll: SMS-Code, PIN-Code, Bestätigung in der App oder endgültige Weiterleitung zur echten Netflix-Seite.
Das wichtigste technische Merkmal dieser Masche ist die WebSocket-Steuerung. Genau diese macht den Angriff interaktiv und ermöglicht es den Betreibern, das Szenario an das jeweilige Opfer und den jeweiligen Bankablauf anzupassen.
Das ist keine „Phishing-Seite“ mehr. Es handelt sich um einen Live-Phishing-Angriff.