Wojciech Ciemski, Autor w serwisie Security Bez Tabu

Północnokoreańska kampania przeciw maintainerom Node.js otwiera nowy rozdział ataków na łańcuch dostaw npm

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania coraz częściej nie polegają na bezpośrednim łamaniu zabezpieczeń repozytoriów czy rejestrów pakietów, lecz na przejmowaniu zaufania do osób utrzymujących kluczowe komponenty open source. Najnowsza kampania przypisywana aktorowi powiązanemu z Koreą Północną pokazuje, że maintainerzy ekosystemu Node.js stali się celem długofalowych operacji socjotechnicznych, których efektem może być przejęcie kont publikacyjnych i wstrzyknięcie złośliwego kodu do popularnych pakietów npm.

To szczególnie niebezpieczny scenariusz, ponieważ kompromitacja pojedynczego opiekuna projektu może przełożyć się na ryzyko dla tysięcy organizacji korzystających z zaufanej biblioteki w procesach developerskich, testowych i produkcyjnych.

W skrócie

Według ustaleń branżowych grupa odpowiedzialna za incydent związany z pakietem Axios rozszerzyła działania na innych rozpoznawalnych maintainerów Node.js. Mechanizm ataku opierał się na budowaniu relacji z ofiarą, aranżowaniu pozornie wiarygodnych kontaktów biznesowych oraz nakłanianiu do instalacji fałszywej aktualizacji, która w rzeczywistości dostarczała zdalne złośliwe oprogramowanie.

Celem byli opiekunowie pakietów o bardzo dużym zasięgu.
Atak wykorzystywał socjotechnikę zamiast klasycznego włamania do platformy publikacyjnej.
Przejęcie legalnego konta maintainera umożliwia publikację złośliwej wersji pakietu pod wiarygodną tożsamością.
Ryzyko obejmuje nie tylko programistów, ale też pipeline’y CI/CD, systemy build oraz środowiska produkcyjne.

Kontekst / historia

Punktem odniesienia dla obecnej kampanii był incydent dotyczący Axios z 31 marca 2026 roku. W jego trakcie do rejestru npm trafiły dwie złośliwe wersje pakietu, które pozostawały dostępne przez około trzy godziny. Ze względu na skalę wykorzystania tej biblioteki zagrożenie objęło szeroki ekosystem aplikacji oraz środowisk automatyzujących budowę i wdrożenia.

Analizy po incydencie wskazały, że kompromitacja nie była skutkiem typowej podatności w kodzie ani błędu samej platformy. Znacznie bardziej prawdopodobnym scenariuszem było wcześniejsze zainfekowanie stacji roboczej maintainera poprzez starannie przygotowaną operację socjotechniczną. To ważna zmiana perspektywy: najcenniejszym zasobem dla napastnika nie jest już samo repozytorium, lecz człowiek posiadający uprawnienia do publikacji.

Tego typu działania wpisują się w szerszy trend obserwowany od kilku lat, w którym grupy państwowe i cyberprzestępcze koncentrują się na deweloperach, firmach technologicznych, projektach open source oraz organizacjach o wysokiej koncentracji zaufania i uprawnień.

Analiza techniczna

Z technicznego punktu widzenia kampania wyróżnia się wysokim poziomem przygotowania operacyjnego. Napastnicy mieli nawiązywać kontakt z ofiarami przez wiarygodnie wyglądające kanały komunikacji, organizować spotkania online i wykorzystywać scenariusze przypominające zwykłe rozmowy biznesowe, rekrutacyjne lub partnerskie. W trakcie takiej interakcji ofiara otrzymywała informację o błędzie oraz instrukcję instalacji rzekomej aktualizacji klienta, wtyczki albo komponentu potrzebnego do połączenia.

W praktyce taki plik działał jako loader instalujący malware klasy RAT. Po uruchomieniu implant mógł zapewnić zdalne wykonywanie poleceń, przejmowanie sesji, kradzież danych uwierzytelniających, eksfiltrację tokenów i dostęp do narzędzi developerskich wykorzystywanych przy publikacji pakietów.

W środowisku maintainera szczególnie cenne są:

tokeny npm i dane logowania do GitHuba,
klucze API oraz sekrety przechowywane lokalnie lub w menedżerach sekretów,
artefakty CI/CD i konfiguracje pipeline’ów,
podpisy wydawnicze oraz uprawnienia do publikacji nowych wersji,
historia sesji i zapisane poświadczenia w narzędziach komunikacyjnych.

W incydencie związanym z Axios kluczowe było opublikowanie złośliwych wersji pakietu z użyciem legalnego konta maintainera. Dodatkowo złośliwa funkcjonalność nie musiała być umieszczona bezpośrednio w głównej logice biblioteki. Zamiast tego mogła zostać ukryta w zależności uruchamiającej mechanizm instalacyjny odpowiedzialny za pobranie kolejnego etapu malware. To technika szczególnie groźna, ponieważ utrudnia szybką inspekcję kodu i może ominąć część podstawowych kontroli wykonywanych przez użytkowników pakietu.

W praktyce oznacza to atak „podpisany zaufaniem”. Gdy napastnik przejmuje legalną tożsamość wydawniczą, tradycyjne sygnały ostrzegawcze, takie jak literówka w nazwie paczki lub nowy, nieznany autor, przestają działać.

Konsekwencje / ryzyko

Skutki takich operacji wykraczają daleko poza pojedynczą zainfekowaną stację roboczą. Przejęcie maintainera może oznaczać kompromitację pakietów używanych przez tysiące lub miliony projektów, a następnie rozprzestrzenienie zagrożenia na kolejne organizacje poprzez automatyczne procesy pobierania i budowy zależności.

kompromitacja pakietów używanych przez ogromną liczbę projektów,
przejęcie środowisk build i wdrożeń automatycznych,
kradzież sekretów z pipeline’ów CI/CD,
infekcja stacji deweloperskich i runnerów budujących obrazy kontenerowe,
długotrwała obecność napastnika w organizacjach korzystających z automatycznych aktualizacji zależności.

Dla przedsiębiorstw oznacza to, że nawet krótkie okno publikacji złośliwej wersji może wystarczyć do skażenia środowisk testowych, produkcyjnych lub farm buildowych. Jeżeli instalacja pakietu uruchomiła dodatkowy kod, samo wycofanie wadliwej wersji z rejestru nie rozwiązuje problemu. Konieczna może być analiza śladów kompromitacji, przegląd historii buildów, rotacja sekretów oraz weryfikacja artefaktów utworzonych w czasie ekspozycji.

Na poziomie strategicznym kampania potwierdza, że open source stał się celem operacji państwowych nie tylko z powodu podatności technicznych, ale również z uwagi na koncentrację zaufania w rękach niewielkiej grupy maintainerów obsługujących krytyczne komponenty cyfrowej infrastruktury.

Rekomendacje

Organizacje rozwijające lub wykorzystujące oprogramowanie z ekosystemu Node.js powinny wdrożyć wielowarstwowe środki obronne. Ochrona software supply chain nie może kończyć się na skanowaniu bibliotek; musi obejmować tożsamość maintainerów, bezpieczeństwo endpointów oraz kontrolę procesu publikacji.

Po stronie maintainerów kluczowe są:

stosowanie sprzętowego MFA dla npm, GitHub i narzędzi komunikacyjnych,
eliminacja długowiecznych tokenów publikacyjnych,
rozdzielenie tożsamości prywatnej, konferencyjnej i wydawniczej,
publikowanie wyłącznie z utwardzonych, dedykowanych stacji roboczych,
ograniczenie ręcznego publikowania poza kontrolowanym pipeline’em,
monitorowanie zmian w adresach e-mail, tokenach i konfiguracji kont.

