Archiwa: Malware - Strona 100 z 181

CVE-2025-59254: eskalacja uprawnień w Desktop Window Manager Core Library systemu Windows

Wprowadzenie do problemu / definicja

CVE-2025-59254 to podatność typu heap-based buffer overflow w komponencie Desktop Window Manager Core Library systemu Windows. Luka może prowadzić do lokalnego podniesienia uprawnień, jeśli nieuprzywilejowany użytkownik uzyska możliwość wywołania podatnej ścieżki kodu odpowiedzialnej za przetwarzanie danych związanych z renderowaniem i kompozycją obrazu.

Problem dotyczy obszaru systemu odpowiedzialnego za zarządzanie oknami, efektami pulpitu oraz kompozycją interfejsu graficznego. Z perspektywy bezpieczeństwa oznacza to ryzyko wykorzystania błędu w jednym z kluczowych elementów architektury Windows.

W skrócie

Publicznie opisano CVE-2025-59254 jako przepełnienie bufora na stercie w bibliotece DWM Core Library. Mechanizm błędu polega na zapisaniu większej ilości danych do zbyt małej alokacji pamięci, co może skutkować naruszeniem sąsiednich struktur w stercie.

Typ podatności: heap-based buffer overflow
Wpływ: lokalna eskalacja uprawnień
Dotknięty komponent: Desktop Window Manager Core Library
Wektor ataku: lokalny, po uzyskaniu dostępu do systemu
Status ujawnienia: publiczny opis bez pełnego działającego exploita

Zagrożenie ma szczególne znaczenie dla stacji roboczych i serwerów, na których napastnik posiada już wstępny dostęp i chce rozszerzyć kontrolę nad systemem.

Kontekst / historia

Desktop Window Manager od lat pozostaje jednym z podstawowych komponentów graficznych Windows. Odpowiada za kompozycję okien, efekty wizualne oraz pośredniczenie między aplikacjami a warstwą prezentacji. Błędy w komponentach niskopoziomowych tego typu są szczególnie istotne, ponieważ operują one na pamięci i złożonych strukturach danych.

W opisie CVE-2025-59254 wskazano, że problem dotyczy ścieżki przetwarzającej dane ramek lub kompozycji. To ważne, ponieważ komponenty graficzne często obsługują dane o zmiennym rozmiarze, a nawet pojedynczy błąd w walidacji długości bufora może skutkować naruszeniem integralności pamięci i otworzyć drogę do dalszej eskalacji.

Publiczne ujawnienie ma ograniczony charakter. Opublikowane informacje techniczne nie zawierają kompletnego łańcucha ataku ani gotowego kodu exploitacyjnego, ale sama klasyfikacja błędu wskazuje na realne znaczenie operacyjne dla środowisk Windows.

Analiza techniczna

Istotą podatności jest przepełnienie bufora na stercie. Dochodzi do niego wtedy, gdy aplikacja lub komponent systemowy rezerwuje blok pamięci o niewystarczającym rozmiarze, a następnie kopiuje do niego większą ilość danych. W efekcie nadpisywana jest pamięć znajdująca się poza docelowym obszarem.

Jeśli atakujący kontroluje zarówno zawartość, jak i długość przetwarzanych danych, może doprowadzić do uszkodzenia struktur sterty, zmiany wartości wskaźników, destabilizacji procesu, a w określonych warunkach także do przejęcia przepływu wykonania. W przypadku DWM kluczowa jest wzmianka o przetwarzaniu danych związanych z frame/composition data.

Możliwy scenariusz techniczny obejmuje dostarczenie specjalnie spreparowanego wejścia, którego rozmiar nie zostanie poprawnie zweryfikowany przed kopiowaniem do pamięci. Jeżeli rozmiar alokacji zostanie oszacowany zbyt nisko, zapis wyjdzie poza granice bufora i naruszy stan sterty. Skutkiem może być awaria procesu albo wykorzystanie błędu do uzyskania wyższych uprawnień, zależnie od obecnych mechanizmów ochronnych, takich jak ASLR, DEP oraz zabezpieczenia sterty.

