Archiwa: PowerShell - Strona 24 z 42 - Security Bez Tabu

Tag: PowerShell

MuddyWater uderza w organizacje w regionie MENA: Operation Olalampo i nowe implanty GhostFetch/CHAR/HTTP_VIP

Wprowadzenie do problemu / definicja „luki”

MuddyWater (znany też jako Mango Sandstorm, TA450 i inne aliasy) to irańska grupa APT kojarzona z działalnością szpiegowską i długofalowym utrzymywaniem dostępu do środowisk ofiar. W najnowszej kampanii – nazwanej Operation Olalampo – celem stały się przede wszystkim organizacje i osoby w regionie MENA (Middle East & North Africa), a wektor wejścia ponownie oparto o phishing z dokumentami Office i makrami.

W skrócie

  • Kampanię zaobserwowano od 26 stycznia 2026 r. i przypisano MuddyWater z wysoką pewnością.
  • Wykryto cztery kluczowe komponenty: downloader GhostFetch, backdoor GhostBackDoor, downloader HTTP_VIP oraz rustowy backdoor CHAR.
  • Warianty ataku używają przynęt (m.in. bilety lotnicze/raporty) i w jednym z torów kończą się instalacją AnyDesk do zdalnej kontroli.
  • Badacze wskazują ślady użycia narzędzi generatywnej AI przy tworzeniu malware (np. nietypowe artefakty w ciągach debug).
  • Campaign intelligence z Group-IB opisuje także C2 przez bota Telegram, co ujawniło fragmenty działań post-exploitation.

Kontekst / historia / powiązania

MuddyWater od lat bazuje na kombinacji: spear-phishingu, nadużywania zaufanych narzędzi administracyjnych (RMM), komponentów modułowych oraz „living-off-the-land”. Zależnie od kampanii grupa potrafi też wykorzystywać podatności w systemach wystawionych do internetu (np. SharePoint/Exchange) jako alternatywny initial access.

W ostatnich miesiącach obserwowano u MuddyWater wyraźną „modernizację” arsenału: od nowych backdoorów i loaderów po coraz częstsze wątki Rust w implantach. Przykładowo opisywano kampanie z rustowym implantem (RustyWater) i spear-phishingiem jako punktem wejścia.
Jednocześnie ESET (opisywane przez Help Net Security) pokazywał, że MuddyWater potrafi kreatywnie maskować loader (np. motyw gry Snake) i rozszerzać zestaw kradzieży poświadczeń po kompromitacji.

Analiza techniczna / szczegóły kampanii i narzędzi

1. Łańcuch infekcji (kill chain) – wspólny rdzeń

Warianty z Operation Olalampo łączy powtarzalny schemat:

  1. Phishing email → 2) Załącznik Office (Word/Excel) → 3) Skłonienie do “Enable Macros” → 4) Makro dekoduje payload i uruchamia komponenty zapewniające zdalną kontrolę / pobieranie kolejnych etapów.

To klasyczny dla MuddyWater wzorzec, spójny z wcześniejszymi obserwacjami, gdzie nacisk kładziono na socjotechnikę i etapowe „dowożenie” funkcji.

2. GhostFetch (1st-stage downloader)

GhostFetch pełni rolę pierwszego stopnia i jest nastawiony na:

  • profilowanie hosta,
  • proste testy „czy to człowiek” (np. walidacja ruchu myszą),
  • kontrolę rozdzielczości ekranu,
  • wykrywanie debuggerów/VM/artefaktów analizy oraz rozpoznanie AV,
  • pobieranie i wykonywanie kolejnych ładunków w pamięci.

To ważne: in-memory execution utrudnia klasyczne wykrycia oparte wyłącznie o artefakty na dysku.

3. GhostBackDoor (2nd-stage backdoor)

GhostBackDoor (dostarczany przez GhostFetch) zapewnia:

  • interaktywną powłokę (shell),
  • operacje odczytu/zapisu plików,
  • możliwość ponownego uruchomienia GhostFetch (czyli „pętla” do rekonfiguracji i aktualizacji łańcucha).

4. HTTP_VIP (native downloader + tor z AnyDesk)

HTTP_VIP to natywny downloader, który:

  • robi rekonesans systemu,
  • łączy się z infrastrukturą C2 (w publicznych opisach pada m.in. domena codefusiontech[.]org),
  • uwierzytelnia się i może pobierać/uruchamiać narzędzia (w tym AnyDesk z serwera C2).

W nowszym wariancie HTTP_VIP dodano też funkcje bardziej „backdoorowe”: zbieranie informacji o ofierze, interaktywny shell, transfer plików, zrzut schowka i zmianę interwału beaconingu.

W praktyce oznacza to, że komponent zaczyna przypominać hybrydę: downloader + lekki agent zdalnej kontroli.

5. CHAR (backdoor w Rust)

CHAR to backdoor napisany w Rust, zidentyfikowany jako element tej samej kampanii. Badacze zwracają uwagę na artefakty sugerujące AI-assisted development (np. nietypowe elementy w stringach debug), co wpisuje się w szerszy trend „przyspieszania” developmentu malware przez aktorów państwowych i quasi-państwowych.

6. Telegram jako kanał C2 (wątek operacyjny)

Wgląd w aktywność C2 przez bota Telegram pozwolił badaczom podejrzeć część działań post-exploitation: uruchamiane komendy, dogrywane narzędzia i techniki zbierania danych. To cenna informacja dla defensywy, bo pomaga odtworzyć zachowanie operatora, nie tylko binarki.

Praktyczne konsekwencje / ryzyko

Największe ryzyka dla organizacji (szczególnie MENA, ale TTP są „przenośne” geograficznie):

  • Szybkie uzyskanie zdalnej kontroli (shell/transfer plików/RMM typu AnyDesk).
  • Trudniejsza detekcja dzięki elementom anty-analizy, walidacji użytkownika i wykonywaniu w pamięci (GhostFetch).
  • Ryzyko kradzieży danych uwierzytelniających i rozbudowy dostępu w sieci (wpisuje się w znane zachowania MuddyWater; w innych kampaniach widziano moduły nastawione na credential theft).
  • Zwiększona „zwinność” operatorów: gdy 1st stage potrafi dociągać kolejne payloady, kampania może zmieniać cel i funkcje bez ponownego „dowożenia” maila.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC / Threat Hunting

  • Poluj na drzewo procesów: EXCEL.EXE/WINWORD.EXE → nietypowe uruchomienia skryptów/loaderów → połączenia sieciowe do nowych domen / nietypowe beacony. (Makra jako trigger).
  • Monitoruj instalację i użycie AnyDesk w środowisku: świeże instalacje, uruchomienia z nietypowych ścieżek, połączenia wychodzące niespójne z polityką IT.
  • Szukaj oznak in-memory execution (telemetria EDR: anomalie w mapowaniach pamięci, nietypowe regiony wykonywalne, procesy Office inicjujące podejrzane wątki).
  • Rozważ reguły detekcji dla ruchu do wskazanej infrastruktury (np. codefusiontech[.]org), z uwzględnieniem, że domeny mogą rotować.

Dla IT / Security Engineering

  • Domyślnie blokuj makra w dokumentach z internetu (lub wymuś podpisywanie makr i allowlisting). To nadal kluczowy punkt zapalny w tym łańcuchu.
  • Ogranicz możliwość uruchamiania zdalnych narzędzi administracyjnych (RMM) do zatwierdzonych przypadków; w innych kampaniach MuddyWater nadużywał legalnych narzędzi do zdalnego zarządzania.
  • Wdroż policyjne „guardrails” dla PowerShell (Constrained Language Mode tam, gdzie realne; logging: Script Block + Module; AMSI), bo MuddyWater historycznie często „dogrywa” działania skryptami i LOLBins.

