Nowy wariant ClickFix wykorzystuje WebDAV i trojanizowaną aplikację Electron do obejścia detekcji

Wprowadzenie do problemu / definicja

ClickFix to technika socjotechniczna, w której ofiara zostaje nakłoniona do samodzielnego uruchomienia złośliwego polecenia, najczęściej za pośrednictwem okna „Uruchamianie” w systemie Windows. Najnowszy wariant tej metody pokazuje wyraźną zmianę taktyki: zamiast opierać się głównie na bezpośrednim użyciu PowerShella czy MSHTA, napastnicy wykorzystują mapowanie zasobu WebDAV, skrypt wsadowy oraz trojanizowaną aplikację Electron, aby utrudnić wykrycie.

Takie podejście zmniejsza liczbę klasycznych sygnałów ostrzegawczych widocznych dla narzędzi EDR i AV. W praktyce oznacza to większą rolę analizy behawioralnej, monitoringu działań użytkownika oraz dokładniejszego nadzoru nad nietypowym użyciem legalnych komponentów systemowych i aplikacyjnych.

W skrócie

Nowa kampania ClickFix zaczyna się od fałszywej strony podszywającej się pod mechanizm CAPTCHA. Użytkownik otrzymuje instrukcję, aby użyć skrótu Win+R, wkleić przygotowane polecenie i uruchomić je manualnie.

Polecenie mapuje zdalny zasób WebDAV jako dysk sieciowy, uruchamia z niego plik CMD, a następnie usuwa mapowanie. Skrypt pobiera archiwum ZIP, rozpakowuje je do katalogu użytkownika i uruchamia legalnie podpisaną, ale zmodyfikowaną aplikację WorkFlowy, w której złośliwy kod ukryto w archiwum ASAR aplikacji Electron.

• Atak bazuje na świadomej interakcji użytkownika.
• Do infekcji używane są natywne funkcje Windows i legalna aplikacja desktopowa.
• Złośliwy komponent działa jako beacon C2 i dropper kolejnych ładunków.
• Ukrycie logiki w pliku app.asar utrudnia tradycyjną analizę.

Kontekst / historia

Kampanie ClickFix w ostatnich miesiącach opierały się głównie na podobnym schemacie: ofiara była przekonywana do manualnego uruchomienia polecenia inicjującego kolejne etapy infekcji. We wcześniejszych wariantach często wykorzystywano interpretery skryptów i popularne LOLBins, takie jak PowerShell, WScript, CScript czy MSHTA.

Nowy wariant odchodzi jednak od najbardziej oczywistych i intensywnie monitorowanych mechanizmów. Zamiast bezpośrednio pobierać i wykonywać malware przy użyciu klasycznych narzędzi skryptowych, operatorzy najpierw montują zdalny zasób jako lokalny dysk, uruchamiają z niego skrypt wsadowy, a następnie używają legalnej aplikacji Electron jako nośnika złośliwej logiki. To pokazuje, iż twórcy kampanii aktywnie dostosowują techniki do współczesnych możliwości detekcyjnych po stronie obrońców.

Analiza techniczna

Łańcuch ataku rozpoczyna się od strony phishingowej imitującej test CAPTCHA. Użytkownik jest instruowany, aby otworzyć okno „Uruchamianie” i wkleić gotowe polecenie. W analizowanym scenariuszu komenda wykorzystuje cmd.exe oraz net use do przypisania zdalnego zasobu WebDAV do litery dysku, uruchomienia pliku update.cmd i usunięcia mapowania po wykonaniu zadania.

Następnie plik update.cmd uruchamia ukrytą instancję PowerShell, która pobiera archiwum ZIP, rozpakowuje je do profilu użytkownika i uruchamia plik WorkFlowy.exe. najważniejsze znaczenie ma fakt, iż nie jest to osobne binarium pełniące rolę loadera, ale starsza wersja legalnej aplikacji WorkFlowy, podpisana przez producenta, ale przepakowana z podmienionym archiwum app.asar.

W aplikacjach Electron plik ASAR służy do przechowywania kodu HTML, JavaScript oraz logiki wykonywanej przez Node.js. W tym przypadku napastnicy zastąpili oryginalny plik main.js własnym, silnie zaciemnionym kodem. Złośliwa logika uruchamia się jeszcze przed prawidłową inicjalizacją programu, blokuje normalne działanie aplikacji i rozpoczyna komunikację z serwerem C2.

Podczas pierwszego uruchomienia tworzony jest unikalny identyfikator ofiary, zapisywany w pliku %APPDATA%\id.txt. Następnie malware wysyła okresowe żądania HTTP POST zawierające identyfikator, nazwę komputera i nazwę użytkownika. Mechanizm C2 pozwala również na odbieranie poleceń i pobieranie kolejnych ładunków, które są dekodowane z Base64, zapisywane do katalogu tymczasowego i uruchamiane, jeżeli stanowią pliki wykonywalne.