Po stronie organizacji korzystających z pakietów npm zalecane są:

twarde pinowanie wersji zależności i blokowanie niekontrolowanych aktualizacji,
używanie lockfile oraz wewnętrznych mirrorów lub proxy dla rejestrów pakietów,
skanowanie zależności pod kątem skryptów postinstall i anomalii w łańcuchu zależności,
budowanie SBOM i śledzenie pochodzenia komponentów,
wdrożenie polityk odrzucających artefakty spoza zatwierdzonego procesu,
monitoring runtime pod kątem nietypowych połączeń wychodzących po instalacji pakietów.

Równie ważne jest przygotowanie operacyjne na incydent supply chain. Zespół bezpieczeństwa powinien mieć gotowe procedury identyfikacji narażonych środowisk, odtwarzania historii buildów, blokady sekretów, wymiany poświadczeń oraz izolacji systemów, które mogły pobrać kolejny etap malware.

W obszarze socjotechniki warto wdrożyć dodatkowe zasady dla pracowników technicznych i maintainerów:

nie instalować aktualizacji przekazywanych ad hoc podczas spotkań,
weryfikować tożsamość nowych kontaktów biznesowych więcej niż jednym kanałem,
traktować zaproszenia dotyczące współpracy, rekrutacji lub inwestycji jako potencjalny wektor ataku,
zgłaszać każdą prośbę o uruchomienie pliku, skryptu lub „niezbędnej aktualizacji” poza standardowym procesem.

Podsumowanie

Kampania wymierzona w maintainerów Node.js pokazuje, że bezpieczeństwo łańcucha dostaw open source zależy dziś nie tylko od jakości kodu i zabezpieczeń platform, ale również od odporności ludzi pełniących role zaufania. Napastnicy wykorzystują cierpliwą socjotechnikę, realistyczną infrastrukturę komunikacyjną i malware dostarczane pod pretekstem rutynowych działań operacyjnych.

Dla organizacji to wyraźny sygnał, że ochrona software supply chain musi obejmować bezpieczeństwo tożsamości maintainera, twardą kontrolę procesu publikacji, ochronę stacji deweloperskich oraz szybkie procedury reagowania na kompromitację zaufanych zależności.

Źródła

SecurityWeek – North Korean Hackers Target High-Profile Node.js Maintainers – https://www.securityweek.com/north-korean-hackers-target-high-profile-node-js-maintainers/
Microsoft Security Blog – Mitigating the Axios npm supply chain compromise – https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/
Axios – North Korean hackers implicated in major supply chain attack – https://www.axios.com/2026/03/31/north-korean-hackers-implicated-in-major-supply-chain-attack
Elastic Security Labs – Inside the Axios supply chain compromise – one RAT to rule them all – https://www.elastic.co/security-labs/axios-one-rat-to-rule-them-all
Socket – Research on targeting of Node.js maintainers and npm supply chain activity – https://socket.dev/

Niemcy ujawniają „UNKN”. Domniemany lider REvil i GandCrab zidentyfikowany

Wprowadzenie do problemu / definicja

Ransomware od lat pozostaje jednym z najpoważniejszych zagrożeń dla firm, instytucji publicznych i operatorów infrastruktury krytycznej. Modele działania rozwijane przez grupy GandCrab i REvil wyznaczyły standardy dla nowoczesnych kampanii wymuszeń cyfrowych, łącząc szyfrowanie danych z presją reputacyjną i finansową.

Najnowsze ustalenia niemieckich organów ścigania wskazują na identyfikację osoby występującej pod pseudonimem „UNKN” lub „UNKNOWN”, łączonej z kierowaniem obiema operacjami. To ważny krok nie tylko z punktu widzenia śledczego, ale również analitycznego, ponieważ wzmacnia wcześniejsze hipotezy o ciągłości pomiędzy ekosystemami GandCrab i REvil.

W skrócie

Niemiecki Federalny Urząd Kryminalny poinformował o ujawnieniu tożsamości osoby podejrzewanej o kierowanie strukturami ransomware GandCrab i REvil. Według śledczych chodzi o 31-letniego obywatela Rosji, Daniila Maksimowicza Szczukina.

Wraz z drugim podejrzanym miał on odpowiadać za dziesiątki ataków, wymuszenia sięgające blisko 2 mln euro oraz szkody gospodarcze przekraczające 35 mln euro. Sprawa ma znaczenie operacyjne, ponieważ pokazuje, że nawet silnie zakonspirowane grupy cyberprzestępcze pozostawiają ślady umożliwiające ich identyfikację.

Kontekst / historia

GandCrab pojawił się na początku 2018 roku i szybko stał się jednym z najbardziej wpływowych projektów ransomware-as-a-service. Model ten umożliwiał operatorom rozwój złośliwego oprogramowania i infrastruktury, a afiliantom prowadzenie włamań oraz udział w zyskach z okupów.

Po formalnym wygaszeniu GandCrab w 2019 roku na pierwszy plan wysunął się REvil, znany również jako Sodinokibi. W środowisku analityków bezpieczeństwa od dawna zakładano, że nowa operacja była reorganizacją lub naturalną kontynuacją wcześniejszego modelu biznesowego rozwiniętego przez GandCrab.

REvil zasłynął z ataków na organizacje o wysokich przychodach oraz z agresywnego stosowania podwójnego wymuszenia. Oznaczało to nie tylko szyfrowanie systemów, ale również wcześniejszą kradzież danych i groźbę ich ujawnienia w przypadku odmowy zapłaty.

Szczególny rozgłos grupa zdobyła po ataku na Kaseya w lipcu 2021 roku. Incydent ten pokazał, jak niebezpieczne mogą być kampanie wymierzone w dostawców usług technologicznych, ponieważ kompromitacja jednego podmiotu może przełożyć się na zakłócenia u wielu klientów jednocześnie.

Analiza techniczna

Z technicznego punktu widzenia zarówno GandCrab, jak i REvil były dojrzałymi platformami ransomware-as-a-service. O ich skuteczności decydowało nie tylko samo szyfrowanie danych, lecz cały ekosystem operacyjny obejmujący wiele etapów ataku.

pozyskiwanie dostępu początkowego do środowiska ofiary,
eskalację uprawnień i ruch boczny w sieci,
eksfiltrację danych przed uruchomieniem szyfrowania,
obsługę negocjacji i płatności w kryptowalutach,
rozwój kolejnych wersji malware’u w celu omijania detekcji.

Kluczowe było rozdzielenie ról pomiędzy operatorów i afiliantów. Operatorzy odpowiadali za rozwój kodu, infrastrukturę i zaplecze płatnicze, natomiast afilianci dostarczali dostęp do zaatakowanych organizacji. Taki model zwiększał skalowalność i pozwalał szybciej monetyzować włamania.

Istotną zmianą było również przejście od prostego szyfrowania do podwójnego szantażu. Nawet jeśli ofiara dysponowała kopią zapasową i mogła odtworzyć systemy, pozostawało ryzyko wycieku danych, utraty zaufania klientów oraz konsekwencji prawnych i regulacyjnych.

Ustalenia niemieckich śledczych wzmacniają ocenę, że pomiędzy GandCrab a REvil istniały silne powiązania osobowe i operacyjne. W praktyce potwierdza to, że ekosystem ransomware nie opiera się wyłącznie na nazwach grup, lecz na relacjach, narzędziach, infrastrukturze i wyspecjalizowanym know-how.

