ClickFix-Variante nutzt WebDAV und trojanisierte Electron-App zur Malware-Verteilung

Sicherheitsforscher von Atos haben eine neue Variante der ClickFix-Angriffstechnik analysiert, die auf ungewöhnliche Ausführungsmethoden setzt und dabei gängige Erkennungsmechanismen wie Microsoft Defender for Endpoint erfolgreich umgeht. Statt auf PowerShell oder MSHTA setzt die Kampagne auf den Windows-Befehl „net use“ sowie eine manipulierte Version der WorkFlowy-Desktop-Anwendung. Entdeckt wurde die Aktivität ausschließlich durch gezieltes Threat Hunting – automatisierte Sicherheitskontrollen schlugen zu keinem Zeitpunkt Alarm.

Angriffsablauf: Bekannter Einstieg, neue Methoden

Der Einstiegspunkt folgt dem inzwischen bekannten ClickFix-Schema: Eine Webseite tarnt sich als CAPTCHA-Mechanismus – im analysierten Fall „happyglamper[.]ro“ – und fordert den Nutzer auf, mit der Tastenkombination Win+R den Ausführen-Dialog zu öffnen. Anschließend soll der Nutzer mit Strg+V einen vorbereiteten Befehl einfügen und diesen mit Enter bestätigen. Der soziale Manipulationsansatz ist dabei bewusst einfach gehalten: Die Seite erweckt den Eindruck einer harmlosen Sicherheitsüberprüfung, während im Hintergrund bereits ein schadhafter Befehl in der Zwischenablage des Nutzers wartet.

Was nach diesem ersten Schritt folgt, weicht jedoch deutlich von bisherigen ClickFix-Kampagnen ab:

• Statt PowerShell oder MSHTA wird ein „net use“-Befehl ausgeführt, der eine vom Angreifer kontrollierte WebDAV-Freigabe als lokales Netzlaufwerk einbindet
• Von diesem eingebundenen Laufwerk wird unmittelbar ein Batch-Skript namens „update.cmd“ geladen und gestartet
• Das Skript startet eine PowerShell-Instanz, die ein ZIP-Archiv von einem externen Server herunterlädt und dessen Inhalt in das Verzeichnis %LOCALAPPDATA%\MyApp\ entpackt
• Im Anschluss wird die enthaltene Binärdatei WorkFlowy.exe gestartet
• Unmittelbar nach der Ausführung wird die Netzlaufwerk-Zuordnung automatisch wieder getrennt, was forensische Spuren auf ein Minimum reduziert

Die Nutzung von „net use“ in Kombination mit WebDAV zur Auslieferung von Schadcode über eine ClickFix-Kampagne war nach Angaben der Forscher bislang nicht dokumentiert. Zwar ist die Technik an sich nicht neu – neu ist jedoch ihre gezielte Einbindung in diesen Angriffskontext, kombiniert mit den nachfolgenden ungewöhnlichen Infektionsstufen.

Grafik Quelle: Atos

Trojanisierte WorkFlowy-App als zentrales Werkzeug

Das heruntergeladene Archiv enthält eine ältere Version der legitimen WorkFlowy-Desktop-Anwendung in Version 1.4.1050, signiert vom Entwickler „FunRoutine Inc.“ und als Electron-Bundle verteilt. Die aktuelle WorkFlowy-Version liegt zum Zeitpunkt der Analyse bereits bei 4.3 – die Angreifer griffen bewusst auf eine ältere Ausgabe zurück, in die sie ihren Code einbetten konnten.

Electron-Anwendungen basieren auf Webtechnologien wie HTML, CSS und JavaScript und nutzen .asar-Archive, um Quellcode beim Verpacken zu komprimieren. Genau hier setzt der Angriff an: Das legitime resources/app.asar-Archiv wurde durch eine manipulierte Version ersetzt, in der die Datei main.js – der Node.js-Einstiegspunkt der Anwendung – gegen eine schadhaft modifizierte Variante ausgetauscht wurde.

Technische Merkmale dieser Implementierung:

• Der Schadcode ist als stark verschleierter Einzeiler umgesetzt, der unmittelbar vor jeder legitimen Anwendungslogik ausgeführt wird
• Er läuft im Node.js-Hauptprozess außerhalb der Chromium-Sandbox und verfügt damit über die vollen Systemrechte des angemeldeten Nutzers
• Die normale WorkFlowy-Funktionalität wird von Beginn an dauerhaft blockiert: Die C2-Beacon-Schleife startet mit einem await f()-Aufruf, der niemals aufgelöst wird, sodass der nachfolgende legitime Initialisierungscode der Anwendung nie zur Ausführung kommt
• Da der Code innerhalb einer signierten, legitimen Anwendung läuft, löst er viele dateibasierte und verhaltensbasierte Erkennungsregeln nicht aus

