Wprowadzenie do problemu
ClickFix to technika socjotechniczna, w której użytkownik jest nakłaniany do samodzielnego uruchomienia polecenia pod pozorem rozwiązania rzekomego problemu technicznego. Najnowszy wariant tej metody pokazuje, że atakujący coraz lepiej łączą manipulację ofiarą z nadużyciem lokalnych artefaktów systemowych, wykorzystując pamięć podręczną przeglądarki jako magazyn dla złośliwego ładunku.
Takie podejście pozwala ograniczyć widoczność etapu dostarczenia malware i jednocześnie ominąć praktyczne ograniczenia długości komend uruchamianych przez okno Windows Run. W efekcie ofiara widzi jedynie krótką instrukcję, podczas gdy właściwy skrypt został wcześniej zapisany lokalnie w cache przeglądarki.
W skrócie
- Atak rozpoczyna się od spreparowanej lub przejętej strony internetowej, która zapisuje złośliwy skrypt w pamięci podręcznej przeglądarki.
- Ładunek bywa maskowany jako nieszkodliwy zasób, na przykład plik graficzny.
- Użytkownik otrzymuje instrukcję uruchomienia krótkiego polecenia w Windows Run.
- Polecenie nie pobiera malware z Internetu, lecz wyszukuje odpowiedni wpis w lokalnym cache i uruchamia go jako skrypt.
- W dalszych etapach wykorzystywane są VBScript, PowerShell oraz komponenty .NET ładowane bezpośrednio do pamięci.
Kontekst i historia
Kampanie ClickFix należą obecnie do najskuteczniejszych metod uzyskania początkowego dostępu, ponieważ nie opierają się na klasycznym przełamywaniu zabezpieczeń, lecz na skłonieniu użytkownika do wykonania złośliwej akcji. Atakujący podszywają się pod komunikaty pomocy technicznej, błędy przeglądarki, fałszywe CAPTCHA lub procedury naprawcze, które z pozoru wyglądają wiarygodnie.
Wcześniejsze obserwacje wskazywały już na rozwój tej techniki w kierunku większej skrytości. W 2025 roku opisywano scenariusze cache smuggling, w których pamięć podręczna przeglądarki była używana do ukrywania elementów dalszego łańcucha infekcji. W 2026 roku ten model dojrzał: złośliwa logika może zostać przygotowana lokalnie jeszcze przed tym, zanim użytkownik wykona końcową komendę.
Analiza techniczna
Techniczny rdzeń opisywanego ataku polega na rozdzieleniu dostarczenia ładunku od momentu jego wykonania. Strona kontrolowana przez napastnika zapisuje złośliwy skrypt w cache przeglądarki, przedstawiając go jako zwykły zasób webowy. Dzięki temu polecenie wyświetlane użytkownikowi pozostaje krótkie i mieści się w praktycznych ograniczeniach okna Uruchamianie w systemie Windows.
Pierwszy uruchamiany komponent ma postać VBScript. Jego zadaniem jest przeszukanie katalogów profilu przeglądarki, odnalezienie właściwego wpisu cache na podstawie oczekiwanego rozmiaru pliku, skopiowanie artefaktu do katalogu tymczasowego i nadanie mu rozszerzenia umożliwiającego wykonanie. Następnie skrypt uruchamiany przez interpreter systemowy rozpoczyna rekonesans hosta, między innymi przy użyciu mechanizmów WMI.
Kolejne etapy obejmują uruchomienie PowerShella oraz dostarczenie dalszych komponentów odpowiedzialnych za pobranie i wykonanie następnego ładunku. W zaobserwowanych scenariuszach dochodziło także do ładowania komponentów .NET bezpośrednio do pamięci procesu oraz do wstrzykiwania kodu w legalne procesy systemowe. Taka architektura utrudnia detekcję i wspiera kradzież poświadczeń oraz komunikację z infrastrukturą napastnika.
Szczególnie istotne jest to, że ten wariant ogranicza liczbę oczywistych sygnałów telemetrii. Jeśli kluczowy ładunek znajduje się już lokalnie w cache, systemy bezpieczeństwa skupione na wykrywaniu podejrzanych pobrań mogą nie zarejestrować najważniejszego momentu infekcji. W praktyce oznacza to konieczność monitorowania zależności między aktywnością w katalogach cache, uruchomieniami interpreterów skryptowych i nietypowymi łańcuchami procesów potomnych.
Konsekwencje i ryzyko
Zagrożenie ma duże znaczenie operacyjne, ponieważ łączy udział użytkownika z użyciem zaufanych narzędzi systemowych. Taki model pozwala ominąć część tradycyjnych zabezpieczeń i ogranicza liczbę prostych wskaźników kompromitacji, takich jak jawne pobranie pliku wykonywalnego lub skryptu w chwili uruchomienia.
Potencjalne skutki obejmują przejęcie poświadczeń, rekonesans środowiska, ustanowienie trwałości, a następnie dalszy ruch boczny w sieci organizacji. Dla firm szczególnie groźne jest to, że infekcja może rozpocząć się od jednej, pozornie rutynowej czynności wykonanej przez użytkownika, który wierzy, że rozwiązuje zwykły problem techniczny.
Dodatkowym czynnikiem ryzyka jest łatwość modyfikowania przynęt. Atakujący mogą wykorzystywać komunikaty o błędach aplikacji, awariach wideokonferencji, problemach z VPN, aktualizacjach przeglądarki czy fałszywych CAPTCHA. W przypadku użycia przejętych witryn wiarygodność całego scenariusza jeszcze bardziej rośnie.
Rekomendacje
Organizacje powinny przyjąć zasadę, że każda instrukcja nakłaniająca użytkownika do wklejenia komendy do Windows Run, PowerShella, Terminala lub podobnego narzędzia jest potencjalnie złośliwa. Żaden legalny komunikat CAPTCHA ani standardowa procedura naprawcza nie powinna wymagać ręcznego uruchamiania kodu przez użytkownika.
- Monitorować procesy odczytujące lub kopiujące dane z katalogów cache przeglądarek.
- Analizować uruchomienia wscript.exe, cscript.exe, powershell.exe i cmd.exe, zwłaszcza gdy następują po aktywności przeglądarki.
- Ograniczyć użycie PowerShell i Windows Script Host do uzasadnionych scenariuszy administracyjnych.
- Wdrożyć kontrole aplikacyjne oraz rejestrowanie bloków skryptowych tam, gdzie to możliwe.
- Polować na artefakty takie jak wpisy RunMRU, nietypowe zadania harmonogramu i anomalie w katalogach tymczasowych użytkowników.
- Szkolić pracowników z rozpoznawania schematu ClickFix: fałszywy problem, gotowa „naprawa”, polecenie do skopiowania i presja na szybkie działanie.
W środowiskach o wyższym poziomie bezpieczeństwa warto również rozważyć ograniczenie użycia skrótu Win+R, jeśli nie jest on istotny z punktu widzenia procesów biznesowych. Coraz większe znaczenie ma też korelacja zdarzeń behawioralnych zamiast polegania wyłącznie na pojedynczych wskaźnikach kompromitacji.
Podsumowanie
Nowy wariant ClickFix pokazuje, że socjotechnika nadal ewoluuje w kierunku większej skrytości i lepszego wykorzystania lokalnych zasobów systemu. Użycie cache przeglądarki jako nośnika złośliwego ładunku pozwala ograniczyć widoczność etapu dostarczenia, ominąć ograniczenia Windows Run i utrudnić wykrycie przez klasyczne mechanizmy oparte na pobraniach lub reputacji plików.
Dla zespołów bezpieczeństwa oznacza to konieczność szerszego spojrzenia na cały łańcuch ataku: od przynęty webowej, przez aktywność w pamięci podręcznej przeglądarki, po uruchamianie interpreterów skryptowych i wykonanie kodu w pamięci. ClickFix przestaje być prostą sztuczką socjotechniczną, a staje się dojrzałym wektorem początkowego dostępu.