Warto podkreślić, że publiczny opis nie zawiera adresów, offsetów, łańcuchów ROP ani kompletnego proof-of-concept. Nie zmniejsza to jednak znaczenia podatności z perspektywy obrony, ponieważ podobne błędy w uprzywilejowanych komponentach systemowych są regularnie wykorzystywane jako element późniejszych etapów ataku.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją CVE-2025-59254 jest możliwość lokalnego podniesienia uprawnień. Tego typu luka nie musi być pierwotnym wektorem wejścia do organizacji, ale może zostać wykorzystana jako drugi etap po phishingu, infekcji malware, przejęciu konta użytkownika lub wykorzystaniu innej podatności.

przejęcie kontekstu o wyższych uprawnieniach przez lokalnego użytkownika,
obejście granic między kontem standardowym a administracyjnym lub systemowym,
zwiększenie skuteczności malware po uzyskaniu początkowego dostępu,
utrudnienie detekcji, jeśli exploit stanie się elementem łańcucha post-exploitation,
wzrost ryzyka kompromitacji niezałatanych stacji roboczych i serwerów.

Szczególnie narażone są środowiska, w których kontrola aplikacji jest ograniczona, użytkownicy pracują z podwyższonymi uprawnieniami, a monitoring zdarzeń lokalnych pozostaje niewystarczający. W kampaniach ransomware i działaniach APT lokalna eskalacja uprawnień często służy do uzyskania trwałości, wyłączenia mechanizmów ochronnych oraz przygotowania ruchu lateralnego.

Rekomendacje

Organizacje powinny potraktować CVE-2025-59254 jako istotną podatność wymagającą standardowej obsługi w ramach zarządzania ryzykiem dla środowisk Windows. Kluczowe znaczenie ma szybka weryfikacja statusu poprawek oraz ograniczenie możliwości lokalnego uruchamiania niezatwierdzonego kodu.

zweryfikować, czy odpowiednie poprawki bezpieczeństwa zostały wdrożone na obsługiwanych wersjach Windows,
przeprowadzić inwentaryzację stacji roboczych i serwerów mogących korzystać z podatnych wydań,
monitorować nietypowe awarie procesów związanych z DWM oraz próby eskalacji uprawnień,
ograniczać lokalne wykonanie niezatwierdzonego kodu z użyciem mechanizmów application control,
egzekwować zasadę najmniejszych uprawnień i minimalizować liczbę lokalnych administratorów,
wdrożyć EDR lub XDR z detekcją anomalii związanych z manipulacją pamięcią i procesami systemowymi,
analizować łańcuchy ataków, w których lokalna eskalacja uprawnień może być etapem po uzyskaniu dostępu początkowego.

Z punktu widzenia zespołów SOC i IR warto rozbudować korelację o sygnały takie jak nagłe podniesienie integralności procesu uruchomionego z kontekstu użytkownika, nietypowe restarty komponentów interfejsu graficznego czy uruchamianie narzędzi administracyjnych bez oczekiwanego ciągu parent-child.

Podsumowanie

CVE-2025-59254 to istotna podatność w Desktop Window Manager Core Library, sklasyfikowana jako heap-based buffer overflow z potencjałem do lokalnej eskalacji uprawnień. Mimo że publiczny opis nie zawiera gotowego exploita, charakter błędu wskazuje na poważne znaczenie dla bezpieczeństwa środowisk Windows.

Dla organizacji najważniejsze pozostają szybkie wdrożenie poprawek, ograniczenie powierzchni lokalnego wykonania kodu oraz wzmocniony monitoring zdarzeń mogących świadczyć o próbach uzyskania wyższych uprawnień. W praktyce właśnie takie luki często stają się kluczowym ogniwem w bardziej złożonych łańcuchach ataku.

Źródła

Exploit Database – Desktop Window Manager Core Library 10.0.10240.0 – Privilege Escalation
https://www.exploit-db.com/exploits/52493
NVD – CVE-2025-59254
https://nvd.nist.gov/vuln/detail/CVE-2025-59254
Microsoft Security Response Center – CVE-2025-59254
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-59254
CVE Details – CVE-2025-59254
https://www.cvedetails.com/cve/CVE-2025-59254/

Atak na łańcuch dostaw GitHub z użyciem AI: kampania „prt-scan” wykorzystuje błędną konfigurację GitHub Actions

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania coraz częściej koncentrują się nie tylko na samym kodzie, ale również na procesach CI/CD. Najnowsza kampania oznaczona jako „prt-scan” pokazuje, że błędna konfiguracja GitHub Actions może stać się bezpośrednim wektorem kompromitacji repozytorium, sekretów oraz procesu publikacji pakietów.