Funktionen des eingebetteten Schadcodes im Detail

Der in main.js eingeschleuste Code übernimmt mehrere klar voneinander trennbare Aufgaben, die zusammen ein vollständiges Angriffswerkzeug ergeben:

1. Persistentes Opfer-Fingerprinting Beim ersten Start der manipulierten Anwendung generiert die Malware eine zufällige, achtstellige alphanumerische ID und schreibt diese in die Datei %APPDATA%\id.txt. Bei allen nachfolgenden Starts wird die gespeicherte ID eingelesen. Auf diese Weise erhält der Angreifer über alle Sitzungen hinweg eine stabile, eindeutige Kennung für jeden kompromittierten Rechner – ohne auf aufwendige System-Fingerprinting-Methoden zurückgreifen zu müssen.

2. Kontinuierlicher C2-Beacon Die Funktion u() sendet in einem festen Intervall von zwei Sekunden einen HTTP-POST-Request an den C2-Server. Dieser Request enthält die generierte Opfer-ID, den Rechnernamen sowie den Windows-Benutzernamen des angemeldeten Kontos. Die übergeordnete Schleife in f() wiederholt diesen Vorgang unbegrenzt und stellt so sicher, dass der Angreifer jederzeit über aktive Infektionen informiert ist.

3. Herunterladen und Ausführen von Folge-Payloads Über die Funktion p() ist die Malware in der Lage, Aufgaben vom C2-Server entgegenzunehmen. Ein empfangenes Task-Objekt enthält Base64-kodierten Dateiinhalt, den die Malware dekodiert, in ein mit einem Zeitstempel versehenes Unterverzeichnis unter %TEMP% schreibt und anschließend über child_process.exec ausführt. Auf diesem Weg können beliebige .exe-Dateien auf dem kompromittierten System gestartet werden.

Zum Zeitpunkt der Analyse war die C2-Domain bereits nicht mehr erreichbar, sodass keine finale Nutzlast beobachtet werden konnte und keine zusätzlichen Dateien oder Verzeichnisse auf dem System angelegt wurden.

Persistenz und Artefakte

Der Dropper selbst implementiert keine Persistenz auf Betriebssystemebene. Der Beacon ist ausschließlich aktiv, solange die WorkFlowy-Anwendung geöffnet ist. Das einzige Artefakt, das vor der Auslieferung einer möglichen Folge-Payload auf die Festplatte geschrieben wird, ist die Datei %APPDATA%\id.txt – und auch dies nur, wenn eine erfolgreiche Verbindung zum C2-Server hergestellt werden konnte.

Die Forscher gehen davon aus, dass die Persistenz auf Betriebssystemebene an die nachgeladene Payload delegiert wird, die der C2-Server über den Dropper ausliefern würde.

Warum automatisierte Erkennung versagte

Die Angriffskette umging automatisierte Sicherheitskontrollen aus mehreren, sich gegenseitig verstärkenden Gründen:

• Native Windows-Werkzeuge: „net use“ und WebDAV gehören zum regulären Funktionsumfang von Windows und erzeugen deutlich weniger auffällige Telemetriedaten als PowerShell, WScript oder MSHTA, die von modernen EDR-Lösungen engmaschig überwacht werden
• Keine eigenständigen Loader oder Skriptinterpreter: Da die Schadlogik innerhalb einer legitim signierten Electron-Anwendung läuft, greifen viele verhaltensbasierte Erkennungsregeln nicht, die auf bekannte Ausführungsmuster eigenständiger Malware-Loader ausgerichtet sind
• ASAR-Archive als blinder Fleck: .asar-Dateien werden von den meisten Sicherheitslösungen nicht aktiv auf eingebetteten Schadcode untersucht, sodass die manipulierte main.js beim regulären Anwendungsstart mit minimaler Sichtbarkeit ausgeführt wird
• Kurzlebige Netzwerkverbindung: Das Netzlaufwerk wird unmittelbar nach der Nutzung wieder getrennt, was die Zeitspanne für eine netzwerkbasierte Erkennung auf ein Minimum reduziert

Aufgedeckt wurde die Kampagne schließlich durch internes Threat Hunting bei Atos, das verdächtige Ausführungsketten analysierte, die vom RunMRU-Registrierungsschlüssel ausgingen. Dieser Schlüssel hält die zuletzt im Windows-Ausführen-Dialog eingegebenen Befehle fest und gilt als charakteristisches Artefakt von ClickFix-Aktivitäten. Durch die gezielte Suche nach ungewöhnlichen Befehlsausführungen aus diesem Kontext heraus konnten die Analysten die Infektionskette rekonstruieren.