Archiwa: Security News - Strona 277 z 502

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

Microsoft wiąże Storm-1175 z Medusą i atakami zero-day na systemy brzegowe

Wprowadzenie do problemu / definicja

Microsoft powiązał grupę oznaczaną jako Storm-1175 z intensywnymi kampaniami ransomware wykorzystującymi rodzinę Medusa oraz z aktywnym nadużywaniem podatności typu N-day i wybranych luk zero-day. To ważny sygnał dla rynku, ponieważ pokazuje, że operatorzy związani z ekosystemem ransomware potrafią dziś bardzo szybko przejść od wykrycia słabego punktu do pełnoskalowego incydentu obejmującego kradzież danych i szyfrowanie systemów.

Z perspektywy obrońców oznacza to konieczność traktowania publicznie dostępnych usług jako priorytetowego obszaru ryzyka. Każde opóźnienie w aktualizacji lub niewystarczające monitorowanie systemów brzegowych może zostać wykorzystane w bardzo krótkim czasie.

W skrócie

Storm-1175 to grupa cyberprzestępcza motywowana finansowo, którą Microsoft łączy z wysokotempowymi operacjami ransomware Medusa. Atakujący koncentrują się na podatnych systemach wystawionych do internetu, a po uzyskaniu dostępu błyskawicznie przechodzą do utrwalenia obecności, eskalacji uprawnień, kradzieży poświadczeń, eksfiltracji danych i wdrożenia szyfrującego ładunku.

celem są przede wszystkim systemy web-facing i narzędzia administracyjne,
część incydentów rozwija się w ciągu 24 godzin,
grupa wykorzystuje zarówno podatności N-day, jak i wybrane zero-day,
w działaniach po kompromitacji szeroko używane są legalne narzędzia administracyjne i RMM,
atak kończy się zwykle modelem podwójnego wymuszenia: kradzież danych i szyfrowanie.

Kontekst / historia

Medusa od dłuższego czasu pozostaje jednym z aktywnych zagrożeń funkcjonujących w modelu ransomware-as-a-service. W takim układzie wspólne zaplecze techniczne i operacyjne może być wykorzystywane przez różnych operatorów oraz afiliantów, co zwiększa skalę i elastyczność kampanii.

W najnowszej analizie Microsoft wskazał, że Storm-1175 szczególnie skutecznie atakuje organizacje korzystające z publicznie dostępnych systemów brzegowych. Na liście obserwowanych celów znalazły się między innymi podmioty z sektorów ochrony zdrowia, edukacji, usług profesjonalnych oraz finansów. Wspólnym mianownikiem jest obecność kluczowych usług, które zapewniają zdalny dostęp lub stanowią punkt wejścia do infrastruktury.

Opis aktywności tej grupy wpisuje się w szerszy trend widoczny w krajobrazie zagrożeń: odejście od długiego rekonesansu na rzecz szybkiej i agresywnej eksploatacji. W praktyce oznacza to, że organizacje mają coraz mniej czasu na wykrycie ataku i jego zatrzymanie przed osiągnięciem przez przeciwnika krytycznych celów.

Analiza techniczna

Kluczowym elementem działań Storm-1175 jest szybka weaponizacja świeżo ujawnionych podatności. Microsoft opisał wykorzystanie ponad 16 luk w 10 różnych produktach, w tym w rozwiązaniach takich jak Microsoft Exchange, PaperCut, Ivanti Connect Secure i Policy Secure, ConnectWise ScreenConnect, JetBrains TeamCity, SimpleHelp, CrushFTP, GoAnywhere MFT, SmarterMail oraz BeyondTrust.

Szczególnie alarmujące są obserwacje dotyczące luk zero-day. W analizie wskazano między innymi CVE-2026-23760 w SmarterMail oraz wcześniejsze nadużywanie CVE-2025-10035 w GoAnywhere MFT jeszcze przed publicznym ujawnieniem. Choć grupa nadal szeroko korzysta z podatności N-day, zdolność do działania jeszcze przed publikacją szczegółów o luce sugeruje bardziej dojrzałe zaplecze techniczne lub dostęp do zewnętrznych dostawców exploitów.

