Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
ClickFix to technika socjotechniczna, w której użytkownik zostaje nakłoniony do samodzielnego uruchomienia złośliwego polecenia. Najczęściej odbywa się to przez fałszywe komunikaty o błędzie, imitacje testów CAPTCHA lub okna weryfikacyjne, które instruują ofiarę, aby skopiowała komendę, wkleiła ją do narzędzia systemowego i zatwierdziła jej wykonanie.
Najnowsze analizy pokazują jednak, że ClickFix przestał być prostą metodą opartą na statycznych skryptach. Coraz częściej działa dziś jako dojrzały model usługowy, w którym backendy API generują payloady na żądanie, dynamicznie je modyfikują i dopasowują do kontekstu ofiary.
W skrócie
Badanie około 3 tysięcy aktywnych ładunków powiązanych z kampaniami ClickFix pokazuje wyraźną zmianę sposobu działania operatorów. Zamiast dostarczać jedną, niezmienną komendę, atakujący korzystają z zaplecza serwerowego, które przygotowuje złośliwy kod w czasie rzeczywistym.
- payloady są generowane dynamicznie przez backend API,
- kolejne żądania mogą zwracać różne warianty tego samego ładunku,
- stosowane są wielowarstwowe techniki zaciemniania,
- pojawił się wariant, w którym właściwy plik trafia wcześniej do katalogu Downloads,
- krótka komenda w schowku pełni jedynie rolę orkiestratora drugiego etapu infekcji.
Kontekst / historia
Popularność ClickFix wynika z prostoty i skuteczności. Technika ta nie wymaga klasycznego exploita przeglądarkowego ani dostarczenia typowego załącznika malware. Z perspektywy atakującego kluczowa zaleta jest oczywista: użytkownik sam wykonuje polecenie, przez co część tradycyjnych zabezpieczeń nie reaguje wystarczająco wcześnie.
We wcześniejszych kampaniach dominował scenariusz polegający na wyświetleniu instrukcji użycia skrótu Windows+R i wklejenia komendy do okna Uruchom. Z czasem operatorzy zaczęli częściej wykorzystywać Windows Terminal oraz inne natywne narzędzia systemowe, co lepiej wpisuje się w normalne wzorce aktywności użytkownika i utrudnia analizę incydentów.
Równolegle ClickFix przestał być domeną wyłącznie prostych kampanii przestępczych. Technika była adaptowana także przez bardziej zaawansowanych aktorów, co potwierdza jej rosnącą wartość jako wektora initial access.
Analiza techniczna
Najważniejszą zmianą jest przejście do modelu payload-on-demand. Złośliwa strona internetowa nie musi już zawierać jednego osadzonego skryptu czy stałej komendy. Zamiast tego komunikuje się z serwerem zaplecza, który po walidacji parametrów lub tokenu zwraca świeżo wygenerowany wariant ładunku.
W praktyce oznacza to, że dwa wejścia na tę samą stronę mogą zakończyć się otrzymaniem różnych reprezentacji tego samego malware. Taki model znacząco obniża skuteczność detekcji opartej na pojedynczych sygnaturach tekstowych, treści schowka lub prostych wskaźnikach kompromitacji.
Z obserwacji wynika, że operatorzy stosują rotacyjne warstwy zaciemniania, wykorzystując między innymi Base64, AES, TripleDES, Rijndael oraz Deflate. Zmienna forma opakowania utrudnia analizę statyczną, mimo że końcowy efekt może prowadzić do uruchomienia tego samego komponentu, na przykład z użyciem PowerShell runspace lub podobnych mechanizmów wykonania w pamięci.
Istotny jest także poziom automatyzacji po stronie kampanii. Serwery mogą dostosowywać payload do systemu operacyjnego, języka interfejsu oraz innych cech klienta. To wskazuje na rosnącą dojrzałość operacyjną i możliwość skalowania ataków bez konieczności ręcznego przygotowywania każdej infekcji.
Drugim ważnym trendem jest wariant oparty na katalogu Downloads. W tym scenariuszu pełny złośliwy skrypt nie trafia bezpośrednio do schowka. Najpierw przeglądarka pobiera archiwum lub plik pomocniczy do katalogu pobrań, a dopiero później do schowka kopiowana jest krótka komenda odpowiedzialna za przeniesienie pliku, jego rozpakowanie i uruchomienie właściwego skryptu.
Taki model utrudnia monitoring, ponieważ sama komenda wygląda mniej podejrzanie niż pełny payload. Dodatkowo część narzędzi analitycznych koncentrujących się wyłącznie na schowku lub tekście wklejanego polecenia może nie zobaczyć pełnego łańcucha wykonania.
Z perspektywy obrony kluczowe staje się więc monitorowanie korelacji zdarzeń. Szczególnie podejrzane są sekwencje, w których explorer.exe lub WindowsTerminal.exe uruchamiają powershell.exe, cmd.exe albo msiexec.exe, po czym następują szybkie operacje na plikach w katalogach Downloads i TEMP oraz komunikacja sieciowa do zewnętrznych hostów.
Konsekwencje / ryzyko
Ewolucja ClickFix do modelu usługowego zwiększa odporność kampanii na klasyczne blokady oparte na IOC. Jeżeli każda ofiara może otrzymać inaczej zakodowaną komendę lub zmienny wrapper kryptograficzny, wartość operacyjna statycznych sygnatur szybko spada.
Dodatkowe ryzyko wynika z możliwości komercjalizacji takiego modelu. Jeżeli backend generujący payloady działa jak gotowa usługa, mniej zaawansowani operatorzy nie muszą budować całego łańcucha infekcji samodzielnie. To może przełożyć się na większą skalę kampanii i częstsze incydenty wykorzystujące manipulację użytkownikiem zamiast luki technicznej.
Wariant z katalogiem Downloads komplikuje także działania forensic i incident response. Ślady są rozproszone między przeglądarką, schowkiem, systemem plików i interpreterem poleceń. Jeżeli organizacja nie zbiera pełnej telemetrii procesów i plików, część krytycznych etapów może pozostać niezauważona.
Rekomendacje
Organizacje powinny traktować ClickFix jako dojrzałą i stale rozwijaną technikę initial access. Obrona nie może ograniczać się do filtrowania treści schowka czy blokowania pojedynczych poleceń. Potrzebne jest połączenie działań edukacyjnych, kontroli behawioralnych i precyzyjnej telemetrii endpointów.
- wdrożyć monitorowanie uruchomień powershell.exe, cmd.exe i msiexec.exe z kontekstów użytkownika,
- śledzić operacje na plikach w katalogach Downloads i TEMP wykonywane tuż przed startem skryptów,
- analizować nietypowe łańcuchy process tree obejmujące Windows Terminal oraz powłokę systemową,
- wykrywać rozpakowywanie archiwów i natychmiastowe wykonanie ich zawartości,
- ograniczyć użycie PowerShell i innych interpreterów do zatwierdzonych scenariuszy administracyjnych,
- wdrożyć application control, AppLocker lub WDAC tam, gdzie jest to możliwe,
- rozwijać szkolenia użytkowników z jasnym komunikatem, by nie wklejali poleceń pochodzących z witryn, fałszywych CAPTCHA i komunikatów błędów,
- korelować telemetrię EDR, DNS i proxy, aby wychwytywać sekwencje: wejście na stronę, pobranie pliku, uruchomienie interpretera i połączenie wychodzące,
- rozszerzyć playbooki SOC o scenariusze ClickFix, FileFix i podobne techniki manualnego wykonania komend.
W procedurach reagowania warto dodatkowo uwzględnić analizę świeżo pobranych archiwów, zawartości katalogów tymczasowych oraz relacji czasowych między pobraniem pliku a uruchomieniem terminala lub interpretera skryptowego.
Podsumowanie
ClickFix wchodzi w nowy etap rozwoju. Zamiast prostych, jednorazowych komend obserwujemy backendy generujące payloady na żądanie, wielowarstwowe zaciemnianie oraz dostosowanie kodu do konkretnej ofiary. Równolegle pojawiają się techniki ograniczające widoczność właściwego ładunku, takie jak wcześniejsze pobranie pliku do katalogu Downloads i użycie krótkiej komendy orkiestrującej.
Dla zespołów bezpieczeństwa najważniejszy wniosek jest praktyczny: skuteczna detekcja musi opierać się na analizie zachowania, korelacji procesów i pełnym łańcuchu zdarzeń, a nie wyłącznie na pojedynczym IOC lub treści schowka. ClickFix pozostaje prosty z perspektywy użytkownika, ale jego zaplecze techniczne staje się coraz bardziej zaawansowane.