ChainScript-RAT macht Polygon-Smart Contracts zu einem austauschbaren C2-Verzeichnis

ChainScript verbreitet sich über gefälschte Installer und nutzt Polygon-Smart-Contracts, um wechselnde C2-Server für Fernzugriff zu finden.

ChainScript-RAT macht Polygon-Smart Contracts zu einem austauschbaren C2-Verzeichnis
Malware

Illustration mit KI erzeugt

Gefälschte Software-Installer eröffnen die Windows-Angriffskette

Bedrohungsakteure nutzen Social Engineering nach dem ClickFix-Muster, um einen bislang nicht dokumentierten Windows-Remote-Access-Trojaner namens ChainScript zu installieren. Die Malware ermöglicht den Betreibern interaktiven Zugriff auf infizierte Systeme und nutzt zugleich die Polygon-Blockchain, um austauschbare Command-and-Control-Infrastrukturen zu finden.

Die Blackpoint Adversary Pursuit Group hat vier ChainScript-Buildnamen identifiziert:

  • ComponentTask33
  • UpdateDigital
  • HostShared
  • OrchidViolet66

Die Builds geben sich als Software aus, die mit Spotify, Zoom Workplace und Microsoft Teams in Verbindung steht. Ein beobachteter, auf Spotify zugeschnittener Installer trägt den Namen ComponentTask33-4d14e6ac.msi.

Die legitimen Anwendungen werden lediglich imitiert; im Zusammenhang mit dieser Kampagne wurde keine Schwachstelle in Spotify, Zoom Workplace, Microsoft Teams, Node.js oder Windows festgestellt. Entsprechend gibt es keinen betroffenen Versionsbereich, keine CVE-Kennung, keinen CVSS-Score und keinen Patch des Herstellers.

Stattdessen beruht der Eindringversuch darauf, das Opfer dazu zu bringen, ein MSI-Paket über msiexec.exe herunterzuladen und auszuführen. Das entspricht dem bekannten ClickFix-Modell: Eine Webseite präsentiert ein vorgetäuschtes Problem oder eine angebliche Installationsanforderung und weist den Nutzer an, eine Aktion auszuführen, durch die vom Angreifer bereitgestellter Code ausgeführt wird.

Die ChainScript-spezifischen Erkenntnisse, einschließlich der Installationskette und des Polygon-basierten Resolvers, gehen auf die technische Analyse der Blackpoint APG zurück.

Node.js, PowerShell und VBScript verbergen das Implantat

Nach der Ausführung installiert das schädliche MSI die Node.js-Laufzeitumgebung und legt mehrere Komponenten in Verzeichnissen ab, die unter %LOCALAPPDATA% wie Microsoft-Verzeichnisse wirken. Zu diesen Dateien gehören der ChainScript-JavaScript-Agent, Konfigurationsmaterial und zusätzliche Binärdateien.

Die Bereitstellungskette nutzt anschließend verborgene PowerShell- und VBScript-Stufen. VBScript fungiert als Hauptstarter für den JavaScript-Agenten, der in der installierten Node.js-Umgebung ausgeführt wird.

Dieser Ansatz bietet der Operation mehrere Möglichkeiten, sich in normale Systemaktivitäten einzufügen. MSI-Pakete sind in Unternehmen gängige Bereitstellungsmechanismen, PowerShell ist ein Standardwerkzeug für die Administration, und Node.js kann auf Entwicklerarbeitsplätzen bereits vorhanden sein. Das verdächtige Muster ergibt sich eher aus der Abfolge und dem Speicherort als aus einer einzelnen ausführbaren Datei.

Nach dem Start richtet ChainScript mithilfe einer geplanten Aufgabe eine Persistenz auf Benutzerebene ein. Zusätzlich legt es einen Registry-Run-Schlüssel als Fallback an, der beim Anmelden des Benutzers einen weiteren Ausführungspfad bietet.

Die verfügbaren Berichte nennen weder den Namen der geplanten Aufgabe noch den Namen des Registry-Werts, die installierten Dateinamen, Datei-Hashes oder die genauen %LOCALAPPDATA%-Pfade. Verteidiger können sich daher nicht auf eine vollständige Sammlung statischer Host-Indikatoren verlassen.

Eine nützliche Verhaltensabfolge für Untersuchungen ist:

  1. Ein kürzlich heruntergeladenes MSI wird über msiexec.exe gestartet.
  2. Der Installer schreibt eine Node.js-Laufzeitumgebung und JavaScript-Dateien unterhalb eines Benutzerprofils.
  3. PowerShell oder VBScript startet diese Dateien oder greift auf sie zu.
  4. Kurz darauf wird eine geplante Aufgabe auf Benutzerebene oder ein Run-Schlüssel angelegt.
  5. Node.js baut eine ausgehende WebSocket-Verbindung auf.