Kluczowym elementem nadużycia jest mechanizm pull_request_target, który przy niewłaściwej implementacji może uruchamiać workflow w kontekście głównego repozytorium także dla niezaufanych pull requestów z forków. W praktyce oznacza to ryzyko kradzieży tokenów, enumeracji sekretów i prób przejęcia dalszych etapów pipeline’u.

W skrócie

Kampania „prt-scan” była zautomatyzowaną operacją wymierzoną w projekty korzystające z podatnych workflow opartych o pull_request_target. Atakujący mieli utworzyć ponad 500 złośliwych pull requestów, wykorzystując wiele kont powiązanych z jednym operatorem oraz techniki automatyzacji wspierane przez AI.

Celem były repozytoria GitHub z niebezpieczną konfiguracją Actions.
Ładunki były dopasowywane do stosu technologicznego ofiary.
Potwierdzono kompromitację co najmniej dwóch pakietów npm.
W części incydentów doszło do wycieku krótkotrwałych poświadczeń i innych sekretów CI/CD.

Kontekst / historia

Zagrożenia wobec platform developerskich i narzędzi automatyzacji budowania rosną od kilku lat, jednak kampania „prt-scan” pokazała nowy poziom skali i personalizacji ataku. W centrum problemu znalazł się trigger pull_request_target, od dawna uznawany za funkcję wymagającą szczególnej ostrożności, ponieważ działa w kontekście repozytorium bazowego i może mieć dostęp do sekretów oraz szerszych uprawnień niż standardowy pull_request.

Według ustaleń badaczy aktywność związana z kampanią rozpoczęła się 11 marca 2026 roku i trwała falami do 2–3 kwietnia 2026 roku. Publiczne ujawnienie nastąpiło 2 kwietnia 2026 roku, choć późniejsze analizy wskazały wcześniejsze testy, kolejne iteracje technik i stopniowe zwiększanie skali operacji.

To istotny sygnał dla całego ekosystemu open source. Atak nie był pojedynczym eksperymentem, lecz częścią szerszego trendu, w którym przestępcy zaczynają systematycznie eksploatować błędy konfiguracyjne w GitHub Actions jako drogę do naruszenia software supply chain.

Analiza techniczna

Schemat działania był stosunkowo prosty, ale efektywny przy dużej liczbie prób. Operator wyszukiwał repozytoria wykorzystujące pull_request_target, forkując je i tworząc gałęzie o charakterystycznym nazewnictwie. Następnie przygotowywał pull requesty zawierające złośliwe modyfikacje w plikach, które miały wysoką szansę uruchomienia podczas CI.

Wśród wykorzystywanych plików pojawiały się między innymi conftest.py, package.json, Makefile, build.rs oraz elementy konfiguracji workflow. Zmiany były maskowane jako rutynowe poprawki związane z budowaniem, testami lub kompatybilnością projektu, co miało zmniejszyć czujność maintainerów.

Po uruchomieniu workflow złośliwy kod próbował najpierw zebrać zmienne środowiskowe i tokeny dostępne w kontekście pipeline’u. Następnie wykonywał rozpoznanie środowiska, obejmujące enumerację sekretów, workflow i potencjalnych integracji zewnętrznych. W kolejnych etapach malware podejmowało próby tworzenia tymczasowych workflow, obchodzenia kontroli bezpieczeństwa oraz opóźnionej eksfiltracji danych, na przykład przez logi lub komentarze do pull requestów.

Najbardziej niepokojącym elementem kampanii było dopasowywanie ładunku do technologii używanej przez ofiarę. Badacze odnotowali wzorce sugerujące użycie AI lub modeli LLM do automatycznego rozpoznawania języka, frameworka i procesu budowania projektu. Dzięki temu atakujący mogli generować pozornie naturalne, „idiomatyczne” zmiany dla repozytoriów Python, Node.js, Rust czy Go.

Jednocześnie sama operacja nie była perfekcyjna technicznie. W części analizowanych prób pojawiały się błędy logiczne, niewłaściwe założenia dotyczące modelu uprawnień GitHub oraz nietrafione wektory wstrzyknięcia. To ograniczyło skuteczność kampanii, ale nie zredukowało ryzyka do zera. Przy setkach zautomatyzowanych prób nawet niski odsetek powodzenia może prowadzić do realnych kompromitacji.

