Archiwa: PowerShell - Strona 4 z 40

GREYVIBE wykorzystuje ChatGPT i Gemini do wsparcia cyberataków na cele związane z Ukrainą

Wprowadzenie do problemu / definicja

Rosnąca dostępność generatywnej sztucznej inteligencji zmienia sposób prowadzenia operacji cybernetycznych. Narzędzia takie jak modele językowe i systemy generujące obrazy są dziś wykorzystywane nie tylko do automatyzacji procesów biznesowych, ale również do przygotowywania kampanii phishingowych, budowy zaplecza technicznego oraz rozwijania komponentów złośliwego oprogramowania.

Przypadek grupy GREYVIBE pokazuje, że AI przestała być wyłącznie eksperymentalnym dodatkiem do działań ofensywnych. Według ustaleń analityków narzędzia takie jak ChatGPT, Gemini i Ideogram AI były używane operacyjnie do wspierania ataków wymierzonych głównie w podmioty związane z Ukrainą.

W skrócie

GREYVIBE to grupa aktywna co najmniej od sierpnia 2025 roku, powiązana operacyjnie z rosyjskojęzycznym środowiskiem zagrożeń.
Ataki były wymierzone w cele wojskowe, rządowe, cywilne i biznesowe związane z Ukrainą.
Grupa wykorzystywała generatywną AI do tworzenia przynęt, stron socjotechnicznych, materiałów graficznych oraz elementów technicznych wspierających malware.
W działaniach obserwowano spear phishing, fałszywe strony CAPTCHA, fikcyjne serwisy randkowe oraz strony podszywające się pod inicjatywy pomocowe i wojskowe.

Kontekst / historia

Analitycy opisują GREYVIBE jako aktora działającego wielowektorowo, którego aktywność wpisuje się w rosyjskie interesy państwowe, zwłaszcza w obszarze wywiadowczym powiązanym z wojną przeciwko Ukrainie. Jednocześnie nie ma pełnej pewności, że jest to klasyczna, ściśle państwowa operacja. Bardziej prawdopodobny wydaje się model hybrydowy, łączący elementy środowiska cyberprzestępczego i działań zgodnych z interesami państwa.

Badacze zidentyfikowali kilka odrębnych kampanii. W ramach PhantomMail rozsyłano wiadomości spear phishingowe z odnośnikami do złośliwych archiwów ZIP i RAR hostowanych na zewnętrznych platformach. PhantomClick opierał się na fałszywych stronach weryfikacji CAPTCHA i technikach ClickFix, które skłaniały ofiary do ręcznego uruchamiania poleceń. Kampania PrincessClub wykorzystywała fikcyjne ukraińskie serwisy randkowe i strony dla dorosłych do dystrybucji malware na Androida i Windows. Obserwowano także działania DroneLink, podszywające się pod inicjatywy wspierające ukraińskie siły zbrojne, oraz kampanię Nebo, w której przynęty imitowały rosyjskie wojskowe systemy łączności.

Analiza techniczna

Najważniejszym elementem aktywności GREYVIBE jest systematyczne wykorzystanie AI w wielu fazach ataku. Narzędzia generatywne miały wspierać przygotowanie realistycznych treści socjotechnicznych, grafik oraz komponentów technicznych używanych w kampaniach. To istotna zmiana jakościowa, ponieważ oznacza pełną integrację AI z cyklem życia operacji ofensywnej.

W arsenale grupy znalazł się między innymi PhantomRelay, modułowy zdalny trojan oparty na PowerShell. Malware komunikował się z infrastrukturą C2 za pomocą WebSocketów i umożliwiał profilowanie systemu, dynamiczne ładowanie dodatkowych skryptów oraz wykonywanie poleceń PowerShell i komend systemowych. Drugim ważnym narzędziem był LegionRelay, również oparty na PowerShell, wykorzystujący REST API do kontaktu z serwerem C2. Służył do eksfiltracji plików, przechwytywania zrzutów ekranu, kradzieży danych z przeglądarek, pozyskiwania informacji z Telegrama i WhatsAppa oraz przygotowywania dostępu RDP.

W kampaniach mobilnych stosowano FallSpy, spyware na Androida przeznaczone do zbierania danych wywiadowczych. Oprogramowanie pozyskiwało kontakty, logi połączeń, informacje o urządzeniu i sieci, dane lokalizacyjne, pliki multimedialne oraz informacje związane z kartą SIM. Taki profil działania wskazuje na charakter nadzorczy i rozpoznawczy, a nie typowo finansowy.

Badacze zwrócili również uwagę na obfuskatory i loadery, takie jak LOOKVALPS, LOOKVALJS, DAYLIGHT i TEASOUP. Część tych narzędzi mogła powstać przy wsparciu modeli językowych, co oznacza, że AI mogła nie tylko zwiększać jakość socjotechniki, ale także przyspieszać rozwój nowych wariantów komponentów utrudniających analizę i klasyfikację próbek.

Interesujący jest także ślad operacyjny grupy. W artefaktach deweloperskich, panelach administracyjnych i komentarzach w kodzie pojawiał się język rosyjski, a część systemów działała zgodnie ze strefą UTC+3. Jednocześnie odnotowano błędy operacyjne, w tym publikowanie próbek testowych na publicznych platformach skanujących, co sugeruje niższy poziom dyscypliny niż w przypadku najbardziej dojrzałych grup państwowych.

Konsekwencje / ryzyko

Przypadek GREYVIBE pokazuje, że generatywna AI obniża próg wejścia dla bardziej zaawansowanych operacji cybernetycznych. Nawet aktor o umiarkowanej dojrzałości może dziś szybciej przygotowywać wiarygodne przynęty, modyfikować kod, rozwijać własne narzędzia i ograniczać liczbę powtarzalnych artefaktów, które ułatwiają obrońcom detekcję i atrybucję.

Dla organizacji oznacza to wzrost ryzyka na kilku poziomach. Po pierwsze, socjotechnika staje się bardziej przekonująca językowo i lepiej dopasowana do kontekstu ofiary. Po drugie, modularne malware oparte na PowerShell i skryptach dynamicznie pobieranych z serwerów C2 może ograniczać skuteczność klasycznych narzędzi antywirusowych. Po trzecie, połączenie kanałów webowych, mobilnych i komunikatorów zwiększa powierzchnię ataku, szczególnie w środowiskach rozproszonych oraz tam, gdzie wykorzystywane są prywatne urządzenia.

Dodatkowym wyzwaniem jest zacieranie granicy między cyberprzestępczością a działaniami wspierającymi cele państwowe. W praktyce oznacza to większą zmienność taktyk, szybsze dostosowywanie kampanii i trudniejszą ocenę motywacji przeciwnika.

Rekomendacje

Organizacje powinny rozwijać wielowarstwowe podejście do ochrony, obejmujące zarówno prewencję, jak i detekcję działań po naruszeniu. Szczególne znaczenie ma ograniczanie skuteczności phishingu poprzez filtrowanie poczty, analizę archiwów i załączników, blokowanie ryzykownych typów plików oraz regularne szkolenia użytkowników.

Monitorować nadużycia PowerShell oraz uruchamianie skryptów z nietypowych lokalizacji.
Analizować komunikację WebSocket i REST do nieznanych hostów.
Ograniczać użycie interpreterów skryptowych tam, gdzie nie są niezbędne biznesowo.
Wdrażać polityki MDM/MAM dla urządzeń mobilnych mających dostęp do danych organizacyjnych.
Blokować sideloading aplikacji poza zaufanymi kanałami dystrybucji.
Rozszerzać playbooki SOC o scenariusze związane z fałszywymi CAPTCHA, przynętami randkowymi i stronami podszywającymi się pod inicjatywy pomocowe.
W threat huntingu większy nacisk kłaść na detekcję zachowań, korelację zdarzeń i analizę sekwencji działań operatora, a nie wyłącznie na sygnatury statyczne.

