Archiwa: Ransomware - Strona 42 z 121

Prawie 2,9 mld skompromitowanych poświadczeń w 2025 roku. Kradzież tożsamości cyfrowej staje się głównym wektorem ataku

Wprowadzenie do problemu / definicja

Skala kradzieży poświadczeń rośnie do poziomu, który zmienia sposób prowadzenia ataków na organizacje. Zamiast klasycznego włamywania się przez exploity lub ręczne obchodzenie zabezpieczeń, cyberprzestępcy coraz częściej uzyskują dostęp poprzez gotowe dane logowania, tokeny sesyjne i artefakty uwierzytelniające pozyskane z malware typu infostealer, wycieków oraz rynków przestępczych. Najnowsze dane wskazują, że w 2025 roku zidentyfikowano niemal 2,9 miliarda skompromitowanych poświadczeń, co potwierdza przesunięcie ciężaru ataków z eksploatacji podatności na nadużywanie tożsamości.

W skrócie

W 2025 roku prześledzono około 2,86–2,9 mld skompromitowanych poświadczeń.
Znacząca część incydentów była związana z aktywnością infostealerów wykradających hasła, ciasteczka, tokeny i dane do usług chmurowych.
Trend ten zwiększa skuteczność ransomware, oszustw BEC, przejęć kont oraz naruszeń środowisk SaaS.
Bezpieczeństwo organizacji coraz silniej zależy dziś od ochrony tożsamości, sesji i urządzeń końcowych, a nie wyłącznie od zarządzania podatnościami.

Kontekst / historia

Problem skompromitowanych poświadczeń nie jest nowy, jednak w ostatnich kilkunastu miesiącach jego dynamika wyraźnie przyspieszyła. Wcześniejsze raporty branżowe wskazywały na setki milionów, a następnie miliardy danych logowania pojawiających się w logach malware, combo-listach i pakietach sprzedawanych na forach cyberprzestępczych. Obecnie rynek ten działa jak dojrzały ekosystem: jedni aktorzy infekują urządzenia, inni agregują dane, a kolejni wykorzystują je do uzyskiwania wstępnego dostępu lub ich odsprzedaży.

W tle widoczna jest również zmiana modelu operacyjnego grup przestępczych. Poświadczenia przestały być jedynie skutkiem ubocznym infekcji, a stały się samodzielnym towarem i kluczowym zasobem umożliwiającym dalsze operacje. Dotyczy to zwłaszcza dostępów do usług pocztowych, platform chmurowych, paneli administracyjnych, VPN, narzędzi deweloperskich oraz systemów tożsamości federacyjnej. Im większe uzależnienie firm od SaaS i zdalnego dostępu, tym większa wartość przejętego konta.

Analiza techniczna

Technicznie rzecz biorąc, źródłem dużej części skompromitowanych poświadczeń są kampanie infostealerów. Tego typu malware, po uruchomieniu na urządzeniu ofiary, przeszukuje przeglądarki, menedżery haseł, portfele kryptowalutowe, klienty pocztowe i lokalne magazyny aplikacji. Celem jest pozyskanie nie tylko loginów i haseł, ale też plików cookie, tokenów sesyjnych, zapisanych formularzy, historii przeglądania oraz konfiguracji kont.

To istotne, ponieważ nowoczesny atak nie musi zaczynać się od łamania hasła. Jeżeli napastnik dysponuje aktywnym tokenem sesyjnym albo przejętym ciasteczkiem uwierzytelniającym, może ominąć część klasycznych mechanizmów ochronnych, a w niektórych scenariuszach także osłabić skuteczność MFA. Szczególnie niebezpieczne są przypadki, w których urządzenie użytkownika jest jednocześnie zalogowane do poczty, narzędzi biurowych, repozytoriów kodu i paneli administracyjnych.

Kolejny etap to monetyzacja lub operacjonalizacja dostępu. Dane logowania są porządkowane, tagowane według typu usługi, kraju, domeny lub wartości biznesowej, a następnie sprzedawane albo wykorzystywane bezpośrednio. Atakujący stosują credential stuffing, przejęcia kont, ruch boczny w środowisku chmurowym, eskalację uprawnień oraz kradzież danych. W przypadku ransomware przejęte poświadczenia coraz częściej służą jako pierwszy krok do uzyskania legalnie wyglądającego dostępu do infrastruktury ofiary.

Dodatkowym czynnikiem wzrostu jest automatyzacja. Duże wolumeny skradzionych danych można dziś szybko filtrować, wzbogacać o dane wywiadowcze i łączyć z narzędziami do masowego testowania dostępów. To powoduje, że wartość operacyjna pojedynczego wycieku jest większa niż kilka lat temu. Napastnik nie potrzebuje już skomplikowanego łańcucha exploitów, jeśli może zalogować się zamiast włamywać.

Konsekwencje / ryzyko

Dla organizacji oznacza to istotny wzrost ryzyka w kilku obszarach. Po pierwsze, kompromitacja kont użytkowników biznesowych umożliwia cichy, trudniejszy do wykrycia dostęp do systemów. Po drugie, przejęcie tożsamości w środowisku SaaS może prowadzić do masowej eksfiltracji danych bez uruchamiania klasycznych wskaźników złośliwego oprogramowania. Po trzecie, skradzione poświadczenia zwiększają skuteczność ataków ransomware i oszustw ukierunkowanych.

Ryzyko jest szczególnie wysokie tam, gdzie występuje ponowne używanie haseł, brak phishing-resistant MFA, słaba segmentacja dostępu oraz niedostateczna widoczność aktywności tożsamościowej. Problem dotyczy również urządzeń prywatnych i przeglądarek pracowników, ponieważ to właśnie tam często przechowywane są dane uwierzytelniające do usług korporacyjnych. Granica między bezpieczeństwem endpointu a bezpieczeństwem tożsamości praktycznie zanika.

Z perspektywy operacyjnej najgroźniejsze są trzy scenariusze: przejęcie konta uprzywilejowanego, kompromitacja tożsamości chmurowej oraz wykorzystanie aktywnej sesji do obejścia części kontroli dostępu. W każdym z tych przypadków czas detekcji może być długi, ponieważ aktywność napastnika przypomina legalne logowanie użytkownika.

Rekomendacje

Organizacje powinny traktować poświadczenia jako zasób wysokiego ryzyka i objąć je ochroną porównywalną z ochroną stacji roboczych oraz systemów krytycznych. Podstawą jest wdrożenie phishing-resistant MFA, preferencyjnie w modelu opartym na kluczach sprzętowych lub FIDO2/WebAuthn, zamiast polegania wyłącznie na kodach SMS czy aplikacjach OTP.

Drugim filarem powinno być ograniczenie możliwości kradzieży danych z endpointów. W praktyce oznacza to twarde polityki dla przeglądarek, blokowanie zapisu haseł w niezarządzanych aplikacjach, kontrolę rozszerzeń, EDR/XDR z telemetrią procesu przeglądarki oraz monitoring artefaktów charakterystycznych dla infostealerów. Warto także ograniczyć użycie lokalnie przechowywanych sekretów i wdrażać krótkotrwałe tokeny dostępu.

Konieczne jest również ciągłe monitorowanie wycieków i zasobów tożsamościowych. Obejmuje to nadzór nad ekspozycją poświadczeń w źródłach zewnętrznych, szybki reset haseł po wykryciu incydentu, unieważnianie sesji, rotację tokenów i kluczy API oraz analizę anomalii logowań. Niezbędne staje się także wdrażanie zasad conditional access, segmentacji uprawnień, least privilege i separacji kont administracyjnych od codziennej pracy użytkownika.

Wreszcie, zespoły SOC i IR powinny aktualizować playbooki o scenariusze związane z przejęciem sesji, token theft i malware typu stealer. Klasyczne procedury resetu hasła nie zawsze są wystarczające, jeśli napastnik nadal dysponuje ważnym tokenem lub sesją przeglądarkową.

Podsumowanie

