Co znajdziesz w tym artykule?
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 ręcznie.
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ą, lecz 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.asarutrudnia tradycyjną analizę.
Kontekst / historia
Kampanie ClickFix w ostatnich miesiącach opierały się głównie na podobnym schemacie: ofiara była przekonywana do ręcznego 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, że 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. Kluczowe znaczenie ma fakt, że nie jest to osobne binarium pełniące rolę loadera, ale starsza wersja legalnej aplikacji WorkFlowy, podpisana przez producenta, lecz 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śli 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. Nawet jeśli 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\RunMRUoraz polecenia uruchamiane z okna „Uruchamianie”. - Wykrywać użycie
net usedo mapowania zdalnych zasobów, zwłaszcza jeśli mapowanie jest krótkotrwałe i prowadzi do zasobów zewnętrznych. - Ograniczać lub kontrolować ruch WebDAV, jeśli 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 oprogramowania z katalogów użytkownika.
- Szkolić pracowników, że legalne testy CAPTCHA i procesy wsparcia IT nie wymagają ręcznego 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, że 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
- Investigating a New Click-Fix Variant — https://thehackernews.com/2026/03/investigating-new-click-fix-variant.html
- Electron Documentation — ASAR Archives — https://www.electronjs.org/docs/latest/tutorial/asar-archives
- MITRE ATT&CK: User Execution — https://attack.mitre.org/techniques/T1204/
- MITRE ATT&CK: Command and Scripting Interpreter — https://attack.mitre.org/techniques/T1059/
- MITRE ATT&CK: Ingress Tool Transfer — https://attack.mitre.org/techniques/T1105/