Diese Kette ist deutlich charakteristischer als jede einzelne Komponente.

Polygon dient als Verzeichnis für austauschbare C2-Server

Das charakteristische Merkmal von ChainScript ist sein C2-Ermittlungsprozess nach dem EtherHiding-Muster. Das Implantat verlässt sich nicht ausschließlich auf eine dauerhaft im Code eingebettete Serveradresse. Stattdessen fragt es einen Polygon-Smart Contract ab, um den Standort des aktiven WebSocket-Command-and-Control-Servers zu erfahren.

Der Verbindungsaufbau umfasst vier wesentliche Schritte:

  1. ChainScript kontaktiert den relevanten Polygon-Vertrag.
  2. Vom Vertrag gesteuerte Daten identifizieren die aktuelle WebSocket-Infrastruktur.
  3. Das Implantat verbindet sich mit diesem Server.
  4. Der Server stellt Befehle und weitere Aufgaben bereit.

Ein Betreiber kann die Auflösungsdaten ändern und infizierte Rechner auf eine Ersatzinfrastruktur umleiten. Bereits vorhandene Implantate können anschließend eine neue Verbindung herstellen, ohne dass ein neuer Malware-Build oder eine weitere Interaktion mit dem Opfer erforderlich ist.

Diese Trennung macht herkömmliche Blockierungsmaßnahmen weniger dauerhaft wirksam. Wird ein WebSocket-Host abgeschaltet oder der Zugriff darauf verhindert, kann dies die Aktivitäten vorübergehend stören. Bleibt die Kontrolle über den vertragsgestützten Auflösungsprozess jedoch erhalten, kann der Betreiber die Malware umleiten.

Zugleich sinkt der Nutzen, eine einzelne Netzwerkadresse aus einem Sample zu extrahieren. Bei der Erkennung müssen der Smart-Contract-Aufruf, die anschließende WebSocket-Sitzung und die für beide Aktivitäten verantwortlichen Prozesse berücksichtigt werden.

Es wurden weder eine Polygon-Vertragsadresse noch ein WebSocket-Hostname, eine IP-Adresse oder eine Kryptowährungs-Wallet-Adresse veröffentlicht. ChainScript steht außerdem weder mit einer offengelegten Schwachstelle noch mit einem Eintrag im CISA-Katalog Known Exploited Vulnerabilities in Verbindung.

Fernzugriff umfasst Screenshots, Payloads und Wallets

Nach der Verbindung mit seinem Server kann ChainScript interaktive Sitzungen mit Command Prompt und PowerShell öffnen. Dadurch erhält der Betreiber direkte Kontrolle über das System, anstatt die Malware auf eine vorab festgelegte Auswahl automatisierter Diebstahlfunktionen zu beschränken.

Zu den unterstützten Befehlen gehören:

  • Dateien lesen, schreiben und anderweitig manipulieren
  • Screenshots aufnehmen
  • Zusätzliche Payloads installieren
  • Vom Server bereitgestelltes JavaScript ausführen
  • Das Implantat aktualisieren
  • Seine Persistenzmechanismen entfernen
  • Kryptowährungs-Wallets in Desktop-Anwendungen aufzählen
  • Browser-Erweiterungen für Kryptowährungs-Wallets aufzählen

Diese Fähigkeiten können für die Opfer mehrere Folgen haben. Die Betreiber können lokale Daten untersuchen, Aktivitäten auf dem Bildschirm überwachen, weitere Malware einsetzen und native Shells nutzen, um über die integrierten Funktionen von ChainScript hinauszugehen.

Die Ermittlung von Wallets ist besonders bemerkenswert, weil sie hochwertige Ziele vor einem anschließenden Diebstahl identifizieren kann. Die Berichte belegen weder, dass von jedem infizierten Host Kryptowährungen gestohlen wurden, noch nennen sie eine Opferzahl oder die geografische Verteilung von ChainScript.

Die Fähigkeit von ChainScript, Persistenz zu entfernen, erschwert zudem die Untersuchung. Ein Betreiber könnte ausgewählte Artefakte beseitigen und andere Payloads zurücklassen. Das Auffinden und Löschen des ursprünglichen MSI wäre daher kein Beleg dafür, dass das System sicher ist.

ClickFix-Betreiber filtern auch macOS-Besucher

Die Aktivitäten unter Windows fügen sich in ein größeres Muster von ClickFix-Operationen ein, bei denen vom Benutzer ausgeführte Befehle mit einer Infrastruktur kombiniert werden, die automatisierte Analysen erschweren soll.