Konsekwencje / ryzyko

Najważniejszym skutkiem kampanii jest potwierdzenie, że błędna konfiguracja GitHub Actions może stać się praktycznym punktem wejścia do ataku na łańcuch dostaw. Nawet jeśli część udanych kompromitacji dotyczyła mniejszych projektów, skutki mogą rozlać się dalej przez zależności open source wykorzystywane w innych środowiskach.

Ryzyko ma kilka warstw. Po pierwsze, istnieje możliwość przejęcia krótkotrwałych poświadczeń workflow, które w określonych warunkach pozwalają na dalsze działania w repozytorium lub usługach zewnętrznych. Po drugie, zagrożone są sekrety CI/CD, takie jak tokeny publikacyjne, klucze API, poświadczenia do usług chmurowych czy tokeny wykorzystywane przez platformy wdrożeniowe. Po trzecie, kampanie tego typu zwiększają obciążenie maintainerów i utrudniają ręczną weryfikację pull requestów przy dużej skali ataku.

Dodatkowym problemem jest operacyjne wykorzystanie AI. Automatyzacja obniża próg wejścia dla mniej zaawansowanych aktorów, a jednocześnie zwiększa tempo i adaptacyjność ataków. To oznacza, że podobne kampanie prawdopodobnie będą się powtarzać, stając się z czasem bardziej precyzyjne i trudniejsze do wykrycia.

Rekomendacje

Organizacje utrzymujące repozytoria na GitHub powinny w pierwszej kolejności przeprowadzić audyt workflow korzystających z pull_request_target. Jeżeli ten mechanizm nie jest absolutnie niezbędny, należy zastąpić go bezpieczniejszymi wzorcami opartymi o pull_request lub ograniczyć jego użycie do ściśle kontrolowanych scenariuszy.

Kluczowe pozostaje wdrożenie zasady minimalnych uprawnień dla GITHUB_TOKEN oraz jawne definiowanie sekcji permissions w workflow. Nie należy dopuszczać do automatycznego wykonywania kodu z niezaufanych forków przy jednoczesnym dostępie do sekretów.

Wymuszanie ręcznego zatwierdzania workflow od first-time contributorów.
Ochrona branchy i obowiązkowe review przed uruchomieniem krytycznych zadań.
Stosowanie warunków ścieżkowych ograniczających aktywację workflow.
Separacja sekretów produkcyjnych od pipeline’ów build/test.
Monitorowanie logów workflow pod kątem anomalii i markerów eksfiltracji.
Regularna rotacja tokenów publikacyjnych oraz sekretów CI/CD.
Przegląd historii pull requestów i workflow pod kątem artefaktów kampanii.

Z perspektywy zespołów bezpieczeństwa szczególnie ważne jest wykrywanie repozytoriów, w których pull_request_target współistnieje z wykonywaniem kodu pochodzącego z forka. Taka kombinacja powinna być traktowana jako sygnał wysokiego ryzyka wymagający natychmiastowej korekty.

Podsumowanie

Kampania „prt-scan” pokazuje, że bezpieczeństwo GitHub Actions i pipeline’ów CI/CD stało się jednym z kluczowych elementów ochrony łańcucha dostaw oprogramowania. Sam wektor ataku nie jest nowy, ale połączenie go z automatyzacją wspieraną przez AI znacząco zwiększa skalę, szybkość i elastyczność działań przeciwnika.

Dla organizacji najważniejszy wniosek jest prosty: ochrona software supply chain nie kończy się na analizie kodu aplikacji. Równie istotne są konfiguracje workflow, model uprawnień, sposób uruchamiania zadań dla niezaufanych kontrybutorów oraz kontrola sekretów wykorzystywanych w procesie budowania i publikacji.

Źródła

Dark Reading — AI-Assisted Supply Chain Attack Targets GitHub — https://www.darkreading.com/application-security/ai-assisted-supply-chain-attack-targets-github
Wiz Blog — Six Accounts, One Actor: Inside the prt-scan Supply Chain Campaign — https://www.wiz.io/blog/six-accounts-one-actor-inside-the-prt-scan-supply-chain-campaign
GitHub Docs — About pull requests — https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
GitHub Docs — Events that trigger workflows — https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
Wiz Blog — Hardening GitHub Actions: Lessons from Recent Attacks — https://www.wiz.io/blog/github-actions-security-guide

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

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/