Dla IR / incident response

  • Jeśli podejrzewasz kompromitację: izoluj host, zabezpiecz obrazy pamięci (ważne przy in-memory), zbierz artefakty Office (załączniki, strefa Mark-of-the-Web), przeanalizuj historię uruchomień AnyDesk i nietypowe wpisy trwałości.

Różnice / porównania z innymi przypadkami

  • Operation Olalampo vs. wcześniejsze backdoory/łańcuchy: tu mocno wybija się zestaw 1st-stage/2nd-stage (GhostFetch → GhostBackDoor) oraz tor HTTP_VIP kończący się AnyDesk, co jest pragmatyczne: szybki zdalny dostęp bez pisania wszystkiego od zera.
  • Ewolucja ku Rust: CHAR (Olalampo) wpisuje się w szerszy trend, gdzie MuddyWater i inne grupy sięgają po Rust dla bardziej „inżynieryjnych”, modularnych implantów. W styczniu 2026 opisywano również kampanię z rustowym implantem (RustyWater) dowożonym spear-phishingiem.
  • Kreatywne techniki obrony przed analizą: ESET opisywał loader (Fooder) maskowany motywem „Snake” oraz nietypowe podejście do opóźnień i kryptografii – co sugeruje, że MuddyWater testuje sposoby na utrudnianie sandboxingu i automatycznej analizy.

Podsumowanie / kluczowe wnioski

Operation Olalampo pokazuje MuddyWater w formie „produkcyjnej”: sprawdzony phishing + dokumenty Office, ale z coraz lepszym doskonaleniem pierwszych etapów (profilowanie, anty-analiza, in-memory) oraz wygodnym dowożeniem zdalnej kontroli (AnyDesk) i modułowych backdoorów (GhostBackDoor, CHAR). Dla obrony najważniejsze jest domknięcie „okna makr”, konsekwentny monitoring narzędzi zdalnego dostępu oraz polowanie na anomalie zachowania procesów Office i nietypową telemetrię pamięci.

Źródła / bibliografia

  1. The Hacker News – opis kampanii i komponentów (GhostFetch, GhostBackDoor, HTTP_VIP, CHAR, AnyDesk) (The Hacker News)
  2. Group-IB – pełna analiza Operation Olalampo, Telegram C2, odkrycia techniczne (Group-IB)
  3. Help Net Security (na bazie ESET) – kontekst ewolucji narzędzi MuddyWater, loader Fooder/MuddyViper, RMM (Help Net Security)
  4. Kudelski Security Research – TTP MuddyWater, kontekst initial access (phishing + exploity), living-off-the-land (kudelskisecurity.com)
  5. CSO Online – wątek rustowych implantów i ewolucji toolingu MuddyWater (RustyWater) (CSO Online)

Pastebin jako wektor oszustwa: komentarze promują atak ClickFix z JavaScriptem, który przechwytuje swapy krypto

Wprowadzenie do problemu / definicja luki

W połowie lutego 2026 zaobserwowano kampanię, w której napastnicy wykorzystują komentarze pod wpisami na Pastebin jako kanał dystrybucji instrukcji prowadzących do kradzieży kryptowalut. Mechanizm jest podstępny: ofiara dostaje „poradnik arbitrażowy”, który rzekomo pozwala zarobić na błędzie w wycenie swapów, a w praktyce nakłania do samodzielnego uruchomienia złośliwego JavaScriptu w przeglądarce. To wariant techniki ClickFix – czyli socjotechniki, gdzie atakujący „wkłada ofierze w ręce” krok po kroku działania, które same realizują kompromitację.

W tym przypadku nie mówimy o klasycznym pobraniu malware na system, tylko o przejęciu logiki działania strony swapowej w kontekście bieżącej sesji, tak aby podmienić adres depozytowy i przekierować środki do portfeli atakującego.

W skrócie

  • Atak jest promowany masowo w komentarzach na Pastebin i kieruje na „dokumentację wycieku”/„metodę zysku”.
  • Ofiara trafia m.in. na dokument (Google Docs) opisujący rzekomy „profit method” dla Swapzone/ChangeNOW.
  • Instrukcja nakazuje wkleić do paska adresu kod uruchamiany przez schemat javascript:.
  • Wstrzyknięty, mocno zaciemniony skrypt ma nadpisywać elementy aplikacji webowej i podmieniać adresy BTC (oraz manipulować wartościami/ofertami), by wyglądało to jak działający „arbitraż”.
  • To rzadki (i ważny) zwrot: ClickFix użyty do modyfikacji działania strony w przeglądarce, a nie do uruchamiania poleceń systemowych.

Kontekst / historia / powiązania

ClickFix jest obserwowany co najmniej od 2024 roku jako rosnąca rodzina „ataków z instrukcją naprawy”, gdzie przestępcy podszywają się pod pomoc techniczną, weryfikację bezpieczeństwa, „fix” błędu w przeglądarce itp., a następnie każą ofierze wykonać komendy (np. PowerShell) lub kliknięcia, które same omijają część zabezpieczeń. Microsoft opisywał tę technikę jako świadome dołożenie interakcji użytkownika, aby wyślizgnąć się spod automatycznych detekcji.

Z kolei sektorowe ostrzeżenia (np. HC3) zwracały uwagę, że ClickFix bazuje na wiarygodnie wyglądających komunikatach i presji, by „szybko naprawić problem”, a skutkiem bywa uruchomienie szkodliwych skryptów/poleceń.

Nowość w kampanii z lutego 2026 polega na tym, że „fix” nie instaluje (bezpośrednio) złośliwego programu w systemie, tylko przestawia transakcję w webowym interfejsie w momencie wykonywania swapu.

Analiza techniczna / szczegóły luki

1) Wejście: komentarze Pastebin → link pośredni → dokument „instrukcja zysku”

Atakujący przeglądają wpisy na Pastebin i zostawiają komentarze promujące „wyciek” oraz obiecujące wysokie zyski (np. kilka/kilkanaście tysięcy USD w parę dni). Link prowadzi do hostingu z przekierowaniem, a dalej do dokumentu typu Google Docs podszywającego się pod poradnik wykorzystania rzekomego błędu w przepływie kursów między usługami (Swapzone/ChangeNOW).

2) Kluczowy trik: uruchomienie kodu przez javascript: w pasku adresu

„Poradnik” każe ofierze wkleić fragment kodu tak, aby został wykonany w kontekście aktualnie otwartej strony swapowej. Technicznie wykorzystuje to schemat javascript:, czyli mechanizm URIs, w którym „nawigacja” skutkuje wykonaniem kodu JavaScript. MDN wprost ostrzega, że używanie javascript: jest odradzane, bo może prowadzić do wykonania arbitralnego kodu.

3) Łańcuch ładunków: loader → obfuskowany payload → web-inject

Z obserwacji wynika, że pierwszy skrypt doładowuje kolejny etap (payload) i wstrzykuje go w stronę, „podmieniając” elementy odpowiedzialne za proces swapu (opisano m.in. nadpisanie legalnego komponentu aplikacji webowej). Następnie atak:

  • podmienia adres depozytowy BTC na jeden z adresów kontrolowanych przez napastnika (losowany z listy),
  • oraz modyfikuje wyświetlane wartości/oferty, by ofiara miała wrażenie, że „metoda” faktycznie daje przewagę kursową.

To ważny aspekt psychologiczny: nie tylko kradzież, ale też „scenografia” potwierdzająca skuteczność rzekomego arbitrażu.

4) Dlaczego to działa?

Bo użytkownik sam wykonuje kod w kontekście zaufanej domeny, w trakcie realnej sesji. W efekcie:

  • UI wygląda znajomo,
  • ofiara „widzi” swój swap,
  • a krytyczny element (adres depozytowy) jest już podmieniony.