Prawie 2,9 miliarda skompromitowanych poświadczeń w skali jednego roku to sygnał, że tożsamość stała się jednym z głównych pól walki w cyberbezpieczeństwie. Współczesne ataki coraz częściej wykorzystują legalnie wyglądające logowanie zamiast głośnej eksploatacji technicznej. Z punktu widzenia obrony oznacza to konieczność przesunięcia priorytetów: od samego patchowania i ochrony perymetru w stronę bezpieczeństwa tożsamości, urządzeń końcowych, sesji i dostępu do usług chmurowych. Firmy, które nie uwzględnią tego trendu w strategii bezpieczeństwa, będą coraz częściej przegrywać nie dlatego, że ktoś przełamał ich zabezpieczenia, lecz dlatego, że ktoś po prostu zalogował się poprawnymi danymi.

Źródła

Co czwarta organizacja ochrony zdrowia odnotowała cyberatak przez urządzenia medyczne

Wprowadzenie do problemu / definicja

Cyberbezpieczeństwo urządzeń medycznych staje się jednym z najważniejszych wyzwań współczesnej ochrony zdrowia. Szpitale, laboratoria i placówki diagnostyczne korzystają dziś z rozbudowanego środowiska połączonych urządzeń, obejmującego m.in. aparaty obrazowania, pompy infuzyjne, monitory pacjenta oraz rozwiązania klasy IoMT. Każde z tych urządzeń pełni funkcję kliniczną, ale jednocześnie może stanowić potencjalny punkt wejścia do infrastruktury cyfrowej organizacji.

W praktyce oznacza to, że bezpieczeństwo sprzętu medycznego nie jest już wyłącznie zagadnieniem technicznym ani serwisowym. To obszar bezpośrednio powiązany z ciągłością działania placówki, ochroną danych pacjentów oraz bezpieczeństwem procesów diagnostycznych i terapeutycznych.

W skrócie

Najnowsze ustalenia pokazują, że około 25% organizacji ochrony zdrowia zgłosiło cyberataki związane z urządzeniami medycznymi. To wyraźny sygnał, że sprzęt kliniczny stał się aktywnym elementem powierzchni ataku, a nie jedynie zapleczem operacyjnym.

urządzenia medyczne są coraz częściej wykorzystywane jako wektor wejścia do sieci,
problem wynika zarówno z podatności technicznych, jak i ograniczonej widoczności tych aktywów,
rosnąca liczba urządzeń IoMT zwiększa złożoność zarządzania bezpieczeństwem,
atak na sprzęt kliniczny może przełożyć się nie tylko na straty IT, ale również na ryzyko operacyjne i kliniczne.

Kontekst / historia

Sektor ochrony zdrowia od lat pozostaje atrakcyjnym celem dla cyberprzestępców. Wynika to z wysokiej wartości danych medycznych, presji na nieprzerwane świadczenie usług oraz rozbudowanego środowiska technologicznego, w którym współistnieją systemy administracyjne, kliniczne i specjalistyczne urządzenia producentów zewnętrznych.

W ostatnich latach szczególnie nasiliły się incydenty związane z ransomware, przejęciem kont uprzywilejowanych, atakami na łańcuch dostaw i wykorzystaniem podatnych urządzeń brzegowych. Rozwój Internet of Medical Things dodatkowo zwiększył powierzchnię ataku. Wiele urządzeń działa przez lata w środowisku produkcyjnym, często z ograniczoną możliwością aktualizacji, przy ścisłej zależności od dostawcy i procedur walidacyjnych utrudniających szybkie wdrożenie poprawek.

W efekcie organizacje medyczne funkcjonują w rzeczywistości, w której bezpieczeństwo urządzeń jest bezpośrednio związane z bezpieczeństwem pacjentów oraz odpornością operacyjną całej placówki.

Analiza techniczna

Cyberataki wykorzystujące urządzenia medyczne rzadko polegają wyłącznie na przejęciu ich funkcji klinicznej. Znacznie częściej sprzęt staje się punktem pośrednim do uzyskania dostępu do sieci, ruchu bocznego, eskalacji uprawnień lub utrzymania trwałej obecności w środowisku. Jest to szczególnie groźne tam, gdzie urządzenia terapeutyczne i diagnostyczne komunikują się z systemami PACS, EHR, serwerami plików, katalogami tożsamości lub platformami producentów.

Najczęściej spotykane problemy techniczne wynikają z braku pełnej kontroli nad cyklem życia urządzeń oraz ich ograniczonej integracji z procesami bezpieczeństwa. W wielu organizacjach sprzęt medyczny pozostaje poza standardowym monitoringiem, nie jest objęty klasycznym hardeningiem i nie generuje wystarczającej telemetrii dla zespołów SOC.

przestarzałe lub niewspierane systemy operacyjne,
domyślne poświadczenia albo konta trudne do modyfikacji,
brak agentów EDR i ograniczona widoczność zagrożeń,
niepełna inwentaryzacja aktywów oraz zależności sieciowych,
niewystarczająca segmentacja między siecią kliniczną a biurową,
opóźnienia w patch management wynikające z wymagań producenta i walidacji.

Z perspektywy napastnika urządzenia medyczne są atrakcyjne, ponieważ pozostają stale aktywne, cieszą się wysokim poziomem zaufania w sieci i nierzadko są pomijane w klasycznych programach ochrony punktów końcowych. Ich kompromitacja może umożliwić skanowanie infrastruktury, tunelowanie ruchu, zbieranie danych, a także zakłócanie pracy systemów wspierających proces leczenia.

Dodatkowym wyzwaniem jest konwergencja IT, OT i IoMT. Urządzenia medyczne nie mogą być już traktowane wyłącznie jako odrębny sprzęt specjalistyczny zarządzany przez dział biomedyczny. Stały się integralnym elementem architektury cyfrowej, co wymaga ścisłej współpracy zespołów bezpieczeństwa, administratorów infrastruktury, inżynierii klinicznej i dostawców technologii.

Konsekwencje / ryzyko

Ryzyko związane z cyberatakami na urządzenia medyczne wykracza daleko poza klasyczne skutki incydentów IT. W ochronie zdrowia każda przerwa techniczna może przełożyć się na ograniczenie dostępności usług, opóźnienia diagnostyczne oraz wzrost ryzyka klinicznego.

przerwy w świadczeniu usług medycznych,
ograniczenie dostępności badań i zabiegów,
wzrost ryzyka dla pacjentów,
wyciek danych medycznych i operacyjnych,
wysokie koszty odtworzenia środowiska i audytów zgodności,
straty reputacyjne dla placówki i jej partnerów.

W praktyce nawet częściowa niedostępność jednego segmentu infrastruktury może wywołać efekt domina. Zakłócenie pracy urządzeń obrazowania, systemów monitorowania czy platform wymiany danych może skutkować przekierowaniem pacjentów, wstrzymaniem procedur, przejściem na tryby awaryjne i wzrostem presji na personel. W przypadku ransomware skala zagrożenia rośnie dodatkowo z powodu ograniczeń czasowych i krytycznego charakteru usług.

Rekomendacje

Organizacje ochrony zdrowia powinny traktować bezpieczeństwo urządzeń medycznych jako integralny element cyberodporności. Kluczowe znaczenie ma odejście od myślenia o sprzęcie klinicznym jako wyjątku od standardów bezpieczeństwa i objęcie go spójnym modelem zarządzania ryzykiem.

prowadzenie pełnej inwentaryzacji urządzeń, wersji systemów i interfejsów komunikacyjnych,
wdrożenie segmentacji sieci opartej na rzeczywistych przepływach i poziomie ryzyka,
monitoring ruchu sieciowego urządzeń IoMT oraz wykrywanie anomalii,
ocena ryzyka dla urządzeń niewspieranych i stosowanie kontroli kompensujących,
zarządzanie podatnościami we współpracy z producentami i inżynierią kliniczną,
eliminacja domyślnych kont, rotacja poświadczeń i kontrola dostępu uprzywilejowanego,
włączenie urządzeń medycznych do planów reagowania na incydenty,
uwzględnianie wymagań cyberbezpieczeństwa już na etapie zakupów i przetargów.

W wielu przypadkach najskuteczniejszym podejściem nie będzie instalacja dodatkowego oprogramowania ochronnego na samym urządzeniu, lecz zastosowanie modelu zero trust, ograniczenie komunikacji, izolacja segmentów, ciągła obserwowalność i szybkie wykrywanie nieautoryzowanych zmian.

