Archiwa: Ransomware - Strona 9 z 117

GhostTree: jak rekursywne junctions w Windows pomagają ukrywać malware przed skanowaniem

Wprowadzenie do problemu / definicja

GhostTree to technika unikania detekcji w systemach Windows, która wykorzystuje rekursywne dowiązania katalogów NTFS typu junction do budowania zapętlonych struktur ścieżek. W praktyce pozwala to tworzyć bardzo dużą liczbę logicznie poprawnych odwołań do tych samych plików i katalogów, co może utrudniać lub wręcz blokować skuteczne skanowanie przez część narzędzi bezpieczeństwa.

Problem nie wynika z klasycznej podatności w jądrze systemu, ale z różnic między sposobem działania systemu plików NTFS a metodą, jaką silniki antywirusowe, EDR i skanery plików realizują rekursywne przeszukiwanie katalogów. To sprawia, że legalna funkcja systemu może zostać wykorzystana ofensywnie.

W skrócie

GhostTree opiera się na mechanizmie junctions w NTFS.
Atakujący może tworzyć zapętlone struktury katalogów bez uprawnień administratora, jeśli ma prawo zapisu do folderu.
Wiele odgałęzień prowadzących do tego samego katalogu powoduje gwałtowny wzrost liczby możliwych ścieżek.
Narzędzia bezpieczeństwa mogą zawieszać się, przekraczać limity czasu lub nie kończyć skanowania.
W efekcie złośliwy plik umieszczony w katalogu bazowym może nie zostać przeanalizowany w odpowiednim czasie.

Kontekst / historia

Dowiązania katalogów i inne typy reparse points od dawna są obecne w ekosystemie Windows. Służą między innymi do zachowania kompatybilności, reorganizacji danych oraz przekierowywania ścieżek bez konieczności fizycznego przenoszenia plików. Z perspektywy administracyjnej są użyteczne, ale z perspektywy bezpieczeństwa bywają niedoszacowanym ryzykiem.

GhostTree rozwija prostszy scenariusz określany jako GhostBranch, w którym pojedynczy katalog potomny wskazuje z powrotem na katalog nadrzędny. W wersji rozszerzonej zamiast jednej pętli powstaje wiele równoległych odgałęzień, co prowadzi do efektu drzewa rekursyjnego. Każda kolejna warstwa zwiększa liczbę poprawnych logicznie ścieżek prowadzących do tych samych obiektów.

Analiza techniczna

Junction w NTFS jest szczególnym typem reparse point, który przekierowuje dostęp z jednego katalogu do innego. Dla aplikacji analizującej system plików zawartość katalogu docelowego może wyglądać tak, jakby znajdowała się lokalnie w miejscu odwołania. To właśnie ten mechanizm staje się podstawą techniki GhostTree.

W najprostszym wariancie tworzony jest katalog podrzędny, który wskazuje z powrotem na katalog nadrzędny. Gdy skaner porusza się rekursywnie po strukturze, może wielokrotnie odwiedzać ten sam logiczny obszar danych pod różnymi ścieżkami. Jeśli oprogramowanie nie rozpoznaje cykli lub nie deduplikuje obiektów według rzeczywistej tożsamości pliku czy katalogu, zaczyna wykonywać zbędną i kosztowną analizę.

GhostTree zwiększa skuteczność tego podejścia przez dodanie wielu katalogów potomnych wskazujących na tego samego rodzica. W rezultacie liczba możliwych kombinacji ścieżek rośnie wykładniczo. Nawet jeśli głębokość pozostaje ograniczona przez długość ścieżki i zachowanie aplikacji, całkowity koszt przetwarzania może stać się bardzo wysoki.

Znaczenie ma także sposób obsługi limitów długości ścieżek w Windows. Chociaż współczesne środowiska mogą wspierać dłuższe ścieżki, wiele narzędzi nadal korzysta z uproszczonych założeń lub starszych mechanizmów. W połączeniu z reparse points może to prowadzić do timeoutów, błędów logiki skanowania albo pomijania właściwego obiektu docelowego.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem GhostTree jest możliwość ukrycia malware w lokalizacji, której pełne przeskanowanie staje się dla narzędzia ochronnego zbyt kosztowne lub praktycznie niewykonalne. Zwiększa to ryzyko, że dropper, loader, ransomware lub inny złośliwy plik pozostanie niewykryty przez istotny czas.

Technika ta jest szczególnie niebezpieczna w środowiskach, które w dużym stopniu opierają bezpieczeństwo na skanowaniu endpointów. Jeśli produkt EDR lub AV nie radzi sobie poprawnie z rekursywnymi junctions, napastnik może wykorzystać tę słabość do opóźnienia analizy lub obejścia jednej z warstw obrony.

Ryzyko nie ogranicza się wyłącznie do detekcji malware. Zapętlone struktury katalogów mogą również wpływać na działanie systemów backupu, DLP, inwentaryzacji zasobów, skryptów administracyjnych i narzędzi IR. W efekcie organizacja może obserwować zwiększone zużycie zasobów, błędy operacyjne, timeouty i problemy z analizą incydentów.

Rekomendacje

Organizacje powinny traktować junctions, symbolic links i inne reparse points jako element wymagający monitorowania. Szczególnie podejrzane są sytuacje, w których katalog potomny wskazuje na katalog nadrzędny lub wiele odgałęzień prowadzi do tej samej lokalizacji.

Wdrożyć wykrywanie cykli w grafie katalogów zamiast ślepego podążania za każdą ścieżką.
Ograniczać głębokość rekursji oraz liczbę ścieżek odwiedzanych przez skanery.
Deduplikować analizę według rzeczywistego obiektu na dysku, a nie wyłącznie tekstowej postaci ścieżki.
Monitorować tworzenie i modyfikację reparse points w telemetryce bezpieczeństwa.
Przeprowadzić audyt uprawnień do katalogów, w których użytkownicy mogą tworzyć junctions.
Testować produkty EDR, AV i skanery plików pod kątem poprawnej obsługi rekursywnych junctions.
Regularnie aktualizować silniki ochronne, ponieważ nowe wersje mogą zawierać poprawki w tym obszarze.

