ClickFix auf der Blockchain: Mehr als 5.400 kompromittierte Websites verbreiten Schadcode

WordPress und PrestaShop als Verteilpunkte missbraucht

Mehr als 5.400 kompromittierte Websites sind Teil einer kriminellen Operation, die ClickFix-Köder, Smart Contracts und WebRTC-Kommunikation kombiniert. Die von Netskope analysierte und am 5. September 2026 bekannt gemachte Aktivität betrifft vor allem Portale auf Basis von WordPress und PrestaShop.

Die Angreifer schleusen ein Skript in die Websites ein, das die nachfolgende Payload aus der BNB Smart Chain Testnet abruft. Dadurch werden überwiegend kleinen Unternehmen gehörende Seiten zu Verteilpunkten für Schadcode, der aus der Ferne gesteuert wird.

Wie der Erstzugriff auf die Websites erfolgte, ist nicht bekannt. Möglich sind daher ausgenutzte Schwachstellen in Komponenten, gestohlene Zugangsdaten oder andere Angriffsvektoren; für eine eindeutige Bewertung liegen jedoch nicht genügend Informationen vor. Auch die Versionen von WordPress, PrestaShop oder möglicherweise betroffenen Plugins wurden nicht mitgeteilt.

Die Operation ist keiner formal identifizierten Schwachstelle zugeordnet: Es gibt keine bekannten CVE, standardisierten Schweregrade oder Einträge im Known Exploited Vulnerabilities-Katalog der CISA. Das beobachtete Problem betrifft bereits kompromittierte Websites und keine konkrete Schwachstelle in einem einzelnen Produkt.

Das Ausmaß ist erheblich. Netskope schätzt, dass täglich mehr als 300 infizierte Websites eingesetzt werden. Seit dem Frühjahr ist die Zahl der Domains, die die RPC-Endpunkte der BNB Smart Chain Testnet kontaktieren, kontinuierlich gestiegen. Im August lag der Tagesdurchschnitt bei knapp 400 Websites, mit einem Höchstwert von 536.

EtherHiding verlagert die Payload in einen Smart Contract

Das in die Websites injizierte Skript muss nicht zwangsläufig die gesamte Schadcode-Kette enthalten. Stattdessen fragt es über die RPC-Endpunkte einen auf der BNB Smart Chain Testnet abgelegten Smart Contract ab und ruft daraus Code oder Konfigurationsdaten ab.

Diese Technik wird als EtherHiding bezeichnet. Die Blockchain dient dabei als dauerhaft verfügbare Verteilungsebene, während die kompromittierte Website den Einstiegspunkt zum Opfer bildet.

Die Nutzung des Testnet bietet mehrere operative Vorteile. Das Netzwerk ist für Entwickler vorgesehen, bildet die Funktionsweise des Mainnet nach und kann kostenlos genutzt werden. Der RPC-Datenverkehr kann zudem wie legitime Aktivitäten im Zusammenhang mit Blockchain-Anwendungen und Entwicklungstools wirken.

Um die Kampagne vollständig zu deaktivieren, reicht es daher nicht aus, einen herkömmlichen Webserver abzuschalten. Die über den Smart Contract erreichbaren Inhalte bleiben im Netzwerk verfügbar, was zentralisierte Takedown-Maßnahmen erschwert.

Die Angreifer können außerdem die vom Contract bereitgestellten Inhalte ändern. Dadurch können sie einen Köder, einen Stager oder eine Konfiguration austauschen, ohne auf allen 5.400 Websites manuell neuen Code einzuschleusen.

Genau das geschah während der analysierten Aktivität: Die ursprüngliche ClickFix-Payload wurde durch einen auf WebRTC Data Channel basierenden Stager ersetzt.

Das gefälschte CAPTCHA bringt Opfer dazu, PowerShell auszuführen

Die zuerst beobachtete Variante zeigt innerhalb der kompromittierten Website ein gefälschtes CAPTCHA. Dabei handelt es sich nicht um eine echte technische Überprüfung, sondern um eine Social-Engineering-Anweisung, die den Nutzer dazu bringen soll, den eigenen Computer selbst zu kompromittieren.

Das Opfer wird aufgefordert, das Windows-Dialogfeld „Ausführen“ zu öffnen, einen PowerShell-Befehl einzufügen und auszuführen. Dieser Befehl lädt die finale Payload herunter und startet sie.

ClickFix umgeht auf diese Weise eines der typischen Hindernisse bei browserbasierten Infektionen. Die Website muss keine Schwachstelle im Betriebssystem ausnutzen: Sie bringt den Nutzer dazu, einen Befehl einzugeben, der wie ein notwendiger Schritt zur Behebung eines Problems oder zum Abschluss einer Überprüfung erscheint.

Die genaue Art der finalen Payload wurde nicht bekannt gegeben. Auch Hashes, Dateinamen oder weitere Indikatoren, die eine Zuordnung der Kette zu einer bestimmten Malware-Familie ermöglichen würden, liegen nicht vor.

Für Nutzer ist das auffälligste Warnsignal daher das Verhalten. Ein legitimes CAPTCHA fordert nicht dazu auf, das Windows-Dialogfeld „Ausführen“ zu öffnen, Befehle einzufügen oder PowerShell zu starten. Eine Seite, die ein solches Vorgehen vorschlägt, sollte geschlossen werden, ohne die Anweisungen auszuführen.

Die WebRTC-Variante führt JavaScript aus, ohne es auf der Festplatte zu speichern

In der nächsten Phase ersetzten die Betreiber den ClickFix-Inhalt im Smart Contract durch einen auf WebRTC Data Channel basierenden JavaScript-Stager.