Podsumowanie

GREYVIBE to przykład współczesnego aktora zagrożeń, który łączy klasyczne techniki socjotechniczne z generatywną AI w celu zwiększenia skali, szybkości i wiarygodności operacji. Analizowane kampanie pokazują, że AI staje się praktycznym mnożnikiem siły zarówno na etapie przygotowania przynęt, jak i podczas rozwoju obfuskatorów, loaderów oraz malware.

Dla zespołów bezpieczeństwa to sygnał, że tradycyjne modele detekcji wymagają aktualizacji. Coraz większe znaczenie ma analiza behawioralna, monitoring skryptów oraz korelacja zdarzeń między pocztą, przeglądarką, punktami końcowymi i urządzeniami mobilnymi.

Źródła

BleepingComputer – GreyVibe hackers use ChatGPT, Gemini to power cyberattacks – https://www.bleepingcomputer.com/news/security/greyvibe-hackers-use-chatgpt-gemini-to-power-cyberattacks/
WithSecure Labs – GREYVIBE: A Russia-nexus group leveraging AI across state-aligned operations – https://labs.withsecure.com/publications/greyvibe

CVE-2026-35616 w FortiClient EMS aktywnie wykorzystywana do wdrażania malware

Wprowadzenie do problemu / definicja

CVE-2026-35616 to krytyczna podatność typu improper access control w FortiClient Endpoint Management Server (EMS), umożliwiająca zdalne wykonanie nieautoryzowanego kodu lub poleceń bez uwierzytelnienia. Ze względu na centralną rolę EMS w zarządzaniu stacjami końcowymi, skutki skutecznego ataku mogą wykraczać daleko poza kompromitację pojedynczego serwera.

W praktyce oznacza to, że atakujący może przejąć zaufany kanał administracyjny i wykorzystać go do działań obejmujących wiele zarządzanych urządzeń jednocześnie. To właśnie ten aspekt sprawia, że omawiana luka stanowi zagrożenie o wysokim priorytecie operacyjnym.

W skrócie

Podatność dotyczy FortiClient EMS w wersjach 7.4.5 i 7.4.6.
Luka została sklasyfikowana jako krytyczna i była aktywnie wykorzystywana w rzeczywistych atakach.
Napastnicy mieli używać serwera EMS do dystrybucji fałszywej poprawki podszywającej się pod aktualizację Fortinet.
Ładunkiem końcowym był EKZ Infostealer, malware ukierunkowany na kradzież danych uwierzytelniających.
Ryzyko obejmuje zarówno przejęcie kontroli nad środowiskiem endpointów, jak i późniejszą eskalację incydentu z użyciem skradzionych poświadczeń.

Kontekst / historia

Fortinet udostępnił poprawki poza standardowym cyklem aktualizacji na początku kwietnia 2026 roku, jednocześnie potwierdzając aktywne wykorzystanie luki w środowiskach produkcyjnych. To ważny sygnał, ponieważ publikacja awaryjnych poprawek zwykle wskazuje na wysokie prawdopodobieństwo dalszych kampanii ataków.

Sprawa szybko zyskała dodatkową wagę po uwzględnieniu CVE-2026-35616 w katalogu Known Exploited Vulnerabilities prowadzonym przez CISA. W praktyce wpis do KEV oznacza, że organizacje powinny potraktować podatność jako pilny problem bezpieczeństwa wymagający natychmiastowych działań naprawczych.

W kolejnych analizach badacze wskazali, że atakujący nie poprzestawali na samym dostępie do serwera EMS. Zamiast tego wykorzystywali mechanizmy platformy do dalszego rozsyłania złośliwych poleceń i komponentów na zarządzane stacje końcowe, co znacząco zwiększało skalę potencjalnych szkód.

Analiza techniczna

Źródłem problemu jest niewłaściwa kontrola dostępu w interfejsach FortiClient EMS. Specjalnie przygotowane żądania HTTP kierowane do określonych endpointów aplikacji mogą zostać obsłużone tak, jakby pochodziły od legalnie uwierzytelnionego administratora.

Skutkiem jest możliwość pominięcia mechanizmów uwierzytelniania i wykonywania operacji administracyjnych bez posiadania prawidłowych poświadczeń. W zależności od scenariusza atakujący może uruchamiać polecenia lub kod na poziomie serwera EMS, a następnie wykorzystywać natywne funkcje zarządzania do dalszej aktywności w środowisku.

W opisywanej kampanii serwer EMS miał służyć do dystrybucji fałszywej poprawki Fortinet uruchamianej przez PowerShell. Finalnym ładunkiem był EKZ Infostealer, którego zadaniem była kradzież danych uwierzytelniających zapisanych w przeglądarkach, między innymi w Chrome i Firefox, a następnie ich zapis lokalny i eksfiltracja przez HTTP.

Technicznie jest to szczególnie groźne połączenie dwóch elementów: kompromitacji centralnego systemu zarządzania oraz użycia zaufanej infrastruktury do wdrażania malware na wielu hostach jednocześnie. Atak nie wymaga więc osobnej kompromitacji każdej stacji roboczej, ponieważ przejęte funkcje EMS mogą stać się narzędziem masowej dystrybucji złośliwego oprogramowania.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest centralizacja ryzyka. Jedna luka w systemie zarządzania endpointami może przełożyć się na jednoczesne narażenie całej populacji urządzeń podłączonych do EMS, co otwiera drogę do wdrożenia infostealera, backdoora, a nawet ransomware na dużą skalę.

Istotnym zagrożeniem pozostaje także kradzież poświadczeń użytkowników i administratorów. Dane uwierzytelniające przejęte z przeglądarek mogą zostać później wykorzystane do dalszych ataków na pocztę, sieci VPN, usługi SaaS, środowiska chmurowe oraz panele administracyjne.

Dla organizacji regulowanych oznacza to również ryzyko naruszenia poufności danych, przestojów operacyjnych, kosztów reagowania incydentowego i potencjalnych obowiązków notyfikacyjnych. Jeśli EMS działa w segmencie o szerokiej łączności i wysokich uprawnieniach, wpływ incydentu może być szczególnie dotkliwy.

Rekomendacje

Najważniejszym krokiem jest natychmiastowe wdrożenie poprawek lub hotfixów dostarczonych przez producenta dla podatnych wersji FortiClient EMS. Organizacje korzystające z wersji 7.4.5 i 7.4.6 powinny traktować aktualizację jako działanie awaryjne.

Równolegle należy przeprowadzić aktywne polowanie na oznaki kompromitacji. Warto przeanalizować logi HTTP i logi aplikacyjne EMS pod kątem nietypowych żądań do endpointów administracyjnych, nieautoryzowanych zmian konfiguracji, niestandardowych zadań PowerShell oraz nagłych akcji dystrybucji aktualizacji do wielu hostów.

Po stronie endpointów zalecane jest sprawdzenie artefaktów mogących wskazywać na obecność infostealera, w tym podejrzanych uruchomień PowerShell, plików wykonywalnych podszywających się pod poprawki, nowych logów zawierających dane uwierzytelniające oraz nietypowego ruchu HTTP po wdrożeniu aktualizacji. W środowiskach podwyższonego ryzyka zasadne może być również wymuszenie resetu haseł użytkowników, których urządzenia mogły zostać objęte kampanią.