Dodatkowo warto uwzględnić GhostTree w działaniach threat huntingowych oraz scenariuszach ćwiczeń zespołów SOC i IR. Pozwala to wcześniej ustalić, czy używane narzędzia rzeczywiście wykrywają ten typ nadużycia i czy skanowanie kończy się prawidłowo.

Podsumowanie

GhostTree pokazuje, że obejście zabezpieczeń nie zawsze wymaga zaawansowanego exploita ani eskalacji uprawnień. Czasami wystarczy wykorzystanie legalnego mechanizmu systemu operacyjnego w sposób, którego oprogramowanie ochronne nie przewidziało. Rekursywne junctions mogą zamienić zwykły katalog w strukturę trudną do pełnego przeskanowania przez źle zaprojektowane silniki analizy.

Dla obrońców to ważne przypomnienie, że skuteczność ochrony endpointów zależy nie tylko od sygnatur i heurystyk, ale również od poprawnego modelowania zachowania systemu plików. Monitorowanie reparse points, testy odporności narzędzi oraz wielowarstwowa detekcja pozostają kluczowe, by ograniczyć skuteczność technik takich jak GhostTree.

Źródła

GhostTree Attack Abused Recursive Windows Junctions to Hide Malware — https://www.bleepingcomputer.com/news/security/ghosttree-attack-abused-recursive-windows-junctions-to-hide-malware/
Hard links and junctions — Microsoft Learn — https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions
Maximum Path Length Limitation — Microsoft Learn — https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

Steam Workshop i Wallpaper Engine wykorzystane do dystrybucji malware

Wprowadzenie do problemu / definicja

Platformy z treściami tworzonymi przez społeczność od dawna znajdują się w obszarze zainteresowania cyberprzestępców. Najnowszy przypadek związany ze Steam Workshop i aplikacją Wallpaper Engine pokazuje, że nawet legalny ekosystem dodatków wizualnych może zostać wykorzystany do dystrybucji złośliwego oprogramowania.

Problem dotyczy przede wszystkim tapet uruchamianych jako aplikacje, które nie są jedynie elementem graficznym, lecz mogą wykonywać kod w systemie Windows. To sprawia, że zwykła personalizacja pulpitu staje się potencjalnym wektorem infekcji.

W skrócie

Badacze bezpieczeństwa wykryli kampanię, w której złośliwe tapety publikowane w Steam Workshop były instalowane przez użytkowników za pośrednictwem Wallpaper Engine. Po uruchomieniu takich elementów dochodziło do instalacji dodatkowych komponentów malware.

Wykryto backdoory i stealery informacji.
Atakujący kradli dane dostępowe do kont Steam.
W części przypadków instalowano koparki kryptowalut, loadery botnetów oraz ransomware.
Choć część złośliwych pozycji usunięto, sam model ataku pozostaje aktualny.

Kontekst / historia

Wallpaper Engine to popularne narzędzie do personalizacji pulpitu dostępne w ekosystemie Steam. Oprogramowanie obsługuje różne typy tapet, w tym materiały wideo, sceny interaktywne, strony internetowe oraz tapety-aplikacje.

Z perspektywy bezpieczeństwa kluczowe znaczenie ma właśnie ostatnia z tych kategorii. Tego typu zawartość może uruchamiać natywne aplikacje Windows, co oznacza, że granica między dekoracyjną treścią a wykonywalnym kodem praktycznie zanika.

Według ustaleń badaczy, atakujący wykorzystywali ten mechanizm co najmniej od końca 2025 roku. Do Steam Workshop trafiały pozornie nieszkodliwe pakiety, które po aktywacji inicjowały pobranie lub uruchomienie dodatkowych ładunków malware.

Analiza techniczna

Sedno zagrożenia tkwi w architekturze funkcji application wallpapers. W odróżnieniu od zwykłych tapet nie są one statycznym zasobem, lecz komponentem mogącym uruchamiać kod w systemie operacyjnym.

W analizowanych przypadkach złośliwe pliki były osadzane bezpośrednio w pakiecie tapety albo ukrywane w chronionych archiwach. Mechanizm socjotechniczny był prosty: użytkownik miał uwierzyć, że instaluje atrakcyjny dodatek wizualny, prostą grę lub nieszkodliwą miniaplikację.

Jeden z opisanych przykładów podszywał się pod działającą zgodnie z oczekiwaniami grę, co miało ograniczyć podejrzenia ofiary. Równolegle w tle uruchamiany był backdoor z rodziny DarkKomet, a dodatkowo wdrażano zmodyfikowaną bibliotekę AggregatorHost.dll odpowiedzialną za wyszukiwanie artefaktów związanych z kontami Steam i kradzież danych uwierzytelniających.

Badacze wskazali również na obecność innych rodzin malware, takich jak Lumma i Vidar, znanych z wykradania danych z przeglądarek, portfeli kryptowalutowych i lokalnych magazynów haseł. W niektórych próbkach obserwowano także koparki kryptowalut, loadery botnetów, RanEngine oraz ransomware.

To sugeruje, że nie chodziło wyłącznie o pojedynczą kampanię jednego aktora, ale o szersze wykorzystywanie tego samego kanału dystrybucji przez różne grupy zagrożeń. Atak ten wpisuje się w model nadużycia zaufanej platformy, w którym użytkownik pobiera złośliwą zawartość z rozpoznawalnego i legalnego źródła.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem ataku jest przejęcie konta Steam i utrata danych uwierzytelniających. Może to prowadzić do utraty dostępu do biblioteki gier, cyfrowych przedmiotów oraz środków przypisanych do profilu.

Ryzyko wykracza jednak poza samo konto gracza. Backdoor może zapewnić trwały dostęp do hosta, stealer umożliwia kradzież haseł i danych finansowych, a miner powoduje zwiększone obciążenie zasobów systemowych.

Jeśli zaatakowane urządzenie jest wykorzystywane również do pracy, incydent może przerodzić się w naruszenie bezpieczeństwa organizacji. Zaufanie do platformy społecznościowej dodatkowo zwiększa skuteczność takiego scenariusza, ponieważ duża liczba pobrań lub pozytywna ekspozycja mogą tworzyć fałszywe poczucie wiarygodności.

Rekomendacje

