Die tückischste Malware auf einer Website legt die Seite nicht unbedingt lahm. Manchmal wird das Produkt ganz normal angezeigt, der Warenkorb funktioniert, der Kunde kann bezahlen und nirgends erscheint eine rote Warnmeldung. Das eigentliche Problem läuft im Hintergrund ab – direkt im Browser des Nutzers.

Cloudflare hat vier solcher Kampagnen beschrieben. Eine fing Klicks ab und leitete sie über einen Affiliate-Link um. Eine zweite erzeugte Affiliate-Anfragen, ohne dass der Nutzer überhaupt geklickt hatte. Eine dritte konnte zusätzlichen JavaScript-Code vom Server des Angreifers nachladen und ausführen. Die vierte sprang nur bei ausgewählten mobilen Nutzern aus bezahlten Kampagnen an und versuchte, Analyse- und Support-Tools abzuschalten.

Warum ein normaler Scan so etwas übersehen kann

Das gemeinsame Muster dieser Angriffe war nicht eine bestimmte Signatur oder eine einzige Methode, den Code zu verstecken. Die Skripte konnten Gerät, Land, Uhrzeit, Herkunft des Besuchers, Kampagnenparameter, Browserzustand oder Netzwerk prüfen und das eigentliche Verhalten erst dann aktivieren, wenn eine ganz bestimmte Kombination von Bedingungen erfüllt war.

WebsiteGarage / Leistungen

Entdecke unsere Leistungen.

Das bedeutet: Wer den Shop im Büro am Laptop überprüft, kann im laufenden Betrieb völlig anderen Code sehen als ein Kunde, der über eine Anzeige auf dem Smartphone kommt. Eine der von Cloudflare beschriebenen Kampagnen enthielt sogar eine Liste mit 325 IP-Adressfragmenten und blieb in ausgewählten Netzwerken inaktiv, damit sie bei Analysen schwerer zu erwischen war.

Genau deshalb reicht die statische Frage “Ist diese Datei als bösartig bekannt?” nicht immer aus. Cloudflare schreibt, dass nach der Entdeckung der Kampagnen sieben von acht Payloads nicht bei VirusTotal erfasst waren. URLScan stufte keinen der acht als bösartig ein.

Die erste Kampagne stahl keine Kartendaten. Sie ließ sich den Verkauf gutschreiben

In einem der Fälle wartete das bösartige Skript auf den passenden Moment und fing den Klick eines mobilen Nutzers ab. Der Kunde sah den Shop weiterhin ganz normal, aber der Traffic wurde durch einen vom Angreifer vorbereiteten Affiliate-Pfad geleitet.

Das konnte dazu führen, dass ein Verkauf falsch zugeordnet und eine Provision jemandem zugeschrieben wurde, der den Kunden überhaupt nicht gewonnen hatte. Ein ziemlich gutes Beispiel dafür, warum ein “Sicherheitsvorfall” nicht immer bedeutet, dass Passwörter oder Kreditkartennummern gestohlen wurden. Manchmal trifft ein Angriff direkt das Marketingbudget und die Daten, mit denen ein Unternehmen den Erfolg seiner Kampagnen bewertet.

Cloudflare trennt dabei bewusst zwischen dem, was der Code technisch konnte, und dem, was tatsächlich als Folge bestätigt wurde. In einer zweiten Variante konnte das Skript ohne einen Klick des Nutzers eine versteckte Affiliate-Anfrage erzeugen. Die Forscher konnten jedoch nicht bestätigen, ob solche Anfragen tatsächlich zu Provisionszahlungen geführt haben.

Auch die Marketing-Kette gehört zur Angriffsfläche

Bei einer der Operationen führte der Weg bis in den Browser durch eine Kette von Marketing-Skripten: Google Tag Manager lud einen weiteren Tag Manager, und dieser wiederum das bösartige Skript. Cloudflare betont ausdrücklich, dass dies kein Beweis dafür ist, dass die Tag Manager selbst kompromittiert wurden. Es zeigt aber sehr deutlich, wie mit jedem weiteren Marketing-Tool auch die Zahl der Stellen wächst, von denen eine Website Code nachlädt.

