Einer großen cyberkriminellen Operation nutzen laut Sicherheitsforschern tausende kompromittierte Kleinunternehmens-Websites, um schadhafte ClickFix-Payloads zu verbreiten, die in Smart Contracts auf der BNB Smart Chain (BSC) versteckt sind.

In den vergangenen Monaten identifizierten die Forscher mehr als 5,400 kompromittierte Websites, die in die Kampagne eingebunden sind. Die meisten betroffenen Sites basieren auf WordPress und PrestaShop, zwei weit verbreiteten Plattformen für Kleinunternehmens-Websites; WordPress allein betreibt einen erheblichen Teil des Webs, und beide Plattformen wurden historisch häufig von Angreifern ins Visier genommen, die veraltete Plugins, schwache Zugangsdaten und ungepatchte Installationen ausnutzen. Wie die Angreifer zunächst Zugriff auf diese Websites erlangten, ist unklar.

Sobald eine Website kompromittiert ist, schleusen die Angreifer ein Skript ein, das zusätzliche schadhafte Inhalte über einen RPC-Endpunkt des BSC-Testnets aus einem Smart Contract abruft. Diese Technik ist als EtherHiding bekannt, bei der Bedrohungsakteure Blockchain-Infrastruktur nutzen, um bösartigen Code oder Konfigurationsdaten zu verbergen. EtherHiding wurde erstmals 2024 von Forschern öffentlich dokumentiert; sein erneuter Einsatz gegen die BSC-Infrastruktur zeigt, wie sich der Ansatz über verschiedene Chains hinweg gehalten und angepasst hat.

Angreifer nutzen Blockchain-Infrastruktur aus

Das BSC-Testnet ist primär für Entwickler gedacht, die Anwendungen vor dem Einsatz auf der Produktions-Blockchain testen. Da es ähnlich wie das Mainnet funktioniert, aber ohne die Kosten Produktions-Transaktionen, bietet es Angreifern eine bequeme Infrastruktur zur Verbreitung schadhafter Inhalte. Weil Blockchain-Daten über viele Knoten repliziert und kaum einseitig löschbar sind, sind Abschaltungen, die bei herkömmlichen Hosting-Anbietern funktionieren, bei in Contracts gespeicherten Payloads deutlich schwieriger umzusetzen.

Durch das Speichern der schadhaften Payloads in Smart Contracts erhalten die Angreifer eine schwer zu störende Infrastruktur-Schicht, da die Inhalte über dezentrale Blockchain-Systeme abrufbar sind, statt ausschließlich auf herkömmlichem Webhosting zu beruhen.

Die Kampagne nutzte die kompromittierten Websites zunächst, um eine ClickFix-Social-Engineering-Köder anzuzeigen. Besuchern wurde eine Seite präsentiert, die wie eine CAPTCHA-Verifizierung aussah. Statt einen üblichen Verifizierungsprozess abzuschließen, wurden Nutzer angewiesen, den Windows-Dialog „Ausführen“ zu öffnen und einen PowerShell-Befehl einzufügen. Befolgten Besucher diese Anweisungen, lud der Befehl die finale schadhafte Payload herunter und führte sie auf dem Computer aus. ClickFix-Köder – gefälschte Verifizierungs- oder Update-Aufforderungen, die Nutzer dazu verleiten, Befehle selbst einzufügen – haben sich im vergangenen Jahr zu einer vielfach berichteten Social-Engineering-Technik entwickelt, unter anderem weil das Opfer die Aktion selbst ausführt und dabei viele browserschutz-basierte Schutzmaßnahmen umgeht.

Da die Angreifer die im Smart Contract gespeicherten Inhalte kontrollierten, konnten sie die Payload aktualisieren, ohne jede kompromittierte Website zu ändern. Später beobachteten die Forscher eine deutliche Änderung des Auslieferungsmechanismus: Der Bedrohungsakteur ersetzte die im Smart Contract gespeicherte ClickFix-Payload durch einen WebRTC-basierten Stager, der eine neue Methode zur Kommunikation mit dem Angreifer etablierte.

WebRTC für verdeckte Code-Auslieferung

Die neuere Variante erstellt eine Peer-Verbindung und einen WebRTC-Datenkanal. Die Forscher stellten fest, dass das Skript ein Session-Description-Offer erzeugt, das einem legitimen WebRTC-Verbindungsvorgang ähnelt, dann aber die entsprechende Antwort selbst konstruiert, statt mit einem echten entfernten Peer zu kommunizieren. Diese Technik ermöglicht es dem bösartigen Skript, einen Datenkanal ohne vollständigen herkömmlichen WebRTC-Handshake aufzubauen; der resultierende Kanal dient als verdeckter Kommunikationspfad zum Angreifer. WebRTC ist eine Browser-Standardtechnologie, die normalerweise für Videoanrufe und Peer-to-Peer-Dateiübertragung verwendet wird, wodurch sich der bösartige Traffic in legitime Webaktivität einfügt.

Der Stager enthält eine fest eincodierte Command-and-Control-Adresse, von der er JavaScript-Code erhält. Der eingehende Code wird im Speicher gepuffert und ausgeführt, nachdem der Kommunikationskanal geschlossen wurde oder nach einem Intervall von 10 Sekunden. Das empfangene JavaScript wird direkt im Browser-Speicher zusammengesetzt und über das Document Object Model dynamisch ausgeführt, sodass der Code läuft, ohne je auf die Festplatte geschrieben zu werden.

Dieser Ansatz kann herkömmliche Endpoint-Erkennung erschweren, da der bösartige Code nicht zwangsläufig als konventionelle Datei auf dem System des Opfers erscheint. Er gibt den Angreifern zudem Flexibilität, den an Besucher ausgelieferten Code zu ändern.

Mehr als 300 Websites täglich aktiv

Die Telemetrie von Netskope zeigt, dass die Kampagne weiterhin in erheblichem Umfang aktiv ist. Laut den Forschern sind täglich mehr als 300 infizierte Websites in die Operation eingebunden, während die Zahl der kompromittierten Sites, die mit BSC-Testnet-RPC-Endpunkten kommunizieren, seit dem Frühjahr weiter gestiegen ist. Im August zeigte die Telemetrie nahezu 400 Websites täglich, die die betreffenden Endpunkte kontaktierten, und die Kampagne erreichte einen Allzeit-Höchststand von 536 Websites pro Tag.

Die Erkenntnisse verdeutlichen, wie Blockchain-Infrastruktur als Teil eines Malware-Verteilnetzwerks zweckentfremdet werden kann. Statt sich allein auf herkömmliche Command-and-Control-Server oder Content-Hosting-Dienste zu verlassen, kombinieren die Angreifer kompromittierte Websites, Smart Contracts und browserbasierte Kommunikationsmechanismen. Für Betreiber von Kleinunternehmens-Websites unterstreicht die Kampagne zudem das operationelle Risiko nicht gepflegter CMS-Installationen, da kompromittierte Websites ihren eigenen Besuchern unbemerkt schadhafte Inhalte ausliefern können.

Netskope empfiehlt Verteidigern, den Pool der mit der Kampagne verbundenen BSC-Testnet-RPC-Endpunkte zu blockieren. Sicherheitsteams sollten außerdem den Netzwerkverkehr auf nicht-webbasierten UDP-Traffic im Zusammenhang mit WebRTC überwachen, was helfen könnte, Systeme zu identifizieren, die am neueren Auslieferungsmechanismus beteiligt sind.

Quelle: CoinTrust