Podsumowanie

Informacja, że już co czwarta organizacja ochrony zdrowia odnotowała cyberatak związany z urządzeniami medycznymi, potwierdza skalę i dojrzałość tego zagrożenia. Infrastruktura kliniczna stała się pełnoprawnym obszarem walki o bezpieczeństwo cyfrowe, a jej kompromitacja może prowadzić do skutków wykraczających poza tradycyjnie rozumiane incydenty IT.

Dla sektora medycznego oznacza to konieczność trwałej zmiany podejścia. Urządzenia medyczne muszą być traktowane jako krytyczne aktywa wymagające ciągłej widoczności, segmentacji, kontroli dostępu, monitoringu oraz ścisłej współpracy między zespołami technicznymi i operacyjnymi.

Źródła

Infosecurity Magazine – A Quarter of Healthcare Organizations Report Medical Device Cyber-Attacks — https://www.infosecurity-magazine.com/news/quarter-healthcare-medical-device/
Infosecurity Magazine – 89% of Healthcare Organizations Use the Most Vulnerable IoT Devices — https://www.infosecurity-magazine.com/news/healthcare-vulnerable-iot-devices/
TechTarget – Weak Connected Medical Device Security Increases Cyberattack Threats — https://www.techtarget.com/healthtechsecurity/news/366594538/Weak-Connected-Medical-Device-Security-Increases-Cyberattack-Threats
PMC – Security vulnerabilities in healthcare: an analysis of medical devices and software — https://pmc.ncbi.nlm.nih.gov/articles/PMC10758361/
Help Net Security – Connected medical devices are the Achilles’ heel of healthcare orgs — https://www.helpnetsecurity.com/2022/12/05/connected-medical-devices-cyberattacks/

Krytyczne luki w OpenKM 6.3.12 i starszych wersjach mogą prowadzić do pełnego przejęcia systemu

Wprowadzenie do problemu / definicja

OpenKM to platforma klasy DMS wykorzystywana do zarządzania dokumentami, obiegiem pracy i przechowywania danych biznesowych. Publicznie opisany zestaw podatności wskazuje, że OpenKM Community Edition 6.3.12 oraz OpenKM Pro Edition 7.1.47 i starsze wersje mogą być narażone na wieloetapowe ataki prowadzące do odczytu plików lokalnych, wykonywania poleceń systemowych oraz pozyskania danych uwierzytelniających z bazy danych.

Z perspektywy bezpieczeństwa jest to scenariusz o najwyższym poziomie ryzyka, ponieważ łączy ekspozycję panelu administracyjnego z możliwością nadużycia funkcji o bardzo szerokich uprawnieniach. W praktyce skutkiem może być nie tylko kompromitacja samej aplikacji, ale również naruszenie poufności dokumentów i wykorzystanie serwera jako punktu wyjścia do dalszych działań w infrastrukturze organizacji.

W skrócie

Opisany publicznie exploit dotyczy OpenKM Community Edition 6.3.12 oraz OpenKM Pro Edition 7.1.47 i wcześniejszych wydań.
Wskazane problemy obejmują odczyt plików lokalnych, zdalne wykonywanie poleceń oraz dostęp do danych użytkowników w bazie.
Łańcuch ataku wykorzystuje funkcje administracyjne dostępne z poziomu interfejsu webowego.
Efektem może być przejęcie kont uprzywilejowanych, ujawnienie hashy haseł i pełna kompromitacja środowiska OpenKM.
Organizacje powinny pilnie ograniczyć dostęp do paneli administracyjnych i zweryfikować dostępność poprawek lub obejść producenta.

Kontekst / historia

Systemy DMS, takie jak OpenKM, często pełnią rolę centralnego repozytorium dokumentów w organizacjach. Przechowują umowy, dokumentację operacyjną, dane kadrowe, materiały finansowe i inne informacje o wysokiej wartości, dlatego są szczególnie atrakcyjnym celem dla cyberprzestępców, operatorów ransomware oraz grup nastawionych na kradzież danych.

Opublikowany materiał w bazie exploitów został oznaczony jako zweryfikowany i opisuje zestaw luk określanych jako zero-day. Istotnym elementem sprawy jest brak przypisanego identyfikatora CVE, co może utrudnić wykrycie zagrożenia w organizacjach opierających proces zarządzania podatnościami wyłącznie na standardowych wpisach CVE i komunikatach agregowanych przez zewnętrzne narzędzia.

Zakres opisu obejmuje zarówno edycję Community, jak i Pro, co sugeruje, że problem może dotyczyć różnych wdrożeń opartych na zbliżonych mechanizmach administracyjnych. To zwiększa znaczenie sprawy dla firm korzystających z OpenKM jako kluczowego komponentu obsługi dokumentów i procesów biznesowych.

Analiza techniczna

Z opisu exploita wynika, że atak obejmuje kilka ścieżek aplikacji związanych z uwierzytelnianiem, panelem administracyjnym i modułami GWT. Jednym z pierwszych etapów jest użycie standardowego mechanizmu logowania, po którym następuje przejście do funkcji administracyjnych dostępnych przez interfejs webowy.

Kluczowym elementem łańcucha ataku ma być panel admin/Scripting. Według opisu exploit wykorzystuje parametr fsPath w akcji typu Load do odczytu plików lokalnych z serwera. Taki mechanizm przypomina niekontrolowany dostęp do systemu plików i może umożliwić pozyskanie konfiguracji, danych aplikacyjnych lub innych informacji pomocnych w dalszej eskalacji.

Ta sama funkcjonalność ma być również wykorzystywana do uruchamiania kodu przy użyciu akcji Evaluate. W przedstawionym scenariuszu wstrzyknięty skrypt wywołuje mechanizm wykonywania poleceń systemowych, co odpowiada klasycznemu zdalnemu wykonywaniu kodu po stronie serwera aplikacyjnego. W praktyce oznacza to możliwość uruchamiania poleceń w kontekście procesu OpenKM i przejęcia kontroli nad hostem.

Drugi istotny obszar to endpoint admin/DatabaseQuery, który według opisu pozwala na wykonywanie arbitralnych zapytań SQL z poziomu panelu administracyjnego. Opublikowany kod odwołuje się do tabeli użytkowników i zapisuje identyfikatory wraz z wartościami haseł do pliku. Nie jest to klasyczna SQL injection, lecz nadużycie zbyt szerokich możliwości funkcji administracyjnej. Skutek pozostaje jednak bardzo poważny, ponieważ napastnik może uzyskać dostęp do danych uwierzytelniających i wykorzystać je do dalszych działań.

Eksploit przewiduje także etap łamania pozyskanych hashy offline z użyciem słownika. Oznacza to, że słaba polityka haseł może bardzo szybko przełożyć się na przejęcie kont użytkowników. Ryzyko rośnie dodatkowo, jeśli poświadczenia są współdzielone z innymi systemami, takimi jak LDAP, Active Directory lub usługi firm trzecich.

Warto podkreślić, że opis obejmuje pobieranie tokenu CSRF i wykonywanie żądań w pozornie prawidłowy sposób. Sugeruje to, że źródłem problemu nie jest wyłącznie ochrona przed CSRF, ale przede wszystkim nadmiernie uprzywilejowane funkcje administracyjne oraz niewystarczające ograniczenia autoryzacyjne dla operacji wysokiego ryzyka.

Konsekwencje / ryzyko

Najgroźniejszym skutkiem opisanych podatności jest możliwość pełnego przejęcia środowiska OpenKM. Jeśli atakujący uzyska dostęp do konta administracyjnego lub wykorzysta słabo zabezpieczony interfejs o szerokich uprawnieniach, może przejść od rozpoznania do aktywnej kompromitacji systemu w bardzo krótkim czasie.

odczyt poufnych plików z serwera i konfiguracji aplikacji,
pozyskanie danych użytkowników oraz hashy haseł z bazy danych,
uruchamianie poleceń systemowych na serwerze aplikacyjnym,
dostęp do dokumentów, metadanych i workflow przechowywanych w systemie,
wykorzystanie przejętego hosta do ruchu bocznego w sieci wewnętrznej.