Das ist wichtig, weil Shopbetreiber beim Thema Sicherheit meist an Server, WordPress, Admin-Konten und Plugin-Updates denken. Im Browser des Kunden läuft aber zusätzlich JavaScript aus Analyse-Tools, Werbesystemen, Chats, Widgets und anderen Diensten. Wenn eine Ebene dieser Kette plötzlich etwas ausliefert, das der Betreiber nie autorisiert hat, kann der eigene Server trotzdem völlig unauffällig aussehen.

Der interessanteste Fall: ein Shop mit aktiver Hintertür im Browser

Die dritte Operation nutzte Code, der bereits früher für Suchumleitungen aufgefallen war. Im Shop blieben die alten Module größtenteils inaktiv. Ein aktiver Codepfad sendete jedoch Telemetriedaten und konnte JavaScript aus der Ferne nachladen.

Praktisch bedeutete das, dass sich das Verhalten des Angriffs verändern ließ, ohne die Dateien des Shops erneut manipulieren zu müssen. Cloudflare konnte nicht feststellen, welche Payloads in einer zweiten Stufe tatsächlich ausgeliefert wurden. Es gibt deshalb keinen Grund, daraus nachträglich eine Geschichte über Datendiebstahl zu machen, den die Forscher nicht bestätigt haben. Bestätigt war allerdings die Möglichkeit, Code aus der Ferne in den Browsern der Kunden nachzuladen und dort auszuführen.

Die vierte Kampagne zielte ausgerechnet auf Traffic, für den der Shop bereits bezahlt hatte

Ein anderes Skript wurde nur bei bestimmten mobilen Besuchen mit passenden Kampagnenparametern aktiv. Es versuchte, Analytics- und Monitoring-Tools abzuschalten, versteckte Chat und Kontaktformular und lud gleichzeitig eigene Ersatzmechanismen für das Tracking.

Cloudflare bestätigte in einer dynamischen Analyse, dass das ersatzweise geladene Analytics-Skript einen Beacon verschickte – also eine unsichtbare Anfrage, mit der Aktivität erfasst wird. Nicht bestätigt wurde dagegen, ob die Angreifer tatsächlich Session-Telemetrie abgegriffen oder Werbeumsätze umgeleitet haben. Diese Grenze ist wichtig: Dass Code etwas Bösartiges tun kann, ist nicht dasselbe wie ein nachgewiesener Schaden.

WebsiteGarage sagt

Die nützlichste Erkenntnis aus dieser Recherche ist unangenehm banal: “Die Website funktioniert” ist kein Sicherheitstest. Und “Der Checkout funktioniert” ist es genauso wenig.

Viele moderne Websites bestehen aus eigenem Code plus einem ganzen Waggon externer Skripte für Werbung, Analytics, Chat, A/B-Tests, Affiliate-Systeme und Automatisierung. Jedes weitere Stück JavaScript läuft auf der Seite des Kunden – also genau dort, wo es einen Klick sehen, das Verhalten der Website verändern oder Daten an eine andere Stelle schicken kann.

Meine Schlussfolgerung daraus wäre nicht: “Entfernt alle Tags.” Das ist ungefähr so praktisch wie der Ratschlag “Trennt das Internet.” Die sinnvollere Konsequenz ist eine andere: Die Liste der Skripte, die ein Shop lädt, sollte bekannt und kontrolliert sein. Und Monitoring darf nicht ausschließlich aus einem einmaligen Scan der Dateien bestehen. Wenn bösartiger Code nur zu einer bestimmten Uhrzeit, auf einem bestimmten Gerät oder bei Traffic aus einer Kampagne aufwacht, hat ein einzelner Scan schlicht eine ziemlich gute Chance, nur die brave Version der Website zu sehen.