Po uzyskaniu dostępu początkowego operatorzy przechodzą do znanego, lecz bardzo skutecznego łańcucha działań po kompromitacji. Tworzą nowe konta, nadają uprawnienia administracyjne, wdrażają web shelle lub inne ładunki dostępu zdalnego, a następnie rozpoczynają rekonesans i ruch boczny. W tym etapie wykorzystywane są narzędzia systemowe typu living-off-the-land, takie jak PowerShell i PsExec.

Na etapie lateral movement Storm-1175 używa również legalnych rozwiązań do zdalnego zarządzania. Wśród wskazanych narzędzi znalazły się Atera, N-able, DWAgent, MeshAgent, AnyDesk, ScreenConnect i SimpleHelp. Dodatkowo grupa korzystała z PDQ Deployer do dystrybucji ładunków oraz z frameworka Impacket do poruszania się po sieci i dalszej eksploatacji. Tego rodzaju aktywność jest szczególnie trudna do wykrycia, ponieważ może przypominać zwykłe działania zespołów IT.

Ważnym komponentem operacji pozostaje kradzież poświadczeń. Microsoft wskazał na zrzuty pamięci LSASS, użycie Mimikatz, modyfikacje ustawień WDigest oraz próby dostępu do NTDS.dit i SAM po uzyskaniu odpowiednio wysokich uprawnień. W niektórych scenariuszach napastnicy odzyskiwali również hasła zapisane w oprogramowaniu backupowym, co mogło ułatwiać przejęcie kolejnych systemów.

Przed wdrożeniem ransomware operatorzy modyfikowali ustawienia ochrony, w tym konfigurację antywirusa, i dodawali wykluczenia dla całych dysków. Następnie przechodzili do eksfiltracji danych, wykorzystując archiwizację plików oraz narzędzia synchronizacji i transferu do zasobów chmurowych. Dopiero po tym etapie uruchamiany był właściwy komponent szyfrujący Medusa, często rozprowadzany centralnie w zaatakowanym środowisku.

Konsekwencje / ryzyko

Największe ryzyko w modelu działania Storm-1175 wynika z połączenia trzech elementów: publicznie dostępnej powierzchni ataku, bardzo krótkiego czasu od uzyskania dostępu do pełnej kompromitacji oraz wykorzystania legalnych narzędzi administracyjnych. Dla zespołów bezpieczeństwa oznacza to drastyczne skrócenie okna detekcji i reakcji.

Dodatkowym zagrożeniem jest model podwójnego wymuszenia. Medusa nie ogranicza się do blokowania dostępu do danych, lecz obejmuje także ich kradzież i groźbę publikacji. To zwiększa presję operacyjną, prawną i reputacyjną na ofiarę, zwłaszcza w sektorach przetwarzających informacje wrażliwe.

W praktyce szczególnie narażone pozostają organizacje utrzymujące w internecie serwery pocztowe, systemy MFT, panele administracyjne, rozwiązania VPN oraz narzędzia zdalnej pomocy. Nawet krótki poślizg w patchowaniu takich usług może wystarczyć, aby przeciwnik przejął środowisko i rozpoczął dalszą eskalację.

Rekomendacje

Podstawą obrony powinno być agresywne zarządzanie podatnościami w systemach wystawionych do internetu. Najwyższy priorytet należy nadać wszystkim usługom brzegowym oraz narzędziom zdalnego dostępu administracyjnego. Równie istotne jest stałe ograniczanie powierzchni ataku i usuwanie zbędnych usług publicznych.

priorytetowo łatać systemy web-facing i rozwiązania administracyjne,
stosować segmentację, izolację i dodatkowe warstwy ochrony, takie jak reverse proxy i WAF,
wymuszać MFA dla dostępu administracyjnego i ograniczać go do zaufanych kanałów,
monitorować tworzenie nowych kont uprzywilejowanych oraz nietypowe użycie PowerShell, PsExec i Impacket,
wykrywać zrzuty LSASS, zmiany w ustawieniach AV i dodawanie wyjątków skanowania,
chronić kontrolery domeny, backupy oraz repozytoria poświadczeń,
regularnie testować procedury odtworzeniowe i gotowe playbooki IR.