Dodatkowo warto ograniczyć powierzchnię ataku poprzez segmentację serwera EMS, zawężenie dostępu administracyjnego do zaufanych sieci, monitorowanie zmian konfiguracji oraz wdrożenie reguł detekcyjnych dla nietypowego użycia mechanizmów zdalnego zarządzania. W przypadku podejrzenia naruszenia bezpieczeństwa należy potraktować wszystkie urządzenia zarządzane przez EMS jako potencjalnie narażone.

Podsumowanie

CVE-2026-35616 pokazuje, jak groźne mogą być podatności w platformach centralnego zarządzania bezpieczeństwem endpointów. W tym przypadku problem nie ogranicza się do zdalnego wykonania kodu na pojedynczym serwerze, lecz obejmuje możliwość przejęcia zaufanego kanału administracyjnego i użycia go do szerokiej dystrybucji malware w organizacji.

Z uwagi na potwierdzone wykorzystanie w atakach, obecność w katalogu KEV oraz powiązanie z kampanią wykorzystującą EKZ Infostealer, luka powinna być traktowana jako zagrożenie najwyższego priorytetu. Szybkie patchowanie, walidacja integralności środowiska i przegląd oznak kompromitacji są w tym przypadku kluczowe.

Źródła

Security Affairs — https://securityaffairs.com/192817/malware/cve-2026-35616-forticlient-ems-flaw-actively-exploited-in-malware-attacks.html
FortiGuard PSIRT: FG-IR-26-099 — https://fortiguard.fortinet.com/psirt/FG-IR-26-099
Arctic Wolf — FortiClient EMS Exploited via CVE-2026-35616 to Deliver EKZ Infostealer Disguised as a Fortinet Patch — https://arcticwolf.com/resources/blog/forticlient-ems-exploited-via-cve-2026-35616-to-deliver-ekz-infostealer-disguised-as-a-fortinet-patch/
NVD — CVE-2026-35616 — https://nvd.nist.gov/vuln/detail/CVE-2026-35616
CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-35616

Kampania phishingowa z fałszywym zamówieniem zakupu wykorzystuje PDF-y do kradzieży poświadczeń

Wprowadzenie do problemu / definicja

Phishing ukierunkowany na środowiska biznesowe coraz częściej wykorzystuje dokumenty przypominające codzienną korespondencję handlową. Jednym z najskuteczniejszych wabików pozostaje rzekome zamówienie zakupu, faktura lub prośba o pilne potwierdzenie dokumentu. W analizowanym scenariuszu cyberprzestępcy używają pliku PDF jako elementu socjotechnicznego, którego celem jest skierowanie ofiary do fałszywej strony logowania i przejęcie danych uwierzytelniających.

W skrócie

Kampania opiera się na wiadomościach e-mail podszywających się pod legalną komunikację handlową. Załączony plik PDF zawiera przycisk lub odnośnik prowadzący do strony phishingowej, gdzie ofiara proszona jest o zalogowanie się w celu wyświetlenia rzekomego zamówienia zakupu. Oprócz loginu i hasła strona może zbierać również informacje o przeglądarce, systemie operacyjnym, języku, rozdzielczości ekranu czy lokalizacji użytkownika. Celem ataku jest przejęcie kont firmowych i dalsze wykorzystanie dostępu w operacjach fraudowych lub malware’owych.

Kontekst / historia

Phishing typu purchase order nie jest nowym zjawiskiem, ale jego skuteczność pozostaje wysoka, ponieważ doskonale wpisuje się w codzienne procesy biznesowe. Działy zakupów, finansów, logistyki i sprzedaży regularnie odbierają zamówienia, potwierdzenia i zapytania ofertowe, przez co podobne wiadomości nie wzbudzają od razu podejrzeń.

W nowszych kampaniach widać także szersze wykorzystanie usług chmurowych i zaufanych platform hostingowych jako infrastruktury pośredniej. Taki model utrudnia blokowanie zagrożeń na poziomie domen i pozwala operatorom szybko rotować adresy URL. Dodatkowo część kampanii jest powiązana z rodzinami zagrożeń pokroju PureLogs, które łączą klasyczny phishing z bardziej zaawansowanymi łańcuchami infekcji obejmującymi skrypty, archiwa, PowerShell i techniki bezplikowe.

Analiza techniczna

Punktem wejścia jest wiadomość e-mail zawierająca plik PDF stylizowany na dokument zakupowy. Sam PDF nie musi zawierać exploita — jego podstawową funkcją jest skłonienie użytkownika do kliknięcia w osadzony link. To ważne, ponieważ wiele organizacji nadal postrzega dokumenty PDF jako mniej ryzykowne niż archiwa czy pliki wykonywalne.

Po kliknięciu użytkownik trafia na stronę podszywającą się pod formularz biznesowego logowania. W takich kampaniach często obserwuje się zestaw technik zwiększających skuteczność operacji i utrudniających analizę:

prewypełnienie pola adresu e-mail ofiary,
obfuskację kodu JavaScript,
zbieranie fingerprintu przeglądarki i środowiska systemowego,
przesyłanie skradzionych danych do operatorów w czasie rzeczywistym.

Taki model pozwala napastnikom bardzo szybko wykorzystać zdobyte dane uwierzytelniające. Przejęte konto może zostać użyte do logowania do poczty firmowej, usług SaaS, paneli administracyjnych, VPN lub systemów przechowywania plików jeszcze zanim użytkownik zorientuje się, że padł ofiarą oszustwa.

Szerszy kontekst techniczny związany z PureLogs pokazuje, że ekosystem ten może obejmować również bardziej rozbudowane łańcuchy dostarczania ładunku. W obserwowanych wariantach pojawiają się archiwa TXZ, osadzony JavaScript, ukrywanie poleceń w zmiennych środowiskowych, uruchamianie PowerShell w trybie ukrytym, odszyfrowywanie ładunków AES, dekompresja Gzip oraz ładowanie komponentów .NET przez reflection. Takie podejście ogranicza ilość artefaktów na dysku i utrudnia wykrycie przez mechanizmy oparte wyłącznie na sygnaturach.

W części przypadków końcowy etap może obejmować steganograficzne ukrycie danych w obrazie, z którego loader odzyskuje właściwy ładunek malware. To pokazuje, że kampanie wykorzystujące pozornie prosty phishing mogą być elementem bardziej złożonej operacji prowadzącej do pełnej kompromitacji stacji roboczej.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem ataku jest przejęcie firmowych danych logowania. Jeśli użytkownik użyje poświadczeń do poczty służbowej lub platform chmurowych, napastnik może uzyskać dostęp do korespondencji, dokumentów i procesów biznesowych. To z kolei otwiera drogę do dalszego phishingu, oszustw BEC, przejmowania wątków finansowych oraz kradzieży danych klientów i informacji handlowych.

dostęp do skrzynki pocztowej i poufnej korespondencji,
przejęcie wątków dotyczących płatności i faktur,
kradzież dokumentów biznesowych i danych klientów,
wykorzystanie konta do dalszych ataków wewnętrznych i zewnętrznych,
eskalacja dostępu dzięki ponownemu użyciu haseł.

Ryzyko rośnie w organizacjach, które nie wymuszają MFA lub pozwalają na szeroki dostęp do wielu usług z poziomu jednego konta. Dodatkowo zebrane metadane o urządzeniu i środowisku użytkownika mogą posłużyć do profilowania ofiary, obchodzenia mechanizmów antyfraudowych i przygotowania kolejnych etapów ataku.