Konsekwencje / ryzyko

Ujawnienie tożsamości domniemanego lidera nie oznacza automatycznego spadku zagrożenia. W świecie ransomware najcenniejszym zasobem pozostają kompetencje, procedury operacyjne, kontakty z afiliantami oraz zdolność do szybkiego odbudowania działalności pod nową marką.

Dla organizacji oznacza to utrzymujące się ryzyko w kilku obszarach. Po pierwsze, model ransomware-as-a-service nadal obniża próg wejścia dla przestępców i sprzyja szybkiemu odtwarzaniu struktur atakujących. Po drugie, szczególnie groźne pozostają ataki na dostawców usług, integratorów i partnerów technologicznych. Po trzecie, podwójne wymuszenie sprawia, że nawet skuteczne mechanizmy backupu nie eliminują całkowicie kosztu incydentu.

Z perspektywy obrony ważne jest również to, że grupy ransomware działają jak przedsiębiorstwa. Inwestują w automatyzację, rozwój kodu, specjalizację ról i poprawę efektywności kampanii, co przekłada się na coraz bardziej przewidywalny, ale i skuteczny model ataku.

Rekomendacje

Sprawa związana z identyfikacją „UNKN” przypomina, że ochrona przed ransomware wymaga podejścia warstwowego i operacyjnego. Skuteczna obrona nie sprowadza się do wdrożenia jednego produktu bezpieczeństwa, lecz wymaga połączenia kontroli technicznych, monitoringu i gotowości reagowania.

wdrożenie silnego MFA dla dostępu zdalnego i administracyjnego,
ograniczenie ekspozycji usług publicznych oraz segmentacja sieci,
regularne zarządzanie podatnościami i szybkie łatanie systemów brzegowych,
monitorowanie prób eksfiltracji danych i nietypowego ruchu lateralnego,
izolacja kopii zapasowych oraz ochrona ich przed usunięciem lub modyfikacją,
wdrożenie EDR/XDR z regułami wykrywania zachowań typowych dla ransomware,
przegląd kont uprzywilejowanych i ograniczenie nadmiarowych uprawnień,
testowanie procedur reagowania na incydenty, także w scenariuszu wycieku danych,
ocena ryzyka po stronie dostawców i partnerów technologicznych,
przygotowanie planów kryzysowych obejmujących aspekty prawne, operacyjne i komunikacyjne.

W praktyce kluczowe znaczenie ma wykrycie intruza przed etapem szyfrowania. Współczesne kampanie ransomware zostawiają ślady dużo wcześniej, między innymi podczas rozpoznania środowiska, przejmowania kont uprzywilejowanych, używania legalnych narzędzi administracyjnych czy uzyskiwania masowego dostępu do udziałów sieciowych.

Podsumowanie

Identyfikacja osoby łączonej z pseudonimem „UNKN” to istotny rozwój w analizie globalnego ekosystemu ransomware i kolejny sygnał, że GandCrab oraz REvil mogły być elementami tej samej lub silnie powiązanej struktury operacyjnej. Dla śledczych to cenny sukces, a dla obrońców potwierdzenie, że mapowanie zaplecza cyberprzestępczego ma realną wartość strategiczną.

Jednocześnie sprawa nie zmienia podstawowego faktu: ransomware pozostaje modelem wysoce adaptacyjnym, odpornym na rozbicie pojedynczej marki i nadal bardzo groźnym dla organizacji o rozbudowanej infrastrukturze oraz złożonym łańcuchu dostaw. Dlatego priorytetem powinno być skrócenie czasu detekcji, ograniczanie powierzchni ataku i gotowość do działania jeszcze przed etapem szyfrowania danych.

Źródła

Złośliwe pakiety NPM podszywające się pod wtyczki Strapi atakują użytkowników i infrastrukturę Guardarian

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla środowisk developerskich opartych na Node.js i JavaScript. Najnowszy incydent pokazuje, że publiczne rejestry pakietów mogą zostać wykorzystane do dystrybucji komponentów podszywających się pod legalne rozszerzenia, a ich instalacja otwiera drogę do uruchomienia złośliwego kodu, kradzieży poświadczeń i przejęcia infrastruktury.

W opisanej kampanii cyberprzestępcy opublikowali fałszywe pakiety NPM imitujące wtyczki do Strapi, czyli popularnego headless CMS. Celem operacji było nie tylko zainfekowanie środowisk użytkowników, ale także uzyskanie dostępu do zasobów powiązanych z platformą Guardarian.

W skrócie

Badacze zidentyfikowali 36 złośliwych pakietów NPM opublikowanych z czterech kont w ramach jednej kampanii wymierzonej w użytkowników Strapi. Ładunki zawarte w tych pakietach umożliwiały między innymi wykonanie kodu przez Redis, instalację reverse shelli, próbę ucieczki z kontenerów Docker, eksfiltrację konfiguracji oraz kradzież poświadczeń.

36 złośliwych pakietów opublikowanych w NPM
Kampania ukierunkowana na ekosystem Strapi
Ataki obejmowały Redis, Docker, PostgreSQL i Elasticsearch
Celem była również infrastruktura powiązana z Guardarian
Taktyka napastników ewoluowała od agresywnego przejęcia do rozpoznania i utrwalania dostępu

Kontekst / historia

Strapi to otwartoźródłowy system headless CMS zbudowany na Node.js, szeroko wykorzystywany do tworzenia aplikacji webowych, mobilnych i API. Popularność platformy oraz oparcie o zewnętrzne zależności sprawiają, że jej ekosystem jest naturalnym celem dla ataków supply chain.

W tej kampanii napastnicy wykorzystali zaufanie deweloperów do rejestru NPM i opublikowali pakiety imitujące rozszerzenia Strapi. Analiza wskazuje, że operacja była skoordynowana, a wzorce nazewnictwa, ścieżki konfiguracji i dobór technik sugerują przygotowanie pod konkretne wdrożenia działające na Linuksie i w środowiskach kontenerowych.

Analiza techniczna

Mechanizm ataku był stosunkowo prosty, ale bardzo skuteczny. Po zainstalowaniu fałszywej wtyczki złośliwy kod uruchamiał jeden z kilku payloadów, których zadaniem było pozyskanie dostępu do środowiska, danych aplikacyjnych i sekretów infrastrukturalnych.

Jeden z wariantów wykorzystywał Redis do modyfikowania zadań crontab, wdrażania webshelli PHP, uruchamiania reverse shelli w Node.js, dodawania kluczy SSH oraz eksfiltracji wybranych komponentów API. Taki zestaw działań wskazuje na próbę przejścia od jednorazowego wykonania kodu do trwałego utrzymania obecności w systemie.

Inny payload został zaprojektowany z myślą o środowiskach Docker. Obejmował wykrywanie warstw overlay, zapisywanie powłok w katalogach hosta, uruchamianie reverse shella oraz odczyt poświadczeń i danych powiązanych z backendem. To pokazuje, że atakujący zakładał obecność kontenerów i próbował wyjść poza granice pojedynczej instancji aplikacji.

Pozostałe ładunki skupiały się na zbieraniu poświadczeń, analizie konfiguracji Strapi, poszukiwaniu plików portfeli i kluczy, atakach na PostgreSQL oraz budowaniu mechanizmów trwałości. Istotne jest to, że kampania nie była ograniczona do jednego scenariusza kompromitacji, lecz obejmowała kilka ścieżek działania zależnie od architektury ofiary.

Konsekwencje / ryzyko