Z perspektywy operacyjnej organizacje powinny zakładać, że kompromitacja systemu brzegowego może bardzo szybko przekształcić się w pełnoskalowy incydent ransomware. Oznacza to potrzebę automatyzacji izolacji hostów, skrócenia czasu triage oraz priorytetyzacji sygnałów związanych z credential theft i nadużyciem narzędzi RMM.

Podsumowanie

Przypadek Storm-1175 pokazuje, że współczesne kampanie ransomware są coraz szybsze, bardziej zautomatyzowane i lepiej przygotowane technicznie. Najważniejsza obserwacja dotyczy skrócenia całego łańcucha ataku: od exploita, przez utrwalenie i kradzież poświadczeń, po eksfiltrację danych i szyfrowanie.

Dla obrońców oznacza to konieczność traktowania każdej krytycznej podatności w systemie publicznie dostępnym jako zdarzenia wysokiego ryzyka. Skuteczna ochrona przed podobnymi operacjami wymaga połączenia szybkiego patchowania, redukcji powierzchni ataku, monitorowania narzędzi administracyjnych, ochrony tożsamości uprzywilejowanych i wysokiej gotowości zespołów reagowania.

Źródła

Microsoft links Medusa ransomware affiliate to zero-day attacks — https://www.bleepingcomputer.com/news/security/microsoft-links-medusa-ransomware-affiliate-to-zero-day-attacks/
Storm-1175 focuses gaze on vulnerable web-facing assets in high-tempo Medusa ransomware operations — https://www.microsoft.com/en-us/security/blog/2026/04/06/storm-1175-focuses-gaze-on-vulnerable-web-facing-assets-in-high-tempo-medusa-ransomware-operations/
CVE-2026-23760 — https://nvd.nist.gov/vuln/detail/CVE-2026-23760
CVE-2025-10035 — https://nvd.nist.gov/vuln/detail/CVE-2025-10035
#StopRansomware: Medusa Ransomware — https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-071a

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.

Źródła

Kompromitacja LiteLLM na PyPI: złośliwe wersje 1.82.7 i 1.82.8 kradły poświadczenia deweloperów

Wprowadzenie do problemu / definicja

Kompromitacja pakietu LiteLLM w repozytorium PyPI to przykład ataku na łańcuch dostaw oprogramowania, w którym napastnik nie atakuje bezpośrednio organizacji, lecz zaufany komponent używany przez programistów i procesy CI/CD. Tego typu incydenty są szczególnie niebezpieczne, ponieważ wykorzystują automatyzację instalacji zależności oraz fakt, że środowiska deweloperskie przechowują liczne sekrety, takie jak klucze, tokeny i konfiguracje dostępu do usług chmurowych.

W przypadku LiteLLM zagrożenie dotyczyło złośliwych wersji 1.82.7 i 1.82.8, które po instalacji uruchamiały kod nastawiony na zbieranie danych uwierzytelniających. To oznacza, że pozornie standardowa aktualizacja biblioteki mogła zamienić stację roboczą lub runner CI/CD w źródło wycieku poświadczeń.

W skrócie

Złośliwe wydania LiteLLM 1.82.7 oraz 1.82.8 zostały opublikowane jako skażone pakiety w oficjalnym ekosystemie Pythona. Ich głównym celem była kradzież sekretów z maszyn deweloperskich i środowisk automatyzacji.

atak dotyczył pakietu dystrybuowanego przez PyPI,
celem były poświadczenia lokalne i chmurowe,
wersja 1.82.8 wykorzystywała mechanizm plików .pth,
zagrożone były zarówno stacje robocze, jak i pipeline’y CI/CD,
sama deinstalacja pakietu nie wystarcza, jeśli sekrety mogły zostać już wykradzione.

Kontekst / historia

LiteLLM to popularna biblioteka upraszczająca integrację z wieloma modelami językowymi przez ujednoliconą warstwę API. Ze względu na szerokie zastosowanie w projektach AI i narzędziach deweloperskich, kompromitacja tej zależności miała potencjał objąć wiele organizacji jednocześnie.