Jeśli kampania kończy się wdrożeniem infostealera, skutki są jeszcze poważniejsze. Oprócz haseł malware może przechwytywać ciasteczka sesyjne, tokeny, dane zapisane w przeglądarce oraz informacje systemowe, co zwiększa szansę na długotrwałe utrzymanie dostępu.

Rekomendacje

Organizacje powinny traktować załączniki PDF używane w komunikacji biznesowej z takim samym poziomem ostrożności jak inne nośniki socjotechniczne. Skuteczna obrona wymaga połączenia procedur, zabezpieczeń technicznych oraz świadomości użytkowników.

potwierdzanie nieoczekiwanych zamówień zakupu innym kanałem komunikacji,
stosowanie zasady drugiej pary oczu przy dokumentach finansowych i zakupowych,
analiza behawioralna załączników i inspekcja URL-i osadzonych w dokumentach,
wymuszenie MFA dla poczty, VPN i aplikacji SaaS,
monitorowanie anomalii logowania, geolokalizacji i nietypowych agentów użytkownika,
wykrywanie ukrytych uruchomień PowerShell i podejrzanych loaderów .NET,
szkolenia oparte na realistycznych scenariuszach phishingu zakupowego,
natychmiastowy reset hasła i unieważnienie sesji po podejrzeniu kompromitacji.

W praktyce szczególnie istotne jest rozdzielenie procesu odbioru dokumentu od procesu logowania do systemu. Każda sytuacja, w której dokument nakłania użytkownika do ponownego uwierzytelnienia, powinna być traktowana jako potencjalnie podejrzana do czasu pełnej weryfikacji.

Podsumowanie

Fałszywe zamówienia zakupu pozostają wyjątkowo skutecznym narzędziem phishingowym, ponieważ wykorzystują naturalne procesy biznesowe oraz zaufanie do dokumentów PDF. Opisywane kampanie pokazują, że nawet prosty mechanizm przekierowania do formularza logowania może stanowić element większego ekosystemu zagrożeń obejmującego kradzież poświadczeń, profilowanie ofiary i dostarczanie infostealerów.

Dla zespołów bezpieczeństwa oznacza to konieczność łączenia ochrony poczty, zabezpieczeń tożsamości, monitorowania endpointów oraz dojrzałych procedur operacyjnych. Kluczową zasadą powinno być założenie, że każdy dokument wymagający kliknięcia i ponownego logowania może być częścią złośliwej kampanii.

Źródła

Infosecurity Magazine – PureLogs Phishing Purchase Order
https://www.infosecurity-magazine.com/news/purelogs-phishing-purchase-order/
Malwarebytes – Inside a purchase order PDF phishing campaign
https://www.malwarebytes.com/blog/threat-intel/2025/12/inside-a-purchase-order-pdf-phishing-campaign
FortiGuard Labs – PureLogs: Delivery via PawsRunner Steganography
https://www.fortinet.com/blog/threat-research/purelogs-delivery-via-pawsrunner-steganography

Złośliwe koparki GPU rozprzestrzeniane przez SEO poisoning i odpowiedzi chatbotów AI

Wprowadzenie do problemu / definicja

Nowa kampania cryptojackingu pokazuje, że klasyczne zatruwanie wyników wyszukiwania nadal pozostaje skuteczną metodą infekcji, a jednocześnie zaczyna obejmować także ekosystem asystentów AI. Atakujący podszywają się pod popularne narzędzia systemowe i diagnostyczne, a następnie dostarczają ofiarom archiwa zawierające legalny instalator oraz złośliwą bibliotekę DLL. Celem nie są przypadkowe komputery, lecz wydajne stacje robocze i komputery graczy wyposażone w mocne karty graficzne.

W skrócie

Atak wykorzystuje fałszywe strony pobierania promowane przez SEO poisoning.
W części przypadków użytkownicy trafiają na złośliwe domeny także przez odpowiedzi chatbotów AI.
Pakiet infekcyjny łączy legalny plik wykonywalny ze złośliwą biblioteką DLL.
Napastnicy uzyskują trwały dostęp do systemu przez legalne narzędzie zdalnego zarządzania.
Końcowym celem jest uruchomienie koparek kryptowalut wykorzystujących GPU.

Kontekst / historia

Cryptojacking od lat pozostaje atrakcyjnym modelem monetyzacji dla cyberprzestępców, ponieważ umożliwia generowanie zysków bez szyfrowania danych czy otwartego szantażu ofiary. W ostatnich latach operatorzy takich kampanii coraz częściej odchodzą od masowych, prostych infekcji i koncentrują się na przejęciu systemów zapewniających wyższy zwrot z operacji.

W tym przypadku szczególnie cenne są komputery graczy, stacje robocze twórców treści, środowiska renderujące i inne maszyny wyposażone w wydajne układy graficzne. To właśnie użytkownicy takich urządzeń często wyszukują benchmarki, sterowniki, kodeki czy aplikacje monitorujące parametry sprzętu, co czyni z nich naturalny cel dla kampanii podszywających się pod popularne narzędzia użytkowe.

Nowym i niepokojącym elementem jest przenikanie tej taktyki do odpowiedzi generowanych przez systemy AI. Oznacza to, że proces wyszukiwania i pozyskiwania oprogramowania staje się coraz szerszym polem nadużyć, wykraczającym poza klasyczne reklamy i wyniki wyszukiwania.

Analiza techniczna

Atak rozpoczyna się od wejścia użytkownika na spreparowaną stronę pobierania. Dostarczane archiwum ZIP zawiera prawidłowy plik wykonywalny legalnej aplikacji oraz złośliwą bibliotekę DLL, co wskazuje na wykorzystanie techniki DLL sideloading. W praktyce legalny proces ładuje podstawiony komponent, który uruchamia kolejne etapy infekcji.

Następnie złośliwa biblioteka uruchamia proces instalacji kolejnego ładunku z użyciem procesu systemowego odpowiedzialnego za instalację pakietów. W dalszym etapie wdrażane jest legalne narzędzie do zdalnego dostępu, co utrudnia wykrycie aktywności i daje napastnikom możliwość utrzymania interaktywnej kontroli nad przejętym hostem.

Kolejny komponent kopiuje się do ukrytego katalogu pod nazwą imitującą legalny składnik systemu. Badacze wskazali również na utworzenie wielu mechanizmów persystencji w różnych lokalizacjach autostartu systemu Windows, co zwiększa odporność złośliwego oprogramowania na częściowe usunięcie lub restart urządzenia.

W części przypadków ładunek dostarczany był również przez skrypt PowerShell i zapisywany lokalnie pod nazwą sugerującą legalny program multimedialny. To klasyczna metoda maskowania aktywności, utrudniająca szybką ocenę sytuacji przez użytkownika i administratora.

Istotnym elementem kampanii jest także process hollowing. Malware uruchamia legalne, podpisane procesy systemowe i wstrzykuje do nich własny kod, co znacząco utrudnia detekcję opartą wyłącznie na reputacji plików lub prostych wskaźnikach kompromitacji. Dodatkowo złośliwy kod modyfikuje ustawienia ochrony, dodając wyjątki do mechanizmów bezpieczeństwa, oraz sprawdza, czy działa w środowisku analitycznym lub maszynie wirtualnej.