Użytkownicy powinni zachować szczególną ostrożność wobec dodatków instalowanych z platform społecznościowych, zwłaszcza jeśli uruchamiają one kod wykonywalny. Dotyczy to nie tylko Wallpaper Engine, ale również innych aplikacji opartych na treściach generowanych przez użytkowników.

Instalować wyłącznie treści pochodzące od znanych i wiarygodnych autorów.
Unikać pakietów typu aplikacyjnego, jeśli ich działanie nie jest w pełni zrozumiałe.
Skanować pobierane elementy narzędziami antymalware z aktualnymi sygnaturami.
Włączyć ochronę konta Steam, w tym uwierzytelnianie wieloskładnikowe.
Monitorować nietypowe biblioteki DLL, wpisy autostartu i procesy potomne.
Nie używać tego samego hosta do celów prywatnych i służbowych, jeśli nie jest to konieczne.

W środowiskach firmowych zalecane jest wdrożenie polityk application control, ograniczeń uruchamiania binariów z katalogów użytkownika, sandboxingu oraz monitorowania aplikacji personalizacyjnych przez systemy EDR i SOC.

Podsumowanie

Incydent związany ze Steam Workshop i Wallpaper Engine pokazuje, że nawet narzędzia kojarzone z rozrywką mogą zostać przekształcone w skuteczny kanał dostarczania malware. Nie był to wyłącznie przypadek złośliwej tapety, lecz przykład nadużycia zaufanego ekosystemu dystrybucji treści.

Najważniejszy wniosek jest jasny: każda funkcja pozwalająca uruchamiać aktywną zawartość powinna być traktowana jak potencjalny mechanizm wykonania kodu. Dla użytkowników oznacza to większą ostrożność przy instalowaniu dodatków, a dla organizacji konieczność twardszej kontroli aplikacji i segmentacji ryzyka.

Źródła

https://www.bleepingcomputer.com/news/security/steam-workshop-abused-to-spread-malware-via-wallpaper-engine-app/
https://securelist.com/
https://partner.steamgames.com/doc/features/workshop
https://help.wallpaperengine.io/

Incydent cyberbezpieczeństwa w Mackay Sugar zakłócił produkcję podczas sezonu przerobu trzciny

Wprowadzenie do problemu / definicja

Mackay Sugar, jeden z największych producentów cukru w Australii, poinformował o incydencie cyberbezpieczeństwa, który wpłynął na część operacji firmy. Zdarzenie pokazuje, jak duże znaczenie dla przedsiębiorstw przemysłowych mają systemy IT wspierające logistykę, planowanie i ciągłość działania.

W sektorze produkcyjnym cyberincydent nie musi bezpośrednio zatrzymać całej infrastruktury technologicznej, aby spowodować poważne zakłócenia. Wystarczy naruszenie systemów odpowiedzialnych za koordynację dostaw, harmonogramowanie prac i obsługę operacyjną, by odczuć skutki w całym łańcuchu wartości.

W skrócie

Incydent został ujawniony 10 czerwca 2026 roku.
Zakłócenia objęły wybrane obszary działalności Mackay Sugar.
Firma uruchomiła procedury awaryjne i zaangażowała zewnętrznych specjalistów ds. cyberbezpieczeństwa.
Rozpoczęto współpracę z odpowiednimi organami oraz proces odtwarzania środowiska.
W zakładzie Farleigh Mill uruchomiono ograniczony, ręczny proces przerobu.
Pojawiły się doniesienia o możliwym powiązaniu zdarzenia z grupą ransomware The Gentlemen.

Kontekst / historia

Incydent wystąpił w szczególnie newralgicznym momencie, czyli podczas sezonu przerobu trzciny cukrowej. Dla tego typu przedsiębiorstwa czas ma kluczowe znaczenie operacyjne i finansowe, ponieważ zakłócenia wpływają nie tylko na samą produkcję, ale również na odbiór surowca, harmonogram zbiorów oraz współpracę z plantatorami i partnerami logistycznymi.

Spółka podkreśliła, że jej priorytetem od początku było bezpieczeństwo ludzi, zabezpieczenie systemów operacyjnych oraz utrzymanie możliwie największej ciągłości działania. W praktyce oznaczało to wdrożenie procesów zastępczych dla najważniejszych funkcji biznesowych i stopniowe przywracanie środowisk wspierających dostawy trzciny, zbiory i pracę młynów.

Kolejne komunikaty firmy wskazywały na postępy w odbudowie zdolności operacyjnej oraz przygotowania do etapowego wznowienia szerszego zakresu działań. To typowy model reagowania w środowisku przemysłowym, gdzie przywracanie pracy musi być prowadzone ostrożnie i z uwzględnieniem bezpieczeństwa procesowego.

Analiza techniczna

Na obecnym etapie nie ujawniono szczegółowych informacji dotyczących wektora ataku, wykorzystanej podatności ani dokładnego zakresu kompromitacji. Tego rodzaju ograniczona transparentność jest częsta we wczesnej fazie obsługi incydentu, gdy organizacja równolegle prowadzi analizę śledczą, ogranicza skutki ataku i odtwarza systemy.

Z technicznego punktu widzenia kluczowe znaczenie mają trzy warstwy ryzyka. Pierwsza to warstwa biznesowego IT, obejmująca komunikację, planowanie, koordynację dostaw i obsługę partnerów. Druga to warstwa OT lub ICS, czyli środowiska przemysłowe odpowiedzialne za bezpieczne prowadzenie procesu technologicznego. Trzecia to warstwa integracyjna pomiędzy IT i OT, która bardzo często stanowi istotny punkt podatności i możliwy kanał rozprzestrzeniania się incydentu.

Komunikaty wskazują, że wpływ incydentu objął przynajmniej systemy wspierające dostawy trzciny, harmonogramowanie zbiorów i operacje młynów. Uruchomienie ograniczonego ręcznego procesu przerobu w Farleigh Mill sugeruje próbę przywrócenia minimalnej zdolności operacyjnej bez pełnego uzależnienia od wszystkich standardowych systemów cyfrowych.