Incydent wpisuje się w szerszy trend ataków supply chain wymierzonych w komponenty o wysokim poziomie zaufania. Takie kampanie są skuteczne, ponieważ zainfekowany pakiet może zostać pobrany nie tylko bezpośrednio przez użytkownika, ale również jako zależność przechodnia innego projektu. W praktyce oznacza to, że część ofiar mogła nie być nawet świadoma wykorzystania LiteLLM w swoim środowisku.

Dodatkowym elementem tła jest rosnące zainteresowanie napastników narzędziami używanymi przez zespoły developerskie, DevOps i DevSecOps. To właśnie tam znajdują się najbardziej wartościowe dane dostępowe: klucze SSH, tokeny publikacyjne, konfiguracje chmurowe i dane używane do automatycznego wdrażania aplikacji.

Analiza techniczna

Technicznie atak polegał na opublikowaniu złośliwych wersji pakietu w oficjalnym kanale dystrybucji. Po instalacji malware działał w kontekście użytkownika lub procesu CI, bez potrzeby wykorzystywania klasycznych luk eskalacyjnych w systemie operacyjnym. To wystarczało, aby odczytać dane z wielu lokalnych lokalizacji typowych dla środowisk deweloperskich.

Analizy wskazują, że złośliwy kod był ukierunkowany na zbieranie artefaktów uwierzytelniających oraz plików konfiguracyjnych. Obejmowało to między innymi:

klucze SSH,
poświadczenia do AWS, Azure i GCP,
konfiguracje Dockera,
pliki .env,
ustawienia narzędzi CLI,
historię poleceń powłoki,
lokalne pliki konfiguracyjne środowisk programistycznych.

Najgroźniejszą różnicą między wersjami 1.82.7 i 1.82.8 było wykorzystanie w tej drugiej mechanizmu pliku .pth. Tego typu plik może zostać przetworzony przez interpreter Pythona przy starcie środowiska, co oznacza możliwość uruchomienia złośliwego kodu nawet wtedy, gdy biblioteka nie została jawnie zaimportowana przez aplikację. W praktyce znacząco zwiększa to skuteczność infekcji i utrudnia jej wykrycie.

Atak ten pokazuje również, jak cenne dla napastnika są lokalne sekrety. W wielu przypadkach nie trzeba łamać zaawansowanych zabezpieczeń, jeśli dane uwierzytelniające znajdują się w przewidywalnych ścieżkach, pamięciach podręcznych, plikach środowiskowych lub artefaktach buildów.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem kompromitacji LiteLLM jest ryzyko wtórnego przejęcia innych systemów. Jeżeli napastnik uzyska dostęp do lokalnych sekretów z maszyny dewelopera lub runnera CI/CD, może wykorzystać je do dalszej eskalacji incydentu w infrastrukturze organizacji.

dostęp do repozytoriów kodu źródłowego,
przejęcie kont i usług chmurowych,
kompromitacja pipeline’ów CI/CD,
publikacja złośliwych obrazów, pakietów lub artefaktów,
ruch boczny do środowisk testowych i produkcyjnych,
dalszy wyciek danych i sekretów organizacji.

Ryzyko jest szczególnie wysokie tam, gdzie stosowane są długowieczne klucze, współdzielone tokeny lub poświadczenia bez ograniczeń czasowych. W takim modelu pojedyncza zależność zainfekowana malware może stać się punktem wejścia do szerszej kompromitacji obejmującej wiele systemów i zespołów.

Problemem pozostaje także detekcja. Jeśli złośliwy kod działa w ramach standardowego uruchamiania interpretera Pythona i czyta lokalne pliki konfiguracyjne, aktywność może przez pewien czas wyglądać jak normalne działanie środowiska programistycznego. To wydłuża czas wykrycia i zwiększa potencjalną skalę szkód.

Rekomendacje

Organizacje, które mogły mieć kontakt z wersjami 1.82.7 lub 1.82.8, powinny traktować incydent jako potencjalną kompromitację poświadczeń. Odpowiedź nie powinna ograniczać się do usunięcia pakietu, lecz objąć pełną ocenę ekspozycji i odtworzenie zaufania do sekretów.