Skala ryzyka jest wysoka, ponieważ zagrożenie dotyczy pakietów instalowanych bezpośrednio w procesie wytwarzania i utrzymania aplikacji. W praktyce instalacja złośliwego komponentu może prowadzić do przejęcia hosta, wycieku danych aplikacyjnych, kompromitacji baz danych, utraty sekretów oraz naruszenia bezpieczeństwa środowisk kontenerowych.

W organizacjach obsługujących płatności, portfele kryptowalutowe lub wrażliwe dane skutki mogą być jeszcze poważniejsze. Poszukiwanie plików portfeli, kluczy i poświadczeń sugeruje wyraźną motywację finansową i wysoki poziom ukierunkowania ataku.

Dodatkowym problemem jest możliwość utrzymania dostępu nawet po usunięciu samego pakietu. Jeśli wcześniej doszło do dodania kluczy SSH, wpisów cron lub zapisania powłok na hoście, kompromitacja może przetrwać znacznie dłużej i umożliwić dalszy ruch boczny w infrastrukturze.

Rekomendacje

Organizacje korzystające ze Strapi i NPM powinny niezwłocznie przeanalizować historię instalowanych pakietów, zależności w projektach oraz aktywność w pipeline’ach CI/CD. Każde podejrzenie instalacji pakietu podszywającego się pod legalną wtyczkę należy traktować jako potencjalną pełną kompromitację systemu.

zweryfikować ostatnio instalowane pakiety i źródła ich publikacji,
przeprowadzić rotację haseł do baz danych i usług backendowych,
wymienić klucze API, sekrety JWT oraz klucze SSH,
sprawdzić wpisy cron, autostart i inne mechanizmy trwałości,
przeanalizować logi Redis, PostgreSQL, Elasticsearch i środowisk kontenerowych,
skontrolować połączenia wychodzące oraz oznaki aktywności reverse shelli,
zbadać integralność plików aplikacyjnych i konfiguracji,
zweryfikować mapowania wolumenów i uprawnienia kontenerów Docker.

Na poziomie strategicznym warto wdrożyć polityki dopuszczania zależności, korzystać z prywatnych repozytoriów lub proxy dla pakietów, rozwijać analizę SBOM i stosować narzędzia wykrywające podejrzane zachowania jeszcze przed instalacją komponentów w środowisku produkcyjnym.

Podsumowanie

Incydent z fałszywymi pakietami NPM podszywającymi się pod wtyczki Strapi potwierdza, że ataki supply chain pozostają jednym z najskuteczniejszych sposobów infiltracji nowoczesnych środowisk aplikacyjnych. Kampania łączyła techniki wykonania kodu, ucieczki z kontenerów, kradzieży poświadczeń, eksfiltracji konfiguracji i utrwalania dostępu.

Szczególnie niepokojące jest ukierunkowanie na infrastrukturę powiązaną z Guardarian oraz dopasowanie payloadów do realiów wdrożeń Strapi. Dla zespołów bezpieczeństwa to kolejny sygnał, że ochrona aplikacji musi obejmować nie tylko własny kod, ale cały ekosystem zależności, proces publikacji pakietów i bezpieczeństwo łańcucha dostaw oprogramowania.

Źródła

SecurityWeek — Guardarian Users Targeted With Malicious Strapi NPM Packages

Ataki webowe na agentów AI: Google DeepMind wskazuje nową powierzchnię zagrożeń

Wprowadzenie do problemu / definicja

Autonomiczni agenci AI coraz częściej działają w środowisku webowym, analizując strony internetowe, korzystając z narzędzi i wykonując operacje w imieniu użytkowników. To sprawia, że sama treść publikowana w sieci może stać się nośnikiem ataku, wpływając nie tylko na odpowiedzi modelu, ale również na jego decyzje i działania.

Badacze Google DeepMind opisali ten problem jako nową klasę zagrożeń, w której odpowiednio spreparowane zasoby internetowe mogą manipulować agentami AI. W praktyce oznacza to, że złośliwa zawartość strony może skłonić system do ujawnienia danych, wykonania niepożądanych operacji lub przyjęcia fałszywych założeń.

W skrócie

Google DeepMind przeanalizował, jak treści webowe mogą zostać wykorzystane do atakowania autonomicznych agentów AI. W badaniu wyróżniono sześć głównych klas zagrożeń, obejmujących ukryte instrukcje, manipulację znaczeniem treści, zatruwanie pamięci, przejmowanie kontroli nad zachowaniem systemu, ataki na środowiska wieloagentowe oraz nadużycia związane z udziałem człowieka w procesie decyzyjnym.

złośliwa treść może być ukryta w elementach niewidocznych dla użytkownika,
atak nie musi łamać infrastruktury bezpieczeństwa, aby przynieść skutki,
ryzyko obejmuje zarówno wyciek danych, jak i błędne działania operacyjne,
szczególnie narażone są systemy z pamięcią trwałą i szerokim dostępem do narzędzi.

Kontekst / historia

Dotychczas dyskusja o bezpieczeństwie modeli językowych koncentrowała się głównie na prompt injection, jailbreakach, wyciekach danych i nadmiernych uprawnieniach. Wraz z rozwojem agentów AI problem przestał jednak dotyczyć wyłącznie samego modelu i objął także całe środowisko operacyjne, w którym agent działa.

Nowe podejście zakłada traktowanie internetu jako aktywnej powierzchni ataku. Nie chodzi już tylko o pojedyncze polecenia kierowane do modelu, ale o systematyczne przygotowywanie treści, które wykorzystują sposób parsowania danych, interpretacji kontekstu, priorytetyzacji celów oraz wykonywania instrukcji przez agentów.

Analiza techniczna

Badacze opisali sześć klas ataków, które mogą być realizowane za pośrednictwem zawartości webowej. Pierwszą z nich jest wstrzykiwanie treści, czyli ukrywanie instrukcji w komentarzach HTML, metadanych, elementach niewidocznych dla człowieka lub danych dostarczanych dynamicznie. Tego rodzaju rozbieżność między tym, co widzi użytkownik, a tym, co przetwarza agent, tworzy przestrzeń do niejawnego sterowania systemem.

Drugą kategorią jest manipulacja semantyczna. W tym przypadku atakujący nie musi ukrywać komend, lecz wykorzystuje odpowiednio sformułowany język, aby przesunąć interpretację kontekstu, osłabić walidację lub wpłynąć na priorytety agenta. Efektem może być błędna ocena sytuacji i podjęcie decyzji zgodnych z interesem napastnika.

Trzecia grupa obejmuje ataki na stan poznawczy agenta, w szczególności na pamięć długoterminową, logi, zewnętrzne bazy wiedzy i mechanizmy uczenia na podstawie wcześniejszych interakcji. Zatrucie takich zasobów może nie dawać natychmiastowego efektu, ale prowadzić do błędów ujawniających się dopiero w kolejnych zadaniach.

Czwarta klasa dotyczy sterowania zachowaniem. Obejmuje osadzone jailbreaki, próby wymuszenia ujawnienia danych uprzywilejowanych oraz skłanianie agenta do uruchamiania podagentów lub narzędzi z jego uprawnieniami. W złożonych procesach automatyzacji może to prowadzić do eskalacji skutków i rozszerzania zasięgu incydentu.

Piąta kategoria to ataki systemowe w środowiskach wieloagentowych. W takich architekturach jeden agent może przekazywać dane kolejnemu, a decyzje mogą opierać się na założeniu zaufania i podobnym sposobie działania modeli. To zwiększa ryzyko efektu domina, w którym pojedyncza manipulacja wpływa na całą sekwencję operacji.