Takie podejście jest zgodne z praktyką odporności operacyjnej w środowiskach przemysłowych. Częściowy powrót do pracy zwykle wymaga walidacji bezpieczeństwa procesu, testów funkcjonalnych oraz sprawdzenia, czy odtwarzane systemy nie stanowią ryzyka dla infrastruktury krytycznej.

Dodatkowym elementem analizy są informacje o możliwym związku zdarzenia z grupą The Gentlemen. W scenariuszu ransomware może to oznaczać zarówno szyfrowanie systemów, jak i model podwójnego wymuszenia, w którym presji operacyjnej towarzyszy groźba ujawnienia skradzionych danych. Brak publicznego potwierdzenia wycieku nie pozwala jednak jednoznacznie ocenić pełnej skali naruszenia poufności.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem incydentu było zakłócenie ciągłości działania. W przedsiębiorstwach rolno-przemysłowych nawet krótkie opóźnienia mogą przekładać się na spadek wydajności, trudności logistyczne oraz dodatkowe koszty związane z przestojami i organizacją pracy w trybie ręcznym.

Ryzyko operacyjne – ograniczenie przepustowości zakładów, przestoje i konieczność pracy w procedurach zastępczych.
Ryzyko dla OT – potencjalny wpływ na bezpieczeństwo procesów technologicznych, jeśli incydent objął obszary styku IT i OT.
Ryzyko danych – możliwość utraty lub kradzieży danych operacyjnych, handlowych i personalnych.
Ryzyko finansowe – koszty reagowania, analiz śledczych, odtwarzania środowiska i strat wynikających z zakłóceń produkcji.
Ryzyko reputacyjne – osłabienie zaufania wśród partnerów, dostawców i odbiorców.
Ryzyko łańcucha dostaw – negatywny wpływ na kontrahentów zależnych od terminowego odbioru i przetwarzania surowca.

W środowisku przemysłowym szczególnie niebezpieczny jest scenariusz, w którym awaria systemów korporacyjnych nie zatrzymuje bezpośrednio urządzeń produkcyjnych, ale uniemożliwia bezpieczne i skoordynowane wznowienie normalnej pracy. Taka sytuacja może znacząco wydłużyć czas powrotu do pełnej operacyjności.

Rekomendacje

Incydent w Mackay Sugar stanowi kolejny sygnał ostrzegawczy dla organizacji przemysłowych, które funkcjonują w modelu silnie zintegrowanych środowisk IT i OT. W praktyce odporność cybernetyczna powinna obejmować zarówno ochronę systemów biurowych, jak i procedury bezpiecznego utrzymania produkcji w sytuacji kryzysowej.

Segmentacja sieci IT i OT oraz ścisła kontrola komunikacji między strefami.
Wdrożenie zasad zero trust dla dostępu zdalnego, kont uprzywilejowanych i działań administracyjnych.
Stały monitoring bezpieczeństwa obejmujący zarówno środowiska IT, jak i sygnały z obszaru OT.
Regularne kopie zapasowe offline oraz testy odtwarzania po incydentach ransomware.
Silne zarządzanie tożsamością, w tym MFA, PAM, rotacja poświadczeń i ograniczanie współdzielonych kont.
Detekcja kradzieży poświadczeń i aktywności infostealerów na stacjach użytkowników oraz w systemach partnerów.
Przygotowanie playbooków reagowania dla środowisk przemysłowych, uwzględniających przejście na tryb ręczny.
Ćwiczenia tabletop i testy ciągłości działania dla scenariuszy zakłócenia produkcji w okresach najwyższego obciążenia.
Weryfikacja bezpieczeństwa dostawców i partnerów logistycznych zintegrowanych z procesami operacyjnymi.
Prowadzenie komunikacji kryzysowej opartej na potwierdzonych faktach i jasnym podziale odpowiedzialności.

Podsumowanie

Przypadek Mackay Sugar pokazuje, że cyberatak na firmę przemysłową może wywołać poważne konsekwencje biznesowe nawet bez pełnego zatrzymania procesu technologicznego. Uderzenie w systemy wspierające logistykę, planowanie i koordynację działań wystarcza, by zakłócić funkcjonowanie całego łańcucha operacyjnego.

To kolejny przykład na to, że odporność cybernetyczna w sektorze produkcyjnym musi być budowana z myślą o współzależności systemów IT i OT, gotowości do pracy w trybie awaryjnym oraz szybkim, kontrolowanym odtwarzaniu kluczowych usług.

Źródła

Australian Sugar Producer Mackay Sugar Reports Cyber Incident — https://securityaffairs.com/193657/data-breach/australian-sugar-producer-mackay-sugar-reports-cyber-incident.html
Mackay Sugar Cyber Security Incident — https://www.mkysugar.com.au/news-updates-circulars/mackay-sugar-cyber-security-incident
Mackay Sugar Cyber Security Incident Update 3 — https://www.mkysugar.com.au/news-updates-circulars/mackay-sugar-cyber-security-incident-akm6l-g5bpl

FulcrumSec twierdzi, że włamał się do Novo Nordisk. W tle 1,3 TB danych i ryzyko utraty własności intelektualnej

Wprowadzenie do problemu / definicja

Incydenty typu hack-and-leak należą dziś do najpoważniejszych zagrożeń dla sektora farmaceutycznego i biotechnologicznego. Tego rodzaju operacje łączą nieautoryzowany dostęp do systemów, kradzież danych oraz presję finansową opartą na groźbie ich publikacji. W przypadku globalnych firm medycznych stawką są nie tylko informacje operacyjne, ale także dokumentacja badań klinicznych, poufne dane rozwojowe oraz własność intelektualna o strategicznej wartości.

Właśnie w taki schemat wpisują się twierdzenia grupy FulcrumSec, która ogłosiła, że przeprowadziła włamanie do duńskiego koncernu farmaceutycznego Novo Nordisk. Według napastników kompromitacja miała objąć zarówno repozytoria kodu, jak i szeroki zestaw danych biznesowych oraz technicznych.

W skrócie

Grupa FulcrumSec przypisała sobie atak na Novo Nordisk.
Napastnicy twierdzą, że uzyskali dostęp z użyciem tokenu GitHub i następnie pozyskali kolejne poświadczenia.
Według deklaracji sprawców wykradziono około 1,3 TB danych oraz listę ponad 700 tysięcy plików.
W tle pojawia się żądanie okupu w wysokości 25 mln dolarów oraz groźba upublicznienia materiałów.
Incydent może mieć znaczenie nie tylko operacyjne, ale również regulacyjne, reputacyjne i biznesowe.