In einem separaten, am 5. August 2026 veröffentlichten Hinweis dokumentierte Microsoft eine macOS-ClickFix-Kampagne, die MacSync und Atomic Stealer (AMOS) auslieferte. Microsoft dokumentierte ChainScript oder seinen Polygon-Resolver nicht unabhängig, doch die Erkenntnisse zeigen, wie ClickFix-Bereitstellungsseiten schädliche Inhalte gezielt anzeigen können.

Microsoft identifizierte bei seinen Untersuchungen mehr als 250 Frontend-Domains. Einige verwendeten Namen im Wörterbuchstil mit dem Bestandteil file, andere ließen dieses Token weg. Beispiele waren filecopperbasket, applefilevault und cloudsendhub.

Die Infrastruktur entwickelte sich von schädlichen Anweisungen, die direkt im HTML der Seite platziert wurden, hin zur Bereitstellung eines kleinen JavaScript-Profilers. Dieser Code sammelte Eigenschaften aus navigator, screen, window, document, location und console und ergänzte sie um WebGL-Hardwaresignale sowie Prüfungen von Zeitzone, Iframe-Zustand und Touch-Unterstützung.

Besucher, die echten Mac-Nutzern ähnelten, konnten die schädliche Download-Aufforderung erhalten. Crawler, Sandboxes und nicht geeignete Systeme sahen möglicherweise stattdessen eine leere Seite oder einen themenfremden Köder.

Eine passende Seite unter apricotfilepoint[.]com zeigte ein gefälschtes „Verified Publisher“-Siegel und bot einen verschleierten curl-Befehl an. Eine andere Anfrage an dieselbe Domain lieferte eine gefälschte Urban-VPN-Proxy-Seite zurück.

Eine einzelne harmlose Antwort ist daher nur ein schwaches Indiz. Wer verdächtige Infrastrukturen nur mit einem Scanner oder einem einzigen Browserprofil testet, kann selektiv ausgelieferte ClickFix-Inhalte übersehen.

Verteidiger sollten Verhalten statt statischer Indikatoren priorisieren

Organisationen können mit dem bekannten Installernamen ComponentTask33-4d14e6ac.msi beginnen, sollten jedoch nicht davon ausgehen, dass jeder ChainScript-Build diesen Namen verwendet. Die weiteren gemeldeten Buildnamen – ComponentTask33, UpdateDigital, HostShared und OrchidViolet66 – bieten zusätzliche Ansatzpunkte für die Suche.

Endpoint-Teams sollten Aktivitäten von msiexec.exe, PowerShell, VBScript und Node.js miteinander korrelieren, insbesondere wenn die betreffenden Dateien unter %LOCALAPPDATA% liegen. Besondere Aufmerksamkeit verdienen Node.js-Prozesse, die aus neu erstellten Verzeichnissen in Benutzerprofilen gestartet werden, wenn sie WebSocket-Verbindungen öffnen oder unbekanntes JavaScript ausführen.

Weitere Prioritäten sind:

  • Kürzlich erstellte geplante Aufgaben auf Benutzerebene und Registry-Run-Schlüssel überprüfen
  • Ungewöhnlichen ausgehenden WebSocket-Datenverkehr untersuchen
  • Zugriffe auf Polygon-Smart Contracts mit Node.js- oder Skriptaktivitäten korrelieren
  • Zugriffe auf Profile von Browser-Erweiterungen und Daten von Desktop-Wallets überwachen
  • Nach Screenshot-Aufnahmen und der Ausführung vom Server bereitgestellten JavaScripts suchen
  • PowerShell-, Prozessstart-, Aufgabenplaner- und Registry-Telemetrie aufbewahren

Nutzer sollten angewiesen werden, keine Befehle in PowerShell, Command Prompt oder das macOS-Terminal einzufügen, nur weil eine Webseite behauptet, dies sei für eine Verifizierung, Installation oder Fehlerbehebung erforderlich.

Es gibt kein spezielles Entfernungstool für ChainScript. Ein verdächtiger Endpoint sollte isoliert und auf die vollständige Ausführungskette, Persistenzeinträge und sekundäre Payloads untersucht werden – nicht nur auf das ursprüngliche MSI. Eine statische C2-Blockierung allein dürfte nicht ausreichen, da der Polygon-basierte Resolver des Implantats darauf ausgelegt ist, einzelne Backend-Server zu überdauern.

Auch interessant

Quellen

Dieser Artikel ist eine eigenständige Aufbereitung auf Basis der folgenden Quellen.

Verwandte ThemenChainScript-RATPolygon-Smart-ContractsClickFixWindows-MalwareC2-InfrastrukturNode.jsPowerShell
Zurück zur Startseite