sprawdzić lockfile, logi instalacji, historię buildów oraz zależności przechodnie,
zweryfikować obrazy kontenerowe, cache pakietów i środowiska wirtualne,
zrotować klucze SSH, tokeny API i poświadczenia chmurowe,
przeanalizować katalogi site-packages pod kątem nieautoryzowanych plików .pth,
przejrzeć pliki .env, konfiguracje CLI, historię poleceń i pamięci podręczne narzędzi,
pinować wersje zależności i ograniczać automatyczne aktualizacje bez walidacji,
przenosić sekrety do scentralizowanych vaultów oraz stosować krótkotrwałe tokeny,
wdrożyć monitoring endpointów i traktować stacje deweloperskie jako zasoby uprzywilejowane.

Z perspektywy strategicznej istotne jest także przygotowanie procedur reagowania na incydenty związane z otwartymi zależnościami. Organizacje powinny zakładać, że kompromitacja popularnego pakietu może mieć skutki porównywalne z naruszeniem krytycznego systemu wewnętrznego.

Podsumowanie

Kompromitacja LiteLLM na PyPI pokazuje, że nowoczesne ataki supply chain coraz częściej koncentrują się na narzędziach używanych bezpośrednio przez deweloperów i automatyzację. W tym modelu głównym celem nie jest wyłącznie kod aplikacji, lecz lokalnie zgromadzone sekrety umożliwiające dostęp do repozytoriów, chmury i procesów wdrożeniowych.

Złośliwe wersje 1.82.7 i 1.82.8 były szczególnie groźne, ponieważ umożliwiały wykonanie kodu kradnącego poświadczenia w standardowym środowisku Pythona. Najważniejszy wniosek jest praktyczny: stacje deweloperskie i runnery CI/CD należy chronić z taką samą dyscypliną jak systemy produkcyjne, a każdy incydent dotyczący zależności traktować jako potencjalny wyciek sekretów.

Źródła

BlueHammer: publiczny exploit zero-day dla Windows umożliwia eskalację uprawnień do SYSTEM

Wprowadzenie do problemu / definicja

BlueHammer to ujawniony publicznie exploit typu local privilege escalation (LPE) dla systemu Windows, który może umożliwiać podniesienie uprawnień z poziomu zwykłego użytkownika do administratora z podwyższonym kontekstem, a nawet do konta SYSTEM. Tego rodzaju podatności są szczególnie niebezpieczne, ponieważ nie muszą służyć do początkowego włamania — ich główną rolą jest przejęcie pełnej kontroli nad urządzeniem już po uzyskaniu ograniczonego dostępu.

W praktyce oznacza to, że nawet jeśli atakujący zaczyna od relatywnie niskich uprawnień, może wykorzystać taki błąd do wyłączenia zabezpieczeń, pozyskania danych uwierzytelniających i dalszego rozprzestrzeniania się w środowisku.

W skrócie

BlueHammer jest opisywany jako niezałatana podatność Windows umożliwiająca lokalną eskalację uprawnień. Publicznie udostępniony kod proof-of-concept ma według dostępnych analiz działać przynajmniej w części scenariuszy, prowadząc do dostępu do bazy SAM i finalnie do przejęcia kontekstu SYSTEM.

dotyczy lokalnej eskalacji uprawnień w Windows,
wykorzystuje kombinację TOCTOU oraz niejednoznaczności ścieżek,
może otworzyć drogę do odczytu poufnych artefaktów uwierzytelniających,
zwiększa ryzyko przejęcia hosta po wcześniejszym phishingu lub nadużyciu poświadczeń,
jest istotny operacyjnie mimo wymogu lokalnego uruchomienia.

Kontekst / historia

Sprawa zyskała rozgłos po upublicznieniu repozytorium zawierającego kod exploita przez badacza bezpieczeństwa rozczarowanego przebiegiem procesu zgłoszenia luki. Z dostępnych informacji wynika, że podatność miała zostać wcześniej przekazana prywatnie, jednak brak poprawki i późniejsza publikacja kodu zmieniły sytuację w incydent o wysokim znaczeniu operacyjnym.

Istotne jest to, że nie chodzi wyłącznie o teoretyczny opis błędu, ale o praktyczny proof-of-concept, który został poddany testom przez innych badaczy. Choć sam autor wskazał na możliwe problemy ze stabilnością i błędy w implementacji, nie zmniejsza to ryzyka. W realnych kampaniach nawet częściowo działający exploit może zostać szybko poprawiony i dostosowany do konkretnych środowisk.