Ryzyko należy uznać za krytyczne zwłaszcza tam, gdzie OpenKM jest dostępny z Internetu, zintegrowany z centralnym systemem tożsamości lub działa na współdzielonej infrastrukturze. Dodatkowym czynnikiem podnoszącym poziom zagrożenia jest publiczna dostępność kodu PoC, co obniża próg wejścia dla mniej zaawansowanych napastników.

Rekomendacje

Organizacje korzystające z OpenKM powinny potraktować sprawę priorytetowo i wdrożyć działania ograniczające ekspozycję bez oczekiwania na pełne potwierdzenie wszystkich scenariuszy w środowisku produkcyjnym.

Natychmiast ograniczyć dostęp sieciowy do interfejsów administracyjnych, szczególnie ścieżek związanych z modułami skryptowymi i zapytaniami do bazy.
Udostępniać panele administracyjne wyłącznie z wydzielonej sieci zarządzającej, przez VPN lub kontrolowany bastion.
Przeprowadzić przegląd kont uprzywilejowanych i wymusić zmianę haseł administratorów oraz użytkowników o podwyższonych uprawnieniach.
Zweryfikować, czy w środowisku nie są używane domyślne lub słabe dane logowania oraz czy poświadczenia nie są współdzielone z innymi systemami.
Przeanalizować logi aplikacyjne, systemowe, reverse proxy i serwera WWW pod kątem żądań do wrażliwych endpointów administracyjnych.
Wdrożyć kontrole kompensacyjne, takie jak reguły WAF, monitoring EDR, segmentacja sieci i minimalizacja uprawnień procesu aplikacyjnego.
Sprawdzić dostępność oficjalnych poprawek, zaleceń producenta oraz nowszych wydań usuwających lub ograniczających ryzykowne funkcje.

Jeżeli architektura rozwiązania na to pozwala, warto rozważyć czasowe wyłączenie najbardziej ryzykownych modułów administracyjnych do momentu pełnej remediacji. Równolegle należy przeprowadzić analizę śladów potencjalnej kompromitacji, szczególnie jeśli system był dostępny publicznie.

Podsumowanie

Opisany publicznie zestaw luk pokazuje, jak niebezpieczne mogą być funkcje administracyjne umożliwiające szeroki dostęp do plików, skryptów i bazy danych. W przypadku OpenKM taki model może prowadzić od ujawnienia danych użytkowników do zdalnego wykonywania poleceń i pełnego przejęcia serwera.

Dla administratorów i zespołów bezpieczeństwa oznacza to konieczność pilnego przeglądu ekspozycji systemu, ograniczenia dostępu do paneli administracyjnych oraz sprawdzenia, czy środowisko nie nosi już oznak naruszenia. W systemach przechowujących dokumenty biznesowe i dane wrażliwe opóźnienie reakcji może znacząco zwiększyć skalę skutków incydentu.

Źródła

Exploit Database – OpenKM 6.3.12 – Multiple – Multiple webapps Exploit
https://www.exploit-db.com/exploits/52520
OpenKM – Official Website
https://www.openkm.com/
OpenKM Community Edition Docker Image
https://hub.docker.com/r/openkm/openkm-ce

Vidar umacnia pozycję na rynku infostealerów po uderzeniach w konkurencyjne kampanie

Wprowadzenie do problemu / definicja

Vidar to złośliwe oprogramowanie z kategorii infostealerów, zaprojektowane do kradzieży danych uwierzytelniających, plików cookies, tokenów sesyjnych, informacji zapisanych w przeglądarkach oraz danych z wybranych aplikacji i portfeli kryptowalutowych. W praktyce jego rola wykracza poza samą eksfiltrację danych, ponieważ skradzione informacje mogą później posłużyć do przejęć kont, nadużyć tożsamości, ruchu lateralnego lub jako punkt wejścia do kolejnych etapów ataku.

W skrócie

Vidar należy obecnie do najważniejszych narzędzi w ekosystemie infostealerów, a jego znaczenie wzrosło po działaniach wymierzonych w konkurencyjne kampanie, takie jak Lumma czy Rhadamanthys. Operatorzy zagrożenia wykorzystali destabilizację rynku, rozwijając infrastrukturę, rozszerzając kanały dystrybucji i umacniając swoją pozycję w obiegu skradzionych logów.

kradnie hasła, cookies, tokeny i dane autofill z przeglądarek,
może wyciągać dane z portfeli kryptowalutowych i lokalnych plików,
wykorzystuje techniki utrudniające analizę i blokowanie infrastruktury C2,
zwiększa ryzyko przejęcia sesji i wtórnych incydentów w środowiskach firmowych.

Kontekst / historia

Vidar funkcjonuje w cyberprzestępczym obiegu od kilku lat jako malware nastawione na masową kradzież danych z systemów Windows. Jego popularność wynika z relatywnie szerokiego zakresu funkcji, prostoty użycia przez operatorów kampanii oraz łatwej monetyzacji skradzionych informacji na podziemnych forach i rynkach handlu logami.

W ostatnim okresie znaczenie Vidara wzrosło w związku z zakłóceniem działania konkurencyjnych rodzin malware. Gdy część dużych kampanii została osłabiona przez działania organów ścigania i presję operacyjną, popyt na narzędzia do kradzieży danych nie zniknął. Został jedynie przesunięty do tych operatorów, którzy byli w stanie szybko przejąć udział w rynku. Vidar wykorzystał tę lukę, korzystając z rozpoznawalności oraz aktywnych kanałów dystrybucji.

Istotne znaczenie ma także szerszy model cyberprzestępczy oparty na handlu logami. W takim układzie sam infostealer nie musi być celem końcowym kampanii. Dane przejęte przez malware mogą zostać sprzedane kolejnym grupom, które użyją ich do oszustw, przejęć kont uprzywilejowanych, nadużyć finansowych lub wdrożenia ransomware.

Analiza techniczna

Vidar koncentruje się na pozyskiwaniu danych z popularnych przeglądarek internetowych. Obejmuje to zapisane hasła, pliki cookies, dane formularzy, historię przeglądania oraz artefakty sesyjne. Z perspektywy bezpieczeństwa przedsiębiorstw szczególnie groźna jest kradzież aktywnych sesji, ponieważ może umożliwić obejście zabezpieczeń opartych wyłącznie na haśle.

Malware interesuje się również rozszerzeniami oraz aplikacjami powiązanymi z kryptowalutami. Dzięki temu operatorzy mogą szybko monetyzować część infekcji, ale nie ograniczają się wyłącznie do kradzieży środków cyfrowych. W zależności od wariantu i kampanii Vidar może także zbierać zrzuty ekranu, informacje z klientów pocztowych oraz wybrane pliki lokalne, dostarczając napastnikowi szerszy obraz środowiska ofiary.

Wektor wejścia pozostaje elastyczny. Zagrożenie bywa rozprzestrzeniane przez phishing, fałszywe instalatory, trojanizowane pakiety programistyczne, instrukcje pobrania publikowane w mediach społecznościowych oraz pliki podszywające się pod narzędzia dla graczy i użytkowników domowych. Taka różnorodność pokazuje, że Vidar skutecznie dostosowuje się do aktualnych trendów socjotechnicznych.

Ważnym elementem technicznym jest ukrywanie infrastruktury dowodzenia i kontroli. Operatorzy mogą stosować mechanizmy dead drop resolver, w których właściwy adres serwera C2 nie jest zapisany bezpośrednio w próbce malware. Zamiast tego złośliwy kod pobiera informacje pośrednio z legalnych serwisów internetowych, co utrudnia analizę statyczną, opóźnia reakcję obrońców i ułatwia szybką zmianę infrastruktury po wykryciu.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem infekcji Vidar nie jest sama utrata hasła, lecz długotrwała kompromitacja tożsamości cyfrowej użytkownika lub organizacji. Przejęte dane mogą zostać wykorzystane do logowania do poczty, usług SaaS, repozytoriów kodu, paneli administracyjnych, VPN i systemów zdalnego dostępu. Jeśli ofiara posiada aktywne sesje w usługach firmowych, napastnik może uzyskać dostęp bez potrzeby łamania hasła.