Praktyczne konsekwencje / ryzyko

  • Nieodwracalność: transakcje BTC (i wielu innych kryptowalut) są w praktyce nieodwracalne – po wysłaniu środków na zły adres odzyskanie ich jest skrajnie trudne lub niemożliwe.
  • Ryzyko dla użytkowników i helpdesków: ofiara często zgłasza „bug w swapie” dopiero po fakcie – a problem nie leży po stronie giełdy, tylko w lokalnym web-inject’cie uruchomionym w przeglądarce.
  • Ryzyko dla firm: pracownicy wykonujący swapy z urządzeń służbowych (lub w środowiskach z danymi firmowymi) mogą dodatkowo narazić organizację na wtórne skutki (np. ekspozycję danych sesyjnych/przeglądarkowych, jeśli kampania ewoluuje).
  • Skalowalność: dystrybucja przez komentarze i dokumenty „poradnikowe” jest tania i masowa – a obietnica szybkiego zysku znacząco zwiększa konwersję.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (SOC/IT może to komunikować jako „security advisory”)

  1. Nigdy nie uruchamiaj kodu w pasku adresu (ani javascript:, ani poleceń „do wklejenia”), nawet jeśli pochodzi z dokumentu „instruktażowego”.
  2. Jeśli korzystasz z agregatorów swapów: weryfikuj adres depozytowy „out-of-band” (np. porównanie z adresem w aplikacji portfela, skan QR z zaufanego źródła, whitelisty adresów).
  3. Traktuj jako czerwone flagi: „leak”, „exploit doc”, „profit method”, „arbitrage bug”, „13k w 2 dni”, „stary node/backend”.

Dla organizacji (polityki i detekcje)

  1. Edukacja pod ClickFix: krótkie szkolenia i komunikaty o schematach „naprawczych”, gdzie użytkownik jest proszony o wykonanie kroków/komend.
  2. Kontrola przeglądarek (MDM/Enterprise): rozważ hardening, rozszerzenia blokujące ryzykowne zachowania, monitorowanie nietypowych wzorców (np. anomalie w ruchu do hostów z surowym tekstem / krótkich redirectów w kontekście finansów).
  3. Procedura IR dla „crypto incidents”: gdy ktoś zgłosi błędny adres lub podejrzane zachowanie swapu – zbieraj artefakty (historia, rozszerzenia, logi przeglądarki, nagranie kroków), bo to może być web-inject uruchomiony lokalnie, a nie incydent po stronie dostawcy.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Klasyczne kampanie ClickFix zwykle kończą się uruchomieniem komend systemowych (PowerShell, skrypty), instalacją stealerów/RAT-ów itp. (to trend opisywany m.in. przez Microsoft oraz Unit 42).
W opisywanym incydencie punkt ciężkości przesunął się w stronę „webowego przejęcia transakcji”: zamiast infekować system, atakujący „podmienia” krytyczne dane w przeglądarce podczas operacji finansowej.

To istotna ewolucja: detekcje endpointowe mogą nie zobaczyć klasycznego droppera, a mimo to dochodzi do straty środków.

Podsumowanie / kluczowe wnioski

  • Kampania z 15 lutego 2026 pokazuje, że komentarze na platformach typu Pastebin mogą pełnić rolę skutecznego kanału dystrybucji socjotechniki.
  • ClickFix dojrzewa: coraz częściej nie „łamie” technologii, tylko łamie proces decyzyjny użytkownika.
  • Wariant z javascript: jest szczególnie groźny dla krypto, bo umożliwia manipulację w ramach zaufanej sesji i podmianę adresów depozytowych bez „klasycznej infekcji”.
  • Najskuteczniejsze zabezpieczenie to połączenie: twardych zasad (nie uruchamiamy kodu z poradników) + weryfikacji adresu przed wysyłką + świadomości ClickFix.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii „Pastebin comments push ClickFix JavaScript attack to hijack crypto swaps” (15.02.2026). (BleepingComputer)
  2. Microsoft Security Blog – analiza techniki ClickFix (21.08.2025). (microsoft.com)
  3. HHS HC3 – „ClickFix Attacks” (Sector Alert, 29.10.2024). (HHS.gov)
  4. Palo Alto Networks Unit 42 – materiał o rosnących kampaniach ClickFix (10.07.2025). (Unit 42)
  5. MDN (Mozilla) – dokumentacja schematu javascript: i ryzyk bezpieczeństwa (01.07.2025). (developer.mozilla.org)

Nowy wariant ClickFix: nslookup i DNS jako kanał dostarczania ładunku PowerShell (ModeloRAT)

Wprowadzenie do problemu / definicja luki

ClickFix to technika socjotechniczna, w której ofiara — „naprawiając problem” (fałszywy błąd, weryfikację CAPTCHA, rzekomą aktualizację) — sama uruchamia polecenia prowadzące do infekcji. Nowość w opisywanej kampanii polega na tym, że kolejne etapy nie są pobierane klasycznym HTTP/HTTPS, lecz… przez DNS, z użyciem wbudowanego narzędzia nslookup.

W skrócie

  • Atakujący nakłaniają użytkownika do uruchomienia komendy w oknie Windows Run.
  • Komenda wykonuje niestandardowe zapytanie DNS do kontrolowanego przez napastnika serwera DNS i parsuje pole „Name:” z odpowiedzi, by uzyskać kolejny ładunek (PowerShell), który jest następnie wykonywany.
  • Łańcuch infekcji prowadzi finalnie do instalacji ModeloRAT (RAT napisany w Pythonie), z mechanizmami rozpoznania i utrzymania się w systemie.

Kontekst / historia / powiązania

ClickFix nie jest „jedną rodziną malware”, tylko powtarzalnym wzorcem nadużycia interakcji użytkownika: ofiara uruchamia polecenie, bo wierzy, że to element weryfikacji lub naprawy. Microsoft i inni dostawcy opisywali już wcześniej ClickFix jako łańcuch, który często kończy się infostealerami, RAT-ami lub loaderami i chętnie korzysta z LOLBins (np. PowerShell) w modelu „fileless”.

Proofpoint pokazywał, że ClickFix szybko rozlał się po ekosystemie zagrożeń (różni aktorzy, różne przynęty, wspólny mechanizm „skopiuj-wklej-uruchom”), a kampanie kończyły się m.in. AsyncRAT, DarkGate, Lumma Stealer czy NetSupport.

Analiza techniczna / szczegóły luki

1) „Dostarczenie” polecenia i uruchomienie nslookup

W opisywanym wariancie użytkownik dostaje instrukcję uruchomienia polecenia w Windows Run. Polecenie uruchamia nslookup tak, aby zapytać konkretny, zewnętrzny serwer DNS (zamiast systemowego resolvera). W materiale wskazano przykład infrastruktury DNS napastnika (adres IP serwera DNS) oraz mechanikę: odpowiedź DNS jest „spreparowana” tak, by zawierała kolejny etap w polu NAME:.

2) DNS jako „lekki staging”

Kluczowe jest to, że DNS służy tu jako kanał etapowania: ofiara najpierw wykonuje zapytanie DNS, a dopiero potem system uruchamia PowerShell pozyskany z odpowiedzi. To utrudnia pracę obronie opartej wyłącznie o filtrowanie web/URL i proxy HTTP.

3) Kolejne etapy: ZIP → Python → VBS → ModeloRAT

W dalszej części łańcucha (wg opisu bazującego na obserwacjach Microsoft) następuje pobranie archiwum ZIP z zewnętrznej infrastruktury, uruchomienie skryptu w Pythonie (rekonesans, discovery), a następnie zrzut/uruchomienie VBScript i finalnie ModeloRAT zapewniający zdalną kontrolę.