Kampania DPRK wykorzystuje GitHub jako kanał C2 w atakach na organizacje w Korei Południowej

Wprowadzenie do problemu / definicja

Zaawansowane kampanie APT coraz częściej wykorzystują legalne usługi internetowe jako element infrastruktury dowodzenia i kontroli. Dzięki temu ruch sieciowy do popularnych platform może wyglądać wiarygodnie i nie wzbudzać podejrzeń, zwłaszcza jeśli organizacja dopuszcza komunikację z powszechnie używanymi serwisami deweloperskimi.

Najnowsza kampania przypisywana podmiotom powiązanym z Koreą Północną pokazuje, że GitHub może pełnić nie tylko rolę hostingu dla złośliwych plików, ale również funkcjonować jako pełnoprawny kanał C2. Celem operacji są organizacje w Korei Południowej, a cały łańcuch ataku został zaprojektowany tak, by utrudnić wykrycie i analizę incydentu.

W skrócie

Atak rozpoczyna się od złośliwego pliku LNK, najprawdopodobniej dostarczanego w wiadomościach phishingowych. Po jego uruchomieniu ofiara widzi dokument-wabik, natomiast w tle uruchamiany jest skrypt PowerShell odpowiedzialny za rozpoznanie środowiska, ustanowienie persystencji i komunikację z repozytorium GitHub kontrolowanym przez napastników.

Punkt wejścia stanowi plik skrótu LNK.
W tle uruchamiany jest PowerShell bez wyraźnej interakcji z użytkownikiem.
Malware sprawdza, czy działa w środowisku analitycznym lub maszynie wirtualnej.
Persystencja jest utrzymywana za pomocą zaplanowanego zadania systemowego.
GitHub służy zarówno do eksfiltracji danych rekonesansowych, jak i pobierania dalszych poleceń.

Kontekst / historia

Opisana operacja wpisuje się w szerszy wzorzec aktywności grup powiązanych z północnokoreańskim ekosystemem zagrożeń, w tym technik obserwowanych wcześniej w kampaniach przypisywanych Kimsuky. W poprzednich incydentach aktorzy ci wykorzystywali już pliki LNK, PowerShell oraz legalne usługi chmurowe do pobierania kolejnych etapów infekcji i utrzymywania trwałego dostępu do systemów ofiar.

W nowszych wariantach takich kampanii widoczny jest nacisk na ograniczenie użycia klasycznych plików wykonywalnych i większe wykorzystanie natywnych narzędzi systemowych. Taka strategia utrudnia wykrywanie przez rozwiązania opierające się głównie na sygnaturach i prostych wskaźnikach kompromitacji. Dodatkowo obserwowane były podobne łańcuchy ataku rozwijane w kierunku wdrażania backdoorów opartych na Pythonie oraz użycia innych zaufanych usług jako pośrednich kanałów dostarczania ładunków.

Analiza techniczna

Początkowy etap infekcji opiera się na zaciemnionym pliku LNK. Po jego otwarciu użytkownik otrzymuje pozornie nieszkodliwy dokument PDF, co ma odwrócić uwagę od faktycznych działań wykonywanych w tle. Równolegle uruchamiany jest PowerShell, który działa w sposób ukryty i bez widocznych oznak dla ofiary.

Następnie skrypt przeprowadza kontrolę środowiska uruchomieniowego. Sprawdzane są artefakty charakterystyczne dla maszyn wirtualnych, debuggerów oraz narzędzi analitycznych. Jeśli system zostanie uznany za środowisko badawcze, kod kończy działanie, co wskazuje na wdrożenie mechanizmów anti-analysis oraz antysandbox.

Jeżeli host przejdzie etap weryfikacji, malware wyodrębnia komponent VBScript i tworzy persystencję przy użyciu harmonogramu zadań systemu Windows. Zaplanowane zadanie uruchamia ładunek PowerShell cyklicznie, zwykle w ukrytym oknie, co pozwala utrzymać dostęp po restarcie systemu i zmniejsza szansę na szybkie wykrycie.