Po zakończeniu fazy ukrywania i utrwalania obecności malware pobiera moduły służące do kopania kryptowalut z użyciem GPU. Wykorzystanie narzędzi górniczych przystosowanych do akceleracji graficznej potwierdza, że napastnicy celowo wybierają hosty o wysokiej mocy obliczeniowej.

Konsekwencje / ryzyko

Najbardziej widocznym skutkiem infekcji jest nieautoryzowane zużycie mocy GPU, energii elektrycznej oraz przyspieszona eksploatacja podzespołów. W środowiskach domowych objawia się to wzrostem temperatur, większym hałasem wentylatorów, spadkiem wydajności komputera i wyższymi rachunkami za prąd.

W organizacjach skutki są znacznie poważniejsze. Zainfekowane stacje robocze mogą działać wolniej, powodować opóźnienia w renderingu, zakłócać pracę aplikacji inżynierskich i obniżać dostępność zasobów dla zespołów korzystających z akceleracji graficznej. Dodatkowo wdrożenie narzędzia zdalnego dostępu oznacza, że przejęty host może stać się punktem wyjścia do dalszych działań ofensywnych.

Ryzyko nie kończy się więc na cryptojackingu. Napastnicy mogą wykorzystać dostęp do instalacji kolejnych ładunków, kradzieży danych uwierzytelniających, ruchu bocznego w sieci, a nawet przygotowania środowiska pod późniejszy atak ransomware lub kradzież danych.

Szczególnie istotne jest także zagrożenie wynikające z nadużycia odpowiedzi chatbotów AI. Jeżeli użytkownicy traktują modele generatywne jako zaufane źródło rekomendacji oprogramowania, błędne lub zmanipulowane wskazania mogą stać się nowym ogniwem łańcucha infekcji.

Rekomendacje

Organizacje powinny ograniczyć pobieranie oprogramowania wyłącznie do oficjalnych stron producentów, zaufanych repozytoriów oraz wewnętrznie zatwierdzonych katalogów aplikacji. Warto wdrożyć polityki zabraniające instalowania narzędzi pobranych bezpośrednio z reklam, wyników wyszukiwania lub odpowiedzi generowanych przez systemy AI bez dodatkowej weryfikacji.

blokować nieautoryzowane narzędzia zdalnego dostępu,
monitorować nietypowe użycie PowerShell i procesów instalacyjnych,
wykrywać zmiany w autostarcie oraz zadaniach harmonogramu,
alertować na dodawanie wyjątków do mechanizmów ochronnych,
analizować uruchamianie podpisanych procesów w nietypowym kontekście,
kontrolować archiwa ZIP i biblioteki DLL uruchamiane z katalogów użytkownika.

W środowiskach posiadających cenne zasoby GPU warto wdrożyć telemetrykę zużycia kart graficznych i profile bazowego obciążenia. Nietypowe, długotrwałe wykorzystanie GPU poza godzinami pracy może być skutecznym wskaźnikiem cryptojackingu.

Z perspektywy użytkownika końcowego kluczowe znaczenie mają podstawowe zasady higieny bezpieczeństwa: weryfikacja domeny przed pobraniem, sprawdzanie podpisów cyfrowych i sum kontrolnych, unikanie pośrednich stron z plikami oraz traktowanie rekomendacji chatbotów jedynie jako wskazówek wymagających potwierdzenia.

Podsumowanie

Opisana kampania pokazuje, że cryptojacking ewoluuje w stronę bardziej selektywnych i rentownych operacji. Połączenie SEO poisoning, nadużycia zaufania do odpowiedzi AI, DLL sideloadingu, wielowarstwowej persystencji, process hollowing i legalnych narzędzi administracyjnych tworzy skuteczny łańcuch ataku wymierzony w komputery o wysokiej wartości obliczeniowej.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona procesu pobierania oprogramowania i kontrola zaufanych narzędzi administracyjnych stają się równie ważne jak klasyczne mechanizmy antymalware. Skuteczna obrona wymaga połączenia polityk instalacyjnych, telemetrii endpointów, detekcji behawioralnej i edukacji użytkowników.

Źródła

BleepingComputer — https://www.bleepingcomputer.com/news/security/gpu-mining-malware-spreads-via-seo-poisoning-ai-chatbots/
Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/
Microsoft Threat Intelligence — https://www.microsoft.com/en-us/security/business/security-101/what-is-threat-intelligence

Luka w Ghost CMS wykorzystana do kampanii ClickFix na setkach stron

Wprowadzenie do problemu / definicja

Ghost CMS stał się celem szeroko zakrojonej kampanii kompromitacji stron internetowych, w której napastnicy wykorzystali załataną już podatność SQL Injection oznaczoną jako CVE-2026-26980. Problem nie wynikał z pojawienia się nowej luki, lecz z opóźnionego wdrażania poprawek przez administratorów, co otworzyło drogę do przejmowania niezałatanych instancji i modyfikowania opublikowanych treści.

W praktyce cyberprzestępcy używali podatności do pozyskania dostępu do wrażliwych danych aplikacji, a następnie do osadzania złośliwego kodu wspierającego kampanie typu ClickFix. W efekcie legalne serwisy były wykorzystywane jako nośnik dalszych ataków na odwiedzających.

W skrócie

Atakujący wykorzystywali CVE-2026-26980 w interfejsie Content API Ghost CMS do nieautoryzowanego odczytu danych z bazy. Najgroźniejszy scenariusz obejmował pozyskanie klucza Admin API, co pozwalało na pełnoprawną edycję treści publikowanych na stronie.

Po przejęciu dostępu operatorzy kampanii wstrzykiwali złośliwy JavaScript do artykułów. Kod przekierowywał użytkowników do fałszywych ekranów weryfikacji człowieka i nakłaniał ich do uruchomienia poleceń w systemie Windows, prowadząc do pobrania kolejnych ładunków malware.

wykorzystana została znana i załatana podatność w Ghost CMS,
atak objął ponad 700 domen,
celem było przejęcie możliwości edycji treści przez Admin API,
końcowym etapem była socjotechnika oparta na schemacie ClickFix.

Kontekst / historia

Ghost to popularny system zarządzania treścią wykorzystywany przez blogi, redakcje i projekty headless CMS. Platformy tego typu są szczególnie atrakcyjne dla przestępców, ponieważ publicznie dostępne API ułatwia automatyczne skanowanie internetu i seryjne wykorzystywanie tych samych błędów na wielu hostach.

Podatność CVE-2026-26980 została wcześniej ujawniona i poprawiona, jednak wiele organizacji nie wdrożyło aktualizacji na czas. To stworzyło klasyczne okno eksploatacji post-patch, w którym napastnicy analizują opublikowaną poprawkę, odtwarzają mechanizm błędu i szybko automatyzują atak.

Z dostępnych analiz wynika, że kampania była aktywna co najmniej od początku maja 2026 roku. Ślady wskazują również, że przygotowania po stronie operatorów rozpoczęły się bardzo szybko po udostępnieniu aktualizacji bezpieczeństwa.

Analiza techniczna

Rdzeniem incydentu była luka SQL Injection umożliwiająca odczyt danych z bazy bez uwierzytelnienia. Kluczowym zasobem z perspektywy napastnika był klucz Admin API, który w architekturze Ghost daje szerokie uprawnienia do zarządzania treścią i elementami systemu.

Po pozyskaniu klucza atakujący nie musieli utrzymywać webshella ani bezpośrednio ingerować w całe środowisko aplikacyjne. Zamiast tego korzystali z natywnych mechanizmów administracyjnych Ghost i modyfikowali wpisy przez legalne interfejsy API, dodając do artykułów złośliwy kod JavaScript.