Ryzyko rośnie tam, gdzie użytkownicy zapisują sekrety w przeglądarkach lub korzystają z jednego urządzenia zarówno do zwykłej pracy, jak i działań administracyjnych. Skradzione cookies, tokeny i pliki konfiguracyjne mogą stać się podstawą do dalszego rozpoznania środowiska, eskalacji dostępu oraz przygotowania wtórnych ataków, w tym ransomware.

Dodatkowym zagrożeniem jest szybka sprzedaż danych na podziemnych rynkach. Oznacza to, że nawet jeśli pierwotny operator nie rozwija ataku samodzielnie, dostęp do środowiska może zostać przekazany innemu podmiotowi. W efekcie pojedyncza infekcja endpointu może zapoczątkować wieloetapowy incydent obejmujący wyciek danych, przejęcie kont i zakłócenie ciągłości działania.

Rekomendacje

Organizacje powinny traktować ochronę przed infostealerami jako osobny obszar obrony, a nie jedynie rozszerzenie ochrony antyphishingowej. Kluczowe jest ograniczenie przechowywania haseł i wrażliwych danych w przeglądarkach, szczególnie na urządzeniach użytkowników uprzywilejowanych. Równolegle należy stosować wieloskładnikowe uwierzytelnianie dla poczty, usług chmurowych, dostępu zdalnego i paneli administracyjnych.

wdrożyć filtrowanie DNS i bezpieczne bramy webowe,
stosować sandboxing załączników i adresów URL,
monitorować ruch wychodzący z endpointów,
wykrywać anomalie logowań i użycia skradzionych sesji,
rozwijać reguły detekcji dla zachowań typowych dla stealerów,
prowadzić threat hunting pod kątem przejętych cookies i tokenów.

W przypadku podejrzenia infekcji nie wystarczy samo usunięcie próbki malware. Należy przeprowadzić pełną procedurę reagowania na incydent, obejmującą izolację hosta, reset haseł, unieważnienie sesji, rotację tokenów i kluczy oraz analizę logowań do usług firmowych. Szczególną uwagę trzeba zwrócić na to, czy zainfekowane urządzenie nie było wykorzystywane do działań administracyjnych.

Podsumowanie

Rosnąca aktywność Vidar pokazuje, że rynek infostealerów szybko dostosowuje się do działań organów ścigania i zakłóceń infrastruktury konkurencyjnych grup. Gdy jedna rodzina malware traci zdolność operacyjną, inna przejmuje klientów, kanały dystrybucji i wolumen infekcji. Z punktu widzenia organizacji oznacza to konieczność traktowania infostealerów jako realnego wektora początkowego dostępu do środowisk firmowych.

Vidar pozostaje groźny nie tylko ze względu na zakres kradzionych danych, ale także przez elastyczne metody dystrybucji i techniki utrudniające blokowanie infrastruktury. Skuteczna obrona wymaga połączenia kontroli technicznych, higieny tożsamości, monitoringu sesji oraz szybkiego reagowania na symptomy kompromitacji danych uwierzytelniających.

Źródła

Dark Reading — Vidar Rises to Top of Chaotic Infostealer Market — https://www.darkreading.com/vulnerabilities-threats/vidar-top-chaotic-infostealer-market
Datadog Security Labs — MUT-4831: Trojanized npm packages deliver Vidar infostealer malware — https://securitylabs.datadoghq.com/articles/mut-4831-trojanized-npm-packages-vidar/
ITPro — Europol hails triple takedown with Rhadamanthys, VenomRAT, and Elysium sting operations — https://www.itpro.com/security/europol-hails-triple-takedown-with-rhadamanthys-venomrat-and-elysium-sting-operations
Delta ThreatLabs — Dead Drop Resolvers: A Taxonomy of C2 Obfuscation via Legitimate Web Services — https://deltathreatlabs.com/research/dead-drop-resolvers-c2-obfuscation/
Aryaka — Vidar Infostealer in Action: From API Hooking to Covert Data Exfiltration — https://www.aryaka.com/docs/reports/vidar-infostealer-in-action.pdf

Wojna między 0APT i KryBit ujawnia kulisy operacji ransomware

Wprowadzenie do problemu / definicja

Konflikty między grupami ransomware zwykle pozostają poza zasięgiem obserwacji obrońców, ponieważ operatorzy koncentrują się na monetyzacji dostępu, szyfrowaniu danych i wymuszeniach. Tym razem rywalizacja między 0APT i KryBit doprowadziła jednak do nietypowej sytuacji: obie strony zaczęły ujawniać wzajemnie dane operacyjne, elementy infrastruktury oraz szczegóły zaplecza technicznego.

Dla zespołów bezpieczeństwa to rzadki wgląd w funkcjonowanie przestępczego ekosystemu od środka. Tego typu incydenty pokazują nie tylko techniczne możliwości grup ransomware, ale również ich wewnętrzne napięcia, mechanizmy budowania reputacji i podatność na błędy operacyjne.

W skrócie

0APT na początku 2026 roku opublikowała szeroką listę rzekomych ofiar, której wiarygodność szybko podważono.
Po okresie ciszy grupa wróciła, twierdząc, że atakuje inne marki ransomware, w tym KryBit.
KryBit odpowiedziała kontruderzeniem i przejęła dane 0APT.
W ujawnionych materiałach znalazły się informacje o administratorach, afiliantach, potencjalnych ofiarach, logach dostępowych oraz kodzie źródłowym.
Najważniejszy wniosek jest taki, że wiele wcześniejszych deklaracji 0APT o licznych ofiarach miało najprawdopodobniej charakter sfabrykowany.

Kontekst / historia

0APT została zaobserwowana pod koniec stycznia 2026 roku, gdy opublikowała listę blisko 200 rzekomych ofiar na swoim blogu wyciekowym. Taki ruch mógł służyć zbudowaniu wiarygodności w środowisku cyberprzestępczym oraz przyciągnięciu afiliantów, jednak brak twardych dowodów na rzeczywiste kompromitacje szybko wzbudził wątpliwości.

Z dostępnych ustaleń wynikało, że grupa posiadała działające narzędzia szyfrujące, ale nie zdołała uzyskać silnej pozycji w ekosystemie ransomware. W praktyce oznaczało to próbę wejścia na rynek poprzez agresywny marketing i kreowanie pozorów skuteczności.

KryBit pojawiła się później, pod koniec marca 2026 roku, jako operator modelu ransomware-as-a-service. Grupa miała oferować narzędzia do ataków na środowiska Windows, Linux, ESXi oraz urządzenia NAS, a także model podziału zysków korzystny dla afiliantów. W odróżnieniu od 0APT sprawiała wrażenie podmiotu bardziej wiarygodnego operacyjnie.

Eskalacja nastąpiła w momencie, gdy 0APT zaczęła publicznie twierdzić, że kompromituje inne grupy ransomware. To wywołało bezpośrednią reakcję KryBit i doprowadziło do otwartego konfliktu, którego skutkiem było wzajemne ujawnianie danych.

Analiza techniczna

Z perspektywy technicznej incydent jest szczególnie interesujący, ponieważ nie dotyczy klasycznego ataku na organizację końcową, lecz kompromitacji zaplecza przestępczej infrastruktury. 0APT opublikowała dane przypisywane innym podmiotom ransomware, w tym bazę SQL powiązaną z Everest. Choć część rekordów miała formę zakodowaną lub haszowaną, sam wyciek sugerował dostęp do fragmentów infrastruktury lub jej zasobów.

Najważniejszy etap nastąpił po odpowiedzi KryBit. W wyniku kontrataku ujawniono informacje wskazujące, że KryBit miała dwóch administratorów, pięciu afiliantów oraz około 20 potencjalnych ofiar. W materiałach znalazły się również dane dotyczące żądań okupu, które miały mieścić się w przedziale od 40 tys. do 100 tys. dolarów.