4) Co tu jest sprytne z perspektywy detekcji?

DNS zwykle jest dozwolony w egress, a nslookup.exe to narzędzie administracyjne. To tworzy „szarą strefę” — aktywność może wyglądać jak troubleshooting, dopóki nie spojrzymy na kontekst procesu (np. cmd.exe/Run → nslookup.exe → uruchomienie poleceń/PowerShell) i cechy zapytań (nietypowy serwer, nietypowe typy odpowiedzi, podejrzane payloady w danych odpowiedzi).

Praktyczne konsekwencje / ryzyko

  • Zwiększona szansa obejścia kontroli webowych: jeśli organizacja mocno filtruje HTTP/HTTPS, a DNS traktuje „po macoszemu”, kanał DNS może stać się skutecznym stagingiem.
  • RAT w sieci = ryzyko pełnej kompromitacji: ModeloRAT jako narzędzie zdalnego dostępu może posłużyć do kradzieży danych, rozpoznania, ruchu bocznego i dalszego dropowania ładunków.
  • Trudniejsze dochodzenie: część „pobrania” dzieje się w DNS, więc bez logów DNS (i korelacji z endpointem) analiza incydentu jest istotnie utrudniona.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–72h)

  1. Wymuś DNS tylko przez zaufane resolvery
    • Blokuj bezpośredni DNS (UDP/TCP 53) do Internetu z sieci użytkowników, jeśli możesz; pozwól tylko na DNS do twoich resolverów / zabezpieczonego forwardera.
  2. Wykrywanie nslookup z parametrem serwera / nietypowym wzorcem użycia
    • Alarmuj na nslookup.exe wywołany przez cmd.exe/explorer.exe w kontekście Run + szybkie następstwo uruchomienia PowerShell.
    • Skorzystaj z gotowych reguł detekcji pod nadużycia DNS/nslookup (np. podejrzanie częste wywołania).
  3. Zbieraj i koreluj logi DNS + EDR
    • Bez telemetrii DNS możesz nie zobaczyć kluczowego elementu stagingu.

Wzmocnienie średnioterminowe (1–4 tygodnie)

  1. Ogranicz PowerShell tam, gdzie się da
    • Constrained Language Mode / polityki aplikacyjne (AppLocker/WDAC), ASR rules, wzmacnianie AMSI/Defender w środowiskach Windows — ClickFix często kończy się PowerShellem.
  2. Szkolenia i „bezpieczniki” UX
    • W ClickFix „security boundary” jest użytkownik. Ucz: „nie uruchamiam poleceń z okienek ‘naprawczych’, CAPTCHA i pseudo-aktualizacji”.

Różnice / porównania z innymi przypadkami

  • Klasyczne ClickFix: często kończy się poleceniem PowerShell, które pobiera payload po HTTP/HTTPS.
  • Ten wariant: DNS jest użyty jako kanał etapowania/„sygnalizacji” — a nslookup staje się narzędziem do pobrania kolejnego polecenia z odpowiedzi DNS. To zmienia priorytety obrony: same kontrole webowe nie wystarczą, jeśli DNS nie jest monitorowany i ograniczany.

Podsumowanie / kluczowe wnioski

  • ClickFix dalej ewoluuje: teraz nie tylko „uruchom PowerShell”, ale też „uruchom nslookup na zewnętrzny DNS i wykonaj to, co wróci”.
  • DNS jako staging jest groźny, bo zwykle jest dozwolony i słabiej inspekcjonowany.
  • Obrona wymaga połączenia: kontrola egress DNS + telemetria DNS + EDR na endpointach + edukacja użytkowników.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii DNS/nslookup i mechaniki „Name:” → PowerShell (BleepingComputer)
  2. Malwarebytes – omówienie łańcucha ZIP → Python → VBS → ModeloRAT (Malwarebytes)
  3. Microsoft Security Blog – tło i typowy łańcuch ClickFix (microsoft.com)
  4. Proofpoint – szerszy kontekst rozprzestrzenienia ClickFix i typowe przynęty/payloady (Proofpoint)
  5. Elastic – referencje i podejście detekcyjne dla nadużyć DNS/nslookup (Elastic)

Google łączy rosyjsko-powiązanego aktora z kampaniami CANFAIL przeciw Ukrainie. W tle: phishing, JavaScript (*.pdf.js) i „LLM-generated lures”

Wprowadzenie do problemu / definicja luki

W połowie lutego 2026 r. Google Threat Intelligence Group (GTIG) opisało wcześniej nieudokumentowanego aktora zagrożeń, którego działania wiąże z kampaniami wymierzonymi w ukraińskie organizacje i dystrybucją malware’u nazwanego CANFAIL. To istotne z dwóch powodów:

  1. Sektorowe ukierunkowanie – cele obejmują obszary krytyczne dla państwa (obrona, administracja, energetyka).
  2. Ewolucja TTP – GTIG zauważa, że aktor zaczął wykorzystywać LLM do rozpoznania, tworzenia przynęt socjotechnicznych i wsparcia działań po kompromitacji.

W praktyce oznacza to bardziej „skalowalny” phishing (lepsza jakość treści, dopasowanie do branży/regionu) nawet u grup, które nie mają zasobów porównywalnych z topowymi rosyjskimi APT.

W skrócie

  • GTIG przypisuje kampanie z CANFAIL nowemu aktorowi, prawdopodobnie powiązanemu z rosyjskimi służbami.
  • Główne cele: obrona, wojsko, administracja, energetyka w Ukrainie; dodatkowo rosnące zainteresowanie aerospace, firmami powiązanymi z dronami, badaniami nuklearnymi/chemicznymi oraz organizacjami humanitarnymi i monitorującymi konflikt.
  • Wektor: phishing podszywający się m.in. pod ukraińskie podmioty energetyczne; w kampanii pojawiają się linki do Google Drive z archiwum RAR zawierającym CANFAIL.
  • Plik jest maskowany jako PDF poprzez podwójne rozszerzenie typu *.pdf.js.
  • CANFAIL to zaciemniony JavaScript, uruchamiający łańcuch z PowerShell, w tym etap pobierający i wykonujący dropper „memory-only”.
  • GTIG łączy aktora również z kampanią PhantomCaptcha, opisaną w 2025 r. przez SentinelLabs, wykorzystującą technikę ClickFix i końcowy ładunek w postaci WebSocket RAT.

Kontekst / historia / powiązania

GTIG umieszcza tę aktywność w szerszym krajobrazie zagrożeń wobec defense industrial base (DIB) – gdzie obserwuje się zarówno klasyczne włamania w infrastrukturę organizacji, jak i coraz częstsze ataki „na ludzi” (pracowników, procesy rekrutacyjne, prywatne skrzynki), co utrudnia detekcję po stronie EDR/korporacyjnego SOC.

Wątek PhantomCaptcha jest tu szczególnie ważny, bo pokazuje, że (1) celowanie w ekosystem wsparcia Ukrainy i (2) social engineering „na klik” potrafią być bardzo dopracowane operacyjnie – SentinelLabs opisywało kampanię aktywną zaledwie jeden dzień, ale przygotowywaną miesiącami.

Analiza techniczna / szczegóły

1. Initial access: phishing + dopasowane listy adresowe

GTIG wskazuje na kampanie phishingowe, w których aktor:

  • podszywa się pod krajowe i lokalne organizacje energetyczne w Ukrainie w celu przejęcia skrzynek (organizacyjnych i prywatnych),
  • potrafi też udawać rumuńską firmę energetyczną współpracującą z klientami w Ukrainie, a wątek operacyjny dotyka także Rumunii i rozpoznania w Mołdawii.
  • buduje listy adresowe dopasowane do regionów i branż, co zwiększa trafność i wiarygodność kampanii.