Kontekst / historia

Sprawa zyskała rozgłos po wcześniejszym ujawnieniu przez Novo Nordisk incydentu bezpieczeństwa, w ramach którego nieuprawnione osoby uzyskały dostęp do części wewnętrznych systemów IT i wyeksfiltrowały dane związane z badaniami klinicznymi. Firma wskazywała, że naruszone informacje miały charakter pseudonimizowany, co ograniczało możliwość bezpośredniej identyfikacji pacjentów bez dostępu do dodatkowych zbiorów danych.

W kolejnej fazie grupa FulcrumSec zaczęła publicznie budować narrację wokół skali ataku. To dobrze znany model działania środowisk nastawionych na wymuszenia: po uzyskaniu dostępu przestępcy próbują zwiększyć presję na ofiarę poprzez przedstawianie dowodów posiadania danych, podkreślanie ich wartości oraz sugerowanie szerokiego zasięgu kompromitacji.

Analiza techniczna

Najważniejszym elementem technicznym całej sprawy jest deklarowany wektor wejścia oparty na tokenie dostępu do GitHub. Jeżeli taki token jest nadmiernie uprzywilejowany, nie wygasa lub nie jest właściwie chroniony, może stać się początkiem pełnego łańcucha kompromitacji. Atakujący zyskuje wtedy możliwość klonowania repozytoriów, analizy kodu, przeszukiwania historii commitów oraz identyfikowania sekretów zapisanych w plikach konfiguracyjnych lub artefaktach deweloperskich.

Opisany scenariusz sugeruje, że początkowy dostęp mógł posłużyć do odnalezienia dalszych poświadczeń, kluczy API, danych do integracji CI/CD oraz dostępu do usług chmurowych i narzędzi badawczo-rozwojowych. W realiach dużych organizacji farmaceutycznych repozytoria bardzo często zawierają nie tylko kod aplikacji, ale też dokumentację procesową, pipeline’y danych, modele analityczne, komponenty AI oraz metadane wspierające prace R&D.

Szczególne znaczenie mają twierdzenia o możliwej kradzieży materiałów o wysokiej wartości biznesowej, takich jak nieujawnione programy lekowe, zastrzeżone struktury związków, elementy pipeline’u RNAi czy prywatne modele AI. Nawet jeśli część tych deklaracji nie została niezależnie potwierdzona, sam profil rzekomo przejętych danych wskazuje na potencjalne przeniknięcie do środowisk o znaczeniu strategicznym.

Nie mniej istotne są przedstawione przez sprawców próbki dowodowe, obejmujące listy plików oraz skradzione poświadczenia. Z perspektywy zespołów reagowania na incydenty oznacza to konieczność traktowania zdarzenia jako potencjalnie wielowarstwowego, obejmującego zarówno wyciek danych, jak i kompromitację tożsamości maszynowych, sekretów aplikacyjnych oraz kont uprzywilejowanych.

Konsekwencje / ryzyko

Dla sektora life sciences skutki podobnego incydentu mogą być znacznie poważniejsze niż w klasycznych atakach ransomware. Pierwszym obszarem ryzyka jest ekspozycja danych badań klinicznych oraz informacji regulacyjnych. Nawet jeśli dane są pseudonimizowane, nie można całkowicie wykluczyć ryzyka wtórnej reidentyfikacji po połączeniu ich z dodatkowymi zbiorami.

Drugim kluczowym zagrożeniem jest utrata własności intelektualnej. W branży farmaceutycznej takie zasoby są rezultatem wieloletnich inwestycji i mogą mieć bezpośredni wpływ na przewagę konkurencyjną, harmonogram projektów, relacje z partnerami oraz wycenę przedsiębiorstwa.

Trzecim problemem jest możliwość długotrwałej obecności przeciwnika w środowisku. Jeżeli naruszone zostały tokeny i konta wykorzystywane w procesach automatyzacji, integracjach chmurowych lub łańcuchu dostaw oprogramowania, incydent może otworzyć drogę do dalszych nadużyć, modyfikacji kodu, sabotażu buildów albo ataków na podmioty współpracujące.

Nie można też pominąć skutków reputacyjnych i prawnych. Firmy przetwarzające dane medyczne, badawcze i partnerskie muszą liczyć się z obowiązkami notyfikacyjnymi, kosztownym dochodzeniem forensycznym, kontrolami regulacyjnymi oraz potencjalnymi roszczeniami kontraktowymi.

Rekomendacje

Podstawowym działaniem powinien być natychmiastowy przegląd wszystkich tokenów dostępowych, kluczy API i sekretów używanych w repozytoriach, systemach CI/CD oraz integracjach z chmurą. Tokeny powinny być krótkotrwałe, ściśle ograniczone zakresem uprawnień i regularnie rotowane.

Równie ważne jest wzmocnienie bezpieczeństwa platform deweloperskich. Obejmuje to wdrożenie odpornego na phishing MFA, segmentację dostępu do repozytoriów, polityki least privilege oraz monitorowanie anomalii związanych z klonowaniem repozytoriów i wykorzystaniem tokenów osobistych lub serwisowych.

Organizacje powinny także prowadzić pełną inwentaryzację przepływu danych pomiędzy środowiskami badawczymi, deweloperskimi i produkcyjnymi. Mapowanie zależności między repozytoriami, magazynami danych, systemami analitycznymi, narzędziami MLOps i zasobami laboratoryjnymi jest niezbędne do oceny realnej skali kompromitacji.

Z perspektywy reagowania na incydenty należy przyjąć założenie, że przeciwnik mógł uzyskać zarówno dane, jak i poświadczenia. W praktyce oznacza to konieczność masowej rotacji sekretów, audytu kont uprzywilejowanych, analizy logów dostępu do repozytoriów, przeglądu systemów budowania oprogramowania oraz weryfikacji integralności krytycznych artefaktów.