Jeszcze większe znaczenie miało jednak przejęcie danych 0APT. Upublicznione artefakty miały obejmować pełne logi dostępu, kod źródłowy PHP oraz pliki systemowe. Taki zestaw materiałów ma dużą wartość dla threat intelligence, ponieważ pozwala analizować architekturę paneli administracyjnych, schematy logowania, organizację serwerów oraz możliwe błędy popełniane przez operatorów.

strukturę paneli administracyjnych i zaplecza zarządzającego,
mechanizmy uwierzytelniania i ścieżki dostępu,
sposób organizacji środowiska serwerowego,
ślady aktywności afiliantów i administratorów,
elementy wskazujące na improwizację lub niski poziom dojrzałości operacyjnej.

Szczególnie istotne okazały się logi dostępu, które miały wskazywać, że ponad 190 ofiar publikowanych wcześniej przez 0APT było fikcyjnych i nie wiązało się z rzeczywistą eksfiltracją danych. To ważna obserwacja, ponieważ pokazuje, że w świecie ransomware reputacja bywa budowana nie tylko poprzez skuteczne ataki, lecz także przez dezinformację i sztuczne kreowanie renomy.

Konsekwencje / ryzyko

Dla obrońców tego rodzaju konflikt może być korzystny tylko częściowo i raczej krótkoterminowo. Z jednej strony ujawnione dane zwiększają przejrzystość działań przeciwnika, umożliwiają analizę jego procedur i wspierają budowę detekcji opartych na technikach, taktykach i procedurach. Z drugiej strony osłabienie jednej marki ransomware nie oznacza zniknięcia zagrożenia.

Operatorzy i afilianci często przenoszą się do nowych programów RaaS, zmieniają nazwę grupy lub odbudowują działalność pod innym szyldem. Narzędzia i branding mogą się zmieniać, ale wzorce lateral movement, eksfiltracji danych czy negocjacji z ofiarami nierzadko pozostają podobne.

ponowne pojawienie się tych samych aktorów pod nową nazwą,
migrację afiliantów do innych programów ransomware-as-a-service,
chaotyczne i trudniejsze do przewidzenia działania wynikające z rywalizacji grup,
wtórne wykorzystanie wykradzionych danych operacyjnych przez kolejne podmioty przestępcze.

Rekomendacje

Organizacje powinny traktować ten incydent jako źródło praktycznych wniosków obronnych, a nie jedynie ciekawostkę z podziemia cyberprzestępczego. Kluczowe znaczenie ma skupienie się na zachowaniach atakujących oraz odporności operacyjnej środowiska.

Monitorować etapy przygotowania do eksfiltracji danych, w tym nietypowe transfery, archiwizację i staging dużych zbiorów plików.
Regularnie testować odtwarzanie kopii zapasowych oraz ich odporność na usunięcie lub modyfikację przez atakującego.
Wzmacniać ochronę endpointów i serwerów przy użyciu EDR/XDR, segmentacji sieci, MFA i ograniczania uprawnień administracyjnych.
Budować detekcje oparte na zachowaniach, a nie wyłącznie na nazwach grup i kampanii.
Utrzymywać proces threat intelligence i szybko przekładać nowe IOC oraz TTP na reguły SIEM, EDR i systemy blokowania ruchu.
Objąć monitoringiem środowiska wieloplatformowe, w tym Linux, ESXi, NAS i systemy serwerowe, a nie tylko stacje robocze.

Podsumowanie

Spór między 0APT i KryBit pokazuje, że ekosystem ransomware jest silnie konkurencyjny, a reputacja, afilianci i monetyzacja są równie ważne jak technologia ataku. W tym przypadku wzajemne wycieki dostarczyły obrońcom cennych informacji o strukturze grup, ich zapleczu i rzeczywistej wiarygodności.

Najważniejszy wniosek dla zespołów bezpieczeństwa jest praktyczny: nawet jeśli konkretna marka ransomware słabnie lub znika, jej operatorzy, afilianci i techniki często przetrwają pod nową postacią. Dlatego skuteczna obrona powinna koncentrować się na wykrywaniu zachowań, odporności operacyjnej i szybkim wykorzystywaniu danych wywiadowczych.

Źródła

Dark Reading — Feuding Ransomware Groups Leak Each Other’s Data

Lotus Wiper uderza w sektor energetyczny Wenezueli: destrukcyjny malware wymierzony w infrastrukturę krytyczną

Wprowadzenie do problemu / definicja

Lotus Wiper to destrukcyjne złośliwe oprogramowanie typu wiper, którego głównym celem jest trwałe niszczenie danych oraz zakłócanie działania systemów, a nie wymuszenie okupu. Najnowsze ustalenia wskazują, że narzędzie zostało wykorzystane w ukierunkowanej kampanii przeciwko organizacjom z sektora energetycznego i utilities w Wenezueli, co wpisuje się w rosnące zagrożenie dla infrastruktury krytycznej.

W przeciwieństwie do klasycznych kampanii ransomware, ataki z użyciem wiperów koncentrują się na sabotażu operacyjnym. W praktyce oznacza to, że ofiara może utracić dostęp do systemów, danych i usług bez możliwości szybkiego odtworzenia środowiska, nawet jeśli nie dochodzi do żadnych żądań finansowych.

W skrócie

Lotus Wiper został powiązany z kampanią wymierzoną w organizacje energetyczne w Wenezueli pod koniec 2025 roku.
Atak nie zawierał mechanizmów ransomware ani żądań okupu, co wskazuje na motywację destrukcyjną.
Łańcuch ataku obejmował użycie skryptów wsadowych, zmianę haseł, dezaktywację kont, wylogowywanie użytkowników i wyłączanie interfejsów sieciowych.
Operatorzy szeroko wykorzystywali techniki living-off-the-land, nadużywając natywnych narzędzi Windows.
Końcowa faza prowadziła do nadpisywania danych, usuwania plików i utrudniania odzyskiwania systemów.

Kontekst / historia

Wipery od lat są wykorzystywane w operacjach wymierzonych w państwa, sektor publiczny oraz infrastrukturę krytyczną. Ich znaczenie rośnie szczególnie tam, gdzie skutki incydentu mogą wykraczać poza obszar IT i wpływać na procesy przemysłowe, logistykę lub świadczenie usług o znaczeniu strategicznym.

W analizowanym przypadku próbki i artefakty powiązane z Lotus Wiper zostały odnotowane w grudniu 2025 roku. Według badaczy końcowy komponent binarny miał zostać skompilowany we wrześniu 2025 roku, co może wskazywać, że operacja była przygotowywana z dużym wyprzedzeniem. Dodatkowego znaczenia sprawie nadaje zbieżność czasowa z publicznymi doniesieniami o zakłóceniach w wenezuelskim sektorze naftowym.

Choć pełna atrybucja kampanii nie została jednoznacznie potwierdzona, zestaw obserwowanych technik sugeruje, że atak nie miał charakteru przypadkowego. Wszystko wskazuje na precyzyjny dobór celu, rozpoznanie środowiska i przygotowanie mechanizmów umożliwiających skoordynowaną destrukcję.

Analiza techniczna

Łańcuch ataku opierał się na kilku następujących po sobie etapach. W początkowej fazie wykorzystywano dwa pliki BAT, które odpowiadały za przygotowanie środowiska i synchronizację działań w sieci domenowej. Jeden ze skryptów tworzył katalog roboczy, podejmował próby zatrzymania określonych mechanizmów systemowych i sprawdzał obecność pliku kontrolnego w udziale NETLOGON, pełniącym rolę domenowego wyzwalacza.

Następny etap obejmował działania destabilizujące środowisko jeszcze przed uruchomieniem właściwego wipera. Skrypt wykonywał enumerację lokalnych kont, zmieniał hasła, dezaktywował wybranych użytkowników, wylogowywał aktywne sesje oraz wyłączał interfejsy sieciowe. Z perspektywy obrony była to faza szczególnie niebezpieczna, ponieważ ograniczała możliwości reakcji zespołów IT i utrudniała zdalne przeciwdziałanie incydentowi.

Na uwagę zasługuje szerokie użycie narzędzi natywnych systemu Windows. Operatorzy korzystali z poleceń związanych z modyfikacją rejestru, zarządzaniem sesjami, obsługą sieci, czyszczeniem woluminów i operacjami na plikach. Takie podejście living-off-the-land pozwala ukrywać aktywność w legalnym ruchu administracyjnym, co znacząco utrudnia wykrycie oparte wyłącznie na sygnaturach.