Łańcuch ataku miał kilka etapów. Najpierw zainfekowana strona ładowała zewnętrzny skrypt pełniący rolę loadera. Następnie następowało profilowanie środowiska przeglądarki oraz selekcja potencjalnych ofiar. W dalszej kolejności użytkownik trafiał na fałszywą stronę weryfikacyjną stylizowaną na mechanizm CAPTCHA lub kontrolę antybotową.

Właśnie na tym etapie uruchamiano model ClickFix. Ofiara otrzymywała instrukcję, aby skopiować i uruchomić lokalnie przygotowaną komendę, najczęściej w oknie Uruchamianie lub PowerShell. Ostatni etap wykonywał więc sam użytkownik, co utrudnia wykrywanie i pozwala ominąć część klasycznych zabezpieczeń opartych wyłącznie na blokowaniu kodu w przeglądarce.

Badacze zwracają również uwagę, że infrastruktura kampanii była dynamicznie zmieniana. Operatorzy podmieniali domeny, skrypty i dalsze ładunki malware, aby utrzymać skuteczność działań mimo publikacji wskaźników kompromitacji i rosnącego zainteresowania obrońców.

Konsekwencje / ryzyko

Dla właścicieli stron najpoważniejszym skutkiem jest utrata integralności publikowanych treści oraz wykorzystanie zaufanej domeny do dystrybucji złośliwego kodu. Użytkownik odwiedzający legalny serwis może zostać wciągnięty w etap socjotechniczny bez wyraźnych oznak klasycznego phishingu.

Taki model działania zwiększa skuteczność kampanii, ponieważ reputacja znanej witryny obniża czujność ofiary. Jednocześnie incydent nie musi oznaczać pełnego przejęcia serwera, aby prowadzić do poważnych skutków bezpieczeństwa i wizerunkowych.

kompromitacja marki i utrata reputacji,
ryzyko umieszczenia domeny na listach blokowanych,
narażenie użytkowników na malware,
utrudnione wykrycie incydentu przy braku monitoringu zmian treści,
konieczność rotacji kluczy i przeglądu historycznych logów.

Rekomendacje

Administratorzy korzystający z Ghost CMS powinni niezwłocznie zweryfikować wersję systemu i wdrożyć poprawki bezpieczeństwa. Jeśli istnieje choćby podejrzenie wcześniejszej kompromitacji, sam update nie jest wystarczający i powinien być traktowany jedynie jako pierwszy krok reakcji.

zaktualizować Ghost CMS do wersji zawierającej poprawkę dla CVE-2026-26980,
przeprowadzić rotację wszystkich kluczy Admin API oraz innych poświadczeń,
przeanalizować logi pod kątem nietypowych wywołań administracyjnych API,
sprawdzić treści artykułów, szablony i ustawienia code injection pod kątem obcych skryptów,
porównać bieżącą zawartość z kopiami zapasowymi i wcześniejszymi wersjami wpisów,
wdrożyć monitoring integralności treści publikowanych przez CMS,
przeanalizować zgłoszenia użytkowników i historię pobrań mogące wskazywać na kontakt ze złośliwą stroną.

Z perspektywy użytkownika końcowego warto podkreślić prostą zasadę: legalna witryna nie powinna wymagać uruchamiania poleceń systemowych w celu przejścia testu CAPTCHA. Taka prośba powinna być traktowana jako jednoznaczny sygnał ataku.

Podsumowanie

Kampania wymierzona w Ghost CMS pokazuje, jak szybko cyberprzestępcy potrafią przejść od publicznie ujawnionej podatności do masowej eksploatacji internetu. Kluczową rolę odegrało opóźnione patchowanie oraz wykorzystanie natywnych funkcji administracyjnych CMS do zatruwania treści zamiast stosowania bardziej klasycznych metod trwałej kompromitacji.

To ważne ostrzeżenie dla administratorów i zespołów bezpieczeństwa. Aktualizacje bezpieczeństwa muszą być traktowane priorytetowo, a monitoring powinien obejmować nie tylko stan serwera, lecz także integralność treści, aktywność API i anomalie w warstwie frontendowej.

Źródła

Ghost CMS flaw abused to push ClickFix attacks on hundreds of sites — https://securityaffairs.com/192655/cyber-crime/ghost-cms-flaw-abused-to-push-clickfix-attacks-on-hundreds-of-sites.html
Ghost CMS Mass Compromised via CVE-2026-26980, Now Fueling ClickFix Attacks — https://blog.xlab.qianxin.com/ghost-cms-mass-compromised-via-cve-2026-26980-now-fueling-clickfix-attacks/
Security update available for Ghost 6.x — https://forum.ghost.org/t/security-update-available-for-ghost-6-x/61908
Ghost Documentation — https://ghost.org/docs/

Microsoft łata krytyczną lukę RCE w SharePoint. Co oznacza to dla organizacji?

Wprowadzenie do problemu / definicja

Zdalne wykonanie kodu, czyli RCE, należy do najgroźniejszych kategorii podatności w systemach firmowych. Tego rodzaju luka może umożliwić atakującemu uruchomienie własnych poleceń na podatnym serwerze, co w praktyce otwiera drogę do przejęcia kontroli nad usługą, kradzieży danych oraz dalszej kompromitacji infrastruktury.

W przypadku Microsoft SharePoint ryzyko jest szczególnie wysokie, ponieważ platforma ta często pełni rolę centralnego repozytorium dokumentów, intranetu i narzędzia wspierającego procesy biznesowe. Jeżeli podatność dotyczy tak krytycznego komponentu, skutki incydentu mogą wykraczać daleko poza sam serwer aplikacyjny.

W skrócie

Microsoft opublikował poprawki bezpieczeństwa usuwające krytyczną lukę RCE w SharePoint. Problem dotyczy rozwiązania szeroko wykorzystywanego w przedsiębiorstwach do współdzielenia plików, obsługi obiegu dokumentów i integracji z innymi usługami środowiska Microsoft.

Dla organizacji oznacza to konieczność szybkiego działania. Priorytetem powinno być nie tylko wdrożenie aktualizacji, ale także sprawdzenie logów, ograniczenie ekspozycji systemów dostępnych z internetu oraz ocena, czy nie doszło już wcześniej do próby wykorzystania podatności.

Kontekst / historia

SharePoint od lat pozostaje atrakcyjnym celem dla cyberprzestępców oraz grup prowadzących operacje ukierunkowane. Wynika to z jego centralnej pozycji w środowiskach korporacyjnych, gdzie przechowuje dokumenty o wysokiej wartości, wspiera pracę zespołową i łączy się z systemami tożsamościowymi oraz aplikacjami biznesowymi.

W przeszłości podatności w tego typu platformach były wykorzystywane zarówno w masowych kampaniach, jak i w bardziej zaawansowanych atakach nastawionych na trwałe utrzymanie dostępu. Kompromitacja portalu współpracy może oznaczać nie tylko utratę kontroli nad aplikacją, ale także dostęp do kont serwisowych, metadanych, repozytoriów dokumentów oraz połączonych usług.

Analiza techniczna

Podatność klasy RCE w SharePoint może wynikać z błędów w przetwarzaniu danych wejściowych, nieprawidłowej walidacji żądań, niebezpiecznej deserializacji albo wadliwej obsługi komponentów wykonywanych po stronie serwera. W praktyce atak często polega na dostarczeniu specjalnie przygotowanego żądania HTTP lub spreparowanego obiektu, który prowadzi do wykonania kodu w kontekście procesu aplikacyjnego.