Analiza techniczna

BlueHammer ma wykorzystywać połączenie dwóch klas problemów: TOCTOU oraz path confusion. Błąd TOCTOU polega na tym, że sprawdzenie uprawnień lub stanu zasobu odbywa się w innym momencie niż rzeczywiste wykonanie operacji. Jeśli atakujący zdoła zmienić warunki pomiędzy tymi etapami, uprzywilejowany komponent może wykonać działanie na obiekcie innym niż ten pierwotnie zweryfikowany.

Drugi element dotyczy niejednoznaczności ścieżek dostępu, czyli manipulowania sposobem rozwiązywania odwołań do plików lub obiektów systemowych. W takim scenariuszu proces działający z wysokimi uprawnieniami może zostać skłoniony do operacji na zasobie kontrolowanym przez atakującego albo do ujawnienia dostępu do chronionych danych.

Według opisów technicznych skuteczne wykorzystanie exploita może prowadzić do dostępu do bazy Security Account Manager, która zawiera skróty haseł lokalnych kont. To szczególnie groźny etap, ponieważ pozyskanie takich danych może umożliwić dalszą eskalację, przejmowanie sesji, ruch boczny oraz utrwalenie obecności w środowisku. W najbardziej niebezpiecznym wariancie końcowym efektem jest uruchomienie procesu w kontekście SYSTEM.

Należy jednak zaznaczyć, że niezawodność exploita może zależeć od wersji systemu, konfiguracji hosta, mechanizmów ochronnych oraz poziomu aktualizacji. Część analiz wskazuje na problemy ze stabilnością, zwłaszcza w niektórych środowiskach serwerowych, ale z perspektywy obrony nie jest to powód do bagatelizowania zagrożenia.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem BlueHammer jest możliwość pełnego przejęcia lokalnego systemu po uzyskaniu minimalnego poziomu wykonania kodu. Atakujący może po eskalacji wyłączyć narzędzia ochronne, instalować malware, modyfikować ustawienia bezpieczeństwa, pozyskiwać poświadczenia i wykonywać operacje administracyjne bez wiedzy użytkownika.

W środowisku firmowym wpływ takiej podatności wykracza poza pojedynczy komputer. Przejęcie stacji roboczej z dostępem do zasobów domenowych może prowadzić do kradzieży kolejnych sekretów, dalszej eskalacji oraz ruchu bocznego. Ryzyko rośnie szczególnie tam, gdzie występuje ponowne używanie haseł lokalnych administratorów, brak segmentacji i nadmiarowe uprawnienia.

Choć BlueHammer nie jest podatnością zdalnego wykonania kodu, warunek lokalnego uruchomienia nie eliminuje zagrożenia. W praktyce wiele łańcuchów ataku rozpoczyna się od phishingu, przejęcia poświadczeń lub wykorzystania innej luki, a następnie przechodzi do lokalnej eskalacji uprawnień. Publiczna dostępność kodu skraca czas potrzebny na weaponizację i zwiększa prawdopodobieństwo pojawienia się kolejnych wariantów.

Rekomendacje

Do czasu publikacji oficjalnych poprawek organizacje powinny traktować BlueHammer jako zagrożenie wymagające aktywnych działań kompensacyjnych. Kluczowe jest ograniczenie możliwości lokalnego wykonania kodu przez użytkowników oraz zwiększenie widoczności prób eskalacji uprawnień.

ograniczyć lokalne uprawnienia użytkowników do niezbędnego minimum,
wdrożyć kontrolę aplikacji za pomocą AppLocker, WDAC lub porównywalnych mechanizmów,
monitorować dostęp do chronionych ścieżek i anomalie związane z bazą SAM,
zwiększyć poziom telemetrii EDR i SIEM dla prób uruchamiania procesów w kontekście SYSTEM,
stosować unikalne hasła lokalnych administratorów i rozwiązania klasy LAPS,
ograniczyć interaktywne logowanie kont uprzywilejowanych na stacjach roboczych,
wzmocnić ochronę przed phishingiem i kradzieżą poświadczeń,
przygotować reguły detekcji pod kątem TOCTOU, manipulacji ścieżkami oraz nagłych zmian tokenów uprawnień.