2. Przynęty generowane przez LLM

Najbardziej „nowoczesnym” elementem jest to, że GTIG zauważa użycie LLM do:

  • rozpoznania i profilowania celów,
  • tworzenia treści przynęt (lures),
  • uzyskiwania odpowiedzi na podstawowe pytania techniczne dot. działań po kompromitacji oraz budowy C2.

To nie musi oznaczać „AI-malware”, ale w praktyce znacząco podnosi jakość socjotechniki i skraca czas przygotowania kampanii.

3. Delivery: Google Drive → RAR → *.pdf.js

W łańcuchu dostarczenia pojawia się:

  • link do Google Drive,
  • archiwum RAR,
  • plik udający dokument PDF dzięki podwójnemu rozszerzeniu *.pdf.js.

To klasyczny trik na zmylenie użytkownika (i czasem pobieżnej kontroli), bo ikona/„nazwa” sugerują PDF, a faktycznie uruchamiany jest skrypt.

4. CANFAIL: zaciemniony JavaScript → PowerShell → dropper w pamięci

GTIG opisuje CANFAIL jako:

  • obfuscated JavaScript malware,
  • którego rolą jest uruchomienie PowerShell,
  • a dalej pobranie i wykonanie memory-only PowerShell droppera (czyli bez klasycznego zapisu „payloadu” na dysk),
  • równolegle z wyświetleniem fałszywego komunikatu „error”, który ma obniżyć czujność ofiary.

Dlaczego to groźne? Etapy „memory-only” utrudniają analizę artefaktów na dysku i mogą ograniczać widoczność dla części narzędzi, jeśli telemetryka PowerShell/AMSI/logowanie jest słabe lub wyłączone.

5. Powiązanie z PhantomCaptcha (ClickFix + WebSocket RAT)

GTIG łączy aktora także z kampanią PhantomCaptcha, w której:

  • użytkownik jest wciągany w „instrukcję” typu ClickFix (np. skopiuj/uruchom komendę PowerShell),
  • a finalny payload to WebSocket RAT umożliwiający zdalne polecenia i eksfiltrację danych.

To ciekawe zestawienie: CANFAIL to „klasyczne” dostarczenie przez archiwum i plik-przynętę, a PhantomCaptcha to bardziej interaktywny social engineering, ale cel (kompromitacja) i profil ofiar pozostają spójne.

Praktyczne konsekwencje / ryzyko

  1. Wzrost skuteczności phishingu dzięki LLM: lepsza polszczyzna/angielski, formalny styl, dopasowanie do procedur instytucji, szybsze tworzenie wariantów.
  2. Ryzyko przejęcia skrzynek e-mail (organizacyjnych i prywatnych) jako punktu startowego do dalszych ataków (BEC, lateral movement, podszycia w korespondencji).
  3. Trudniejsza detekcja etapów „in-memory” i nadużyć PowerShell, zwłaszcza w środowiskach z ograniczonym logowaniem.
  4. Szeroki profil celów (od energetyki po organizacje humanitarne) zwiększa prawdopodobieństwo, że skutki będą „łańcuchowe” – kompromitacja jednego partnera potrafi otworzyć drogę do kolejnych.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które mają sens niezależnie od tego, czy jesteś bezpośrednim celem (Ukraina), czy partnerem/kontrahentem w regionie:

E-mail i przeglądanie plików

  • Blokuj lub oznaczaj pliki z podwójnymi rozszerzeniami oraz nietypowymi kombinacjami typu *.pdf.js; rozważ reguły w bramkach e-mail.
  • Ogranicz uruchamianie skryptów z archiwów (RAR/ZIP) i wdrażaj polityki „Mark of the Web”/ASR tam, gdzie to możliwe.

Telemetria i detekcja

  • Włącz/utwardź logowanie PowerShell (Script Block Logging, Module Logging) oraz integrację AMSI – to realnie zwiększa szanse wykrycia łańcuchów JS→PS.
  • Szukaj korelacji: procesy skryptowe + pobrania z chmur plikowych (np. dyski online) + nietypowe komunikaty „error” w tym samym czasie.

Kontrola tożsamości

  • Wymuś MFA na poczcie oraz rozważ odporne metody (FIDO2/WebAuthn) dla kont uprzywilejowanych.
  • Monitoruj anomalie logowania, reguły przekierowań w skrzynkach, OAuth consent i aplikacje pocztowe.

Odporność na ClickFix

  • Przeszkol użytkowników, że „CAPTCHA/strona ochrony” nigdy nie powinna wymagać uruchamiania komend w PowerShell/Terminalu. PhantomCaptcha pokazała, że to działa, gdy jest dobrze opakowane.

Różnice / porównania z innymi przypadkami

CANFAIL vs PhantomCaptcha/ClickFix:

  • Wektor:
    • CANFAIL: archiwum RAR + plik *.pdf.js (podszycie pod dokument).
    • PhantomCaptcha: przynęta prowadzi do „instrukcji” uruchomienia komendy (ClickFix) i końcowo RAT.
  • Wspólny mianownik:
    • dominacja socjotechniki i korzystanie z „zaufanych” elementów (np. usługi chmurowe, wiarygodne szablony, formalny język),
    • profil ofiar związany z Ukrainą i jej ekosystemem wsparcia/obrony.
  • Trend:
    • przesunięcie akcentu w stronę działań, które omijają klasyczną widoczność enterprise (prywatne konta, indywidualne cele, procesy HR).

Podsumowanie / kluczowe wnioski

CANFAIL to kolejny przykład tego, że nawet aktor oceniany jako „mniej zaawansowany” może szybko zwiększać skuteczność dzięki LLM: lepsze rozpoznanie, lepsze treści phishingowe, szybsze iteracje kampanii.
Technicznie łańcuch jest pragmatyczny: RAR → *.pdf.js → JS → PowerShell → memory-only dropper, a w tle podobna filozofia „user-execution” jak w ClickFix.
Dla obrońców oznacza to konieczność połączenia: (1) higieny pocztowej i świadomości użytkowników, (2) solidnej telemetrii PowerShell, (3) twardej kontroli tożsamości.

Źródła / bibliografia

  • The Hacker News: opis aktora i łańcucha CANFAIL (13 lutego 2026). (The Hacker News)
  • Google Cloud Blog (GTIG): „Beyond the Battlefield: Threats to the Defense Industrial Base” (10 lutego 2026). (Google Cloud)
  • SentinelOne SentinelLabs: raport „PhantomCaptcha: Multi-Stage WebSocket RAT…” (22 października 2025). (SentinelOne)
  • BleepingComputer: omówienie PhantomCaptcha/ClickFix (22 października 2025). (BleepingComputer)
  • The Record: tło operacyjne i cele PhantomCaptcha (22 października 2025). (The Record from Recorded Future)

Claude „Artifacts” nadużywane do dystrybucji macOS infostealerów w ataku ClickFix

Wprowadzenie do problemu / definicja luki

Atakujący zaczęli wykorzystywać publicznie udostępniane „Artifacts” w Claude (Anthropic) jako element łańcucha infekcji w kampaniach ClickFix, kierując ofiary (macOS) do uruchomienia poleceń w Terminalu. To nie jest „luka” typu CVE w samym Claude, tylko nadużycie funkcji publikowania treści i wysokiej wiarygodności, jaką użytkownicy przypisują materiałom „wyglądającym na wygenerowane przez AI / poradnik”.