Jeżeli luka jest osiągalna zdalnie i nie wymaga skomplikowanych warunków wstępnych, atakujący może uzyskać możliwość uruchamiania poleceń systemowych, instalowania web shelli, kradzieży poświadczeń oraz pobierania dokumentów i danych z farmy SharePoint. Taki dostęp może następnie posłużyć do ruchu bocznego i eskalacji uprawnień w całym środowisku.

uruchamianie poleceń systemowych na serwerze,
instalacja web shelli lub innych implantów,
kradzież poświadczeń kont serwisowych,
dostęp do dokumentów i metadanych,
wykorzystanie integracji z Active Directory i innymi usługami.

Z perspektywy obrony warto analizować nietypowe żądania do aplikacji, tworzenie nowych plików w katalogach webowych, uruchamianie procesów potomnych przez komponenty IIS i SharePoint oraz połączenia wychodzące do nieznanych adresów. Istotne mogą być także anomalie związane z PowerShell, procesem w3wp.exe, harmonogramem zadań oraz zmianami konfiguracji aplikacji.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem wykorzystania takiej luki jest pełne przejęcie serwera SharePoint. To z kolei może prowadzić do wycieku poufnych dokumentów, sabotażu danych, wdrożenia ransomware lub użycia infrastruktury ofiary jako punktu wyjścia do dalszych ataków wewnętrznych.

Ryzyko znacząco rośnie, gdy serwer jest wystawiony do internetu, poprawki bezpieczeństwa są opóźniane, a środowisko korzysta z kont serwisowych o zbyt szerokich uprawnieniach. Brak segmentacji sieci i ograniczone monitorowanie logów dodatkowo zwiększają prawdopodobieństwo, że atak pozostanie niezauważony przez dłuższy czas.

przejęcie serwera aplikacyjnego,
wyciek danych i dokumentów,
ruch boczny w sieci organizacji,
naruszenie zgodności i obowiązki raportowe,
kosztowne przestoje operacyjne.

Rekomendacje

Podstawowym krokiem powinno być natychmiastowe wdrożenie oficjalnych poprawek bezpieczeństwa dla wszystkich wspieranych instancji SharePoint. Sama aktualizacja nie zamyka jednak całego procesu reagowania. Organizacje powinny równolegle zweryfikować, czy podatność nie została wykorzystana przed wdrożeniem łatek.

Zespoły bezpieczeństwa powinny przeprowadzić przegląd wszystkich środowisk SharePoint, w tym instancji testowych i rzadko używanych. Należy potwierdzić wersje oprogramowania, przeanalizować logi IIS, SharePoint, Windows Event Log oraz dane z systemów EDR lub XDR. Warto również sprawdzić obecność nietypowych plików, web shelli, zadań harmonogramu i podejrzanych zmian konfiguracyjnych.

zidentyfikować wszystkie serwery SharePoint w organizacji,
potwierdzić poziom poprawek i wdrożyć aktualizacje priorytetowo,
przeanalizować logi i telemetrię bezpieczeństwa,
zweryfikować konta serwisowe oraz zapisane poświadczenia,
ograniczyć ekspozycję usług publicznych,
wzmocnić segmentację sieci i zasadę najmniejszych uprawnień,
przygotować plan reagowania na potwierdzoną eksploatację.

Dobrą praktyką będzie także przegląd konfiguracji reverse proxy, WAF oraz zasad dostępu administracyjnego. W środowiskach szczególnie narażonych warto czasowo podnieść poziom monitoringu i zwiększyć częstotliwość analizy alertów związanych z farmą SharePoint.

Podsumowanie

Krytyczna luka RCE w Microsoft SharePoint to poważne zagrożenie dla organizacji korzystających z tej platformy jako centralnego narzędzia współpracy i przechowywania dokumentów. Skuteczna eksploatacja może doprowadzić do przejęcia serwera, wycieku danych i dalszej kompromitacji środowiska IT.

Najważniejsze działania to szybkie wdrożenie poprawek, kontrola logów i artefaktów, ograniczenie powierzchni ataku oraz ocena, czy infrastruktura nie została naruszona jeszcze przed instalacją aktualizacji. W praktyce szybkość reakcji może zdecydować o skali incydentu i kosztach jego obsługi.

Źródła

The Hacker News — https://thehackernews.com/2026/05/microsoft-patches-sharepoint-rce-flaw.html
Microsoft Security Response Center — https://msrc.microsoft.com/
Microsoft SharePoint documentation — https://learn.microsoft.com/sharepoint/

MuddyWater wykorzystuje DLL side-loading w kampanii cyberszpiegowskiej obejmującej dziewięć państw

Wprowadzenie do problemu / definicja

DLL side-loading to technika polegająca na uruchomieniu złośliwego kodu za pośrednictwem legalnego, podpisanego pliku wykonywalnego, który ładuje podstawioną bibliotekę DLL z lokalizacji kontrolowanej przez napastnika. Dzięki temu malware działa pod przykryciem zaufanego procesu, co utrudnia wykrycie przez systemy ochronne bazujące na reputacji plików, sygnaturach oraz uproszczonej analizie procesów.

Najnowsza kampania przypisywana grupie MuddyWater pokazuje, że metoda ta pozostaje skutecznym narzędziem cyberszpiegostwa. Operacja miała objąć organizacje z wielu sektorów i regionów świata, a jej celem było uzyskanie trwałego dostępu, rozpoznanie środowiska oraz przejęcie wrażliwych danych.

W skrócie

Według ujawnionych analiz, w pierwszym kwartale 2026 roku MuddyWater prowadziła działania wymierzone w co najmniej dziewięć organizacji z dziewięciu krajów na czterech kontynentach. Wśród celów znalazły się podmioty z branży produkcyjnej, elektronicznej, edukacyjnej, finansowej, publicznej oraz usług profesjonalnych.

Atakujący wykorzystywali podpisane binaria fmapp.exe oraz sentinelmemoryscanner.exe.
Kluczowym elementem łańcucha ataku było boczne ładowanie złośliwych bibliotek DLL.
W kampanii użyto także skryptów Node.js i PowerShell do rekonesansu oraz wykonywania dalszych działań.
Implanty umożliwiały kradzież danych z przeglądarek Chromium, zrzuty ekranu, eskalację uprawnień i utrzymywanie dostępu.

Kontekst / historia

MuddyWater od lat jest kojarzona z operacjami cyberszpiegowskimi nastawionymi na długotrwałe utrzymanie obecności w sieciach ofiar, zbieranie informacji oraz dyskretne poruszanie się po infrastrukturze. W tej kampanii widoczna jest kontynuacja takiego modelu działania, ale również jego wyraźne dopracowanie.

Zamiast głośnych technik generujących dużą liczbę alertów, grupa wykorzystuje legalne komponenty, etapuje działania i ponownie uruchamia implanty w celu podtrzymywania trwałości. Jest to podejście dobrze wpisujące się w operacje wywiadowcze, w których kluczowa jest cierpliwość, niski profil aktywności i ograniczanie śladów.

Wcześniejsze analizy także wskazywały na wykorzystanie zestawu fmapp.exe i fmapp.dll. Obecnie obserwowany wariant pokazuje jednak rozszerzenie tego modelu o dodatkowe binaria, skrypty pośredniczące oraz bardziej uporządkowany łańcuch po uzyskaniu dostępu do systemu. Szczególnie istotny jest przypadek dużego producenta elektroniki z Korei Południowej, gdzie intruzi mieli utrzymywać się w sieci przez około tydzień.