Szósta klasa obejmuje scenariusze human-in-the-loop. Agent może zostać tak zmanipulowany, aby przekazać człowiekowi fałszywe rekomendacje lub wiarygodnie brzmiące instrukcje, które w rzeczywistości realizują cel atakującego. To szczególnie groźne tam, gdzie użytkownik nadmiernie ufa analizie przygotowanej przez system AI.

Konsekwencje / ryzyko

Z perspektywy przedsiębiorstw problem ma znaczenie praktyczne, ponieważ agenci AI coraz częściej uzyskują dostęp do poczty elektronicznej, systemów CRM, platform SaaS, repozytoriów dokumentów i narzędzi administracyjnych. Jeśli taki system przetwarza niezaufaną treść bez odpowiedniej izolacji, ryzyko obejmuje zarówno poufność informacji, jak i integralność procesów biznesowych.

Możliwe skutki to wyciek danych, wykonywanie nieautoryzowanych działań, generowanie błędnych decyzji operacyjnych, zatruwanie pamięci trwałej, propagacja dezinformacji oraz wykorzystanie agenta przeciwko jego operatorowi. W środowiskach wieloagentowych zagrożenie rozszerza się dodatkowo na kolejne komponenty automatyzacji.

Istotne jest również to, że wiele z opisanych technik nie wymaga klasycznego przełamania zabezpieczeń infrastrukturalnych. Wystarczy odpowiednio przygotowana treść wejściowa, co przesuwa ciężar obrony z blokowania exploitów na kontrolę zaufania do danych, ograniczanie uprawnień i monitorowanie działań agentów.

Rekomendacje

Organizacje wdrażające agentów AI powinny traktować treści internetowe jako potencjalnie wrogie dane wejściowe. Niezbędne staje się oddzielenie warstwy prezentowanej człowiekowi od warstwy interpretowanej przez model oraz filtrowanie zbędnych metadanych, ukrytych instrukcji i artefaktów, które nie są konieczne do realizacji zadania.

Kluczowe pozostaje stosowanie zasady najmniejszych uprawnień. Agent nie powinien mieć dostępu do narzędzi, danych i operacji, które nie są absolutnie niezbędne. Szczególną ostrożność należy zachować przy działaniach nieodwracalnych, takich jak wysyłanie wiadomości, modyfikacja rekordów, inicjowanie procesów czy przekazywanie danych do usług zewnętrznych.

wdrożenie walidacji kontekstu i filtrowania treści wejściowych,
monitorowanie sekwencji działań agenta pod kątem anomalii,
wprowadzenie dodatkowych potwierdzeń dla operacji wysokiego ryzyka,
wersjonowanie i audyt pamięci trwałej,
segmentacja ról i ograniczanie współdzielonego kontekstu w architekturach wieloagentowych,
regularne testy red-teamowe ukierunkowane na prompt injection i content injection.

Ważnym elementem powinny być także procedury governance, obejmujące polityki dopuszczalnych źródeł danych, klasyfikację działań wymagających nadzoru człowieka oraz ocenę odporności systemów agentowych przed wdrożeniem produkcyjnym.

Podsumowanie

Badania Google DeepMind pokazują, że bezpieczeństwo agentów AI należy analizować nie tylko na poziomie modelu, ale także środowiska, w którym działa. Złośliwe strony internetowe, ukryte instrukcje, zatrute źródła pamięci i manipulacja relacją człowiek–agent tworzą nową, praktyczną powierzchnię ataku.

Dla zespołów bezpieczeństwa to sygnał, że modele zagrożeń muszą objąć również warstwę agentową i operacyjną. Firmy planujące szerokie wdrożenia autonomicznych systemów AI powinny już teraz inwestować w izolację danych wejściowych, ograniczanie uprawnień, kontrolę pamięci oraz audyt decyzji podejmowanych przez agentów.

Źródła

Oszuści przenoszą kampanie SMS o mandatach do kodów QR

Wprowadzenie do problemu / definicja

Cyberprzestępcy rozwijają kampanie smishingowe, w których podszywają się pod sądy, wydziały komunikacji i inne instytucje stanowe w USA. Najnowsza odsłona tego procederu wykorzystuje kody QR zamiast tradycyjnych linków, aby skłonić odbiorców do opłacenia rzekomego mandatu, opłaty drogowej lub należności parkingowej.

To przykład tzw. quishingu, czyli phishingu prowadzonego z użyciem kodów QR. Taka metoda utrudnia wykrywanie zagrożenia przez część systemów bezpieczeństwa i zwiększa szansę, że użytkownik sam przejdzie do fałszywej strony płatności.

W skrócie

Atak rozpoczyna się od wiadomości SMS stylizowanej na pilne wezwanie do uregulowania wykroczenia drogowego. Zamiast bezpośredniego odnośnika wiadomość zawiera obraz z kodem QR, który po zeskanowaniu kieruje ofiarę do wieloetapowego łańcucha przekierowań.

Po drodze użytkownik może zostać poproszony o rozwiązanie testu CAPTCHA, a następnie trafia na stronę imitującą oficjalny serwis urzędowy. Tam przestępcy wyłudzają dane osobowe i dane karty płatniczej, często pod pretekstem niewielkiej opłaty, która ma uśpić czujność ofiary.

Kontekst / historia

Oszustwa związane z fałszywymi mandatami, opłatami drogowymi i parkingowymi były szeroko obserwowane już wcześniej, jednak wcześniejsze kampanie zwykle opierały się na klasycznych linkach umieszczanych bezpośrednio w treści SMS-a. Obecna zmiana pokazuje ewolucję taktyki po stronie przestępców.

Zastąpienie adresu URL kodem QR nie jest przypadkowe. Atakujący dostosowują swoje metody do rosnącej świadomości użytkowników oraz do zabezpieczeń, które coraz skuteczniej wykrywają podejrzane linki. Jednocześnie wykorzystują dobrze znane mechanizmy socjotechniczne: presję czasu, groźbę konsekwencji prawnych i stosunkowo niską kwotę do zapłaty.

Kampanie tego typu mogą być łatwo lokalizowane pod różne stany i regiony, co zwiększa ich wiarygodność. Odbiorca ma wrażenie, że komunikat pochodzi od znanej, lokalnej instytucji, a sprawa wymaga natychmiastowej reakcji.

Analiza techniczna

Łańcuch ataku zaczyna się od wiadomości pochodzącej z nieznanego numeru lub nadawcy. SMS zawiera grafikę przypominającą oficjalne zawiadomienie o zaległej płatności, a centralnym elementem jest kod QR prowadzący do infrastruktury kontrolowanej przez przestępców.

Po zeskanowaniu kodu użytkownik nie trafia od razu na właściwy formularz phishingowy. Najpierw przechodzi przez stronę pośrednią, która może służyć do profilowania ofiary, zarządzania przekierowaniem oraz utrudniania analizy przez badaczy bezpieczeństwa i systemy automatyczne.

Włączenie CAPTCHA do tego procesu dodatkowo ogranicza skuteczność narzędzi analizujących podejrzane adresy w sposób automatyczny. Dopiero po wykonaniu tego kroku ofiara zostaje przekierowana do witryny podszywającej się pod urząd lub agencję stanową.

Fałszywe strony są projektowane tak, aby przypominały oficjalne portale administracyjne. Zwykle wyświetlają niewielką zaległość i prowadzą użytkownika przez formularz zbierający:

imię i nazwisko,
adres zamieszkania,
numer telefonu,
adres e-mail,
dane karty płatniczej.

