Wprowadzenie do problemu / definicja luki
ClickFix to technika socjotechniczna, która udaje „naprawę” problemu (np. CAPTCHA, błąd przeglądarki, weryfikacja człowieka) i instruuje użytkownika, by wkleił polecenie do Windows Run (Win+R) lub uruchomił je w PowerShell/cmd. To nie jest luka w oprogramowaniu, tylko skuteczny wektor initial access oparty o zachowanie użytkownika i „życie z ziemi” (LOLBAS). W 2026 r. ClickFix jest coraz częściej łączony z łańcuchami loader → RAT/stealer → ruch boczny → ransomware, bo daje atakującym szybkie wejście i dobre maskowanie.
W skrócie
Z obserwacji opisanej 7 marca 2026 r. wynika, iż operatorzy śledzeni jako Velvet Tempest (DEV-0504) użyli kampanii malvertising prowadzącej do miksu ClickFix + CAPTCHA, aby skłonić ofiary do wklejenia zaciemnionego polecenia w oknie „Uruchom”. Następnie uruchomiony został kaskadowy łańcuch cmd.exe i narzędzi systemowych (w tym finger.exe) do pobrania pierwszych loaderów; jeden z elementów był archiwum podszywającym się pod PDF. W kolejnych etapach widoczna była automatyzacja przez PowerShell, kompilacja komponentów .NET przez csc.exe w katalogach tymczasowych oraz elementy oparte o Pythona dla utrzymania się w systemie (np. w C:\ProgramData). Finalnie miało to doprowadzić do uruchomienia loadera i pobrania CastleRAT.
Kluczowy niuans: w obserwowanym incydencie nie doszło do uruchomienia samego ransomware Termite, ale część infrastruktury/hostingu narzędzi była powiązana z wcześniejszymi intruzjami przypisywanymi do „Termite” (co sugeruje współdzielenie zasobów lub playbooków w ekosystemie afiliantów).
Kontekst / historia / powiązania
BleepingComputer wskazuje, iż Velvet Tempest (DEV-0504) to doświadczony aktor, kojarzony z działalnością afilianta w wielu „epokach” ransomware. W praktyce takie grupy często zmieniają brand, przechodzą między programami RaaS i reużywają TTP, a równolegle korzystają z usług wyspecjalizowanych operatorów (np. MaaS/loader).
Istotne jest też tło „Castle*”: analizy branżowe opisują CastleLoader/CastleRAT jako elementy modularnego systemu dystrybucji malware, wykorzystywanego w kampaniach wieloetapowych (loader pobiera kolejne komponenty, a RAT daje trwałą kontrolę i rozpoznanie środowiska).
Analiza techniczna / szczegóły łańcucha
Poniżej typowy obraz techniczny tej klasy ataków (zbieżny z opisem incydentu i szerszymi analizami ClickFix/Castle):
Etap 0 — dystrybucja (malvertising / kompromitowane strony):
- reklamy lub przejęte witryny kierują na stronę „weryfikacji”, która prezentuje instrukcję wklejenia komendy do Win+R.
Etap 1 — ClickFix (uruchomienie polecenia przez użytkownika):
- ofiara uruchamia zaciemnioną komendę; w obserwacji pojawiają się zagnieżdżone łańcuchy cmd.exe oraz użycie finger.exe do pobrania pierwszych loaderów (LOLBAS, „życie z ziemi”).
Etap 2 — staging i wykonywanie kolejnych komponentów:
- PowerShell pobiera dalsze payloady i uruchamia komendy,
- widoczna jest kompilacja .NET przez csc.exe w katalogach tymczasowych,
- pojawiają się komponenty Pythona wspierające persistence (np. w C:\ProgramData).
Etap 3 — loader → RAT:
- BleepingComputer opisuje, iż łańcuch finalnie „staged” loader i pobrał CastleRAT, kojarzony z rodziną CastleLoader dystrybuującą różne RAT-y i stealery.
- Niezależne analizy CastleLoader pokazują, iż ten typ loadera bywa budowany tak, by dekodować i uruchamiać payload w pamięci, ograniczając artefakty na dysku, oraz pobierać kolejne etapy z infrastruktury atakujących.
Dlaczego to jest groźne dla ransomware?
Bo po stabilnym osadzeniu RAT-a atakujący mają czas na rozpoznanie AD, kradzież poświadczeń, enumerację hostów i przygotowanie warunków do masowego wdrożenia szyfratora (czasem dopiero po dniach/tygodniach).
Praktyczne konsekwencje / ryzyko
W opisywanej obserwacji po uzyskaniu dostępu widoczne były działania „hands-on keyboard”, w tym rozpoznanie Active Directory, discovery hostów oraz profilowanie środowiska, a także próby pozyskiwania poświadczeń (np. z przeglądarki). To klasyczny schemat pre-ransomware: najpierw kontrola i mapowanie, potem eskalacja i dopiero na końcu decyzja o szyfrowaniu/eksfiltracji.
Dla biznesu przekłada się to na:
- ryzyko przejęcia kont uprzywilejowanych i kompromitacji domeny,
- kradzież danych i długotrwałą obecność (persistence),
- możliwość uruchomienia ransomware w późniejszym terminie (również przez innego operatora, jeżeli dostęp zostanie „sprzedany” lub współdzielony).
Rekomendacje operacyjne / co zrobić teraz
Poniżej zestaw działań „tu i teraz” (priorytety SOC/IR):
- Zablokuj ClickFix jako zachowanie, nie jako pojedynczy IOC
- reguły EDR/SIEM na nietypowe uruchomienia: Win+R → cmd/powershell z długimi, zaciemnionymi parametrami,
- monitoring „łańcuchów” procesów: explorer.exe → rundll32/cmd/powershell/mshta/regsvr32 (zależnie od wariantu kampanii).
- Hunting na LOLBAS i staging
- korelacje na finger.exe w kontekście pobierania danych (rzadkie w normalnych środowiskach),
- wykrywanie kompilacji przez csc.exe w %TEMP%/katalogach użytkownika,
- alerty na podejrzane artefakty i trwałość w C:\ProgramData (zadania, usługi, autorun).
- Zabezpieczenia tożsamości
- natychmiastowa rotacja haseł dla kont podejrzanych + wymuszenie MFA (szczególnie kont admin/serwisowych),
- przegląd logowań i tokenów sesyjnych (nietypowe lokalizacje/urządzenia),
- ograniczenie uprawnień lokalnych adminów i segmentacja dostępu do AD.
- Containment na endpointach
- izolacja hostów z anomaliami w drzewie procesów (ClickFix/loader/RAT),
- pełna triage pamięci i artefaktów (bo część etapów może być in-memory).
- Prewencja użytkownika
- krótkie szkolenie „just-in-time”: „CAPTCHA nigdy nie wymaga Win+R i wklejania komend”,
- blokady politykami (AppLocker/WDAC) na nieautoryzowane interpretery i nietypowe ścieżki uruchomień.
Różnice / porównania z innymi przypadkami
To, co wyróżnia ClickFix, to przeniesienie „momentu kompromitacji” na użytkownika: nie trzeba eksploitu, bo ofiara sama uruchamia payload. Unit 42 opisuje ClickFix jako rosnący trend i pokazuje, iż kampanie potrafią dynamicznie zmieniać implementację (różne rodziny malware, różne łańcuchy), a mimo to rdzeń jest stały: obfuscated PowerShell/command + kolejne etapy.
Z kolei analizy łańcuchów ClickFix w innych kampaniach (np. kończących się stealerami) pokazują podobną logikę: shellcode/loader → wstrzyknięcie do legalnych procesów → eksfiltracja. To ważne, bo organizacje często bagatelizują „tylko stealer”, a w praktyce stealer bywa etapem budowy dostępu pod większą operację.
Podsumowanie / najważniejsze wnioski
- ClickFix to skuteczny, „tani” wektor initial access, który omija potrzebę exploitów i utrudnia obronę, bo opiera się na zachowaniu użytkownika.
- W opisywanym przypadku widoczny jest klasyczny playbook: malvertising → ClickFix → LOLBAS/PowerShell/.NET → CastleRAT, a następnie działania manualne w sieci (AD discovery itp.).
- Nawet jeżeli w danej obserwacji ransomware nie zostanie uruchomione, taki dostęp należy traktować jako incydent o wysokim priorytecie, bo to typowy etap „przygotowania pola” pod szyfrowanie i/lub eksfiltrację.
- Obrona wymaga podejścia behawioralnego: wykrywania łańcuchów procesów, nietypowych LOLBAS (np. finger.exe), kompilacji csc.exe, persistence w ProgramData oraz twardej higieny tożsamości.
Źródła / bibliografia
- BleepingComputer — „Termite ransomware breaches linked to ClickFix CastleRAT attacks” (7 marca 2026) (BleepingComputer)
- Darktrace — „CastleLoader & CastleRAT: Behind TAG150’s Modular Malware Delivery System” (26 listopada 2025) (Darktrace)
- Palo Alto Networks Unit 42 — „Fix the Click: Preventing the ClickFix Attack Vector” (aktualizacja 10 lipca 2025) (Unit 42)
- LevelBlue / SpiderLabs — „How ClickFix Opens the Door to Stealthy StealC Information Stealer” (12 lutego 2026) (levelblue.com)
- Blackpoint Cyber — „Snakes in the Castle: Inside a Python-Driven CastleLoader Delivery” (9 grudnia 2025) (Blackpoint)