W skrócie

  • Kampania jest promowana m.in. przez reklamy Google i pozycjonowanie pod konkretne zapytania (np. narzędzia sieciowe lub macOS CLI).
  • Użytkownik trafia na publiczny Artifact Claude lub stronę podszywającą się pod Apple Support (np. artykuł na platformie blogowej), gdzie dostaje instrukcję wklejenia komendy do Terminala.
  • Wykonanie polecenia pobiera i uruchamia loader, który finalnie instaluje infostealera (w opisywanym przypadku: MacSync).
  • Skala: badacze raportują dziesiątki tysięcy wyświetleń złośliwych instrukcji (wskaźnik ekspozycji, niekoniecznie liczba skutecznych infekcji).

Kontekst / historia / powiązania

ClickFix to technika socjotechniczna, w której kluczowym „bypassem” jest wciągnięcie użytkownika w wykonanie komendy samodzielnie (np. Run/PowerShell na Windows albo Terminal na macOS). Z perspektywy obrony to istotne, bo część kontroli bezpieczeństwa widzi aktywność jako inicjowaną przez użytkownika, a nie klasyczny dropper.

W 2025–2026 obserwowano rozwój ClickFix w różnych wariantach: od prostych fałszywych CAPTCHA po bardziej wyrafinowane łańcuchy, np. z użyciem zaufanych komponentów systemu (LotL) na Windows.
Jednocześnie ekosystem macOS infostealerów rośnie — popularne rodziny (Atomic/AMOS, Poseidon, Cthulhu) są często dystrybuowane przez malvertising i „trojanizowane instalatory”, co dobrze pasuje do mechaniki ClickFix (reklama → landing → instrukcja → uruchomienie).

Analiza techniczna / szczegóły ataku

1) Wejście: reklamy i SEO pod „techniczne” zapytania

Badacze opisali scenariusz, w którym użytkownik szuka narzędzi lub porad dla macOS (np. resolver DNS, analizator miejsca na dysku, Homebrew), a w wynikach pojawia się promowany link prowadzący do:

  • publicznego Artifact Claude, albo
  • strony udającej wsparcie Apple.

2) Rdzeń ClickFix: komenda „naprawcza”

W obu wariantach użytkownik jest zachęcany do uruchomienia w Terminalu polecenia, którego efekt jest typowy dla downloaderów:

  • dekodowanie zakodowanej treści i wykonanie w powłoce (np. schemat „base64 → shell”), lub
  • pobranie treści przez narzędzie sieciowe i bezpośrednie przekazanie do interpretera (np. „curl → shell”).

Nie przytaczam pełnych komend 1:1, bo są to instrukcje wykonawcze dla złośliwego łańcucha — ale ważne jest, że oba wzorce są klasycznymi „red flagami” w środowiskach macOS/Unix.

3) Payload: MacSync infostealer i AppleScript jako „silnik kradzieży”

Po uruchomieniu, łańcuch pobiera loader dla MacSync. Według opisu kampanii:

  • komunikacja z C2 ma być realizowana z użyciem osadzonych tokenów/kluczy oraz z podszywaniem się user-agentem przeglądarki,
  • a właściwe kradzieże danych mają być realizowane przez osascript (AppleScript), obejmując m.in. keychain, dane przeglądarek i portfele krypto,
  • dane są pakowane do archiwum w /tmp/…zip, a następnie wysyłane do C2 metodą HTTP POST, z mechanizmem retry i „sprzątaniem” po udanej eksfiltracji.

4) Wspólna infrastruktura

Badacze wskazują, że oba warianty pobierają drugi etap z tego samego adresu C2, co sugeruje jednego operatora/kampanię (lub przynajmniej współdzieloną infrastrukturę).

Praktyczne konsekwencje / ryzyko

  1. Ryzyko kradzieży tożsamości i przejęć kont – infostealery celują w hasła/cookies/sesje przeglądarkowe, dane w pęku kluczy, komunikatory i portfele.
  2. Ryzyko wtórnej eskalacji – skradzione sesje (SSO/VPN), tokeny i klucze API często stają się wejściem do sieci firmowej lub chmury. (To wprost wynika z typowych następstw incydentów infostealerowych; sama kampania opisuje komponent C2 i eksfiltrację danych).
  3. Nowy „wektor wiarygodności” – publiczne treści hostowane na rozpoznawalnej domenie usługi AI mogą wyglądać „bezpieczniej” niż przypadkowy landing, a jednocześnie zawierają gotowe instrukcje do samodzielnego uruchomienia.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i helpdesku (macOS)

  • Zasada zero-trustu dla komend: nie uruchamiaj w Terminalu poleceń z reklamy/wyników wyszukiwania/poradnika, jeśli nie rozumiesz dokładnie każdego fragmentu (zwłaszcza wzorców „pobierz i wykonaj”, „base64 → shell”).
  • Weryfikuj źródło narzędzi: Homebrew i narzędzia systemowe pobieraj z oficjalnych stron/projektów, nie z „poradników” z reklam.
  • W razie podejrzenia wykonania komendy: odłącz urządzenie od sieci, zabezpiecz logi (Unified Logs), sprawdź nietypowe procesy/uruchomienia osascript, przeanalizuj ruch wychodzący i rozważ reset tokenów/sesji oraz zmianę haseł na czystym urządzeniu.

Dla SOC/Blue Team

  • Detekcja zachowań: reguły/alerty na nietypowe uruchomienia osascript w kontekście pobierania treści z sieci i dostępu do artefaktów przeglądarek/keychain.
  • Kontrola egress: monitorowanie POST/egress do świeżych domen, korelacja z procesami powłoki i osascript.
  • Higiena reklam i wyszukiwania: w środowiskach firmowych ogranicz/filtruj malvertising, rozważ polityki przeglądarkowe i DNS security. (To spójne z obserwacją, że kampania startuje z wyników Google i reklam).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • ClickFix na Windows vs macOS: na Windows coraz częściej pojawiają się warianty „living-off-the-land”, gdzie wykonanie jest proxy’owane przez zaufany komponent (np. skrypty/komponenty Microsoft), aby ominąć proste detekcje „PowerShell.exe”. Na macOS nacisk bywa kładziony na shell + AppleScript (osascript) jako warstwę kradzieży.
  • Rola malvertising: Unit 42 zwraca uwagę, że macOS infostealery są często dystrybuowane przez reklamy i fałszywe instalatory — tutaj malvertising jest połączony z „poradnikiem” w Artifact, co zwiększa perswazyjność.
  • „Hosted trust”: to kolejny przykład, że atakujący testują różne platformy (AI, blogi, serwisy udostępniania treści) jako „nośniki” instrukcji ClickFix, bo łatwo skalują zasięg i utrudniają blokowanie.

Podsumowanie / kluczowe wnioski

  • To kampania ClickFix, w której „payloadem” jest instrukcja — a nie exploit: użytkownik sam uruchamia łańcuch w Terminalu.
  • „Claude Artifacts” działają tu jako wiarygodnie wyglądający hosting treści (publiczny link na domenie usługi AI), wzmacniany przez reklamy i SEO.
  • Na macOS w centrum technicznym stoi kombinacja shell → pobranie loadera → osascript do kradzieży danych i eksfiltracji do C2.
  • Obrona powinna łączyć edukację (nie uruchamiaj niezweryfikowanych komend), kontrolę reklam/wyszukiwania oraz detekcję zachowań osascript/shell + egress.

Źródła / bibliografia

  1. BleepingComputer — opis kampanii: Claude Artifacts + Google Ads → ClickFix → MacSync infostealer (13 lutego 2026). (BleepingComputer)
  2. Microsoft Security Blog — analiza techniki ClickFix i jej łańcucha ataku (21 sierpnia 2025). (Microsoft)
  3. Unit 42 (Palo Alto Networks) — przegląd rosnącego zagrożenia macOS infostealerami i typowych TTP (4 lutego 2025). (Unit 42)
  4. InfoQ — kontekst funkcji Claude Artifacts i ich roli jako przestrzeni do udostępniania/organizacji „wytworów” AI (30 czerwca 2025). (InfoQ)
  5. The Hacker News — przykład ewolucji ClickFix (fałszywe CAPTCHA + zaufane komponenty Windows/App-V) (27 stycznia 2026). (The Hacker News)