Z punktu widzenia obrony ważne jest to, że skutkiem ataku nie musi być wyłącznie pojedyncze obciążenie karty. Zebrane informacje mogą zostać wykorzystane do dalszych oszustw finansowych, kradzieży tożsamości, kolejnych kampanii phishingowych lub sprzedaży danych w cyberprzestępczym obiegu.

Konsekwencje / ryzyko

Najbardziej oczywistą konsekwencją jest utrata środków finansowych i przejęcie danych płatniczych. W praktyce skala ryzyka jest jednak znacznie szersza, ponieważ przestępcy pozyskują także pełen zestaw danych osobowych przydatnych w dalszych nadużyciach.

kradzież tożsamości,
zakładanie kont lub usług na dane ofiary,
przygotowanie kolejnych, bardziej wiarygodnych ataków socjotechnicznych,
ukierunkowane oszustwa bankowe,
obrót pakietami danych w podziemnym ekosystemie cyberprzestępczym.

Dodatkowym czynnikiem ryzyka jest psychologia ataku. Komunikaty o rzekomych mandatach i obowiązku stawienia się przed sądem wywołują stres, a niska kwota płatności może skłonić ofiarę do szybkiego działania bez weryfikacji autentyczności wiadomości.

Rekomendacje

Użytkownicy indywidualni i organizacje powinni traktować nieoczekiwane SMS-y dotyczące mandatów, opłat drogowych lub spraw urzędowych jako potencjalnie złośliwe, zwłaszcza jeśli zawierają kod QR. W takich przypadkach warto stosować podstawowe, ale konsekwentne zasady bezpieczeństwa.

nie skanować kodów QR z nieoczekiwanych wiadomości,
nie korzystać z danych kontaktowych i instrukcji podanych w podejrzanym SMS-ie,
weryfikować sprawę wyłącznie przez oficjalny portal instytucji lub numer znaleziony samodzielnie,
edukować użytkowników w zakresie smishingu i quishingu,
uwzględniać urządzenia mobilne w politykach bezpieczeństwa,
monitorować domeny podszywające się pod instytucje publiczne,
blokować znane domeny phishingowe na poziomie DNS, proxy oraz narzędzi EDR i MDM,
zgłaszać incydenty operatorom i właściwym zespołom reagowania.

W środowiskach firmowych szczególnie istotne jest rozszerzenie detekcji zagrożeń o scenariusze mobilne. Klasyczne zabezpieczenia poczty elektronicznej nie są wystarczające, jeśli użytkownik inicjuje kontakt z infrastrukturą atakującego przez skanowanie obrazu smartfonem.

Podsumowanie

Przeniesienie kampanii phishingowych z tradycyjnych linków do kodów QR pokazuje, że oszuści aktywnie dostosowują się do mechanizmów obronnych i zachowań użytkowników. Połączenie quishingu, CAPTCHA i wieloetapowych przekierowań zwiększa skuteczność ataku i utrudnia jego automatyczne wykrywanie.

Dla obrońców oznacza to konieczność szerszego spojrzenia na bezpieczeństwo mobilne, a dla użytkowników przypomnienie podstawowej zasady: każdą prośbę o natychmiastową płatność należy weryfikować wyłącznie przez oficjalne kanały instytucji, nigdy przez treść otrzymanej wiadomości.

Źródła

BleepingComputer — https://www.bleepingcomputer.com/news/security/traffic-violation-scams-switch-to-qr-codes-in-new-phishing-texts/
Governor of New York — Consumer Alert: New York State agencies do not request personal or payment information by text message — https://www.governor.ny.gov/

Qilin i Warlock wykorzystują podatne sterowniki do wyłączania EDR i obchodzenia ochrony Windows

Wprowadzenie do problemu / definicja

Technika BYOVD, czyli Bring Your Own Vulnerable Driver, polega na wykorzystaniu legalnie podpisanych, ale podatnych sterowników do uzyskania dostępu na poziomie jądra systemu. W praktyce daje to atakującym możliwość obchodzenia mechanizmów ochronnych, wyłączania agentów bezpieczeństwa i ograniczania widoczności działań po przejęciu stacji lub serwera.

Najnowsze obserwacje pokazują, że grupy ransomware Qilin i Warlock aktywnie stosują ten model operacyjny, aby neutralizować rozwiązania EDR i zwiększać skuteczność końcowych etapów ataku. To wyraźny sygnał, że sama ochrona endpointów bez kontroli integralności sterowników staje się niewystarczająca.

W skrócie

Qilin i Warlock wykorzystują technikę BYOVD do wyłączania lub omijania zabezpieczeń endpointów.
Qilin stosuje wieloetapowy łańcuch infekcji z użyciem biblioteki „msimg32.dll” uruchamianej techniką DLL side-loading.
Ładunek Qilin ma zdolność eliminowania ponad 300 sterowników EDR należących do wielu dostawców.
Warlock łączy eksploatację niezałatanych serwerów SharePoint z użyciem podatnego sterownika jądra do terminowania produktów ochronnych.
Oba przypadki pokazują rosnące znaczenie ataków wymierzonych bezpośrednio w mechanizmy kernel-mode.

Kontekst / historia

BYOVD nie jest nowym zjawiskiem, jednak w ostatnich latach stał się szczególnie ważnym elementem operacji ransomware. Zamiast tworzyć własne rootkity, operatorzy coraz częściej sięgają po podpisane sterowniki wydane pierwotnie do legalnych zastosowań, lecz zawierające luki umożliwiające wykonywanie uprzywilejowanych operacji.

Taki model jest atrakcyjny z perspektywy przestępców, ponieważ pozwala przejść przez część mechanizmów zaufania systemu Windows i wykonywać działania na poziomie jądra bez konieczności stosowania bardziej zaawansowanych exploitów. To również utrudnia detekcję, ponieważ wykorzystywane komponenty na pierwszy rzut oka mogą wyglądać jak legalne elementy systemowe.

W analizowanych kampaniach Qilin wyróżnia się skalą aktywności oraz naciskiem na działania po uzyskaniu dostępu. Warlock z kolei rozwija klasyczny schemat ransomware o szerokie użycie narzędzi administracyjnych i tunelujących, co wskazuje na dojrzały model prowadzenia intruzji. Wspólnym mianownikiem obu operacji jest próba wyłączenia telemetrii i ochrony jeszcze przed wdrożeniem szyfrowania lub eksfiltracji danych.

Analiza techniczna

W przypadku Qilin łańcuch infekcji rozpoczyna się od biblioteki „msimg32.dll”, uruchamianej techniką side-loading. Komponent ten działa jako loader PE, który przygotowuje środowisko wykonawcze dla właściwego modułu odpowiedzialnego za neutralizację narzędzi ochronnych. Drugi etap jest osadzony w loaderze w postaci zaszyfrowanej i deszyfrowany dopiero podczas działania w pamięci, co ogranicza liczbę artefaktów pozostawianych na dysku.

Loader wykorzystuje kilka mechanizmów utrudniających wykrycie. Obejmują one neutralizację hooków w przestrzeni użytkownika, tłumienie zdarzeń Event Tracing for Windows oraz ukrywanie wzorców przepływu sterowania i wywołań API. Celem jest ograniczenie widoczności zarówno dla produktów EDR, jak i dla narzędzi analizy behawioralnej.