Faza destrukcyjna miała charakter wielowarstwowy. Atakujący nadpisywali dane na woluminach, kopiowali binaria systemowe do własnego katalogu roboczego, a następnie wykorzystywali mechanizmy lustrzanego kopiowania do nadpisywania lub usuwania zawartości folderów. Dodatkowo tworzono plik zajmujący niemal całą wolną przestrzeń dysku, co mogło jeszcze bardziej ograniczać szanse na odzyskanie danych i przywrócenie systemów do działania.

Sam Lotus Wiper był odszyfrowywany i uruchamiany przez pomocniczy plik wykonywalny podszywający się pod legalny komponent środowiska HCL Domino. Po uruchomieniu malware aktywował wymagane uprawnienia, usuwał punkty przywracania systemu, nadpisywał fizyczne dyski zerami, czyścił dzienniki zmian USN oraz wyszukiwał pliki przeznaczone do usunięcia. Proces kasowania obejmował wcześniejsze zerowanie zawartości plików, zmianę nazw na losowe oraz usuwanie natychmiastowe lub odroczone do czasu restartu systemu.

Całość wskazuje na wcześniejszy kompromis środowiska ofiary. Taki scenariusz wymagał bowiem nie tylko dostarczenia komponentów na wiele hostów, ale również dobrej znajomości struktury domeny, udziałów sieciowych oraz specyfiki używanych systemów. To przemawia za planowaną operacją, a nie za oportunistycznym incydentem.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją ataku z użyciem Lotus Wiper jest trwała utrata danych i unieruchomienie systemów. W sektorze energetycznym może to oznaczać nie tylko problemy po stronie IT, lecz także zakłócenia procesów operacyjnych, logistyki, produkcji i utrzymania usług krytycznych.

Istotnym zagrożeniem jest również połączenie długiego czasu obecności napastnika w środowisku z wykorzystaniem legalnych narzędzi administracyjnych. Taka kombinacja utrudnia detekcję, wydłuża czas reakcji i zwiększa prawdopodobieństwo, że organizacja zorientuje się o incydencie dopiero w momencie rozpoczęcia fazy niszczącej.

Ryzyko rośnie szczególnie w środowiskach, w których sieci IT i OT nie są odpowiednio segmentowane, a kopie zapasowe pozostają dostępne z poziomu skompromitowanej domeny. W takich warunkach skutki ataku mogą szybko rozszerzyć się poza systemy biurowe i wpłynąć na elementy wspierające procesy przemysłowe.

Rekomendacje

Organizacje działające w sektorach energetycznym, przemysłowym i utilities powinny traktować kampanię z użyciem Lotus Wiper jako ważny scenariusz odniesienia dla budowy odporności operacyjnej. Kluczowe znaczenie ma segmentacja środowisk IT, OT i ICS oraz ograniczenie ruchu administracyjnego pomiędzy strefami o różnym poziomie krytyczności.

Monitorowanie udziałów domenowych, zwłaszcza NETLOGON, pod kątem nieautoryzowanych plików i zmian pełniących rolę wyzwalaczy.
Wykrywanie nietypowego użycia narzędzi takich jak diskpart, robocopy, fsutil, netsh, reg, sc czy wmic, szczególnie gdy pojawiają się masowo na wielu hostach.
Ograniczenie liczby kont uprzywilejowanych, wdrożenie tieringu administracyjnego oraz alertowanie przy zmianach haseł, dezaktywacji kont i masowym wylogowywaniu sesji.
Wdrożenie kopii zapasowych odpornych na modyfikację i usunięcie, odseparowanych logicznie lub fizycznie od domeny produkcyjnej.
Regularne testowanie procedur odtwarzania oraz ćwiczenie scenariuszy reagowania na incydent typu wiper.
Budowa detekcji behawioralnej opartej na korelacji zdarzeń, a nie wyłącznie na znanych wskaźnikach IOC.

W praktyce obrona przed takim zagrożeniem wymaga wcześniejszej widoczności w środowisku, spójnej telemetrii i przygotowania operacyjnego. Gdy rozpoczyna się właściwa faza niszczenia danych, czas na skuteczną reakcję jest zwykle bardzo ograniczony.

Podsumowanie

Lotus Wiper pokazuje, że współczesne kampanie przeciwko infrastrukturze krytycznej coraz częściej mają charakter czysto destrukcyjny. W tym modelu celem nie jest finansowy zysk, lecz trwałe zakłócenie działania organizacji poprzez niszczenie danych, blokowanie dostępu i paraliż operacyjny.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest jasny: skuteczna ochrona przed wiperem wymaga segmentacji, kontroli uprawnień, monitorowania aktywności administracyjnej oraz odpornych mechanizmów odtworzeniowych. Bez tych elementów nawet pojedyncza kampania może wywołać długotrwałe skutki biznesowe i operacyjne.

Źródła

Dark Reading – Lotus Wiper Attack Targets Venezuelan Energy Firms, Utilities
https://www.darkreading.com/cyber-risk/lotus-wiper-attack-targeted-venezuelan-energy-firms-utilities
Securelist – Lotus Wiper: a new threat targeting the energy and utilities sector
https://securelist.com/tr/lotus-wiper/119472/
Microsoft Learn – System Restore Functions
https://learn.microsoft.com/en-us/windows/win32/sr/system-restore-functions
Microsoft Learn – Change Journals (USN)
https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals
Reuters – reporting on disruption affecting Venezuelan oil operations in December 2025
https://www.reuters.com/

AI wykryła 38 luk w OpenEMR. Krytyczne błędy zagrażały bazie danych i danym medycznym

Wprowadzenie do problemu / definicja

OpenEMR to otwartoźródłowa platforma elektronicznej dokumentacji medycznej, wykorzystywana przez ponad 100 tys. świadczeniodawców ochrony zdrowia. Najnowsza analiza bezpieczeństwa wykazała 38 wcześniej nieudokumentowanych podatności, obejmujących m.in. SQL injection, błędy autoryzacji, XSS, path traversal oraz problemy z obsługą sesji.

Skala odkrycia pokazuje, że systemy przetwarzające dane pacjentów pozostają szczególnie atrakcyjnym celem ataków, a jednocześnie coraz większą rolę w wykrywaniu błędów odgrywają narzędzia oparte na sztucznej inteligencji. W tym przypadku automatyczna analiza kodu znacząco przyspieszyła identyfikację słabości w rozbudowanej aplikacji medycznej.

W skrócie

W ciągu około trzech miesięcy wykryto 38 podatności i przypisano im identyfikatory CVE.
Najgroźniejsze błędy mogły prowadzić do kompromitacji bazy danych, wycieku chronionych informacji zdrowotnych oraz potencjalnego zdalnego wykonania kodu.
Istotna część poprawek trafiła do wydania OpenEMR 8.0.0 z 11 lutego 2026 r., a kolejne poprawki wdrożono w marcu 2026 r.
Sprawa pokazuje rosnącą skuteczność AI w analizie bezpieczeństwa kodu oraz potrzebę szybkiego reagowania na podatności w systemach ochrony zdrowia.

Kontekst / historia

OpenEMR od lat należy do najbardziej rozpoznawalnych otwartoźródłowych systemów EHR i funkcjonuje w środowiskach, w których przetwarzane są dane o wysokiej wrażliwości. Już wcześniej platforma była przedmiotem analiz bezpieczeństwa, a wcześniejsze audyty wykazywały, że rozbudowana logika biznesowa i szeroka powierzchnia ataku utrudniają pełne zabezpieczenie systemu.

Obecne badanie pokazuje zmianę skali i tempa pracy. W relatywnie krótkim czasie zidentyfikowano więcej problemów niż podczas wcześniejszych, szeroko komentowanych analiz wykonywanych głównie ręcznie. To wyraźny sygnał, że narzędzia AI mogą istotnie skracać czas potrzebny do przeszukiwania dużych repozytoriów oraz identyfikowania błędów logicznych, autoryzacyjnych i implementacyjnych.