Z perspektywy obrony szczególnie istotne są dwa elementy. Po pierwsze, złośliwy kod znajduje się wewnątrz archiwum ASAR, które nie zawsze podlega szczegółowej inspekcji. Po drugie, wczesny etap infekcji opiera się na działaniach użytkownika oraz legalnych narzędziach systemowych, co ogranicza liczbę jednoznacznych wskaźników kompromitacji.

Konsekwencje / ryzyko

Największe ryzyko tego wariantu wynika z połączenia socjotechniki, legalnych komponentów oraz nietypowego łańcucha wykonania. Użytkownik sam uruchamia polecenie, co utrudnia szybkie odróżnienie incydentu od zwykłej aktywności administracyjnej lub błędnie zinterpretowanej operacji użytkownika.

Mapowanie WebDAV jako dysku sieciowego i uruchomienie skryptu z lokalnie widocznej ścieżki może wyglądać mniej podejrzanie niż klasyczne pobranie pliku przez PowerShell czy użycie MSHTA. Dodatkowo wykorzystanie legalnie podpisanej aplikacji obniża poziom podejrzeń po stronie użytkowników i części narzędzi ochronnych.

Po uzyskaniu komunikacji z serwerem C2 operator może dostarczyć dowolny kolejny ładunek. Otwiera to drogę do wdrożenia stealerów, backdoorów, ransomware lub narzędzi do dalszej penetracji środowiska. choćby jeżeli pierwszy etap nie implementuje trwałości systemowej, kolejne komponenty mogą ją dodać bez większych przeszkód.

Rekomendacje

Organizacje powinny rozszerzyć strategie detekcji poza klasyczne reguły skupione wyłącznie na PowerShellu, MSHTA i typowych LOLBins. W praktyce konieczne jest monitorowanie kontekstu uruchomienia poleceń, nietypowych działań w oknie Win+R oraz operacji wykonywanych przez explorer.exe.

• Monitorować wpisy w kluczu Explorer\RunMRU oraz polecenia uruchamiane z okna „Uruchamianie”.
• Wykrywać użycie net use do mapowania zdalnych zasobów, zwłaszcza jeżeli mapowanie jest krótkotrwałe i prowadzi do zasobów zewnętrznych.
• Ograniczać lub kontrolować ruch WebDAV, jeżeli nie jest wymagany biznesowo.
• Rozszerzyć telemetrię o tworzenie i wykonywanie plików w %TEMP%, %LOCALAPPDATA% i %APPDATA%.
• Monitorować uruchamianie aplikacji Electron z niestandardowych lokalizacji oraz analizować zawartość app.asar.
• Wdrożyć allowlisting aplikacji i ograniczyć możliwość uruchamiania nieautoryzowanego systemu z katalogów użytkownika.
• Szkolić pracowników, iż legalne testy CAPTCHA i procesy wsparcia IT nie wymagają manualnego wklejania poleceń do Win+R.

Zespoły SOC i threat hunting powinny również przeszukiwać środowisko pod kątem artefaktów takich jak id.txt w katalogu %APPDATA%, obecność rozpakowanych archiwów ZIP w profilach użytkowników, uruchamianie starszych wersji WorkFlowy z nietypowych ścieżek oraz ślady krótkotrwałych mapowań dysków do zasobów zewnętrznych.

Podsumowanie

Nowy wariant ClickFix pokazuje, iż operatorzy kampanii stale rozwijają techniki unikania detekcji. Przeniesienie ciężaru infekcji z bezpośrednich wywołań dobrze monitorowanych interpreterów do łańcucha opartego na WebDAV, skryptach wsadowych i trojanizowanej aplikacji Electron znacząco utrudnia wykrycie ataku na wczesnym etapie.

Dla obrońców najważniejszy wniosek jest jednoznaczny: skuteczna ochrona musi obejmować nie tylko znane narzędzia wykonawcze, ale również zachowanie użytkownika, nietypowe użycie natywnych funkcji Windows oraz anomalie w legalnych aplikacjach desktopowych. W tym modelu analityka behawioralna i aktywny threat hunting stają się kluczowe.

Źródła

1. Investigating a New Click-Fix Variant — https://thehackernews.com/2026/03/investigating-new-click-fix-variant.html
2. Electron Documentation — ASAR Archives — https://www.electronjs.org/docs/latest/tutorial/asar-archives
3. MITRE ATT&CK: User Execution — https://attack.mitre.org/techniques/T1204/
4. MITRE ATT&CK: Command and Scripting Interpreter — https://attack.mitre.org/techniques/T1059/
5. MITRE ATT&CK: Ingress Tool Transfer — https://attack.mitre.org/techniques/T1105/