Po uruchomieniu malware korzysta z dwóch sterowników. Pierwszy, „rwdrv.sys”, jest przemianowaną wersją „ThrottleStop.sys” i służy do uzyskania dostępu do pamięci fizycznej jako warstwa działająca w trybie jądra. Drugi, „hlpdrv.sys”, odpowiada za końcowe terminowanie procesów i komponentów związanych z ponad 300 sterownikami EDR. Przed jego załadowaniem malware wyrejestrowuje callbacki monitorujące ustanowione przez oprogramowanie ochronne, aby proces dezaktywacji przebiegał bez zakłóceń.

W przypadku Warlock technika BYOVD została zintegrowana z szerszym łańcuchem ataku. Grupa wykorzystuje niezałatane serwery Microsoft SharePoint, a następnie wdraża zestaw narzędzi wspierających trwałość, ruch boczny i unikanie detekcji. Wśród obserwowanych elementów znalazły się TightVNC, PsExec, RDP Patcher, Velociraptor, Visual Studio Code, Cloudflare Tunnel, Yuze i Rclone. Do wyłączania produktów bezpieczeństwa na poziomie jądra wykorzystywany jest podatny sterownik „NSecKrnl.sys”, który zastąpił wcześniejszy komponent używany w poprzednich kampaniach.

Z technicznego punktu widzenia najważniejsze jest to, że oba przypadki pokazują przesunięcie akcentu z prostego omijania procesów user-mode na aktywne operacje przeciwko mechanizmom kernel-mode. Oznacza to, że klasyczne wykrywanie oparte na procesach, usługach lub artefaktach na dysku może nie wystarczać, jeśli organizacja nie monitoruje ładowania sterowników, zmian integralności jądra oraz anomalii w callbackach systemowych.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją użycia BYOVD jest możliwość skutecznego oślepienia narzędzi obronnych jeszcze przed uruchomieniem właściwego ransomware. Jeżeli agent EDR zostanie wyłączony lub jego sterowniki zostaną unieszkodliwione, organizacja traci widoczność telemetryczną w najbardziej krytycznej fazie incydentu.

Utrudnia to wykrycie eskalacji uprawnień, identyfikację eksfiltracji danych, obserwację ruchu bocznego oraz rozpoznanie przygotowań do szyfrowania. Dodatkowe ryzyko wynika z wykorzystania legalnie podpisanych sterowników, które mogą zostać początkowo uznane za wiarygodne przez system operacyjny i część narzędzi kontroli aplikacji.

Jeśli środowisko nie wdraża ścisłej polityki dopuszczania sterowników, atakujący mogą uruchomić kod jądra bez konieczności używania podatności typu zero-day. W praktyce zwiększa to skuteczność ataków na organizacje o wysokim poziomie dojrzałości bezpieczeństwa, które opierają się głównie na ochronie endpointów i detekcji behawioralnej.

W przypadku Qilin dodatkowo niepokojący jest czas pomiędzy uzyskaniem dostępu a uruchomieniem ransomware, wynoszący średnio około sześciu dni. Taki odstęp daje przestępcom możliwość rozpoznania środowiska, pozyskania poświadczeń, eskalacji uprawnień i przygotowania mechanizmów wyłączania ochrony. Oznacza to, że okno na wykrycie ataku istnieje, ale szybko się zamyka, jeśli telemetryka zostanie osłabiona na późniejszym etapie operacji.

Rekomendacje

Organizacje powinny wdrożyć ścisłą kontrolę sterowników ładowanych w systemach Windows, w tym ograniczenie do podpisanych komponentów pochodzących wyłącznie od jawnie zaufanych wydawców. Sam podpis cyfrowy nie powinien być jedynym kryterium zaufania, ponieważ to właśnie legalne, lecz podatne sterowniki są nadużywane w technice BYOVD.

Niezbędne jest monitorowanie zdarzeń związanych z instalacją i ładowaniem sterowników oraz korelowanie ich z anomaliami w pracy agentów EDR. Szczególną uwagę warto poświęcić przypadkom pojawienia się nietypowych plików SYS, zmianom w callbackach jądra, nagłemu zanikowi telemetrii oraz nieoczekiwanemu zakończeniu procesów ochronnych.

Kluczowe pozostaje również rygorystyczne zarządzanie poprawkami, zwłaszcza dla komponentów bezpieczeństwa wykorzystujących sterowniki oraz dla systemów brzegowych, takich jak SharePoint. W środowiskach o podwyższonym ryzyku warto rozważyć dodatkowe mechanizmy polityk aplikacyjnych, kontroli integralności kernela oraz regularne przeglądy list blokowanych podatnych sterowników.

Po stronie operacyjnej warto rozwijać procedury wykrywania aktywności poprzedzającej szyfrowanie, takich jak kradzież poświadczeń, ruch boczny, użycie narzędzi administracyjnych, tunelowanie ruchu oraz eksfiltracja danych. Obrona przed ransomware nie powinna zaczynać się dopiero na etapie uruchomienia szyfratora, lecz znacznie wcześniej — w fazie nadużycia dostępu i przygotowania środowiska do sabotażu zabezpieczeń.

Podsumowanie

Aktywność Qilin i Warlock pokazuje, że BYOVD stał się dojrzałym i praktycznym narzędziem w arsenale operatorów ransomware. Wzorzec jest coraz bardziej czytelny: najpierw wyłączenie ochrony na poziomie endpointu i kernela, następnie utrzymanie dostępu, ruch boczny i przygotowanie środowiska, a dopiero na końcu działania destrukcyjne lub wymuszające okup.

Dla zespołów bezpieczeństwa oznacza to konieczność przesunięcia uwagi z samego malware na wcześniejsze etapy intruzji oraz na kontrolę integralności sterowników i widoczność działań w jądrze systemu. Bez tego nawet zaawansowane rozwiązania EDR mogą zostać skutecznie unieszkodliwione przed momentem, w którym zdążą zareagować.

Źródła

The Hacker News — Qilin and Warlock Ransomware Use Vulnerable Drivers to Disable 300+ EDR Tools — https://thehackernews.com/2026/04/qilin-and-warlock-ransomware-use.html
Cisco Talos Blog — Qilin ransomware technical analysis — https://blog.talosintelligence.com/qilin-ransomware/
Trend Micro Research — Inside Water Gamayun/Warlock ransomware attack playbook — https://www.trendmicro.com/en_us/research/26/d/inside-water-gamka-warlock-ransomware-attack-playbook.html
MITRE ATT&CK — BYOVD and defense evasion related techniques — https://attack.mitre.org/

Irańska kampania password spraying atakuje Microsoft 365. Ponad 300 organizacji w Izraelu na celowniku

Wprowadzenie do problemu / definicja

Password spraying to technika ataku polegająca na sprawdzaniu niewielkiej liczby popularnych haseł wobec dużej liczby kont użytkowników. W przeciwieństwie do klasycznego brute force nie skupia się na jednym koncie, lecz rozprasza próby logowania, dzięki czemu trudniej ją wykryć i zablokować. Najnowsza kampania przypisywana aktorowi powiązanemu z Iranem pokazuje, że metoda ta pozostaje bardzo skuteczna przeciwko środowiskom Microsoft 365, zwłaszcza tam, gdzie organizacje nadal mają problemy z jakością haseł i pełnym wdrożeniem MFA.

W skrócie

Badacze bezpieczeństwa opisali wieloetapową kampanię password spraying wymierzoną głównie w organizacje w Izraelu oraz Zjednoczonych Emiratach Arabskich. Ataki miały występować w trzech falach w marcu 2026 roku i objęły ponad 300 organizacji w Izraelu oraz ponad 25 w ZEA, a pojedyncze przypadki odnotowano również w Europie, Stanach Zjednoczonych, Wielkiej Brytanii i Arabii Saudyjskiej.

