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 + ręczne 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”.
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, że 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ć nawet 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śli 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 / kluczowe wnioski
CrashFix pokazuje, że 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)
GootLoader (JScriptowy „loader” wykorzystywany często jako initial access pod kolejne etapy, w tym ransomware) został zaobserwowany z nową techniką unikania detekcji: dystrybucją ładunku w celowo zniekształconym (malformed) archiwum ZIP, które psuje analizę wielu narzędzi bezpieczeństwa i popularnych rozpakowywarek, ale nadal otwiera się w domyślnym eksploratorze Windows. W praktyce nie jest to pojedyncza luka CVE, tylko sprytnie zaprojektowany anti-analysis & evasion pattern na poziomie formatu pliku i łańcucha dostarczenia.
W skrócie
Kampania wykorzystuje ZIP-y sklejone z 500–1000 następujących po sobie archiwów (ZIP „działa”, bo parser czyta kluczowe struktury od końca pliku).
Archiwum ma cechy celowego „uszkodzenia” (m.in. nietypowe/popsute pola w strukturach ZIP), przez co 7-Zip/WinRAR i część pipeline’ów analitycznych potrafi się wywracać lub nie wyciągać zawartości.
etap zawiera zwykle JScript, który po uruchomieniu prowadzi do uruchomienia kolejnych procesów (m.in. PowerShell) i persistence.
Expel opublikował podejście detekcyjne (w tym regułę YARA) oparte o unikalne właściwości tych archiwów.
Kontekst / historia / powiązania
GootLoader to znany od lat komponent ekosystemu „access-as-a-service”: jego rolą bywa wejście do sieci ofiary, a następnie „handoff” dostępu do kolejnych operatorów (np. do wdrożenia narzędzi post-exploitation lub ransomware). Źródła branżowe łączą jego powrót (po przerwie) z aktywnością od listopada 2025 i wskazują na powiązania z aktorem śledzonym jako Vanilla Tempest oraz kontekstem ransomware (np. Rhysida).
Równolegle Red Canary opisuje GootLoader jako zagrożenie często sprzęgnięte z SEO poisoning i dystrybucją ZIP-ów „udających” dokumenty (prawne/finansowe), co dobrze pasuje do profilu kampanii nastawionych na masowe infekcje i wysoki współczynnik kliknięć.
Analiza techniczna / szczegóły luki
1) „Hashbusting” i sklejanie setek ZIP-ów
Najbardziej charakterystyczna cecha: plik wynikowy to setki (500–1000) ZIP-ów sklejonych w jeden. Ponieważ standardowy odczyt ZIP bazuje na strukturze End of Central Directory (EOCD) znajdującej się na końcu, archiwum nadal może się rozpakować — mimo że wcześniej w pliku „siedzi” mnóstwo śmieci/powtórek. Co ważne: liczba sklejonych archiwów jest losowa, co utrudnia detekcję po hashu (każdy pobierający dostaje inny plik).
2) Malformed ZIP jako anti-analysis (psucie narzędzi)
Expel opisuje dodatkowe „anomalia” w strukturach ZIP (m.in. problemy w EOCD oraz randomizacje pól, które nie są krytyczne dla działania w Windows, ale potrafią wprowadzać inne narzędzia w błąd). Efekt: część unarchiverów i automatycznych workflowów analitycznych nie potrafi stabilnie wyciągnąć zawartości lub traktuje plik jako uszkodzony.
3) „Egzotyczne” dostarczenie: budowanie finalnego ZIP-a po stronie ofiary
Ciekawy detal: w opisie Expel finalny plik nie musi być po prostu pobrany jako gotowy ZIP. Ofiara może otrzymać XOR-owaną „bryłę” danych, która na hoście jest dekodowana i wielokrotnie dopisywana do siebie aż osiągnie docelowy rozmiar — co utrudnia wykrycie w tranzycie (np. po stronie sieci/secure web gateway).
4) Uruchomienie JScript z ZIP-a i łańcuch procesów
Gdy użytkownik otworzy archiwum w Eksploratorze i kliknie plik .js, domyślne skojarzenie uruchamia Windows Script Host (wscript.exe), często z katalogu tymczasowego (bo Explorer wypakowuje do temp). Expel wskazuje to jako mocny punkt detekcyjny: wscript.exe uruchamiający .js z %AppData%\Local\Temp jest w większości środowisk anomalią. Dalej pojawia się persistence przez .LNK w folderze autostartu oraz kolejne uruchomienia .js z użyciem cscript.exe, po czym typowo następuje cscript.exe → powershell.exe z obfuskacją.
5) Gdzie w tym „bypass security controls”?
To obejście jest wielowarstwowe:
statyczne skanowanie i automatyczne rozpakowywanie przez część narzędzi może się nie udać (bo ZIP jest „malformed”), więc silnik nie dociera do payloadu,
detekcje oparte o hash stają się mało użyteczne (hashbusting),
jeśli finalny plik powstaje po stronie endpointu, narzędzia sieciowe mogą zobaczyć coś innego niż finalne archiwum.
Praktyczne konsekwencje / ryzyko
Wyższa skuteczność initial access: nawet jeśli organizacja ma dobre filtry na bramie e-mail / web, problemy z ekstrakcją i analiza statyczna mogą dawać „ślepe plamy”.
Szybszy „handoff” do kolejnych operatorów: GootLoader jest opisywany jako komponent, który ułatwia dalsze wdrożenia (C2, narzędzia post-exploitation, potencjalnie ransomware).
Ryzyko operacyjne w SOC: analitycy mogą dostać artefakt, którego nie da się łatwo rozpakować standardowymi narzędziami, co spowalnia triage i IR.
Rekomendacje operacyjne / co zrobić teraz
1) „Wyłącz łatwe uruchamianie JScript”
Jeśli biznes nie wymaga JScript, rozważ:
zmianę skojarzeń .js/.jse tak, aby otwierały się np. w Notatniku, a nie w Windows Script Host,
ograniczenie uruchamiania wscript.exe/cscript.exe (np. politykami, allowlistingiem, ASR/EDR).
2) Detekcje behawioralne (praktyczne i odporne na hashbusting)
W SOC/EDR poluj na:
wscript.exe uruchamiający .js z %AppData%\Local\Temp,
tworzenie .LNK w folderze autostartu użytkownika i wskazywanie na skrypty w nietypowych lokalizacjach,
cscript.exe uruchamiający .js z użyciem krótkich nazw NTFS (np. FILENA~1.js),
drzewo procesów cscript.exe → powershell.exe i kolejne, silnie obfuskowane polecenia PowerShell.
3) Detekcja po kształcie pliku (YARA / własne parsowanie ZIP)
Zamiast polegać na hashu:
wykorzystaj regułę YARA/heurystyki wykrywające wielokrotne wystąpienia struktur ZIP (np. setki nagłówków lokalnych i EOCD) oraz ich specyficzne bajty/pola,
traktuj ZIP-y „nie do rozpakowania” jako sygnał, nie przeszkodę: nieudana ekstrakcja powinna eskalować, a nie kończyć analizę.
4) Uporządkowanie polityk Mark-of-the-Web / stref pochodzenia
Windows bazuje na oznaczaniu plików informacją o strefie pochodzenia (Attachment Manager / „zone information”). Upewnij się, że polityki nie wyłączają tego mechanizmu tam, gdzie jest potrzebny, bo jego brak utrudnia ocenę ryzyka przez system i narzędzia zależne od tych metadanych.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Klasyczne kampanie ZIP często liczą na hashe, proste obfuskacje lub password-protected archiwa. Tutaj nacisk jest na psucie analizy narzędziami i na to, że Windows i tak to otworzy.
W porównaniu z typowymi „archive bombs”, to nie jest próba kompresyjnego DoS, tylko kontrolowane „zepsucie” formatu + masowe duplikacje struktur (pod automaty, nie pod człowieka).
Podsumowanie / kluczowe wnioski
GootLoader pokazuje, że w 2026 roku „bypass” nie musi oznaczać exploita w EDR — czasem wystarczy inteligentne wykorzystanie różnic w parsowaniu formatów plików i projektowanie łańcucha dostarczenia pod słabe punkty automatyzacji obrony. Najlepsza odpowiedź to połączenie: twardych ograniczeń uruchamiania skryptów (JScript/WSH), detekcji behawioralnej oraz identyfikacji anomalii w strukturze ZIP (zamiast hashy).
Źródła / bibliografia
Expel – „Planned failure: Gootloader’s malformed ZIP actually works perfectly” (15 stycznia 2026). (Expel)
BleepingComputer – „Gootloader now uses 1,000-part ZIP archives for stealthy delivery” (15 stycznia 2026). (BleepingComputer)
Security Affairs – „GootLoader uses malformed ZIP files to bypass security controls” (18 stycznia 2026). (Security Affairs)
Red Canary – „Gootloader” (Threat Detection Report – opis zagrożenia i typowego wektora). (Red Canary)
Microsoft Learn – Policy CSP: AttachmentManager (zarządzanie oznaczaniem strefy pochodzenia plików). (Microsoft Learn)
Microsoft rozpoczął testy nowej polityki systemowej, która ma dać administratorom IT możliwość odinstalowania aplikacji Microsoft Copilot na urządzeniach zarządzanych (np. w środowiskach firmowych z MDM). Zmiana jest istotna dla organizacji, które chcą ograniczać „konsumenckie” doświadczenia AI na stacjach roboczych, uporządkować powierzchnię ataku i zmniejszyć zamieszanie użytkowników między Copilotem konsumenckim a Microsoft 365 Copilot.
W skrócie
Polityka nazywa się RemoveMicrosoftCopilotApp i pojawiła się w Windows 11 Insider Preview Build 26220.7535 (KB5072046) (kanały Dev/Beta).
Po włączeniu polityki Microsoft Copilot zostanie odinstalowany „jednorazowo” (a użytkownik nadal może go ponownie zainstalować).
Ma to działać w scenariuszach urządzeń zarządzanych m.in. przez Microsoft Intune oraz SCCM.
Polityka jest „targetowana” – uruchomi się tylko, jeśli urządzenie/użytkownik spełnia warunki (m.in. brak uruchomień Copilota przez 28 dni).
Kontekst / historia / powiązania
W ostatnich kilkunastu miesiącach Microsoft intensywnie przebudowywał doświadczenie Copilota w Windows i w środowiskach komercyjnych. W dokumentacji Microsoft wskazuje m.in., że konsumencka aplikacja Microsoft Copilot nie obsługuje logowania Entra i w praktyce kieruje użytkownika do Microsoft 365 Copilot Chat w przeglądarce, co dodatkowo komplikuje „kto z czego ma korzystać” w firmie.
Warto też pamiętać, że w 2025 r. Microsoft musiał reagować na błąd aktualizacji Windows 11, który przypadkowo odinstalowywał Copilota na części urządzeń i odpinał go z paska zadań — to pokazało, jak wrażliwy jest ten element ekosystemu na zmiany w dystrybucji i politykach.
Analiza techniczna / szczegóły polityki
Gdzie pojawiła się polityka
Nowa opcja została opisana przez Windows Insider Team w ogłoszeniu buildu 26220.7535. Administrator może ją włączyć w edytorze zasad grupy pod ścieżką:
User Configuration → Administrative Templates → Windows AI → Remove Microsoft Copilot App
Jak działa (logika warunkowa)
Polityka ma zastosowanie tylko wtedy, gdy spełnione są jednocześnie warunki:
Microsoft 365 Copilot i Microsoft Copilot są zainstalowane,
Microsoft Copilot nie został zainstalowany przez użytkownika,
Microsoft Copilot nie był uruchamiany przez ostatnie 28 dni.
Po włączeniu: aplikacja Microsoft Copilot zostanie odinstalowana „once” (jednorazowo). Użytkownik nadal może ją potem ponownie zainstalować, jeśli będzie chciał.
Zakres edycji Windows
Microsoft wskazuje dostępność polityki na Enterprise, Pro i EDU.
Zarządzanie z Intune / SCCM
BleepingComputer podaje, że odinstalowanie ma następować na endpointach zarządzanych przez Microsoft Intune lub System Center Configuration Manager (SCCM) po włączeniu tej polityki.
Praktyczne konsekwencje / ryzyko
Co to daje bezpieczeństwu i zgodności
Redukcja „konsumenckiego” punktu wejścia do AI na firmowych stacjach — mniej ryzyka, że użytkownik będzie próbował używać niewłaściwego kanału (np. niezgodnego z polityką organizacji) lub mylił Copilot konsumencki z kontrolowanym M365 Copilot. Kontekst rozróżnienia consumer vs commercial opisuje Microsoft.
Porządek w standardzie obrazu (golden image) i w audytach: łatwiej udowodnić, że aplikacja nie jest obecna na zarządzanych urządzeniach (choć uwaga: polityka jest „once”, a użytkownik może reinstalować).
Ograniczenia, o których trzeba pamiętać
Skoro użytkownik może ponownie zainstalować aplikację, sama polityka nie jest „twardą blokadą” — to raczej mechanizm porządkowy/porządkujący niż finalne egzekwowanie.
Polityka działa tylko dla scenariuszy spełniających warunki (np. „nieuruchamiane 28 dni”) — w praktyce część środowisk może nie zobaczyć efektu na wszystkich stacjach.
Rekomendacje operacyjne / co zrobić teraz
Zweryfikuj, które „Copilot-y” masz w organizacji Microsoft rozdziela doświadczenia: konsumencki Microsoft Copilot vs komercyjny Microsoft 365 Copilot/M365 Copilot Chat. To ma znaczenie dla polityk, komunikacji do użytkowników i helpdesku.
Jeśli celem jest trwałe ograniczenie uruchamiania/instalacji, rozważ AppLocker Microsoft wprost rekomenduje AppLocker jako właściwy mechanizm kontroli tej aplikacji (blokowanie instalacji/uruchomienia), zamiast polegać na starszych ustawieniach.
Przygotuj plan egzekwowania (nie tylko „cleanup”)
„RemoveMicrosoftCopilotApp” może posprzątać aplikację, ale ponieważ użytkownik może ją przywrócić, w praktyce potrzebujesz warstwy egzekwującej (np. AppLocker) tam, gdzie wymagają tego polityki bezpieczeństwa.
Pilot na małej grupie (szczególnie jeśli masz środowiska mieszane Pro/Enterprise/EDU) Polityka jest na razie w Insiderach, więc potraktuj ją jako zapowiedź kierunku i testuj wpływ na UX oraz zgłoszenia do service desku.
Różnice / porównania z innymi przypadkami
Odinstalowanie (RemoveMicrosoftCopilotApp): „sprzątanie” aplikacji — jednorazowe usunięcie, możliwa reinstalacja przez użytkownika; dodatkowo warunki targetowania.
PowerShell: opcja manualna/skryptowa do usuwania pakietu aplikacji (Microsoft opisuje kroki w dokumentacji), ale to zwykle „operacyjne narzędzie” do remediacji, a nie mechanizm zarządzania polityką na dłuższą metę.
Historyczny incydent z 2025 r. (błąd aktualizacji): tam usunięcie Copilota było nieintencjonalne; tutaj Microsoft wprowadza kontrolowany mechanizm administracyjny.
Podsumowanie / kluczowe wnioski
Microsoft idzie w stronę większej sterowalności Copilota w firmach: nowa polityka ma umożliwić adminom odinstalowanie aplikacji Copilot na urządzeniach zarządzanych.
Mechanizm jest warunkowy i jednorazowy, więc nie zastępuje twardego egzekwowania — do tego sensowniejsze są narzędzia typu AppLocker.
Dla cyberbezpieczeństwa i compliance to dobra wiadomość: łatwiej ustandaryzować środowisko i ograniczać niepożądane „konsumenckie” powierzchnie AI, ale trzeba to domknąć warstwą polityk i komunikacji do użytkowników.
Źródła / bibliografia
Windows Insider Blog – Announcing Windows 11 Insider Preview Build 26220.7535 (Dev & Beta Channels) (Windows Blog)
BleepingComputer – Microsoft may soon allow IT admins to uninstall Copilot (BleepingComputer)
Microsoft Learn – Updated Windows and Microsoft 365 Copilot Chat experience (Microsoft Learn)
The Verge – Microsoft has fixed the Copilot automatic uninstall bug (kontekst historyczny) (The Verge)
ClickFix to nie „luka” w sensie CVE, tylko wzorzec socjotechniczny: atakujący wyświetla ofierze wiarygodnie wyglądającą usterkę (np. błąd przeglądarki, CAPTCHA, „aktualizację”, a nawet ekran awarii), po czym prowadzi ją krok po kroku do samodzielnego uruchomienia polecenia (PowerShell/Terminal/Run). Kluczowy trik polega na tym, że to użytkownik staje się „launcherem” – omijając część automatycznych barier bezpieczeństwa.
Na początku stycznia 2026 r. opisano świeżą odsłonę tej techniki: kampanię wymierzoną w sektor hotelarski w Europie, gdzie przynętą jest fałszywa wiadomość o anulowaniu rezerwacji Booking.com, a elementem „wow” – fałszywy BSOD (Blue Screen of Death) odpalany w przeglądarce.
W skrócie
Cel: firmy z branży hospitality w Europie; przynęta „anulowanie rezerwacji” z kwotą zwrotu, która buduje presję czasu.
Mechanika: link z phishingu → klon Booking.com → fałszywy błąd/„CAPTCHA” → przejście w fullscreen → fałszywy BSOD → instrukcja Win+R i wklejenie komendy → uruchomienie łańcucha infekcji.
Technika „living off the land”: wykorzystanie legalnego MSBuild.exe do kompilacji/uruchomienia payloadu z pliku projektu .proj.
Payload: zmodyfikowany DCRat (RAT) + możliwości dalszego doładowania (w obserwacji: m.in. miner).
Kontekst / historia / powiązania
ClickFix został szerzej opisany jako rosnący trend od 2024 r. – pojawia się w kampaniach wykorzystujących phishing, malvertising i skompromitowane strony. Często kończy się infekcjami typu infostealer (np. Lumma) lub RAT/loaderami, a sam „fix” wymaga od użytkownika kopiowania-wklejania i uruchamiania poleceń.
W obserwacjach Microsoftu powtarza się też motyw wstrzykiwania/uruchamiania ładunków w pamięci oraz nadużywania narzędzi systemowych (LOLBins) – w tym m.in. msbuild.exe czy powershell.exe – co utrudnia detekcję opartą o klasyczne sygnatury plików.
Opisywana kampania (PHALT#BLYX) wpisuje się w ten trend, ale wyróżnia się „opakowaniem” (BSOD) oraz dopasowaniem do specyficznego kontekstu biznesowego (hotelarstwo + sezonowość + presja rozliczeń).
Atak startuje od e-maila podszywającego się pod informację o anulowaniu rezerwacji. Element psychologiczny jest prosty: „gość anuluje, jest zwrot (często znaczący), trzeba działać szybko”.
2) Klon serwisu i przynęta w przeglądarce
Kliknięcie prowadzi na stronę-klona Booking.com (w opisie wskazano m.in. domenę low-house[.]com), przygotowaną jako „high-fidelity clone” z odpowiednim brandingiem. Strona wyświetla błąd w stylu „Loading is taking too long” i zachęca do kliknięcia przycisku odświeżenia.
3) Fałszywy BSOD w trybie fullscreen = właściwy ClickFix
Po kliknięciu przycisku strona przechodzi w fullscreen i wyświetla fałszywy ekran BSOD. Następnie ofiara dostaje instrukcję:
otwórz Uruchom (Win+R),
wciśnij CTRL+V (w schowku jest już przygotowana komenda),
zatwierdź (Enter/OK).
To ważny szczegół: atakujący przenosi „punkt wykonania” na czynność użytkownika, co (w zależności od środowiska) może ominąć część kontroli, które lepiej działają na automatyczne pobrania/uruchomienia.
4) PowerShell + projekt MSBuild (v.proj) i kompilacja „na żywo”
W tej kampanii wklejone polecenie uruchamia PowerShell, który (równolegle do odwracania uwagi „wabikiem” w postaci strony administracyjnej) pobiera plik projektu .NET (v.proj) i wykorzystuje legalny MSBuild.exe do kompilacji oraz uruchomienia osadzonego payloadu.
Securonix podkreśla, że to ewolucja: wcześniejsze próbki powiązane z tym aktorem wykorzystywały prostsze łańcuchy oparte o .hta/mshta.exe, a przejście na MSBuild ma charakter „living off the land” (większa odporność na proste detekcje).
5) Eskalacja, persistencja i obrona przed obroną
W opisie kampanii pojawiają się m.in.:
dodawanie wyjątków w Windows Defender,
próby uzyskania uprawnień admina (UAC),
pobranie kolejnych komponentów przez BITS (Background Intelligent Transfer Service),
persistencja przez plik .url w folderze Startup.
6) Payload: DCRat + „hands-on-keyboard”
Końcowy ładunek to DCRat (zdalny dostęp), uruchamiany z technikami typu process hollowing oraz wstrzykiwaniem do procesu aspnet_compiler.exe (wskazywane jako wykonanie w pamięci). DCRat zapewnia m.in. zdalny pulpit, keylogger, reverse shell i możliwość doładowania kolejnych payloadów (w obserwowanym przypadku dołożono koparkę kryptowalut).
Praktyczne konsekwencje / ryzyko
Dla organizacji (szczególnie hotelarstwa) ryzyko nie kończy się na jednym zainfekowanym komputerze recepcji:
Kompromitacja kont i danych: keylogging + zdalny dostęp to prosta droga do kradzieży poświadczeń (poczta, PMS/CRM, systemy płatności, panele OTA).
Rozprzestrzenianie w sieci: RAT umożliwia rozpoznanie środowiska i ruch lateralny (zwłaszcza jeśli segmentacja jest słaba).
Dalsze payloady: miner jest „widoczny”, ale te same możliwości często służą do wdrożeń bardziej destrukcyjnych (np. kolejne narzędzia post-exploitation).
Koszty operacyjne i reputacyjne: incydent w sezonie wysokiego obłożenia oznacza chaos operacyjny, ryzyko wycieku danych gości oraz potencjalne konsekwencje regulacyjne.
Rekomendacje operacyjne / co zrobić teraz
Szybkie działania (24–72h)
Komunikat do pracowników: „Windows/Booking.com nigdy nie wymagają wklejania poleceń do Win+R/PowerShell. BSOD nie daje instrukcji naprawy w przeglądarce.” (to konkretnie adresuje mechanikę ataku).
Wzmocnij filtrację poczty: reguły na tematykę anulowania rezerwacji/zwrotów i linków do domen podobnych do Booking.com; izolacja linków (URL rewriting / sandbox).
Polityki ograniczające “Run” tam, gdzie nie jest potrzebne: Microsoft wprost wskazuje, że redukcja użycia okna Uruchom (Win+R) w rolach, które go nie wymagają, może ograniczać skuteczność ClickFix.
Twardnienie endpointów
Ogranicz/monitoruj LOLBins: msbuild.exe, powershell.exe, (często także inne narzędzia „systemowe” nadużywane w ClickFix). Microsoft opisuje msbuild.exe jako jeden z procesów, w które bywa wstrzykiwany kod w kampaniach ClickFix.
PowerShell logging: włącz Script Block Logging (4104), Module Logging oraz Process Creation (4688) i koreluj z wywołaniami Win+R / nietypowymi parametrami. (To praktyczny fundament do polowań na ClickFix, bo „fix” prawie zawsze zostawia ślad w telemetrii procesu).
Kontrola Defender exclusions + BITS: alerty na dodawanie wyjątków, nietypowe joby BITS inicjowane z kontekstu PowerShell oraz tworzenie plików .url w Startup.
Monitoring / hunting
Unit 42 zwraca uwagę, że skuteczne podejście to połączenie edukacji użytkowników z polowaniem w EDR/Windows Event Logs na charakterystyczne wzorce ClickFix. W praktyce: szukaj sekwencji „przeglądarka → Win+R → PowerShell → msbuild → połączenia wychodzące”. (
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
„Fałszywy BSOD” vs „fałszywa aktualizacja / CAPTCHA”: ClickFix często udaje drobne problemy (CAPTCHA, błąd strony, update). W tej kampanii BSOD ma zwiększyć autorytet komunikatu i poczucie awarii krytycznej.
MSBuild jako etap kompilacji: wiele kampanii ClickFix kończy się prostszym pobraniem i uruchomieniem komponentu; PHALT#BLYX idzie w stronę „build chain” (projekt .proj + MSBuild.exe), co jest spójne z trendem nadużywania LOLBins do uruchamiania ładunków w pamięci.
DCRat jako payload: Microsoft wskazuje, że ClickFix jest używany do dystrybucji zarówno infostealerów, jak i RAT-ów (oraz loaderów). Ten przypadek to klasyczny RAT z potencjałem dalszej eskalacji w sieci ofiary.
Podsumowanie / kluczowe wnioski
ClickFix działa, bo przerzuca odpowiedzialność za uruchomienie malware na użytkownika – a to bywa trudniejsze do zatrzymania samą automatyką.
Kampania PHALT#BLYX (grudzień 2025 / opis 5 stycznia 2026) pokazuje, że atakujący potrafią łączyć wysokiej jakości phishing + realistyczny klon serwisu + teatralny BSOD z technikami „living off the land” (MSBuild).
Najbardziej opłacalna obrona to miks: edukacja (zakaz wklejania komend), ograniczenie Win+R tam gdzie zbędne, twardnienie i monitoring PowerShell/MSBuild/BITS/Startup.
Źródła / bibliografia
BleepingComputer – ClickFix attack uses fake Windows BSOD screens to push malware (5 stycznia 2026) (BleepingComputer)
GlassWorm to wielofalowa kampania typu supply chain wymierzona w ekosystem rozszerzeń Visual Studio Code (Microsoft Visual Studio Marketplace) oraz Open VSX (alternatywny, „vendor-neutral” rejestr używany m.in. przez edytory kompatybilne z VS Code). Atak polega na publikowaniu trojanizowanych rozszerzeń, które po instalacji uruchamiają kolejne etapy infekcji: kradzież tokenów i danych, instalację backdoora oraz – w najnowszej odsłonie – próbę podmiany aplikacji obsługujących portfele sprzętowe na wersje złośliwe.
Istotna zmiana w fali 4: po wcześniejszym skupieniu na Windows, kampania przeniosła ciężar na macOS (deweloperów), co ma sens operacyjny – to popularna platforma w software housach i środowiskach krypto/Web3.
W skrócie
Kogo atakują? Deweloperów na macOS instalujących zaufanie-budujące rozszerzenia VS Code/Open VSX.
Jak? 3 podejrzane rozszerzenia na Open VSX zawierają zaszyfrowany (AES-256-CBC) payload w skompilowanym JavaScript, uruchamiany po opóźnieniu ~15 minut.
Po co? Kradzież danych (tokeny GitHub/NPM, dane przeglądarki, Keychain), celowanie w portfele krypto (rozszerzenia i aplikacje desktop), a w fali 4 także mechanizm podmiany Ledger Live i Trezor Suite.
C2/odporność infrastruktury: utrzymany został mechanizm C2 oparty o blockchain Solana (dynamiczne wskazywanie endpointów).
Kontekst / historia / powiązania
Październik 2025: kampania została opisana jako atak wykorzystujący m.in. „niewidzialne” znaki Unicode do ukrycia złośliwego kodu w rozszerzeniach.
Kolejne fale: napastnicy wracali mimo nagłośnienia i usuwania złośliwych pozycji z marketplace’ów.
Reakcja ekosystemu: zespół Open VSX (Eclipse Foundation) podkreślał, że incydent został opanowany, usuwał złośliwe rozszerzenia i wprowadzał zmiany w zarządzaniu tokenami oraz skanowaniu publikacji.
W praktyce ta historia pokazuje typowy problem obrony w łańcuchu dostaw: nawet po „cleanupie” i wzmacnianiu kontroli, atakujący iterują techniki dostarczania (Unicode → binaria/kompilacja → szyfrowany JS + opóźnienia) i przenoszą cele na najbardziej „opłacalne” środowiska.
Analiza techniczna / szczegóły luki
1) Nośnik: złośliwe rozszerzenia (Open VSX / VS Code)
W fali 4 badacze wskazali trzy identyfikatory rozszerzeń (Open VSX), powiązane z macOS-owym łańcuchem infekcji:
2) Dostarczenie i unikanie detekcji: szyfrowanie + opóźnienie
Zamiast „niewidzialnego” Unicode, payload jest opakowany w AES-256-CBC i zaszyty w skompilowanym JavaScript. Dodatkowo logika wykonuje się po ok. 15 minutach, co utrudnia sandboxing (wiele automatycznych analiz dynamicznych kończy się szybciej).
W porównaniu do wcześniejszych podejść (np. PowerShell/Registry na Windows), fala 4 używa natywnych dla macOS mechanizmów:
AppleScript do wykonania etapów wstępnych,
LaunchAgents jako mechanizm persystencji,
próby pozyskania haseł z Keychain (w tym wskazywane jest też pozyskanie samej bazy Keychain).
4) C2 na blockchainie Solana (odporność na „takedown”)
Mechanizm C2 pozostaje kluczowym elementem kampanii: malware ma pobierać aktualne endpointy (np. URL) z danych powiązanych z aktywnością w sieci Solana, co utrudnia klasyczne blokowanie domen/serwerów „na sztywno”.
Najbardziej niepokojący element fali 4: kod sprawdza obecność Ledger Live i Trezor Suite, a następnie ma próbować pobrać i zainstalować ich trojanizowane odpowiedniki (po usunięciu legalnej aplikacji). Badacze odnotowali też, że w momencie testów część endpointów mogła zwracać puste pliki, przez co sama podmiana mogła „cicho” nie dojść do skutku – ale mechanizm jest już gotowy.
Przykładowe IoC (wartości z publicznych analiz)
Podejrzane rozszerzenia: jak wyżej (3 ID).
Wskazywane IP infrastruktury (C2/eksfil): m.in. 45.32.151.157, 45.32.150.251 (oraz historycznie 217.69.11.60).
Portfel/identyfikator wykorzystywany w mechanizmie Solana-C2 (podawany przez badaczy): BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC.
Praktyczne konsekwencje / ryzyko
Ryzyko kradzieży tożsamości deweloperskiej: tokeny i dane dostępowe do GitHub/NPM mogą przełożyć się na kolejne kompromitacje (repozytoria, paczki, pipeline’y CI/CD).
Ryzyko finansowe (krypto): celowanie w portfele przeglądarkowe i desktopowe oraz eskalacja w stronę portfeli sprzętowych oznaczają potencjalnie wyższy „payoff” dla atakujących.
Ryzyko lateral movement i trwałej obecności: persystencja (LaunchAgents) + zdalny dostęp/pośrednictwo ruchu (historycznie opisywane jako VNC/SOCKS) może zmienić stację deweloperską w punkt wejścia do sieci firmowej.
Natychmiastowy audyt rozszerzeń VS Code na macOS (szczególnie instalowanych z Open VSX), z naciskiem na nowe/mało znane wydawców oraz „podejrzanie podobne” nazwy (np. podszywanie się pod popularne narzędzia typu formatter/theme).
Wymuś allow-listę rozszerzeń (organizacyjnie) i ogranicz możliwość instalacji z nieautoryzowanych marketplace’ów, jeśli to możliwe.
Hunting na macOS pod kątem persystencji: przegląd ~/Library/LaunchAgents oraz /Library/LaunchAgents, korelacja z czasem instalacji rozszerzeń VS Code.
Monitoring procesów i zachowań:
nietypowe użycie osascript / AppleScript w kontekście VS Code,
odwołania do narzędzia security i operacji na Keychain,
nietypowe archiwizowanie/staging danych w katalogach tymczasowych (w analizach wskazywano staging w /tmp).
Blokady i detekcje sieciowe (z rozwagą): dodaj do watchlisty wskazywane IP/ścieżki eksfiltracji, ale traktuj je jako zmienne (Solana-C2 ułatwia rotację).
Rotacja sekretów: jeśli wykryjesz podejrzane rozszerzenia na endpointach deweloperskich, załóż kompromitację tokenów (GitHub PAT, NPM, SSH keys) i wykonaj kontrolowaną rotację oraz przegląd logów dostępu.
Dla deweloperów
Instaluj rozszerzenia tylko od zweryfikowanych wydawców i weryfikuj, czy linki/identyfikatory wydawcy zgadzają się z projektem.
Ogranicz uprawnienia i ekspozycję sekretów w środowisku developerskim (np. osobne konta, krótkie TTL tokenów, minimalne scope).
Jeśli używasz Ledger/Trezor: zwróć uwagę na nagłe reinstalacje/„aktualizacje” aplikacji i weryfikuj podpisy/pochodzenie instalatorów (szczególnie po instalacji nowych rozszerzeń).
Różnice / porównania z innymi przypadkami
Fale 1–2: nacisk na ukrywanie kodu przez „niewidzialne” Unicode (w tym klasy znaków, które potrafią umykać typowym ostrzeżeniom) i kradzież danych deweloperskich/krypto.
Fala 3: odejście od „niewidzialnego” kodu w stronę trudniejszych w analizie artefaktów (np. natywnych/kompilowanych), utrzymanie Solana-C2.
Fala 4 (teraz):pełny pivot na macOS + AES-256-CBC w JS + opóźnienie 15 min + LaunchAgents/Keychain oraz wyraźna eskalacja w stronę podmiany Ledger Live i Trezor Suite.
To nie jest „jednorazowy incydent marketplace’u”, tylko kampania, która iteruje TTP pod presją publikacji i działań porządkowych.
Podsumowanie / kluczowe wnioski
GlassWorm w 4. fali pokazuje, że deweloperskie marketplace’y są atrakcyjnym wektorem APT-like dla cyberprzestępców (skala + zaufanie + dostęp do sekretów).
Pivot na macOS i próby podmiany Ledger/Trezor to sygnał, że kampania celuje w środowiska o wysokiej wartości (krypto, Web3, startupy).
Obrona „perymetrem” i samymi IOC nie wystarczy: potrzebne są polityki instalacji rozszerzeń, kontrola sekretów i detekcja behawioralna na endpointach deweloperskich.
Jak sezon urlopowy tworzy lukę operacyjną w cyberobronie (i co z tym zrobić)
Święta – dla większości z nas czas odpoczynku i wyciszenia. Dla hakerów? Wręcz przeciwnie – to okres żniw. Cyberprzestępcy dosłownie „kochają” długie weekendy i przerwy świąteczne, bo wtedy czujność obrony jest najniższa. Zespoły bezpieczeństwa (SOC, blue team) pracują często w okrojonym składzie albo pełnią dyżury zdalnie, podczas gdy atakujący nie biorą urlopu. Rezultat?
MITRE ATT&CK mapowanie (główne):T1190 Exploit Public-Facing Application (takt. Initial Access). ATT&CK v18, technika T1190 v2.8, Last Modified: 24 Oct 2025.
Ryzyko „skali Internetu”: Censys raportował ~103,476 potencjalnie podatnych instancji (stan na 22 grudnia 2025) oraz „no known exploitation at time of writing”.
Krótka definicja techniczna
T1190 (Exploit Public-Facing Application) to technika Initial Access, w której atakujący wykorzystuje lukę w aplikacji/usłudze wystawionej na Internet (lub szerzej: osiągalnej z sieci), aby uzyskać dostęp i uruchomić kod w kontekście tej aplikacji. W przypadku CVE-2025-68613 wektor jest sieciowy, a „wejściem” są workflow expressions w n8n oceniane w kontekście niedostatecznie odizolowanym od runtime, co daje RCE z uprawnieniami procesu n8n.
Gdzie występuje / przykłady platform (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365)
Typowe środowiska dla n8n + ryzyko T1190/CVE-2025-68613:
Windows: n8n jako proces node.exe/usługa; detekcja głównie po process creation (4688/Sysmon EID 1) i anomaliach w ruchu wychodzącym.
Linux: najczęściej spotykane wdrożenie (bare metal/VM/containers); detekcja po execve (auditd) i potomkach procesu node.
K8s (EKS/AKS/GKE): n8n jako Deployment/StatefulSet; ślady w K8s audit, logach Ingress (nginx/traefik), oraz w telemetrii runtime (Falco/eBPF).
AWS: n8n na EC2/ECS/EKS; ryzyko wzrasta, jeśli instancja ma rolę IAM (po RCE możliwa kradzież tokenów z metadata). T1190 wspiera platformy IaaS/Containers.
Azure: n8n na VM/AKS; analogicznie — MDE/AMA/Defender for Cloud do korelacji procesu i sieci.
ESXi: n8n uruchomione jako VM; kontekst T1190 obejmuje również ESXi jako platformę (ogólnie dla public-facing usług).
AD: sama luka nie jest „AD-specific”, ale dostęp uwierzytelniony bywa pochodną kompromitacji tożsamości/SSO. W praktyce koreluj: logowanie do n8n ↔ zmiany workflow ↔ zdarzenia na hostach domenowych, jeśli n8n ma integracje.
M365: jeśli n8n przechowuje tokeny do M365 (Graph/Exchange/SharePoint), po przejęciu instancji ryzykujesz nadużycie tych tokenów; szukaj anomalii w M365 Unified Audit Log (operacje administracyjne, nietypowe OAuth usage).
Szczegółowy opis techniki (jak działa, cele, dlaczego jest skuteczna)
Mechanika (na przykładzie n8n i CVE-2025-68613)
Warunek wstępny: atakujący posiada dostęp uwierzytelniony do n8n (PR:L).
Punkt wejścia: podczas konfiguracji workflow wprowadzane są expressions (np. w polach korzystających z expression engine).
Błąd izolacji: w podatnych wersjach expression evaluation może odbywać się w kontekście niewystarczająco odizolowanym od runtime (CWE-913).
Efekt: możliwość uruchomienia dowolnego kodu z uprawnieniami procesu n8n → odczyt/zmiana workflow, dostęp do danych, potencjalne operacje systemowe.
Dlaczego to jest skuteczne w realnym środowisku
n8n bywa wystawiane na Internet (panel edycji, webhooki, API), a workflow często przechowują sekrety i integracje (SaaS, chmury).
Wymóg uwierzytelnienia nie „ratuje” sytuacji, jeśli:
konta są współdzielone,
brak MFA,
jest SSO z podatnym IdP,
dochodzi do przejęcia sesji/tokenów.
Skuteczność rośnie, gdy proces n8n działa z szerokimi uprawnieniami (np. root w kontenerze, dostęp do socketa Dockera, dostęp do metadata/roli IAM, szeroki egress).
Sekwencja: logowanie → edycja workflow/API → błędy 5xx/4xx → chwilę później anomalie procesowe/egress (korelacja).
Windows
Security
4688
node.exe/n8n uruchamia cmd.exe, powershell.exe lub narzędzia sieciowe (nietypowe dla automatyzacji).
Windows
Sysmon
EID 1, 3, 11
Process create + network connect + file create w krótkim oknie czasu po zmianie workflow.
Linux
auditd
execve, connect
Proces node (n8n) spawn’uje /bin/sh, interpretery, pobiera pliki, tworzy cron/systemd.
K8s
K8s audit log
create/patch/exec
Niespodziewane pods/exec, zmiany w Deployment/Secret/ConfigMap po incydencie (jeśli atak eskaluje do K8s API).
AWS
CloudTrail
AssumeRole, GetCallerIdentity, List*, Get*, Put*
Nietypowe użycie roli/kluczy przypisanych do n8n/instancji po symptomach RCE (szczególnie STS).
M365
Unified Audit Log
Operacje Exchange/SharePoint/Entra
Skok w aktywności aplikacji/OAuth (jeśli w n8n były tokeny do M365) — koreluj czasowo z przejęciem instancji.
Uwaga: część wpisów (CloudTrail/M365/K8s) jest warunkowa — zależy od tego, jakie integracje i uprawnienia ma n8n w Twoim środowisku.
Detekcja (praktyczne reguły)
Sigma (gotowa reguła)
title: Suspicious child process spawned by n8n / Node.js (possible n8n RCE - CVE-2025-68613)
id: 3e7b6d6a-3a33-4a23-9a9a-2c7e3b6f4c11
status: experimental
description: >
Detects suspicious process spawning patterns where a Node.js-based n8n service spawns shells
or common system utilities. Useful as a post-exploitation signal for CVE-2025-68613.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2025-68613
author: Badacz CVE (SOC/Blue Team)
date: 2025/12/24
tags:
- attack.initial_access
- attack.t1190
- attack.execution
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\node.exe'
- '\n8n.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\bitsadmin.exe'
- '\certutil.exe'
- '\mshta.exe'
- '\rundll32.exe'
condition: selection_parent and selection_child
falsepositives:
- Legitimate automation that intentionally executes OS commands from workflows (high-risk design).
- Maintenance scripts launched by the n8n service account.
level: high
Splunk (SPL)
Przykład dla Sysmon (EID 1) lub równoważnych zdarzeń procesu:
index=endpoint (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1)
(
ParentImage="*\\node.exe" OR ParentImage="*\\n8n.exe" OR ParentCommandLine="* n8n *"
)
(
Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe"
OR Image="*\\bitsadmin.exe" OR Image="*\\certutil.exe" OR Image="*\\mshta.exe" OR Image="*\\rundll32.exe"
)
| stats count min(_time) as first_seen max(_time) as last_seen values(Computer) values(User) values(ParentCommandLine) values(CommandLine) by Image, ParentImage
| convert ctime(first_seen) ctime(last_seen)
KQL (Azure / Microsoft Defender for Endpoint)
Wariant oparty o DeviceProcessEvents:
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("node.exe", "node", "n8n.exe", "n8n")
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","bash","sh")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, FolderPath, SHA256
| order by Timestamp desc
CloudTrail query (AWS CLI/CloudWatch)
CloudWatch Logs Insights (przykład “polowania” na nietypowe STS/Identity po objawach kompromitacji aplikacji):
process
where event.type == "start"
and process.parent.name in ("node","node.exe","n8n","n8n.exe")
and process.name in ("cmd.exe","powershell.exe","pwsh.exe","bash","sh","wscript.exe","cscript.exe")
Heurystyki / korelacje (co łączyć)
Najlepiej działa korelacja „multi-sygnał” (T1190), zgodna z ideą: request → error → post-exploit behavior:
Ingress/WAF/Reverse proxy: nietypowe żądania do n8n + skok 4xx/5xx.
Aplikacja: logi n8n (w JSON) pokazują wzmożoną aktywność edycji/uruchomień workflow albo błędy w evaluacji.
Host/Container: proces node zaczyna tworzyć nietypowe potomki (shell/interpretery) w krótkim oknie czasu po anomaliach HTTP.
Egress: nowe połączenia wychodzące (szczególnie do Internetu lub do usług typu metadata 169.254.169.254 w chmurach — jeśli środowisko to umożliwia). MITRE opisuje taki łańcuch korelacyjny jako skuteczną strategię detekcji dla T1190 (również dla aplikacji kontenerowych i chmurowych).
False positives / tuning
Najczęstsze źródła FP:
Środowiska, w których n8n z założenia uruchamia polecenia systemowe (workflow jako „orchestrator” hosta).
Zadania administracyjne (backup, eksport, maintenance) wykonywane przez konto serwisowe n8n.
Tuning praktyczny:
Dodaj warunek kontekstu: alertuj tylko, jeśli parent=Node/n8n uruchamia shell i jednocześnie:
jest „nowy” zewnętrzny kierunek egress,
wystąpił spike 5xx,
zaszła zmiana workflow/aktywacja workflow w nietypowych godzinach.
Wykorzystaj n8n audit do identyfikacji “risky nodes”/niechronionych webhooków i potraktuj je jako wskaźnik podwyższonego ryzyka (priorytetyzacja instancji do hardeningu).
Playbook reagowania (kroki + komendy)
Krok 1 — identyfikacja narażenia (scoping)
Sprawdź wersję n8n i porównaj z zakresem podatności oraz wersjami naprawionymi.
Jeśli korzystasz z logów plikowych/JSON — upewnij się, że logowanie jest włączone i parsowalne (np. N8N_LOG_FORMAT=json, N8N_LOG_OUTPUT=file).
Zalecenia workarounds od maintainerów (tymczasowe, gdy nie możesz patchować od razu):
Ogranicz prawa do tworzenia/edycji workflow wyłącznie do w pełni zaufanych użytkowników.
Uruchom n8n w środowisku utwardzonym: najmniejsze uprawnienia OS, segmentacja, ograniczony egress.
Krok 3 — zebranie materiału dowodowego
Zbierz: logi reverse proxy/WAF, logi n8n (najlepiej JSON), zdarzenia procesów na hoście, listę aktywnych połączeń, listę zmienionych plików w ostatnich 24–72h.
Przykładowe komendy (Linux):
# połączenia i procesy (triage)
ss -tpn
ps -eo pid,ppid,user,cmd --sort=-%cpu | head
# szybkie polowanie na świeże pliki (dostosuj ścieżki do wdrożenia)
find / -xdev -mtime -2 -type f 2>/dev/null | head
Krok 4 — eradication i recovery
Upgrade do wersji naprawionej: 1.120.4 / 1.121.1 / 1.122.0, preferencyjnie 1.122.0+.
Jeśli podejrzewasz przejęcie: potraktuj instancję jak „burned”:
rotuj sekrety/tokenu API używane w workflow,
wymuś reset sesji/kont,
rozważ redeploy z czystego obrazu + odtworzenie workflow z zaufanego backupu.
Skala ekspozycji: Censys raportował 103,476 potencjalnie podatnych instancji (stan na 22 grudnia 2025), co typowo napędza skanowanie oportunistyczne po publikacji krytycznego RCE.
Status exploitacji: według Censys (22 grudnia 2025) „No known exploitation at time of writing” — to nie jest gwarancja bezpieczeństwa, ale ważny punkt odniesienia w komunikacji ryzyka.
Disclosure: advisory na GitHub opublikowano 19 grudnia 2025, jako krytyczne, z przypisaniem CWE-913 i wskazaniem patched versions.
Lab (bezpieczne testy) — przykładowe komendy
Poniżej bezpieczne testy dla zespołu SOC/Blue Team (bez payloadów i bez instrukcji exploitacji):
Weryfikacja konfiguracji logowania (parsowalność pod SIEM) Zgodnie z dokumentacją n8n ustaw logi na JSON i wyjście do pliku/console (w zależności od wdrożenia).
Uruchomienie security audytu n8n To test „higieny” instancji (risky nodes, niechronione webhooki, outdated instance).
# w środowisku testowym / na kopii instancji
n8n audit
Test detekcji post-exploit (symulacja TTP bez exploita)
W labie sprawdź, czy Twoje EDR/SIEM podnosi alert, gdy proces node uruchamia nieoczekiwany interpreter/shell (symulacja kontrolowana przez administratora labu).
Celem jest walidacja reguł Sigma/SPL/KQL/EQL z sekcji 7.
Mapowania (Mitigations, Powiązane techniki)
Mitigations dla T1190 (MITRE)
Z techniki T1190 wynikają szczególnie praktyczne mitygacje:
M1048 Application Isolation and Sandboxing
M1050 Exploit Protection (np. WAF)
M1037 Filter Network Traffic (zwłaszcza outbound z serwera aplikacji)
