Der eigentliche Bruch mit bisherigen ClickFix-Mustern liegt im Zwischenschritt zur Schadcode-Auslieferung. Üblicherweise haben Angreifer an dieser Stelle PowerShell oder mshta verwendet, um die nächste Stufe nachzuladen. Hier wird stattdessen „net use" eingesetzt, um ein Netzlaufwerk eines externen Servers einzubinden und von dort ein Batch-Skript auszuführen. Laut Atos sind diese Vorgehensweisen zwar nicht grundsätzlich neu, in ClickFix-Angriffen aber zuvor nie beobachtet worden. In der Praxis wird dabei eine entfernte WebDAV-Freigabe als lokales Laufwerk eingebunden, die gehostete Batch-Datei über normale Dateisystem-Mechanismen ausgeführt und die Zuordnung unmittelbar danach wieder entfernt.
Das initiale Skript „update.cmd" wird vom eingebundenen Laufwerk geladen und ausgeführt, anschließend wird das Laufwerk entfernt. Es startet eine PowerShell-Instanz, die ein ZIP-Archiv herunterlädt, es in das Verzeichnis „%LOCALAPPDATA%\MyApp" entpackt und die Datei „WorkFlowy.exe" ausführt.
Das Archiv enthält die WorkFlowy-Desktop-Anwendung in Version 1.4.1050, signiert vom Entwickler „FunRoutine Inc." und verteilt als Electron-Bundle. Electron-Anwendungen nutzen „.asar"-Archive, um ihren Quellcode zu verpacken. Der Schadcode wurde in die „main.js" eingeschleust, den Node.js-Einstiegspunkt der App, der im „app.asar"-Archiv liegt. Die Angreifer ersetzten dieses Archiv durch eine eigene Version und verpackten eine ältere App-Version (v1.4 statt der aktuellen v4.3) mit eingefügtem Code neu. Die legitime „main.js" wurde durch eine stark verschleierte Einzeiler-Struktur ersetzt, die zuerst ausgeführt wird und die eigentliche WorkFlowy-Funktion blockiert.
Der Schadcode läuft im Node.js-Hauptprozess – außerhalb der Chromium-Sandbox – mit den vollen Rechten des angemeldeten Nutzers. Es werden keine Dateien auf die Festplatte geschrieben, und da die Schadlast im „.asar"-Archiv steckt, bleibt der Code zusätzlich verborgen. Wird keine C2-Verbindung aufgebaut, entstehen keine Dateien oder Verzeichnisse; zum Zeitpunkt der Analyse antwortete die C2-Domain bereits nicht mehr.
Eine Persistenz auf Betriebssystemebene richtet der Dropper nicht ein – der Beacon läuft nur, solange WorkFlowy geöffnet ist. Das einzige vor der nächsten Stufe auf die Festplatte geschriebene Artefakt ist „%APPDATA%\id.txt" mit einer Opfer-Kennung, und das nur bei korrekt aufgebauter C2-Verbindung. Die Persistenz dürfte dem Payload überlassen sein, den das C2 über den Dropper ausliefert.
Atos betont, dass die Aktivität von den Sicherheitskontrollen nicht erkannt und allein durch gezieltes Threat Hunting identifiziert wurde. Die Erkennung stützte sich auf den Ausführungskontext statt auf Payload-Indikatoren – konkret auf die Suche nach verdächtigen Befehlen aus dem Ausführen-Dialog des Explorers, die im RunMRU-Registrierungsschlüssel festgehalten werden. Da ClickFix-Kampagnen zunehmend auf native Werkzeuge und vertrauenswürdige Anwendungen setzen, die kaum Alarme erzeugen, sei proaktives, hypothesengestütztes Hunting zur frühzeitigen Aufdeckung solcher schwachen Signale entscheidend.