Najczęściej celem były środowiska Microsoft 365 należące do administracji publicznej, samorządów, firm technologicznych, podmiotów z sektora transportowego i energetycznego oraz organizacji prywatnych. Schemat działania obejmował masowe próby logowania z użyciem infrastruktury Tor, a następnie korzystanie z komercyjnych usług VPN do dalszego dostępu i przeglądania danych, w tym skrzynek pocztowych.

Atak opierał się na rozproszonych próbach logowania do wielu kont.
Napastnicy wykorzystywali zarówno sieć Tor, jak i komercyjne usługi VPN.
Głównym celem były dane przechowywane w ekosystemie Microsoft 365.
Największe ryzyko dotyczyło organizacji publicznych i sektorów krytycznych.

Kontekst / historia

Password spraying od lat pozostaje jednym z podstawowych sposobów uzyskiwania initial access przez grupy APT oraz operatorów prowadzących ukierunkowane operacje wywiadowcze. Microsoft 365 jest szczególnie atrakcyjnym celem, ponieważ stanowi centralny punkt komunikacji, współpracy i przechowywania dokumentów w nowoczesnych organizacjach.

W opisywanej kampanii analitycy wskazali na możliwe powiązania z interesami operacyjnymi Iranu. Zwrócono uwagę, że znaczącą grupę ofiar stanowiły izraelskie jednostki samorządowe, a dobór części celów miał korelować z obszarami dotkniętymi marcowymi atakami rakietowymi. Taki profil wskazuje, że operacja mogła mieć znaczenie nie tylko wywiadowcze, ale również wspierać szersze działania związane z oceną skutków zdarzeń kinetycznych.

Badacze odnotowali również podobieństwa do wcześniejszych działań irańskich klastrów zagrożeń, w tym aktywności kojarzonej z Peach Sandstorm i Gray Sandstorm, które wcześniej wykorzystywały password spraying jako skuteczny wektor wejścia do środowisk chmurowych.

Analiza techniczna

Kampania była prowadzona etapowo. W pierwszej fazie napastnicy wykonywali intensywne skanowanie i masowe próby logowania do wielu tenantów Microsoft 365. Wykorzystywali przy tym adresy IP pochodzące z węzłów wyjściowych sieci Tor, regularnie je zmieniając, aby utrudnić blokowanie oraz osłabić skuteczność prostych mechanizmów detekcyjnych opartych na pojedynczym wskaźniku sieciowym.

W ruchu obserwowano także User-Agent podszywający się pod starszą wersję Internet Explorera. Taki zabieg mógł służyć ujednoliceniu wzorca ruchu lub maskowaniu aktywności. Sama technika nie wymagała użycia exploita ani złośliwego oprogramowania na etapie początkowym, ponieważ opierała się wyłącznie na skutecznym odgadnięciu słabych lub powtarzalnych haseł.

Po uzyskaniu poprawnych poświadczeń operatorzy przechodzili do drugiej fazy. Zamiast kontynuować działania z infrastruktury anonimizującej, logowali się przez komercyjne usługi VPN. Część adresów IP była geolokalizowana w Izraelu, co mogło zmniejszać ryzyko wzbudzenia alarmu oraz pomagać w obchodzeniu polityk opartych na lokalizacji.

Trzeci etap obejmował wykorzystanie legalnego dostępu do przeglądania i potencjalnej eksfiltracji informacji. Oznaczało to przede wszystkim dostęp do poczty elektronicznej, ale również do innych zasobów dostępnych w ekosystemie Microsoft 365. Z punktu widzenia obrońcy szczególnie niebezpieczne jest to, że skuteczne logowanie mogło wyglądać jak zwykła aktywność użytkownika, zwłaszcza po przejściu z Tora na lokalnie geolokalizowany VPN.

Faza 1: rozproszone próby logowania z sieci Tor.
Faza 2: logowanie z użyciem komercyjnych usług VPN.
Faza 3: dostęp do skrzynek pocztowych i innych danych w chmurze.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem skutecznego password spraying jest przejęcie legalnego dostępu do kont użytkowników. W przypadku organizacji publicznych i podmiotów infrastrukturalnych może to prowadzić do ujawnienia korespondencji operacyjnej, danych osobowych, dokumentów wewnętrznych, harmonogramów działań, list kontaktowych oraz informacji o incydentach.

W środowisku Microsoft 365 kompromitacja jednego konta bardzo często staje się punktem wyjścia do dalszego rekonesansu. Napastnik może analizować relacje zaufania, wykorzystywać przejętą skrzynkę do phishingu wewnętrznego, przeglądać zasoby SharePoint, Teams i OneDrive, a następnie rozszerzać dostęp bez uruchamiania malware. To znacząco utrudnia wykrycie przez klasyczne rozwiązania endpoint security.

Szczególne zagrożenie dotyczy jednostek samorządowych i sektorów krytycznych. Nawet ograniczony dostęp do poczty może dostarczyć informacji o procesach reagowania kryzysowego, stanie usług publicznych, partnerach zewnętrznych i procedurach operacyjnych. Jeżeli kampania była skorelowana z działaniami militarnymi, jej znaczenie wykracza poza standardową cyberprzestępczość i wpisuje się w logikę działań państwowych.

Rekomendacje

Podstawowym środkiem ochrony pozostaje pełne wymuszenie MFA dla wszystkich użytkowników, bez wyjątków dla kont uprzywilejowanych, administracyjnych czy serwisowych. Tam, gdzie to możliwe, warto wybierać metody odporne na phishing, takie jak klucze sprzętowe lub nowoczesne mechanizmy bezhasłowe.

Organizacje powinny stale monitorować logi uwierzytelniania pod kątem wzorców typowych dla password spraying. Chodzi przede wszystkim o wiele nieudanych prób logowania wobec licznych kont, realizowanych z jednego źródła lub z grupy powiązanych źródeł. Detekcja nie może opierać się wyłącznie na pojedynczym adresie IP, ponieważ atakujący aktywnie rotują infrastrukturę.

Konieczne jest także wdrożenie polityk Conditional Access, które ograniczają logowanie do zatwierdzonych lokalizacji, urządzeń i poziomów ryzyka. W praktyce warto blokować lub dodatkowo weryfikować logowania z sieci anonimizujących, w tym z węzłów Tor, oraz z nietypowych usług VPN.

Wymusić MFA dla wszystkich kont.
Stosować silne i unikalne hasła.
Monitorować logi pod kątem rozproszonych prób logowania.
Wdrożyć Conditional Access i kontrolę ryzyka logowania.
Usunąć nieużywane konta i ograniczyć uprawnienia administracyjne.
Zachować odpowiednią retencję logów audytowych.
Przygotować procedury resetu poświadczeń i unieważniania sesji.

Podsumowanie

Kampania wymierzona w organizacje korzystające z Microsoft 365 potwierdza, że password spraying pozostaje jednym z najtańszych i najskuteczniejszych sposobów uzyskania dostępu do środowisk chmurowych. Operacja była wieloetapowa, dobrze dopasowana do realiów SaaS i ukierunkowana na cele o wysokiej wartości operacyjnej.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest jednoznaczny: ochrona tożsamości musi być traktowana jako fundament cyberobrony. MFA, monitoring logowań, odpowiednie polityki dostępu warunkowego, blokowanie ruchu z sieci anonimizujących oraz właściwa retencja logów nie są dodatkiem, lecz podstawą ograniczania ryzyka.