Analiza techniczna

Rdzeniem kampanii jest nadużycie zaufanych, podpisanych plików wykonywalnych do załadowania złośliwych bibliotek DLL. W jednym wariancie wykorzystywany był plik fmapp.exe, który ładował spreparowaną bibliotekę fmapp.dll. W drugim wariancie użyto sentinelmemoryscanner.exe, który uruchamiał złośliwy moduł sentinelagentcore.dll.

Taki mechanizm sprawia, że kod wykonywany jest w kontekście procesu wyglądającego na legalny. Z perspektywy obrony oznacza to niższą skuteczność części klasycznych mechanizmów antywirusowych oraz utrudnienia dla analityków SOC, którzy mogą początkowo uznać proces za nieszkodliwy.

Złośliwe biblioteki zawierały komponent oparty na narzędziu ChromElevator, używanym do pozyskiwania haseł, ciasteczek sesyjnych oraz danych kart płatniczych z przeglądarek opartych na Chromium. To ważny element całej operacji, ponieważ przejęcie cookies i sekretów aplikacyjnych może umożliwić napastnikom dostęp do usług webowych i chmurowych bez konieczności natychmiastowego przełamywania wszystkich mechanizmów MFA.

Łańcuch infekcji nie kończył się jednak na samym DLL side-loadingu. Atakujący wykorzystywali skrypty Node.js do uruchamiania poleceń PowerShell odpowiedzialnych za rozpoznanie środowiska i zbieranie danych o systemie. W praktyce implanty miały realizować wiele zadań operacyjnych.

Enumerację systemu, kont i zasobów.
Wykonywanie zrzutów ekranu.
Kradzież danych z rejestru i plików systemowych, w tym artefaktów związanych z bazą SAM.
Próby eskalacji uprawnień.
Tworzenie tuneli SOCKS5 do pośredniczenia ruchu.
Przygotowanie środowiska pod ruch boczny i dalszą eksfiltrację.

W części incydentów skradzione dane były tymczasowo przechowywane w publicznych usługach transferu plików. Taka metoda ogranicza potrzebę utrzymywania stale aktywnej komunikacji z infrastrukturą dowodzenia i kontroli, a jednocześnie może utrudniać korelację ruchu sieciowego. Charakterystyczne było również ponowne uruchamianie wykorzystanych binariów i skryptów, co wskazuje na model pracy oparty na trwałych implantach, a nie wyłącznie na ciągłej aktywności operatora.

Na poziomie detekcji szczególnie interesujące jest użycie binarium powiązanego z oprogramowaniem bezpieczeństwa. Taki zabieg działa zarówno technicznie, jak i psychologicznie: proces przypominający element znanego produktu ochronnego może zostać zignorowany, zaniżony w priorytecie lub błędnie uznany za część normalnej aktywności systemu.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem tego typu kampanii jest długotrwała, trudna do wykrycia obecność przeciwnika w środowisku ofiary. Jeśli napastnicy uzyskają dostęp do haseł, ciasteczek, sekretów aplikacyjnych i danych lokalnych z przeglądarek, mogą przejąć kontrolę nad znacznie większą częścią infrastruktury niż tylko nad pojedynczą stacją roboczą.

Przejmowanie sesji do usług chmurowych i paneli administracyjnych.
Omijanie części zabezpieczeń opartych na pojedynczym logowaniu i aktywnych sesjach.
Ruch boczny między segmentami sieci.
Budowanie dodatkowych kanałów dostępu przez tunele i proxy.
Pozyskiwanie danych operacyjnych, handlowych i technologicznych.

Ryzyko jest szczególnie wysokie dla organizacji przemysłowych, producentów elektroniki, instytucji publicznych oraz podmiotów finansowych. W takich środowiskach wartość informacji wywiadowczych jest bardzo duża, a pozornie niewielkie naruszenie może szybko doprowadzić do kompromitacji kont uprzywilejowanych, usług krytycznych lub danych biznesowych.

Niebezpieczeństwo wynika również z tego, że DLL side-loading często wykorzystuje dozwolone aplikacje i ścieżki wykonywania. Jeżeli dodatkowo dochodzi do kradzieży poświadczeń lokalnych i domenowych, incydent może eskalować od pojedynczego hosta do przejęcia większego segmentu infrastruktury.

Rekomendacje

Organizacje powinny rozwijać detekcję opartą na zachowaniu procesów, a nie tylko na ich nazwie, podpisie cyfrowym czy reputacji. Sam fakt, że proces jest podpisany i wygląda wiarygodnie, nie powinien być traktowany jako wystarczający dowód bezpieczeństwa.

W praktyce warto wdrożyć następujące działania ochronne i detekcyjne:

Blokować lub ograniczać wykonywanie nieautoryzowanych binariów z katalogów użytkownika i lokalizacji tymczasowych.
Monitorować zdarzenia image load dla procesów wysokiego ryzyka oraz wykrywać odchylenia od standardowego zestawu ładowanych bibliotek.
Analizować łańcuchy procesów obejmujące PowerShell, Node.js i procesy potomne uruchamiane przez legalne aplikacje użytkowe.
Ograniczać możliwość przechowywania i odczytu wrażliwych danych z przeglądarek na stacjach o podwyższonym ryzyku.
Segmentować sieć i utrudniać ruch boczny przez kontrolę SMB, RDP oraz komunikacji administracyjnej.
Monitorować ruch wychodzący do usług transferu plików i innych kanałów mogących służyć do etapowej eksfiltracji.
Prowadzić threat hunting ukierunkowany na biblioteki o nazwach zgodnych z legalnymi komponentami, ale zapisane poza standardowymi ścieżkami instalacyjnymi.
Rotować poświadczenia i unieważniać aktywne sesje po stwierdzeniu możliwej kradzieży danych z przeglądarek.
Wzmacniać telemetrię EDR o analizę modułów ładowanych do procesów podpisanych cyfrowo.
Utrzymywać procedury reagowania obejmujące analizę pamięci, artefaktów PowerShell, usług i zadań odpowiedzialnych za trwałość.

W środowiskach wysokiego ryzyka warto dodatkowo rozważyć allowlisting aplikacji oraz bardziej rygorystyczny audyt procesów, które wyglądają na zaufane, ale działają poza przewidywanym kontekstem biznesowym. Coraz większego znaczenia nabiera też centralne monitorowanie artefaktów związanych z kradzieżą danych z przeglądarek i eksportem cookies.

Podsumowanie

Kampania przypisywana MuddyWater potwierdza, że skuteczne operacje cyberszpiegowskie nie wymagają wyłącznie nowych exploitów ani wyjątkowo zaawansowanego malware. Wystarczy odpowiednio dobrany zestaw technik: legalne binaria, DLL side-loading, skrypty Node.js i PowerShell, kradzież danych z przeglądarek oraz ostrożne utrzymywanie dostępu.

Dla zespołów bezpieczeństwa najważniejsza lekcja jest prosta: legalny proces nie zawsze oznacza bezpieczny proces. Skuteczna obrona wymaga analizy pełnego łańcucha wykonania, bibliotek ładowanych do pamięci oraz rzeczywistego kontekstu, w jakim uruchamiane są aplikacje.

Źródła

https://thehackernews.com/2026/05/muddywater-uses-dll-side-loading-in.html
https://www.group-ib.com/blog/muddywater-operation-olalampo/
https://www.huntress.com/blog/muddywater-attack-chain
https://issues.chromium.org/issues/353746890