Z drugiej strony ten sam postęp technologiczny może działać na korzyść napastników. Jeśli obrońcy są w stanie szybciej odnajdywać luki, to również cyberprzestępcy mogą automatyzować poszukiwanie podatności w systemach krytycznych, w tym w oprogramowaniu medycznym.

Analiza techniczna

Wśród ujawnionych luk dominowały trzy grupy problemów: błędy autoryzacji, podatności typu SQL injection oraz nadmierna ekspozycja danych przez interfejsy API. W wielu miejscach aplikacja akceptowała identyfikatory rekordów przekazywane przez użytkownika bez właściwej weryfikacji uprawnień do odczytu lub modyfikacji danych. Tego rodzaju błędy odpowiadają schematowi IDOR i mogą umożliwiać dostęp do dokumentacji medycznej, danych płatności czy formularzy pacjentów.

Za najpoważniejszą uznano podatność CVE-2026-24908 z oceną CVSS 10.0. Problem dotyczył parametru _sort w Patient REST API. Przekazywane wartości były dołączane do klauzuli SQL bez skutecznej walidacji i bez ograniczenia do bezpiecznego zbioru pól. W praktyce uwierzytelniony atakujący mógł wykorzystać ten mechanizm do odczytu hashy haseł, analizy zawartości tabel bazy danych, a w sprzyjających warunkach również do operacji na plikach po stronie serwera, co otwierało drogę do dalszej eskalacji.

Drugim szczególnie istotnym błędem była luka CVE-2026-23627 w module immunizacji. Parametr patient_id trafiał do zapytań SQL bez prawidłowej parametryzacji. Pozwalało to uwierzytelnionemu użytkownikowi budować złośliwe zapytania prowadzące do przejęcia kontroli nad bazą danych, kradzieży informacji zdrowotnych i pozyskania poświadczeń. W środowiskach z nadmiernymi uprawnieniami po stronie DBMS ryzyko eskalacji było jeszcze większe.

Wyróżniono także CVE-2026-24487, dotyczącą interfejsu FHIR CareTeam. Mechanizm powinien ograniczać odpowiedzi do danych przypisanych do konkretnego pacjenta, jednak z powodu błędu architektonicznego filtr pacjenta nie był prawidłowo stosowany. W rezultacie endpoint mógł zwracać informacje o zespołach opieki dla wszystkich pacjentów, a nie wyłącznie dla rekordu objętego zakresem tokena. To szczególnie niebezpieczny przykład błędu logiki biznesowej w integracjach opartych na standardzie FHIR.

Istotny jest także sam proces remediacji. Dla każdej z 38 podatności przygotowano propozycje poprawek zgodne z architekturą repozytorium, co przyspieszyło wdrażanie łatek. Dodatkowo analizator AI został włączony do procesu code review, aby podobne problemy były wykrywane wcześniej, jeszcze przed wdrożeniem zmian do środowisk produkcyjnych.

Konsekwencje / ryzyko

Wpływ opisanych podatności należy ocenić jako wysoki, szczególnie w sektorze ochrony zdrowia. Systemy EHR przechowują dane osobowe, historię leczenia, informacje finansowe oraz dokumenty o znaczeniu operacyjnym i regulacyjnym. Ich kompromitacja może prowadzić do naruszenia poufności danych pacjentów, zakłóceń działania placówki, manipulacji dokumentacją medyczną, a także do wtórnych incydentów, takich jak ransomware, kradzież tożsamości czy oszustwa ubezpieczeniowe.

Dodatkowe ryzyko wynika z faktu, że część błędów mogła zostać wykorzystana przez użytkownika posiadającego jedynie podstawowy, uwierzytelniony dostęp. W praktyce oznacza to możliwość nadużycia przejętego konta, słabego hasła, skompromitowanego tokena lub poświadczeń wykradzionych w innym incydencie. Tam, gdzie organizacje nie wdrożyły segmentacji, monitorowania aktywności bazy danych oraz minimalizacji uprawnień, skutki potencjalnego ataku mogły być znacznie poważniejsze.

W środowisku medycznym należy uwzględnić również konsekwencje prawne i zgodnościowe. Ekspozycja danych zdrowotnych może uruchamiać obowiązki notyfikacyjne, audyty, wysokie koszty obsługi incydentu oraz długotrwałe straty reputacyjne. To przypomnienie, że błędy aplikacyjne w systemach klinicznych wpływają nie tylko na bezpieczeństwo informacji, ale też na ciągłość świadczenia usług i bezpieczeństwo pacjentów.

Rekomendacje

Organizacje korzystające z OpenEMR powinny w pierwszej kolejności zweryfikować używaną wersję systemu i niezwłocznie zastosować wszystkie poprawki opublikowane po wydaniu 8.0.0, w tym aktualizacje udostępnione w marcu 2026 r. Samo wdrożenie łatek nie powinno jednak kończyć procesu reakcji.

Przeprowadzić przegląd logów aplikacyjnych, serwerowych i bazodanowych pod kątem anomalii związanych z REST API, modułem immunizacji oraz interfejsami FHIR.
Wymusić rotację poświadczeń oraz skontrolować uprawnienia użytkowników i tokenów OAuth2.
Ograniczyć uprawnienia kont bazy danych, szczególnie w zakresie funkcji umożliwiających odczyt i zapis plików na serwerze.
Wdrożyć parametryzację zapytań, whitelistę parametrów wejściowych i dodatkowe kontrole ACL na poziomie aplikacji.
Przeprowadzić testy autoryzacyjne pod kątem IDOR, brakujących kontroli dostępu i błędów zakresu w API.
Monitorować nietypowe zapytania SQL, odpowiedzi zawierające nadmierny zakres danych oraz próby enumeracji rekordów pacjentów.
Włączyć skanowanie bezpieczeństwa do pipeline’u CI/CD i procesu code review, z naciskiem na analizę semantyczną kodu.

Dla dostawców oprogramowania i zespołów utrzymaniowych płynie z tego szerszy wniosek: systemy medyczne wymagają ciągłego testowania bezpieczeństwa logiki biznesowej. Tradycyjne skanery dobrze wykrywają część klas błędów, ale często gorzej radzą sobie z lukami autoryzacyjnymi, niewłaściwym zakresem dostępu i problemami architektonicznymi w API.

Podsumowanie

Przypadek OpenEMR dobrze ilustruje dwa równoległe trendy w bezpieczeństwie aplikacji. Po pierwsze, systemy ochrony zdrowia pozostają szczególnie atrakcyjnym i ryzykownym celem ze względu na wartość danych oraz złożoność logiki biznesowej. Po drugie, narzędzia AI realnie zwiększają tempo wykrywania podatności, co może działać zarówno na korzyść obrońców, jak i atakujących.

Wykrycie 38 luk, w tym błędów umożliwiających kompromitację bazy danych i potencjalne zdalne wykonanie kodu, powinno skłonić administratorów do pilnego przeglądu aktualizacji, konfiguracji uprawnień i ekspozycji API. To również ważny sygnał dla całej branży, że bezpieczeństwo systemów EHR musi być traktowane jako proces ciągły, łączący szybkie łatanie, analizę architektury i automatyzację kontroli bezpieczeństwa już na etapie tworzenia oprogramowania.

Źródła

Dark Reading – AI Finds 38 Security Flaws in Electronic Health Record Platform — https://www.darkreading.com/vulnerabilities-threats/ai-finds-38-security-flaws-openemr
AISLE – AISLE Discovers 38 CVEs in Healthcare Software Used by 100,000 Medical Providers — https://aisle.com/blog/aisle-discovers-38-critical-security-vulnerabilities-in-healthcare-software-used-by-100000-providers
GitHub Advisory – SQL Injection in Patient API Sort Parameter — https://github.com/openemr/openemr/security/advisories/GHSA-rcc2-45v3-qmqm
GitHub Advisory – SQL Injection in Immunization Search/Report — https://github.com/openemr/openemr/security/advisories/GHSA-x3hw-rwrg-v25h
GitHub Advisory – FHIR Patient Compartment Bypass in CareTeam Resource — https://github.com/openemr/openemr/security/advisories/GHSA-4frq-f657-hwrc