WebRTC wird von Browsern normalerweise für Echtzeitkommunikation eingesetzt. In diesem Fall baut der Stager eine Peer-Verbindung und einen Datenkanal auf und erzeugt eine Sitzungsbeschreibung, wie sie bei einem normalen Handshake verwendet wird.

Der Ablauf ist jedoch ungewöhnlich: Der Stager erstellt die Antwort selbst und fügt sie wieder in die Verbindung ein. Auf diese Weise umgeht er einen tatsächlichen Handshake und kann dennoch einen Datenkanal zur Infrastruktur der Angreifer öffnen.

Der JavaScript-Code wird von einer im Stager eingebetteten Command-and-Control-Adresse abgerufen. Die Daten werden im Speicher des Browsers gesammelt und anschließend ausgeführt, sobald der Kanal geschlossen wird oder 10 Sekunden abgelaufen sind.

Die Ausführung erfolgt dynamisch, indem der Code dem head-Element des DOM hinzugefügt wird. Der Inhalt muss daher nicht als Datei auf der Festplatte gespeichert werden.

Diese Methode reduziert die Zahl der Artefakte, die bei dateibasierten Kontrollen zur Verfügung stehen. Unsichtbar wird die Aktivität dadurch jedoch nicht: Beobachtbar bleiben die RPC-Anfragen, der WebRTC-Datenverkehr, das Verhalten des Browsers und die Kommunikation mit dem C2.

Die hartcodierte Adresse des Command-and-Control-Servers wurde nicht veröffentlicht. Auch die konkreten Adressen der beteiligten RPC-Endpunkte sind nicht bekannt, obwohl Netskope in seinen Empfehlungen eine Reihe zu blockierender Endpunkte genannt hat.

Diese Kontrollen sollten auf Websites, im Netzwerk und an Endpunkten umgesetzt werden

Administratoren von WordPress- und PrestaShop-Websites sollten Seiten, Templates und Komponenten auf injizierte Skripte untersuchen. Die Analyse muss auch Anfragen an RPC-Endpunkte der BNB Smart Chain Testnet sowie einen Abgleich mit dem erwarteten Verhalten des Portals umfassen.

Da keine bekannten verwundbaren Versionen vorliegen, kann die Maßnahme nicht auf einen einzelnen Patch beschränkt werden. Die Aktualisierung von CMS und Komponenten bleibt sinnvoll, beweist jedoch nicht, dass eine bereits kompromittierte Website bereinigt wurde. Erforderlich sind eine direkte Überprüfung des Codes und eine Analyse der Netzwerkverbindungen.

Für Unternehmensverteidiger empfiehlt Netskope:

• die von den Forschern identifizierte Gruppe von RPC-Endpunkten der BNB Smart Chain Testnet zu blockieren;
• Nicht-Web-UDP-Datenverkehr im Zusammenhang mit WebRTC zu überwachen;
• ungewöhnliche RPC-Anfragen von WordPress- und PrestaShop-Websites zu suchen;
• über das Windows-Dialogfeld „Ausführen“ gestartete PowerShell-Prozesse zu erkennen;
• die dynamische Ausführung von JavaScript im Speicher des Browsers zu überwachen;
• Verbindungen zu in den Code eingebetteten C2-Adressen zu identifizieren.

Eine pauschale Sperrung erfordert eine Bewertung der legitimen Nutzung des Testnet, insbesondere in Entwicklungsumgebungen. Wo sie nicht umgesetzt werden kann, sollten RPC-Anfragen protokolliert und mit Ursprungsdomain, Browser, Prozess und nachfolgendem WebRTC-Datenverkehr korreliert werden.

Die aussagekräftigsten Indikatoren ergeben sich daher aus ihrer Kombination. Der Besuch einer Website, gefolgt von einem RPC-Aufruf an das Testnet und dem unerwarteten Aufbau eines WebRTC-Kanals, liefert ein belastbareres Signal als jedes dieser Ereignisse für sich genommen.

Nach dem Erstzugriff bleiben viele Aktivitäten unbemerkt

Die Operation zeigt zwei unterschiedliche Ebenen der Kompromittierung. Zum einen geht es um die Betreiber der Websites, deren Infrastruktur genutzt wird, um weitere Opfer zu erreichen. Zum anderen sind die Nutzer PowerShell-Befehlen oder über WebRTC bereitgestelltem JavaScript ausgesetzt.

Eine namentliche Zuordnung der Angreifer wurde nicht vorgenommen. Unbekannt bleiben außerdem die Methode, mit der die Websites kompromittiert wurden, und das endgültige Ziel aller Infektionsketten.

Der von Netskope separat erwähnte Blue Report 2026 hilft dabei, das Problem der Aktivitäten nach dem Erstzugriff einzuordnen. Auf Grundlage von 338 Millionen Simulationen in den Produktionsumgebungen der Kunden stellt der Bericht fest, dass nach der Verwendung gültiger Zugangsdaten nur 37 % der Aktionen der Angreifer blockiert werden.

Dieser Wert ordnet die ClickFix-Kampagne keinem bestimmten Angriffsvektor zu und belegt nicht, dass gestohlene Zugangsdaten verwendet wurden. Er verdeutlicht jedoch die Grenzen einer Verteidigung, die ausschließlich daran gemessen wird, ob sie den Erstzugriff verhindern kann.

Bei dieser Operation muss die Erkennung der gesamten Kette folgen: von der Kompromittierung der Website über die Abfrage der Blockchain und die Interaktion mit dem Opfer bis hin zu PowerShell oder WebRTC und schließlich zur Kommunikation mit dem C2. Wird nur einer dieser Schritte blockiert, kann der Angriff unterbrochen werden. Werden die Ereignisse jedoch nicht miteinander korreliert, bleiben den Betreibern mehrere alternative Wege.