Z perspektywy reagowania na incydenty warto również sprawdzić, czy na hostach nie występują ślady odczytu chronionych artefaktów uwierzytelniających, nietypowych operacji na plikach systemowych oraz uruchamiania procesów potomnych z podwyższonym kontekstem. Zespoły bezpieczeństwa powinny też śledzić komunikaty producenta, aby jak najszybciej przejść od mitigacji do pełnego usunięcia ryzyka.

Podsumowanie

BlueHammer pokazuje, że lokalna podatność może mieć bardzo poważne konsekwencje biznesowe i operacyjne, nawet jeśli nie zapewnia zdalnego wejścia do systemu. Publiczne ujawnienie exploita przed udostępnieniem poprawki zwiększa presję na zespoły bezpieczeństwa i skraca okno reakcji.

Najważniejsze działania na obecnym etapie to ograniczenie lokalnych uprawnień, ścisła kontrola uruchamianego kodu, monitoring prób eskalacji oraz szybkie wdrożenie aktualizacji, gdy tylko staną się dostępne.

Źródła

CVE-2026-35616 w FortiClient EMS: krytyczna luka zero-day aktywnie wykorzystywana przed publikacją poprawek

Wprowadzenie do problemu / definicja

Fortinet opublikował awaryjne poprawki dla podatności CVE-2026-35616 w platformie FortiClient EMS. To krytyczna luka wynikająca z niewłaściwej kontroli dostępu w interfejsie API, która może umożliwić nieuwierzytelnionemu napastnikowi obejście mechanizmów bezpieczeństwa i wykonanie nieautoryzowanych operacji na podatnym systemie.

Znaczenie problemu dodatkowo podnosi fakt, że producent potwierdził aktywne wykorzystywanie podatności w rzeczywistych atakach jeszcze przed pełnym wdrożeniem poprawek. Oznacza to scenariusz zero-day, w którym organizacje mogły zostać narażone na kompromitację zanim pojawiły się oficjalne środki naprawcze.

W skrócie

CVE-2026-35616 to podatność sklasyfikowana jako improper access control, oceniona na 9.1 w skali CVSS v3. Luka dotyczy FortiClient EMS i pozwala atakującemu bez uwierzytelnienia wykonywać nieautoryzowane polecenia lub kod poprzez odpowiednio przygotowane żądania API.

Podatne są wersje FortiClient EMS 7.4.5 oraz 7.4.6.
Linia 7.2 według producenta nie jest podatna.
Fortinet udostępnił hotfixy dla wskazanych wersji.
Trwała poprawka ma zostać uwzględniona również w wydaniu 7.4.7.
Eksploatacja podatności została potwierdzona w środowiskach rzeczywistych.

Kontekst / historia

Incydent wpisuje się w utrzymujący się trend ataków wymierzonych w systemy brzegowe, konsole administracyjne oraz platformy zarządzania bezpieczeństwem. Rozwiązania klasy EMS są szczególnie atrakcyjne dla napastników, ponieważ zwykle mają szeroką widoczność nad stacjami końcowymi, integrują się z narzędziami ochronnymi i działają z wysokimi uprawnieniami.

W tym przypadku podatność została zgłoszona producentowi po zaobserwowaniu aktywnej eksploatacji. Tego rodzaju sytuacja znacząco skraca czas reakcji po stronie obrońców, ponieważ klasyczny cykl zarządzania poprawkami przestaje być wystarczający. Organizacje muszą równolegle aktualizować systemy, analizować logi i zakładać możliwość wcześniejszego naruszenia.

Analiza techniczna

Źródłem problemu jest błąd klasy CWE-284, czyli niewłaściwa kontrola dostępu. W praktyce oznacza to, że aplikacja nie egzekwuje poprawnie zasad autoryzacji dla określonych funkcji API. Odpowiednio spreparowane żądanie może więc zostać zaakceptowane mimo braku ważnej sesji lub wymaganych uprawnień.

Najgroźniejszym aspektem tej podatności jest charakter pre-auth. Atakujący nie musi wcześniej przejmować legalnego konta ani uzyskiwać dostępu do poświadczeń. Jeśli podatny interfejs API jest osiągalny, może próbować bezpośrednio wykonywać nieautoryzowane działania na serwerze EMS.