Dla organizacji z branży farmaceutycznej istotne jest również wdrożenie dodatkowych zabezpieczeń wokół danych badań klinicznych i własności intelektualnej. Wśród nich warto wskazać szyfrowanie warstwowe, DLP ukierunkowane na dokumentację R&D, ścisłą kontrolę eksportu danych, znakowanie informacji oraz wyraźne rozdzielenie środowisk badawczych od narzędzi ogólnokorporacyjnych.

Podsumowanie

Domniemany atak na Novo Nordisk pokazuje, że współczesne kampanie wymuszeniowe coraz częściej koncentrują się na zasobach o najwyższej wartości strategicznej: repozytoriach kodu, sekretach dostępowych, danych badań klinicznych i własności intelektualnej. Nawet jeśli część twierdzeń sprawców nadal wymaga weryfikacji, sam scenariusz dobrze ilustruje skalę ryzyka związanego z kompromitacją tożsamości deweloperskich i niewłaściwie chronionych tokenów.

Dla firm działających w sektorach regulowanych to kolejny sygnał, że bezpieczeństwo łańcucha wytwarzania oprogramowania oraz ochrona środowisk R&D powinny być traktowane jako element krytyczny, a nie jedynie funkcja wspierająca działalność biznesową.

Źródła

SecurityWeek – Cybercrime Group Claims Novo Nordisk Hack
https://www.securityweek.com/cybercrime-group-claims-novo-nordisk-hack/

Phantom Stealer: bezplikowy infostealer kradnący dane z przeglądarek

Wprowadzenie do problemu / definicja

Phantom Stealer to złośliwe oprogramowanie typu infostealer, którego głównym celem jest wykradanie poświadczeń, cookies sesyjnych oraz innych wrażliwych danych przechowywanych w przeglądarkach internetowych. Zagrożenie zwraca uwagę przede wszystkim ze względu na bezplikowy charakter działania, który ogranicza liczbę śladów pozostawianych na dysku i utrudnia wykrycie przez tradycyjne rozwiązania bezpieczeństwa oparte na sygnaturach.

W praktyce oznacza to, że atakujący koncentrują się na przejęciu tego, co dziś ma największą wartość operacyjną: tożsamości użytkownika, aktywnych sesji oraz dostępu do usług biznesowych obsługiwanych z poziomu przeglądarki.

W skrócie

Phantom Stealer jest rozprzestrzeniany głównie w kampaniach phishingowych, w których wykorzystywane są spreparowane załączniki podszywające się pod dokumenty biznesowe. Po uruchomieniu łańcucha infekcji malware działa przede wszystkim w pamięci operacyjnej, a następnie przechwytuje dane zapisane w przeglądarkach oraz informacje mogące ułatwić dalszą kompromitację środowiska.

kradnie zapisane hasła i dane autouzupełniania,
przechwytuje cookies sesyjne,
zbiera informacje finansowe i dane z narzędzi SaaS,
może odczytywać schowek, wykonywać zrzuty ekranu i rejestrować naciśnięcia klawiszy,
wykorzystuje model malware-as-a-service, który ułatwia szeroką dystrybucję.

Kontekst / historia

Infostealery od lat należą do najaktywniejszych narzędzi używanych przez cyberprzestępców. Wraz z rosnącym znaczeniem aplikacji chmurowych, bankowości internetowej i platform SaaS, przeglądarka stała się jednym z najważniejszych punktów dostępu do danych i procesów biznesowych. To właśnie w niej przechowywane są hasła, tokeny, dane formularzy oraz sesje pozwalające na szybki dostęp do krytycznych systemów.

Phantom Stealer wpisuje się w ten trend, ale wyróżnia się wieloetapowym łańcuchem infekcji oraz zastosowaniem technik utrudniających analizę. Istotne znaczenie ma również komercjalizacja tego typu narzędzi. Model MaaS sprawia, że z jednego rozwiązania może korzystać wielu operatorów, a rozwój funkcji i mechanizmów omijania detekcji przebiega szybciej niż w klasycznych, jednorazowych kampaniach.

Analiza techniczna

Atak zwykle rozpoczyna się od wiadomości phishingowej zawierającej załącznik udający legalny dokument, na przykład zapytanie ofertowe lub korespondencję handlową. Po otwarciu pliku uruchamiany jest zaciemniony skrypt wsadowy, który inicjuje kolejne etapy infekcji i przygotowuje środowisko do uruchomienia ładunku w pamięci.

W analizowanych kampaniach operatorzy wykorzystują kilka warstw ukrywania logiki działania. Celem jest zarówno utrudnienie analizy statycznej, jak i ograniczenie skuteczności podstawowych mechanizmów ochronnych. Szczególnie istotne jest to, że duża część złośliwej aktywności skupia się wokół droppera, a nie wyłącznie samego końcowego malware.

silnie zaciemnione polecenia PowerShell,
ukryte znaki Unicode,
ciągi zakodowane w Base64,
maskowanie wywołań API,
wielowarstwowe dekodowanie i uruchamianie kodu bez zapisu na dysku.

Po skutecznym uruchomieniu Phantom Stealer może zostać wstrzyknięty do legalnego procesu systemowego, co dodatkowo utrudnia detekcję. Tego typu działanie pozwala złośliwemu kodowi ukrywać się w kontekście zaufanych procesów i zmniejsza szansę na szybkie wykrycie incydentu przez użytkownika lub podstawowe systemy ochronne.

Po infekcji malware uzyskuje dostęp do szerokiego zestawu danych przechowywanych lokalnie lub używanych przez użytkownika w codziennej pracy.

zapisane poświadczenia w popularnych przeglądarkach,
cookies sesyjne,
dane autouzupełniania,
informacje z menedżerów haseł,
dane związane z bankowością online i aplikacjami SaaS,
zawartość schowka,
obraz pulpitu użytkownika.

Ważnym elementem kampanii jest także redundancja w eksfiltracji danych. Zamiast jednego kanału komunikacyjnego operatorzy mogą używać kilku równoległych metod przesyłania skradzionych informacji. Taki model zwiększa odporność operacji na blokowanie infrastruktury oraz utrudnia pełne odtworzenie przebiegu incydentu.

Konsekwencje / ryzyko