Luka w Notatniku Windows 11: kliknięcie linku Markdown mogło uruchamiać pliki „po cichu” (CVE-2026-20841)

Wprowadzenie do problemu / definicja luki

Microsoft załatał podatność typu Remote Code Execution (RCE) w nowoczesnym Notatniku Windows 11, związaną z obsługą Markdown. Luka polegała na tym, że po otwarciu pliku .md w trybie Markdown i kliknięciu spreparowanego odnośnika, Notatnik mógł uruchomić wskazany program lub zasób bez typowych ostrzeżeń bezpieczeństwa Windows.

W skrócie

  • Identyfikator: CVE-2026-20841 (Windows Notepad App).
  • Klasa błędu: Microsoft/NVD opisują to jako command injection / niewłaściwe neutralizowanie elementów specjalnych w poleceniu (CWE-77).
  • Wektor ataku wg NVD: AV:N/AC:L/PR:N/UI:R — wymagane jest działanie użytkownika (kliknięcie).
  • Praktyka ataku: linki Markdown mogły wskazywać m.in. na file:// (lokalne pliki wykonywalne) lub nietypowe URI (np. ms-appinstaller://).
  • Microsoft wdrożył poprawkę w ramach aktualizacji z lutego 2026 (Patch Tuesday).

Kontekst / historia / powiązania

Źródłem problemu była „modernizacja” Notatnika w Windows 11: aplikacja przestała być wyłącznie prostym edytorem tekstu i zyskała m.in. renderowanie Markdown oraz klikalne linki.
W szerszym obrazie to kolejny przykład, jak „pozornie niewinne” funkcje (renderowanie, podgląd, linki, protokoły) potrafią stworzyć nowe ścieżki ataku w aplikacjach, które użytkownicy traktują jako „bezpieczne z definicji”.

Analiza techniczna / szczegóły luki

Jak działał scenariusz nadużycia

  1. Atakujący dostarczał ofierze plik .md (np. przez phishing, załącznik, komunikator, repozytorium, share).
  2. Ofiara otwierała plik w Notatniku i przełączała/korzystała z widoku Markdown, gdzie link stawał się interaktywny.
  3. Po Ctrl+klik w link (tak opisały testy), Notatnik wywoływał obsługę „niezweryfikowanych” protokołów/URI i mógł doprowadzić do uruchomienia programu lub pobrania/wykonania zasobu zdalnego — bez oczekiwanego ostrzeżenia.

Co było szczególnie niebezpieczne

  • Możliwość wskazania plików wykonywalnych przez file:// lub użycia protokołów systemowych/instalacyjnych.
  • Potencjalny wariant z zdalnymi udziałami SMB, gdzie kliknięcie prowadziłoby do wykonania pliku z zasobu sieciowego bez typowego „tarcia” po stronie systemu.
  • Wykonanie następowało w kontekście uprawnień użytkownika (czyli dokładnie tyle, ile ma ofiara).

Co zmieniła poprawka

Według testów opisywanych przez BleepingComputer, Notatnik po poprawce zaczął wyświetlać ostrzeżenia dla linków niebędących http:// lub https://. Dotyczy to m.in. file:, ms-settings:, ms-appinstaller:, mailto:, ms-search:.

Praktyczne konsekwencje / ryzyko

To nie jest klasyczny „drive-by exploit” — nadal potrzebna jest interakcja użytkownika. Ale w praktyce:

  • Plik tekstowy/Markdown ma niski „próg podejrzaności” (ludzie chętnie go otwierają, żeby sprawdzić co jest w środku).
  • Link może wyglądać jak niewinny odnośnik typu „Otwórz logi” / „Instrukcja” / „Kliknij, aby naprawić”.
  • W środowiskach firmowych taka luka pasuje do łańcuchów ataku: phishing → dropper → kliknięcie → uruchomienie payloadu (zwłaszcza gdy atakujący ma już coś na dysku lub na udziale SMB).

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj Notatnik (Windows 11) — aplikacja zwykle aktualizuje się przez Microsoft Store, ale w organizacjach bywa to kontrolowane politykami. Upewnij się, że urządzenia nie są „zatrzymane” na starszych wersjach.
  2. Zablokuj/ogranicz nietypowe protokoły tam, gdzie to możliwe (np. politykami aplikacyjnymi/ASR, kontrolą protokołów, hardeningiem środowiska).
  3. Traktuj pliki .md jak dokumenty aktywne, jeśli pochodzą z zewnątrz: sandbox, podgląd bez klikania, skan AV/EDR, izolacja.
  4. Edukacja użytkowników: „Nie klikaj linków w plikach tekstowych/Markdown z maila/Teams/Slack, jeśli nie znasz źródła”.
  5. Monitoring: poluj na anomalie typu uruchomienia procesu pochodzące z Notatnika (np. notepad.exe → cmd.exe, powershell.exe, instalatory, binarki z udziałów sieciowych).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • To nie jest błąd w stylu „makr Office” — mechanizm jest prostszy, ale bazuje na podobnym założeniu: użytkownik ufa formatowi pliku i klika element interaktywny.
  • Warto też odróżnić „Notepad” od „Notepad++”: The Register zwraca uwagę na bliskość czasową dyskusji o problemach bezpieczeństwa w ekosystemie edytorów tekstu, ale są to różne produkty i różne wektory.

Podsumowanie / kluczowe wnioski

CVE-2026-20841 pokazuje klasyczny problem „rozszerzania prostych narzędzi”: gdy aplikacja do czytania tekstu zaczyna renderować treści i obsługiwać wiele protokołów, rośnie powierzchnia ataku. Luka w Notatniku Windows 11 umożliwiała uruchamianie plików (lokalnych lub zdalnych) po kliknięciu linku Markdown bez oczekiwanych ostrzeżeń, a poprawka dodaje dodatkowe monity dla nie-HTTP(S) URI. Najważniejsze działania to: aktualizacja, hardening protokołów/URI, procedury dla plików Markdown z zewnątrz i telemetria procesów potomnych z Notatnika.

Źródła / bibliografia

  • BleepingComputer — opis podatności i zachowania „bez ostrzeżeń”, przykłady URI oraz informacja o poprawce (ostrzeżenia dla nie-HTTP/S). (BleepingComputer)
  • NVD (NIST) — klasyfikacja, CVSS v3.1 vector oraz powiązanie z CWE-77 i odnośnik do MSRC. (NVD)
  • Rapid7 — kontekst Patch Tuesday (luty 2026) i przegląd podatności z tego wydania. (Rapid7)
  • The Register — szerszy kontekst i komentarz do „Markdown w Notatniku” oraz dyskusji o ryzykach w edytorach. (The Register)

Atakujący wykorzystują luki w SolarWinds Web Help Desk do wdrażania Velociraptora i tuneli Cloudflare

Wprowadzenie do problemu / definicja luki

SolarWinds Web Help Desk (WHD) to popularny system ITSM/ticketowy, często wystawiany (niestety) do internetu dla wygody administratorów. W lutym 2026 pojawiły się wiarygodne potwierdzenia aktywnego wykorzystywania krytycznych podatności w WHD do uzyskania zdalnego wykonania kodu bez uwierzytelnienia (unauthenticated RCE), a następnie do wdrażania legalnych narzędzi użytych „na opak” — m.in. Zoho/ManageEngine do zdalnego dostępu, Cloudflare Tunnel (cloudflared) do trwałego wejścia oraz Velociraptor jako kanału C2/operacji post-exploitation.