Z punktu widzenia operacyjnego luka jest wyjątkowo niebezpieczna z kilku powodów. Po pierwsze, wektor ataku nie wymaga uwierzytelnienia. Po drugie, dotyczy API, czyli interfejsu często używanego automatycznie przez integracje i narzędzia administracyjne. Po trzecie, potwierdzona aktywna eksploatacja zwiększa prawdopodobieństwo masowego skanowania internetu oraz szybkiego pojawienia się publicznych exploitów i prób automatyzacji ataków.

Konsekwencje / ryzyko

Ryzyko dla organizacji korzystających z podatnych wersji FortiClient EMS należy uznać za bardzo wysokie. Skuteczne wykorzystanie luki może doprowadzić do przejęcia kontroli nad komponentem zarządzającym ochroną stacji końcowych, a następnie umożliwić dalsze działania wewnątrz infrastruktury.

Potencjalne skutki obejmują eskalację uprawnień, ruch lateralny, manipulację politykami bezpieczeństwa, zakłócenie działania agentów endpointowych, a także przygotowanie środowiska pod kolejne etapy ataku, w tym wdrożenie ransomware. Im większy zakres uprawnień i integracji posiada instancja EMS, tym większa skala potencjalnego incydentu.

Dodatkowym problemem jest to, że systemy zarządzające często działają w segmentach administracyjnych lub są dostępne z sieci o podwyższonym poziomie zaufania. Ich kompromitacja może więc prowadzić nie tylko do utraty integralności konfiguracji, ale również do rozszerzenia ataku na wiele zasobów organizacji.

Rekomendacje

Organizacje używające FortiClient EMS 7.4.5 i 7.4.6 powinny potraktować ten problem priorytetowo. Samo wdrożenie poprawek jest kluczowe, ale przy potwierdzonej eksploatacji równie ważna jest weryfikacja, czy podatne systemy nie zostały już naruszone przed aktualizacją.

Niezwłocznie zinwentaryzować wszystkie instancje FortiClient EMS i potwierdzić ich wersje.
Zastosować dostępne hotfixy dla wersji 7.4.5 i 7.4.6 lub przejść do wersji zawierającej trwałą poprawkę.
Ograniczyć ekspozycję interfejsów zarządzających oraz API wyłącznie do zaufanych adresów i segmentów administracyjnych.
Przeanalizować logi pod kątem nietypowych żądań API, prób obejścia uwierzytelniania i nieautoryzowanych zmian konfiguracji.
Zweryfikować, czy na serwerze EMS nie uruchamiano podejrzanych poleceń, procesów lub zadań harmonogramu.
Wymusić rotację poświadczeń administracyjnych oraz przegląd tokenów i integracji, jeśli istnieje podejrzenie kompromitacji.
Objąć system wzmożonym monitoringiem EDR, SIEM i NDR, ze szczególnym uwzględnieniem komunikacji wychodzącej z hosta zarządzającego.
Przygotować plan containment obejmujący izolację serwera, analizę śledczą i odbudowę z zaufanego źródła.

W praktyce FortiClient EMS powinien być traktowany jako zasób o podwyższonym znaczeniu krytycznym. Obejmuje to ścisłą segmentację, minimalizację dostępu administracyjnego oraz regularny przegląd ekspozycji usług wspierających i integracyjnych.

Podsumowanie

CVE-2026-35616 to krytyczna podatność w FortiClient EMS, która łączy obejście kontroli dostępu z możliwością wykonywania nieautoryzowanych działań przez API. Najważniejszym elementem tej sprawy jest potwierdzona aktywna eksploatacja przed szerokim wdrożeniem poprawek, co znacząco zwiększa poziom ryzyka dla organizacji korzystających z podatnych wersji.

Dla administratorów i zespołów bezpieczeństwa oznacza to konieczność natychmiastowego działania: aktualizacji, przeglądu telemetrii oraz sprawdzenia, czy systemy nie zostały już wykorzystane przez atakujących. W przypadku platform zarządzających bezpieczeństwem opóźnienie reakcji może mieć poważne skutki dla całego środowiska.