Skutki działania Phantom Stealer nie ograniczają się do pojedynczej kradzieży hasła. W środowisku firmowym przejęcie przeglądarki może oznaczać dostęp do skrzynek pocztowych, paneli administracyjnych, systemów finansowych, platform CRM, aplikacji chmurowych i narzędzi do zdalnego zarządzania. Szczególnie groźna jest kradzież cookies sesyjnych, ponieważ może umożliwić przejęcie aktywnej sesji bez konieczności ponownego uwierzytelniania.

Dla organizacji o wysokiej wartości biznesowej, zwłaszcza z sektora finansowego, oznacza to ryzyko dalszej eskalacji incydentu i wykorzystania skradzionych danych przez inne grupy przestępcze.

oszustwa finansowe i nieautoryzowane transakcje,
przejęcie kont uprzywilejowanych,
wtórne włamania do środowiska wewnętrznego,
eskalacja incydentu do ransomware lub BEC,
wyciek danych klientów i danych operacyjnych,
naruszenia regulacyjne oraz straty reputacyjne.

Rekomendacje

Organizacje powinny traktować przeglądarkę jako krytyczny punkt końcowy, a nie jedynie narzędzie użytkownika. W przypadku zagrożeń bezplikowych kluczowe znaczenie ma analiza zachowań, monitoring procesów oraz kontrola dostępu do tożsamości i sesji.

wdrożenie EDR lub XDR z analizą behawioralną procesów potomnych, PowerShell i prób iniekcji do legalnych procesów,
ograniczenie uruchamiania skryptów wsadowych, PowerShell i interpreterów poza uzasadnionym kontekstem administracyjnym,
monitorowanie nietypowych linii poleceń, dekodowania Base64 oraz prób uruchamiania kodu bez zapisu na dysku,
wzmocnienie ochrony poczty elektronicznej i sandboxingu załączników,
ograniczenie przechowywania haseł i tokenów w przeglądarkach,
stosowanie odpornych na phishing metod MFA,
regularne unieważnianie sesji po podejrzeniu kompromitacji,
segmentacja dostępu do systemów finansowych i administracyjnych,
szkolenie użytkowników w zakresie rozpoznawania phishingu podszywającego się pod korespondencję handlową,
aktualizowanie reguł detekcji na podstawie wskaźników kompromitacji i telemetryki od dostawców bezpieczeństwa.

W razie wykrycia infekcji nie należy ograniczać reakcji wyłącznie do resetu haseł. Konieczne jest również unieważnienie aktywnych sesji, analiza historii logowań, ocena ryzyka przejęcia tokenów oraz sprawdzenie, czy skradzione dane nie zostały wykorzystane do dalszego ruchu bocznego w środowisku.

Podsumowanie

Phantom Stealer pokazuje, że nowoczesne kampanie infostealerów coraz częściej łączą phishing ukierunkowany, techniki bezplikowe, wielowarstwowe zaciemnianie oraz elastyczną eksfiltrację danych. Atak na przeglądarkę stał się dziś w praktyce atakiem na tożsamość użytkownika i jego dostęp do kluczowych usług biznesowych.

Dla zespołów bezpieczeństwa oznacza to konieczność przesunięcia ciężaru obrony z klasycznego wykrywania plików na ochronę tożsamości, monitoring sesji oraz analizę zachowań procesów i skryptów uruchamianych w systemie.

Źródła

Krytyczna luka w SimpleHelp pozwala tworzyć nieautoryzowane konta techników

Wprowadzenie do problemu / definicja

W oprogramowaniu SimpleHelp wykryto krytyczną podatność oznaczoną jako CVE-2026-48558, która dotyczy mechanizmu uwierzytelniania opartego na OpenID Connect. Błąd może umożliwić nieautoryzowanemu atakującemu utworzenie uprzywilejowanego konta technika bez przechodzenia standardowego procesu logowania i bez skutecznego wymuszenia uwierzytelniania wieloskładnikowego.

To szczególnie istotny problem dla organizacji korzystających z narzędzi zdalnego wsparcia, ponieważ tego typu platformy mają zwykle szeroki dostęp do zarządzanych stacji roboczych, serwerów i sesji administracyjnych. W praktyce luka może stać się punktem wejścia do dalszej kompromitacji środowiska.

W skrócie

Podatność dotyczy wersji SimpleHelp 5.5.15 i starszych oraz wydań pre-release z linii 6.0.
Warunkiem wykorzystania luki jest aktywne uwierzytelnianie OIDC oraz odpowiednie mapowanie grup techników do dostawcy tożsamości.
Atakujący może utworzyć nowe konto technika bez posiadania legalnych poświadczeń.
Skutkiem może być dostęp do konsoli administracyjnej i możliwość wykonywania działań na zarządzanych endpointach.
Producent udostępnił poprawki w wersjach 5.5.16 oraz 6.0RC2.

Kontekst / historia

SimpleHelp to platforma wykorzystywana do zdalnego wsparcia technicznego, zdalnego dostępu oraz administracji urządzeniami końcowymi. Narzędzia tego typu od lat pozostają atrakcyjnym celem dla cyberprzestępców, ponieważ zapewniają rozległy wgląd w infrastrukturę organizacji i często działają z wysokimi uprawnieniami.

Znaczenie podatności rośnie dodatkowo w środowiskach, gdzie serwer jest wystawiony do internetu i zintegrowany z zewnętrznym dostawcą tożsamości. W takim modelu nawet ograniczony błąd w logice federacyjnego logowania może prowadzić do pełnego obejścia zabezpieczeń i uzyskania dostępu do funkcji zarezerwowanych dla personelu technicznego.

Problem został nagłośniony po analizie badaczy bezpieczeństwa, którzy wskazali, że luka nie dotyczy wszystkich instalacji, lecz tylko tych spełniających określone warunki konfiguracyjne. Mimo to potencjalna skala ryzyka pozostaje wysoka, ponieważ publicznie dostępne instancje zdalnego wsparcia są często intensywnie skanowane przez atakujących.

Analiza techniczna

Źródłem podatności jest nieprawidłowa walidacja danych tożsamości otrzymywanych od dostawcy OIDC. W określonym scenariuszu serwer może zaakceptować nieuprawnione informacje uwierzytelniające i dopuścić do utworzenia nowego użytkownika typu Technician.