Kolejny etap obejmuje profilowanie systemu ofiary. Zbierane są informacje o hoście, które następnie trafiają do pliku dziennika i są przesyłane do repozytorium GitHub z wykorzystaniem osadzonego tokenu dostępowego. To samo repozytorium może następnie dostarczać kolejne instrukcje, konfigurację lub dodatkowe moduły potrzebne do rozwinięcia ataku.

Z perspektywy obronnej szczególnie istotne jest to, że operatorzy opierają się głównie na legalnych narzędziach systemowych i zaufanych usługach sieciowych. W praktyce oznacza to użycie podejścia living-off-the-land, które zmniejsza ślad na dysku i zaciera granicę między ruchem legalnym a aktywnością złośliwą.

Konsekwencje / ryzyko

Najpoważniejszym zagrożeniem jest możliwość ukrycia komunikacji C2 w zwykłym ruchu HTTPS do popularnej platformy deweloperskiej. Organizacje, które traktują taki ruch jako automatycznie zaufany, mogą przez długi czas nie zauważyć aktywności napastników. To szczególnie niebezpieczne w środowiskach, gdzie monitoring ruchu wychodzącego do usług chmurowych jest ograniczony.

Ryzyko obejmuje nie tylko rekonesans systemu, ale również trwałe utrzymanie dostępu, wykonywanie poleceń zdalnych i pobieranie dalszych modułów. W praktyce może to prowadzić do kradzieży danych, ruchu lateralnego, wdrożenia spyware lub backdoora, a także wykorzystania przejętej stacji roboczej do dalszych działań wywiadowczych.

Szczególnie narażone są instytucje publiczne, podmioty rządowe, sektor obronny, think tanki oraz firmy współpracujące z administracją. Tego typu kampanie mają zwykle charakter ukierunkowany i długoterminowy, dlatego skutki kompromitacji mogą być znacznie poważniejsze niż w przypadku masowych operacji cyberprzestępczych.

Rekomendacje

Organizacje powinny ograniczyć możliwość uruchamiania nieautoryzowanych plików LNK pochodzących z poczty elektronicznej, archiwów i folderów tymczasowych. W praktyce oznacza to wdrożenie polityk blokujących wykonywanie skrótów z niezaufanych lokalizacji oraz wzmocnienie filtracji wiadomości phishingowych zawierających podejrzane załączniki.

Niezbędne jest również monitorowanie użycia PowerShella, VBScript i harmonogramu zadań pod kątem nietypowych wzorców. Szczególną uwagę należy zwracać na ukryte okna, zakodowane polecenia, tworzenie cyklicznych zadań oraz połączenia sieciowe inicjowane przez interpretery skryptowe.

Włączyć rozszerzone logowanie PowerShell i rejestrowanie bloków skryptowych.
Audytować tworzenie i modyfikację zaplanowanych zadań.
Analizować komunikację wychodzącą do platform deweloperskich i repozytoriów.
Stosować zasadę najmniejszych uprawnień oraz segmentację sieci.
Ograniczać użycie interpreterów skryptowych tam, gdzie nie są potrzebne biznesowo.
Przygotować playbooki reagowania obejmujące analizę LNK, PowerShell, VBScript i tokenów API.

Warto także prowadzić regularny threat hunting pod kątem hostów, które cyklicznie łączą się z zewnętrznymi repozytoriami bez uzasadnienia biznesowego. W nowoczesnych środowiskach bezpieczeństwa kluczowa staje się korelacja telemetrii procesów, zadań systemowych i aktywności sieciowej.

Podsumowanie

Opisana kampania potwierdza, że zaawansowani aktorzy zagrożeń nadal skutecznie łączą phishing, pliki LNK, PowerShell oraz legalne usługi internetowe w celu budowy trudnych do wykrycia łańcuchów infekcji. Wykorzystanie GitHub jako kanału C2 zwiększa szanse na ukrycie działań w zwykłym ruchu sieciowym, a oparcie ataku na natywnych narzędziach Windows ogranicza liczbę oczywistych wskaźników kompromitacji.

Dla zespołów bezpieczeństwa oznacza to konieczność odejścia od prostego modelu zaufania do popularnych platform i skupienia się na analizie behawioralnej. Skuteczna obrona wymaga dziś nie tylko blokowania znanych zagrożeń, ale także monitorowania tego, jak legalne narzędzia i usługi są wykorzystywane w nietypowy sposób.

Źródła

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.