W skrócie

  • Co się dzieje: aktywna eksploatacja instancji SolarWinds WHD wystawionych do internetu.
  • Najważniejsza podatność: CVE-2025-40551 (deserializacja niezaufanych danych → RCE), dodana przez CISA do KEV z krótkim terminem remediacji dla agencji federalnych (USA).
  • Dodatkowo obserwowane/rozważane CVE: m.in. CVE-2025-26399 oraz CVE-2025-40536 (bypass kontroli bezpieczeństwa) – w zależności od kampanii i momentu włamania.
  • Po wejściu: szybkie wdrożenie narzędzi dual-use (Zoho/ManageEngine), tuneli Cloudflare oraz Velociraptora wykorzystywanego jako C2.
  • Rekomendacja nr 1: aktualizacja WHD do 2026.1 lub nowszej i odcięcie paneli/admina od internetu.

Kontekst / historia / powiązania

Na przełomie stycznia i lutego 2026 SolarWinds udostępnił poprawki dla pakietu podatności w WHD, w tym krytycznych problemów jak CVE-2025-40551 (deserializacja) oraz CVE-2025-40536 (bypass zabezpieczeń); badacze przypisują odkrycia m.in. do Horizon3.ai i watchTowr.
Równolegle Microsoft opisał przypadki wielostopniowych intruzji zaczynających się od eksploatacji internet-exposed WHD, kończących się ruchem lateralnym w stronę aktywów „high value” (włącznie z ryzykiem kompromitacji domeny).
Huntress natomiast pokazał „z bliska” realny łańcuch ataku z 7 lutego 2026, gdzie po wejściu atakujący natychmiast uruchomili wdrażanie narzędzi do utrzymania dostępu i sterowania środowiskiem.

Analiza techniczna / szczegóły luki

Jakie podatności są wykorzystywane?

  • CVE-2025-40551 – kluczowy wektor: błąd deserializacji niezaufanych danych, prowadzący do RCE bez logowania. Status “Known Exploited” (KEV) sugeruje realne, potwierdzone użycie w atakach.
  • CVE-2025-40536 – opisywany jako security control bypass w zestawie styczniowych poprawek.
  • CVE-2025-26399 – starsza podatność, która również pojawia się w obserwacjach branżowych dot. aktywnej eksploatacji; w części przypadków trudno jednoznacznie przypisać konkretny CVE, bo hosty bywały podatne jednocześnie na „stary” i „nowy” zestaw.

Typowy łańcuch ataku (na podstawie obserwacji incident response)

  1. Initial access: eksploatacja podatnej, wystawionej do internetu instancji WHD → uruchomienie poleceń w kontekście aplikacji.
  2. Szybkie dołożenie zdalnego dostępu: instalacja agentów narzędzi klasy RMM (np. Zoho/ManageEngine) poprzez ciche MSI (np. msiexec /q /i ...).
  3. C2 i redundancja dostępu: wdrożenie Velociraptora (legalny DFIR) jako kanału C2 oraz zestawienie Cloudflare Tunnel (cloudflared) jako zapasowej ścieżki dostępu.
  4. Post-exploitation: rozpoznanie AD, enumeracja kont i grup (w tym uprzywilejowanych), ustanawianie trwałości (np. reverse SSH/RDP) oraz próby osłabienia zabezpieczeń na hoście.

Wersje i łatki

W źródłach pojawiają się różne progi wersji podatnych (co bywa efektem kilku CVE oraz różnych gałęzi hotfixów), ale wspólny mianownik jest prosty: aktualizuj do SolarWinds WHD 2026.1 (lub nowszej) zgodnie z zaleceniami producenta.

Praktyczne konsekwencje / ryzyko

  • Pełna kompromitacja serwera WHD: RCE bez logowania na aplikacji wystawionej do internetu to w praktyce „otwarte drzwi”.
  • Ryzyko kompromitacji domeny: Microsoft wprost opisuje scenariusz foothold → lateral movement → aktywa wysokiej wartości, co w środowiskach z WHD blisko AD bywa krytyczne.
  • Trudniejsze wykrycie (dual-use tooling): Zoho/ManageEngine, Cloudflare Tunnel czy Velociraptor są legalne i nierzadko spotykane w IT — atakujący liczą na to, że zginą w szumie.
  • Utrzymanie dostępu mimo działań obronnych: dodatkowe kanały (tunel Cloudflare, Velociraptor jako C2) zwiększają odporność ataku na proste blokady.

Rekomendacje operacyjne / co zrobić teraz

  1. Patch natychmiast: zaktualizuj SolarWinds WHD do 2026.1+ (lub wersji wskazanej w Twojej linii wsparcia) i usuń stare hotfixy tylko po potwierdzeniu ścieżki upgrade’u.
  2. Odłącz WHD od internetu: jeśli WHD musi być dostępny zdalnie — wymuś VPN/Zero Trust, filtrację IP, MFA, a interfejs admina trzymaj wyłącznie w sieci zarządzającej.
  3. Hunting / IOC-driven triage (praktyczne tropy):
    • nietypowe uruchomienia msiexec z parametrami cichej instalacji i URL (MSI z hostingu plików),
    • obecność/uruchomienia cloudflared, nietypowe tunele wychodzące,
    • artefakty Velociraptor (szczególnie, jeśli organizacja go nie używa),
    • oznaki osłabiania zabezpieczeń hosta (zmiany w Defender/Firewall, podejrzane zadania harmonogramu).
  4. Rotacja sekretów: zresetuj hasła i klucze powiązane z WHD (konta serwisowe, integracje, dostęp do bazy), rozważ ponowne wydanie poświadczeń, jeśli WHD miał dostęp do zasobów krytycznych.
  5. Segmentacja i egress control: ogranicz ruch wychodzący z serwera WHD (allow-list), monitoruj nietypowe połączenia do usług tunelujących i chmur.
  6. Detekcja behawioralna: postaw na reguły wykrywające łańcuchy procesów (np. usługa WHD/Tomcat → cmd.exe/PowerShell → BITS/download), a nie tylko sygnatury.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Ten incydent to podręcznikowy przykład trendu „living off the land + dual-use”: zamiast custom malware, atakujący stawiają na legalne narzędzia administracyjne i IR/DFIR. Velociraptor jest tu szczególnie ciekawy — normalnie służy do polowań i analizy incydentów, a w rękach napastnika staje się elastycznym kanałem zdalnego sterowania.

Podsumowanie / kluczowe wnioski

  • WHD wystawiony do internetu + krytyczne luki = realne ryzyko szybkiej kompromitacji i eskalacji w głąb sieci.
  • W praktyce atak po wejściu może opierać się na „legalnych” narzędziach (Zoho/ManageEngine, Cloudflare Tunnel, Velociraptor), co utrudnia wykrycie bez dobrego telemetry + korelacji zachowań.
  • Najważniejsze działania: upgrade do 2026.1+, odcięcie ekspozycji internetowej, hunting pod konkretne artefakty i rotacja poświadczeń.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii i narzędzi (Zoho/Cloudflare/Velociraptor) (BleepingComputer)
  2. Huntress – analiza aktywnej eksploatacji i łańcucha ataku (Huntress)
  3. Microsoft Security Blog – obserwacje dot. multi-stage intrusion i guidance detekcyjne (Microsoft)
  4. Help Net Security – kontekst poprawek i lista CVE z pakietu styczniowego (Help Net Security)
  5. NVD (wpis KEV/CISA dla CVE-2025-40551: daty, wymagane działania) (NVD)