Wprowadzenie do problemu / definicja luki
Kampanie ClickFix to specyficzna forma socjotechniki, w której atakujący nie „włamują się” wprost, tylko doprowadzają do samodzielnego wykonania polecenia przez użytkownika (zwykle PowerShell/cmd), omijając część kontroli opartych o automatyzację i heurystyki. Microsoft opisuje to jako łańcuch ataku oparty o wabik wizualny + manualne wykonanie komendy, po którym następuje pobranie i uruchomienie złośliwego ładunku.
W styczniu 2026 r. badacze opisali nowy wariant tej metody: CrashFix. Tym razem przynętą jest… prawdziwy problem techniczny wywołany celowo – fałszywe rozszerzenie „adblocka” doprowadza do zawieszenia i awarii przeglądarki, a następnie proponuje „naprawę”, która w praktyce jest uruchomieniem złośliwego polecenia.
W skrócie
- Kampania wykorzystuje fałszywe rozszerzenie NexShield dla Chrome/Edge, podszywające się pod ekosystem uBlock (m.in. przez przypisywanie autorstwa Raymondowi Hillowi).
- Rozszerzenie wywołuje DoS na przeglądarce (zasobożerny mechanizm powodujący freeze/crash), po czym wyświetla okno z instrukcją „naprawy” w stylu ClickFix: Win+R → Ctrl+V → Enter.
- Na hostach domain-joined (typowo firmowych) finalnym ładunkiem jest nowy RAT w Pythonie: ModeloRAT.
Kontekst / historia / powiązania
ClickFix jest obserwowany co najmniej od początku 2024 r. jako taktyka wykorzystywana w wielu kampaniach dystrybucji malware (RAT-y, infostealery), często pod przykrywką „aktualizacji” lub „weryfikacji” w przeglądarce.
W CrashFix widoczna jest ewolucja: zamiast udawać awarię lub blokadę treści, atakujący realnie psują przeglądarkę (kontrolowany DoS), co zwiększa wiarygodność komunikatu „Twoja przeglądarka zatrzymała się nieprawidłowo”.
Analiza techniczna / szczegóły łańcucha infekcji
1) Dostarczenie: malvertising + pozorna legalność sklepu
Scenariusz startowy to klasyczne połączenie: użytkownik szuka „adblocka”, trafia na sponsorowane wyniki/reklamę, po czym instalacja prowadzi do (pozornie) oficjalnego kanału dystrybucji – sklepu rozszerzeń. Huntress opisuje, iż reklama kierowała do wpisu w Chrome Web Store dla NexShield, co u wielu ofiar obniża czujność („skoro w sklepie, to bezpieczne”).
2) Mechanizm awarii: kontrolowany DoS na Chrome/Edge
Kluczowy element NexShield to wyczerpywanie zasobów przeglądarki przez masowe tworzenie połączeń chrome.runtime w pętli. Huntress opisuje funkcję, która próbuje iterować choćby 1e9 razy, a po zakończeniu natychmiast planuje kolejną serię, tworząc nieskończoną pętlę; efektem są skoki CPU/RAM i finalny crash/hang.
Dodatkowo kampania stosuje opóźnienie uruchomienia (około 60 minut), aby osłabić skojarzenie „zainstalowałem rozszerzenie → przeglądarka się psuje”.
3) „Naprawa” w stylu ClickFix: schowek + uruchom
Po restarcie przeglądarki rozszerzenie pokazuje fałszywe ostrzeżenie i zachęca do „skanowania”, a następnie instruuje użytkownika, by wkleił polecenie (już podstawione w schowku) do okna uruchamiania/wiersza poleceń. To dokładnie wzorzec ClickFix: użytkownik wykonuje komendę sam, co bywa trudniejsze do zablokowania wyłącznie filtrowaniem treści WWW.
W opisywanym łańcuchu PowerShell pobiera i uruchamia kolejne etapy, m.in. poprzez Invoke-WebRequest, a następnie wykonuje zawartość zwróconą przez serwer (model „download & execute”).
4) Rozgałęzienie: WORKGROUP vs domain-joined
Kampania sprawdza, czy host jest dołączony do domeny. Huntress opisuje profilowanie ofiary (w tym enumerację i sprawdzenia antyanalizowe) oraz podejście „VIP”: dla domain-joined dostarczany jest ModeloRAT (Python), a dla maszyn niebędących w domenie badacze obserwowali odpowiedź typu „TEST PAYLOAD!!!!” (co sugeruje testy lub niższy priorytet tej gałęzi).
5) ModeloRAT: możliwości i utrzymanie
ModeloRAT (Python) ma cechy pełnoprawnego backdoora: komunikację C2 (opisywane jest m.in. szyfrowanie RC4), mechanizmy rozpoznania systemu, wykonywanie poleceń (w tym PowerShell), oraz persistencję w rejestrze (Run key).
Praktyczne konsekwencje / ryzyko
- Ryzyko dla firm jest wyraźnie wyższe, bo kampania preferuje hosty domain-joined – pojedynczy endpoint może stać się przyczółkiem do dalszych działań (AD, lateral movement, kradzież poświadczeń).
- Zaufanie do „oficjalnych sklepów” nie jest gwarancją – atak działa, bo wiele organizacji i użytkowników uznaje obecność w sklepie za weryfikację bezpieczeństwa.
- ClickFix/CrashFix omija część klasycznych zabezpieczeń, bo moment krytyczny to dobrowolne uruchomienie komendy przez użytkownika (często w kontekście PowerShell).
Rekomendacje operacyjne / co zrobić teraz
Dla organizacji (IT/SecOps)
- Wymuś polityki rozszerzeń (allowlist, blokada instalacji niezatwierdzonych dodatków) w Chrome/Edge w środowisku firmowym; traktuj rozszerzenia jak oprogramowanie wymagające akceptacji. (Uzasadnienie ryzyka: domenowe hosty są celem kampanii).
- Detekcja zachowań ClickFix: alertuj na nietypowe uruchomienia powershell.exe/cmd.exe inicjowane przez użytkownika po komunikatach „fix/scan”, szczególnie gdy następują po incydencie z przeglądarką. (Schemat łańcucha ClickFix).
- Higiena PowerShell: ogranicz uruchamianie skryptów (Constrained Language Mode tam, gdzie to realne), monitoruj Invoke-WebRequest/IEX, i łańcuchy „download & execute”.
- Postępowanie po incydencie: samo usunięcie rozszerzenia nie musi wystarczyć – w kampanii po ClickFix instalowane są payloady (np. ModeloRAT), więc potrzebny jest pełny triage endpointu.
Dla użytkowników
- Instaluj rozszerzenia wyłącznie od dobrze znanych wydawców, weryfikuj nazwę, stronę projektu i reputację; uważaj na „klony” obiecujące „advanced protection”.
- Zasada nadrzędna: nigdy nie wklejaj i nie uruchamiaj poleceń podsuwanych przez stronę/okno „naprawy”, jeżeli nie rozumiesz ich działania i nie możesz ich zweryfikować niezależnie.
Różnice / porównania z innymi przypadkami
- Klasyczny ClickFix zwykle opierał się o fałszywe „weryfikacje”, „update’y” lub komunikaty blokujące treść; CrashFix idzie krok dalej, bo generuje realny crash przeglądarki, przez co „naprawa” wydaje się bardziej uzasadniona.
- W ujęciu taktycznym to wciąż ta sama oś: user-driven execution (użytkownik uruchamia komendę), ale z mocniejszym „bodźcem” psychologicznym: frustracją po awarii.
Podsumowanie / najważniejsze wnioski
CrashFix pokazuje, iż ClickFix dojrzewa: atakujący nie tylko „udają problem”, ale potrafią go wytworzyć (DoS przeglądarki) i w ten sposób skłonić użytkownika do wykonania komendy. W tej kampanii szczególnie niepokojące jest rozgałęzienie na domain-joined i dostarczanie ModeloRAT jako narzędzia do utrzymania zdalnego dostępu w sieciach firmowych.
Jeśli zarządzasz flotą endpointów, potraktuj to jako sygnał do zaostrzenia kontroli nad rozszerzeniami przeglądarkowymi oraz do budowy detekcji pod socjotechnikę „wklej i uruchom”.
Źródła / bibliografia
- BleepingComputer – opis kampanii NexShield/CrashFix i skutków (Chrome/Edge, DoS, ModeloRAT). (BleepingComputer)
- Huntress – analiza techniczna CrashFix (mechanizm DoS chrome.runtime, opóźnienie, łańcuch PowerShell, ModeloRAT). (Huntress)
- Malwarebytes – perspektywa ClickFix + opis rozgałęzienia domain-joined vs non-domain i zalecenia bezpieczeństwa. (malwarebytes.com)
- Microsoft Security Blog – model łańcucha ataku ClickFix i dlaczego to omija część klasycznych kontroli. (Microsoft)
- HHS/HC3 Sector Alert (TLP:CLEAR) – tło ClickFix (od 2024), typowe wektory i ryzyka socjotechniczne. (HHS.gov)