Skuteczne wykorzystanie luki wymaga spełnienia kilku warunków konfiguracyjnych:

uwierzytelnianie OIDC jest włączone,
co najmniej jedna grupa techników została powiązana z dostawcą OIDC,
dla tej grupy aktywowano możliwość logowania użytkowników uwierzytelnianych grupowo.

Jeżeli te warunki są spełnione, napastnik nie musi posiadać aktywnego konta w organizacji. Może samodzielnie doprowadzić do utworzenia nowego konta technicznego, a następnie zalogować się do konsoli i korzystać z przypisanych uprawnień. W praktyce może to oznaczać możliwość uruchamiania zdalnych sesji, wykonywania skryptów, podejmowania działań administracyjnych oraz przygotowania dalszych etapów ataku.

Z perspektywy detekcji incydentu kluczowe znaczenie mają logi aplikacyjne. Szczególną uwagę warto zwrócić na nowe konta techników, nietypowe adresy e-mail, nagłe zmiany konfiguracji oraz aktywność administracyjną wykonywaną krótko po utworzeniu konta. Podejrzane powinny być również działania pochodzące z nieznanych lokalizacji sieciowych lub realizowane poza standardowymi godzinami pracy zespołu wsparcia.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-48558 należy ocenić jako wysokie, a w niektórych środowiskach nawet krytyczne. Luka dotyczy warstwy uwierzytelniania i może prowadzić bezpośrednio do uzyskania uprzywilejowanego dostępu do systemu zdalnego wsparcia.

Możliwe skutki obejmują:

przejęcie zdalnego dostępu do stacji roboczych i serwerów,
wykonywanie poleceń oraz skryptów w zarządzanym środowisku,
obejście MFA dla nowo utworzonego konta technika,
ruch boczny w sieci organizacji,
przygotowanie ataków ransomware, kradzieży danych lub sabotażu operacyjnego.

Szczególnie niebezpieczny jest fakt, że wykorzystanie luki nie wymaga wcześniejszego przejęcia legalnych poświadczeń. Oznacza to, że organizacje mogą zostać zaatakowane jeszcze przed wykryciem jakichkolwiek prób klasycznego logowania lub phishingu ukierunkowanego na personel IT.

Rekomendacje

Najważniejszym działaniem naprawczym jest niezwłoczna aktualizacja SimpleHelp do wersji zawierającej poprawkę, czyli co najmniej 5.5.16 albo 6.0RC2, w zależności od wykorzystywanej gałęzi produktu. Odkładanie wdrożenia poprawek zwiększa ryzyko wykorzystania luki w aktywnych kampaniach.

Dodatkowo organizacje powinny rozważyć następujące kroki:

zweryfikować, czy integracja OIDC jest rzeczywiście niezbędna,
przeanalizować mapowanie grup techników do dostawcy tożsamości,
wyłączyć logowanie grupowe tam, gdzie nie jest wymagane operacyjnie,
ograniczyć dostęp administracyjny za pomocą list dozwolonych adresów IP,
przejrzeć logi pod kątem nieznanych kont techników i podejrzanych zmian konfiguracji,
skontrolować historię zdalnych sesji, wykonywanych skryptów i działań administracyjnych,
wzmocnić monitoring i alertowanie dla serwera SimpleHelp,
ograniczyć bezpośrednią ekspozycję usługi do internetu, jeśli model działania na to pozwala.

W środowiskach o podwyższonym profilu ryzyka uzasadnione może być także przeprowadzenie pełnego przeglądu uprawnień kont techników, rotacja poświadczeń administracyjnych oraz dodatkowa analiza śladów potencjalnej wcześniejszej kompromitacji.

Podsumowanie

CVE-2026-48558 pokazuje, jak groźne mogą być błędy w integracji federacyjnego uwierzytelniania z narzędziami o wysokim poziomie uprzywilejowania. W tym przypadku pojedyncza wada w obsłudze OIDC może doprowadzić do utworzenia nieautoryzowanego konta technika, a następnie do realnego przejęcia kontroli nad zarządzanymi endpointami.

Dla organizacji korzystających z SimpleHelp priorytetem powinno być szybkie ustalenie, czy podatne warunki konfiguracyjne występują w ich środowisku, oraz natychmiastowe wdrożenie poprawek. Im większa ekspozycja systemu na internet i im szersze uprawnienia techników, tym większe znaczenie ma pilna reakcja.

Źródła

https://www.bleepingcomputer.com/news/security/simplehelp-bug-lets-hackers-create-rogue-remote-support-accounts/
https://nvd.nist.gov/vuln/detail/CVE-2026-48558
https://simple-help.com/release-notes#v5.5.16
https://horizon3.ai/attack-research/disclosures/cve-2026-48558-simplehelp-unauthenticated-account-creation/

Steam Workshop i Wallpaper Engine wykorzystane do dystrybucji malware

Wprowadzenie do problemu / definicja

W skrócie

Wykryto backdoory i stealery informacji.
Atakujący kradli dane dostępowe do kont Steam.
W części przypadków instalowano koparki kryptowalut, loadery botnetów oraz ransomware.
Choć część złośliwych pozycji usunięto, sam model ataku pozostaje aktualny.

Kontekst / historia

Analiza techniczna

Konsekwencje / ryzyko

Rekomendacje

Instalować wyłącznie treści pochodzące od znanych i wiarygodnych autorów.
Unikać pakietów typu aplikacyjnego, jeśli ich działanie nie jest w pełni zrozumiałe.
Skanować pobierane elementy narzędziami antymalware z aktualnymi sygnaturami.
Włączyć ochronę konta Steam, w tym uwierzytelnianie wieloskładnikowe.
Monitorować nietypowe biblioteki DLL, wpisy autostartu i procesy potomne.
Nie używać tego samego hosta do celów prywatnych i służbowych, jeśli nie jest to konieczne.

Podsumowanie

Źródła

https://www.bleepingcomputer.com/news/security/steam-workshop-abused-to-spread-malware-via-wallpaper-engine-app/
https://securelist.com/
https://partner.steamgames.com/doc/features/workshop
https://help.wallpaperengine.io/