Archiwa: Security News - Strona 114 z 502

Złośliwe koparki GPU rozprzestrzeniane przez SEO poisoning i odpowiedzi chatbotów AI

Wprowadzenie do problemu / definicja

Nowa kampania cryptojackingu pokazuje, że klasyczne zatruwanie wyników wyszukiwania nadal pozostaje skuteczną metodą infekcji, a jednocześnie zaczyna obejmować także ekosystem asystentów AI. Atakujący podszywają się pod popularne narzędzia systemowe i diagnostyczne, a następnie dostarczają ofiarom archiwa zawierające legalny instalator oraz złośliwą bibliotekę DLL. Celem nie są przypadkowe komputery, lecz wydajne stacje robocze i komputery graczy wyposażone w mocne karty graficzne.

W skrócie

Atak wykorzystuje fałszywe strony pobierania promowane przez SEO poisoning.
W części przypadków użytkownicy trafiają na złośliwe domeny także przez odpowiedzi chatbotów AI.
Pakiet infekcyjny łączy legalny plik wykonywalny ze złośliwą biblioteką DLL.
Napastnicy uzyskują trwały dostęp do systemu przez legalne narzędzie zdalnego zarządzania.
Końcowym celem jest uruchomienie koparek kryptowalut wykorzystujących GPU.

Kontekst / historia

Cryptojacking od lat pozostaje atrakcyjnym modelem monetyzacji dla cyberprzestępców, ponieważ umożliwia generowanie zysków bez szyfrowania danych czy otwartego szantażu ofiary. W ostatnich latach operatorzy takich kampanii coraz częściej odchodzą od masowych, prostych infekcji i koncentrują się na przejęciu systemów zapewniających wyższy zwrot z operacji.

W tym przypadku szczególnie cenne są komputery graczy, stacje robocze twórców treści, środowiska renderujące i inne maszyny wyposażone w wydajne układy graficzne. To właśnie użytkownicy takich urządzeń często wyszukują benchmarki, sterowniki, kodeki czy aplikacje monitorujące parametry sprzętu, co czyni z nich naturalny cel dla kampanii podszywających się pod popularne narzędzia użytkowe.

Nowym i niepokojącym elementem jest przenikanie tej taktyki do odpowiedzi generowanych przez systemy AI. Oznacza to, że proces wyszukiwania i pozyskiwania oprogramowania staje się coraz szerszym polem nadużyć, wykraczającym poza klasyczne reklamy i wyniki wyszukiwania.

Analiza techniczna

Atak rozpoczyna się od wejścia użytkownika na spreparowaną stronę pobierania. Dostarczane archiwum ZIP zawiera prawidłowy plik wykonywalny legalnej aplikacji oraz złośliwą bibliotekę DLL, co wskazuje na wykorzystanie techniki DLL sideloading. W praktyce legalny proces ładuje podstawiony komponent, który uruchamia kolejne etapy infekcji.

Następnie złośliwa biblioteka uruchamia proces instalacji kolejnego ładunku z użyciem procesu systemowego odpowiedzialnego za instalację pakietów. W dalszym etapie wdrażane jest legalne narzędzie do zdalnego dostępu, co utrudnia wykrycie aktywności i daje napastnikom możliwość utrzymania interaktywnej kontroli nad przejętym hostem.

Kolejny komponent kopiuje się do ukrytego katalogu pod nazwą imitującą legalny składnik systemu. Badacze wskazali również na utworzenie wielu mechanizmów persystencji w różnych lokalizacjach autostartu systemu Windows, co zwiększa odporność złośliwego oprogramowania na częściowe usunięcie lub restart urządzenia.

W części przypadków ładunek dostarczany był również przez skrypt PowerShell i zapisywany lokalnie pod nazwą sugerującą legalny program multimedialny. To klasyczna metoda maskowania aktywności, utrudniająca szybką ocenę sytuacji przez użytkownika i administratora.

Istotnym elementem kampanii jest także process hollowing. Malware uruchamia legalne, podpisane procesy systemowe i wstrzykuje do nich własny kod, co znacząco utrudnia detekcję opartą wyłącznie na reputacji plików lub prostych wskaźnikach kompromitacji. Dodatkowo złośliwy kod modyfikuje ustawienia ochrony, dodając wyjątki do mechanizmów bezpieczeństwa, oraz sprawdza, czy działa w środowisku analitycznym lub maszynie wirtualnej.

Po zakończeniu fazy ukrywania i utrwalania obecności malware pobiera moduły służące do kopania kryptowalut z użyciem GPU. Wykorzystanie narzędzi górniczych przystosowanych do akceleracji graficznej potwierdza, że napastnicy celowo wybierają hosty o wysokiej mocy obliczeniowej.

Konsekwencje / ryzyko

Najbardziej widocznym skutkiem infekcji jest nieautoryzowane zużycie mocy GPU, energii elektrycznej oraz przyspieszona eksploatacja podzespołów. W środowiskach domowych objawia się to wzrostem temperatur, większym hałasem wentylatorów, spadkiem wydajności komputera i wyższymi rachunkami za prąd.

W organizacjach skutki są znacznie poważniejsze. Zainfekowane stacje robocze mogą działać wolniej, powodować opóźnienia w renderingu, zakłócać pracę aplikacji inżynierskich i obniżać dostępność zasobów dla zespołów korzystających z akceleracji graficznej. Dodatkowo wdrożenie narzędzia zdalnego dostępu oznacza, że przejęty host może stać się punktem wyjścia do dalszych działań ofensywnych.

Ryzyko nie kończy się więc na cryptojackingu. Napastnicy mogą wykorzystać dostęp do instalacji kolejnych ładunków, kradzieży danych uwierzytelniających, ruchu bocznego w sieci, a nawet przygotowania środowiska pod późniejszy atak ransomware lub kradzież danych.

Szczególnie istotne jest także zagrożenie wynikające z nadużycia odpowiedzi chatbotów AI. Jeżeli użytkownicy traktują modele generatywne jako zaufane źródło rekomendacji oprogramowania, błędne lub zmanipulowane wskazania mogą stać się nowym ogniwem łańcucha infekcji.

Rekomendacje

Organizacje powinny ograniczyć pobieranie oprogramowania wyłącznie do oficjalnych stron producentów, zaufanych repozytoriów oraz wewnętrznie zatwierdzonych katalogów aplikacji. Warto wdrożyć polityki zabraniające instalowania narzędzi pobranych bezpośrednio z reklam, wyników wyszukiwania lub odpowiedzi generowanych przez systemy AI bez dodatkowej weryfikacji.

blokować nieautoryzowane narzędzia zdalnego dostępu,
monitorować nietypowe użycie PowerShell i procesów instalacyjnych,
wykrywać zmiany w autostarcie oraz zadaniach harmonogramu,
alertować na dodawanie wyjątków do mechanizmów ochronnych,
analizować uruchamianie podpisanych procesów w nietypowym kontekście,
kontrolować archiwa ZIP i biblioteki DLL uruchamiane z katalogów użytkownika.

W środowiskach posiadających cenne zasoby GPU warto wdrożyć telemetrykę zużycia kart graficznych i profile bazowego obciążenia. Nietypowe, długotrwałe wykorzystanie GPU poza godzinami pracy może być skutecznym wskaźnikiem cryptojackingu.

Z perspektywy użytkownika końcowego kluczowe znaczenie mają podstawowe zasady higieny bezpieczeństwa: weryfikacja domeny przed pobraniem, sprawdzanie podpisów cyfrowych i sum kontrolnych, unikanie pośrednich stron z plikami oraz traktowanie rekomendacji chatbotów jedynie jako wskazówek wymagających potwierdzenia.

Podsumowanie

Opisana kampania pokazuje, że cryptojacking ewoluuje w stronę bardziej selektywnych i rentownych operacji. Połączenie SEO poisoning, nadużycia zaufania do odpowiedzi AI, DLL sideloadingu, wielowarstwowej persystencji, process hollowing i legalnych narzędzi administracyjnych tworzy skuteczny łańcuch ataku wymierzony w komputery o wysokiej wartości obliczeniowej.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona procesu pobierania oprogramowania i kontrola zaufanych narzędzi administracyjnych stają się równie ważne jak klasyczne mechanizmy antymalware. Skuteczna obrona wymaga połączenia polityk instalacyjnych, telemetrii endpointów, detekcji behawioralnej i edukacji użytkowników.

Źródła

BleepingComputer — https://www.bleepingcomputer.com/news/security/gpu-mining-malware-spreads-via-seo-poisoning-ai-chatbots/
Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/
Microsoft Threat Intelligence — https://www.microsoft.com/en-us/security/business/security-101/what-is-threat-intelligence

Holenderska policja zatrzymała podejrzanego o włamanie do systemów Ajax Amsterdam

Wprowadzenie do problemu / definicja

Incydent dotyczący Ajax Amsterdam pokazuje, że naruszenie bezpieczeństwa w organizacji sportowej może wykraczać daleko poza klasyczny wyciek danych. W tej sprawie chodzi o podejrzenie wielokrotnego, nieuprawnionego dostępu do systemów klubu piłkarskiego, obejmującego zarówno dane kibiców, jak i funkcje operacyjne związane z biletami oraz zakazami stadionowymi.

Z perspektywy cyberbezpieczeństwa to przykład naruszenia, które łączy problem poufności, integralności danych oraz kontroli dostępu. Tego typu incydenty są szczególnie groźne, ponieważ mogą wpływać nie tylko na prywatność użytkowników, ale też na działanie kluczowych procesów biznesowych.

W skrócie

Holenderska policja zatrzymała 35-letniego mężczyznę podejrzanego o włamanie do systemów Ajax Amsterdam. Według dostępnych informacji klub miał zostać zaatakowany na początku 2026 roku, a sprawca miał uzyskiwać nieautoryzowany dostęp wielokrotnie.

Incydent dotyczył systemów obsługujących dane kibiców oraz bilety.
Według wcześniejszych ustaleń możliwa była modyfikacja części zakazów stadionowych.
Media wskazywały również na możliwość przenoszenia zakupionych biletów.
Sprawa pokazuje znaczenie ochrony logiki biznesowej, a nie tylko samych baz danych.

Kontekst / historia

Sprawa stała się głośna pod koniec marca 2026 roku, gdy Ajax poinformował o incydencie bezpieczeństwa związanym z podatnościami w swoich systemach IT. Klub przekazał, że atakujący uzyskał dostęp do danych należących do kilkuset osób.

Już na tym etapie uwagę zwracał fakt, że naruszenie nie ograniczało się wyłącznie do odczytu informacji. Z dostępnych ustaleń wynikało, że problem dotyczył również funkcji biznesowych systemu, co oznacza znacznie wyższy poziom ryzyka operacyjnego.

Zgodnie z opublikowanymi informacjami, 27 maja 2026 roku holenderska policja zatrzymała podejrzanego w gminie Buren. Po zgłoszeniu incydentu wszczęto dochodzenie, które doprowadziło do identyfikacji i zatrzymania mężczyzny podejrzewanego o wielokrotne, celowe i bezprawne wnikanie do systemów komputerowych klubu.

Analiza techniczna

Najważniejszym aspektem technicznym tego incydentu jest charakter nadużytych uprawnień. Z publicznie opisanych ustaleń wynika, że wykorzystane podatności nie dawały jedynie możliwości pobrania danych, ale także pozwalały wykonywać operacje wpływające na logikę działania systemu.

W praktyce chodziło o środowiska obsługujące dane kibiców, bilety oraz zakazy stadionowe. Tego typu systemy zazwyczaj integrują portal użytkownika, zaplecze administracyjne, interfejsy API, mechanizmy autoryzacji i usługi partnerskie. Jeżeli luka występuje w warstwie API albo modelu kontroli dostępu, skutki mogą być znacznie poważniejsze niż w przypadku standardowego wycieku rekordów z bazy danych.

Doniesienia medialne sugerowały, że problem mógł dotyczyć szerokiego dostępu do danych fanów przez interfejsy API i współdzielone klucze. Taki schemat może wskazywać na błędy typu broken access control, nadmiernie szerokie uprawnienia usługowe albo niewłaściwą segmentację sekretów aplikacyjnych.

Z technicznego punktu widzenia szczególnie alarmujące były następujące obszary:

dostęp do danych osobowych użytkowników,
możliwość przenoszenia lub przepisywania biletów,
możliwość modyfikowania wpisów związanych z zakazami stadionowymi.

Taki zakres działań sugeruje, że system mógł nie egzekwować wystarczająco silnej separacji ról i kontekstu operacji. W dobrze zaprojektowanej architekturze mechanizmy odpowiedzialne za konta kibiców, administrację zakazami oraz zarządzanie biletami powinny być od siebie wyraźnie odseparowane zarówno logicznie, jak i pod względem uprawnień.

Konsekwencje / ryzyko

Ryzyko wynikające z tego typu incydentu należy oceniać wielowymiarowo. Po pierwsze, naruszenie poufności danych kibiców może prowadzić do phishingu, przejęć kont, oszustw socjotechnicznych oraz dalszych ataków ukierunkowanych.

Po drugie, możliwość zmiany statusu zakazów stadionowych lub przenoszenia biletów oznacza ingerencję w procesy biznesowe. W praktyce zwiększa to ryzyko nadużyć finansowych, obejścia kontroli bezpieczeństwa obiektu, sporów z klientami oraz utraty zaufania do systemów sprzedażowych.

Po trzecie, incydent może rodzić skutki regulacyjne i prawne. Jeżeli sprawa obejmuje dane osobowe, organizacja musi ocenić obowiązki notyfikacyjne wobec właściwych organów oraz osób, których dane dotyczą. Dla podmiotów zarządzających dużą bazą użytkowników szkody reputacyjne mogą być równie kosztowne jak same skutki techniczne.

Istnieje również ryzyko wtórne. Jeżeli atakujący poznał architekturę aplikacji, interfejsów API i modeli danych, nawet po załataniu pierwotnej luki organizacja musi brać pod uwagę możliwość istnienia dodatkowych wektorów wejścia, skradzionych sekretów lub pozostawionych mechanizmów trwałości.

Rekomendacje

Dla organizacji zarządzających systemami biletowymi, kontami klientów i funkcjami administracyjnymi kluczowe są następujące działania:

Przegląd i wzmocnienie kontroli dostępu — należy zweryfikować wszystkie ścieżki autoryzacji, szczególnie w API i panelach administracyjnych.
Segmentacja funkcji biznesowych — systemy odpowiedzialne za bilety, dane użytkowników i decyzje administracyjne powinny być odseparowane.
Rotacja sekretów i audyt kluczy współdzielonych — konieczna jest pełna inwentaryzacja tokenów i kluczy oraz ograniczenie ich zakresu uprawnień.
Pełne logowanie operacji wysokiego ryzyka — zmiany dotyczące biletów, kont i wpisów administracyjnych powinny być rejestrowane z pełnym kontekstem.
Monitoring anomalii biznesowych — warto wykrywać nie tylko wskaźniki techniczne, ale również nietypowe transfery biletów czy masowe odczyty danych kont.
Testy bezpieczeństwa aplikacji i API — regularne testy powinny obejmować logikę biznesową oraz autoryzację na poziomie obiektów.
Procedury reagowania na incydenty — po wykryciu podobnego zdarzenia należy szybko ustalić zakres zmian, zabezpieczyć logi, przeprowadzić rotację poświadczeń i niezależny przegląd architektury.

Podsumowanie

Incydent związany z Ajax Amsterdam pokazuje, że nowoczesne ataki na organizacje nie kończą się wyłącznie na kradzieży danych. Coraz częściej celem jest także manipulacja procesami biznesowymi, które mają bezpośredni wpływ na klientów, operacje i bezpieczeństwo fizyczne.

Z perspektywy obrony kluczowe znaczenie mają segmentacja systemów, ścisła autoryzacja, monitoring działań wysokiego ryzyka oraz regularne testy logiki aplikacyjnej. To właśnie te elementy decydują o tym, czy podobny incydent pozostanie ograniczonym naruszeniem, czy przerodzi się w poważny kryzys operacyjny.

Źródła

BleepingComputer — Dutch police arrests suspect linked to Ajax football club hack — https://www.bleepingcomputer.com/news/security/dutch-police-arrests-suspect-linked-to-ajax-football-club-hack/

GlassWorm: przejęcie infrastruktury C2 zakłóciło groźną kampanię ataków na łańcuch dostaw oprogramowania

Wprowadzenie do problemu / definicja

GlassWorm to kampania malware wymierzona przede wszystkim w programistów, zespoły DevOps oraz środowiska tworzenia oprogramowania. Jej celem jest przejęcie poświadczeń, kompromitacja repozytoriów kodu i rejestrów pakietów, a następnie wykorzystanie zdobytego dostępu do dalszego rozprzestrzeniania złośliwych komponentów w łańcuchu dostaw oprogramowania.

To przykład nowoczesnego ataku supply chain, w którym pojedyncza infekcja stacji roboczej dewelopera może przełożyć się na szerokie skutki biznesowe i operacyjne. W praktyce oznacza to, że atakujący nie muszą uderzać bezpośrednio w końcowe ofiary — wystarczy przejąć zaufany element procesu wytwarzania aplikacji.

W skrócie

Skoordynowane działania doprowadziły do zakłócenia kanałów command-and-control wykorzystywanych przez GlassWorm. Kampania była powiązana z infekcjami realizowanymi przez złośliwe rozszerzenia oraz przejęte lub trojanizowane pakiety publikowane w popularnych ekosystemach deweloperskich.

celem były środowiska programistyczne i konta deweloperów,
malware kradł tokeny, dane z przeglądarek i informacje systemowe,
operatorzy dysponowali funkcjami zdalnego wykonywania kodu,
infrastruktura C2 była odporna dzięki wielu równoległym kanałom komunikacji,
zakłócenie C2 ogranicza bieżące sterowanie, ale nie usuwa skutków wcześniejszych kompromitacji.

Kontekst / historia

Ataki na software supply chain od kilku lat należą do najpoważniejszych zagrożeń w cyberbezpieczeństwie. W przeciwieństwie do klasycznych incydentów endpointowych, kompromitacja narzędzi deweloperskich, zależności open source, pipeline’ów CI/CD czy marketplace’ów rozszerzeń pozwala przeciwnikom osiągnąć skalę trudną do uzyskania innymi metodami.

GlassWorm wpisuje się właśnie w ten trend. Z dostępnych ustaleń wynika, że operatorzy wykorzystywali więcej niż jeden wektor dostępu: złośliwe rozszerzenia do narzędzi używanych przez programistów, a także pakiety publikowane lub przejmowane w popularnych ekosystemach. Taka strategia zwiększa skuteczność kampanii, ponieważ środowiska deweloperskie z natury regularnie pobierają nowe komponenty i opierają się na zaufaniu do zewnętrznych źródeł.

Istotne jest także to, że kompromitacja dewelopera nie kończy się na kradzieży pojedynczego hasła. W wielu organizacjach taka stacja robocza ma dostęp do kodu źródłowego, kluczy API, sekretów CI/CD, platform chmurowych, systemów ticketowych i narzędzi publikacji pakietów. To czyni ją celem o znacznie większej wartości niż standardowy punkt końcowy użytkownika biznesowego.

Analiza techniczna

Technicznie GlassWorm był kampanią wieloetapową. Początkowe zakażenie następowało przez złośliwy pakiet lub rozszerzenie, które po uruchomieniu inicjowało rozpoznanie środowiska i pobierało kolejne komponenty. Malware wyszukiwał tokeny, poświadczenia oraz artefakty związane z platformami deweloperskimi, repozytoriami i rejestrami pakietów.

Jednym z kluczowych modułów był implant typu JavaScript RAT wykorzystujący komunikację WebSocket. Taki komponent umożliwia nie tylko eksfiltrację danych, ale także wykonywanie poleceń na przejętym hoście, pobieranie dodatkowych modułów i rozszerzanie zakresu operacji po stronie atakujących.

Opis kampanii wskazuje również na użycie złośliwego rozszerzenia przeglądarkowego zdolnego do pozyskiwania bardzo wrażliwych danych operacyjnych. Chodziło m.in. o zrzuty ekranu, naciśnięcia klawiszy i zawartość schowka. To pokazuje, że GlassWorm funkcjonował nie tylko jako narzędzie kradzieży tokenów, ale także jako platforma posteksploatacyjna umożliwiająca głęboki nadzór nad aktywnością ofiary.

Według ujawnionych informacji zainfekowane systemy mogły być dalej wykorzystywane jako element zaplecza operacyjnego atakujących. Oznacza to możliwość przekształcania hostów w proxy, pośredniki ruchu lub ukryte punkty dostępu dla kolejnych działań. Z perspektywy obrońcy podnosi to ryzyko wtórnego wykorzystania własnej infrastruktury do dalszych kampanii.

Na szczególną uwagę zasługuje architektura command-and-control. GlassWorm miał korzystać z czterech niezależnych kanałów sterowania, co znacząco zwiększało odporność na blokowanie i przejęcie infrastruktury.

mechanizm dead drop oparty na blockchainie Solana,
pobieranie konfiguracji przez sieć BitTorrent DHT,
wykorzystanie legalnych usług internetowych jako nośników informacji o infrastrukturze,
bezpośrednia komunikacja z serwerami C2 hostowanymi u dostawców VPS.

Taka wielowarstwowa architektura utrudnia neutralizację kampanii, ponieważ wyłączenie jednego kanału nie musi oznaczać przerwania łączności z implantem. To model typowy dla bardziej dojrzałych operacji, projektowanych z myślą o trwałości i szybkim odtwarzaniu zdolności operacyjnych.

Konsekwencje / ryzyko

Największym zagrożeniem związanym z GlassWorm jest możliwość skażenia łańcucha dostaw oprogramowania na szeroką skalę. Jeśli atakujący przejmują konta publikacyjne, tokeny dostępu do repozytoriów lub środowiska deweloperskie, mogą wprowadzić złośliwy kod do projektów używanych później przez klientów, partnerów i systemy produkcyjne.

Skutki takiej kompromitacji wykraczają daleko poza pojedynczy endpoint. Organizacje muszą liczyć się z ryzykiem:

kradzieży własności intelektualnej i kodu źródłowego,
przejęcia procesu budowania i wdrażania aplikacji,
publikacji zainfekowanych pakietów do rejestrów,
ruchu bocznego do środowisk wewnętrznych i chmurowych,
utrzymania trwałej obecności przeciwnika w procesie wytwarzania oprogramowania.

Samo zakłócenie infrastruktury C2 należy uznać za istotny sukces obronny, ale nie oznacza ono automatycznego zamknięcia incydentu. Tokeny mogły już zostać skradzione i wykorzystane, dane mogły zostać wyprowadzone, a złośliwe artefakty mogły wcześniej trafić do repozytoriów lub łańcucha zależności. Innymi słowy, przejęcie C2 zmniejsza bieżące możliwości operatorów, lecz nie cofa skutków wcześniejszej kompromitacji.

Rekomendacje

Organizacje tworzące oprogramowanie powinny traktować stacje robocze deweloperów jako zasoby krytyczne i chronić je podobnie jak systemy uprzywilejowane. W praktyce warto wdrożyć kilka warstw zabezpieczeń technicznych i procesowych.

ograniczyć zaufanie do rozszerzeń i pakietów poprzez whitelisting, weryfikację wydawców i skanowanie artefaktów,
stosować krótkotrwałe tokeny, rotację poświadczeń oraz zasadę najmniejszych uprawnień,
wymusić MFA wszędzie tam, gdzie to możliwe, zwłaszcza dla repozytoriów, rejestrów i chmury,
monitorować endpointy deweloperskie pod kątem nietypowych procesów, połączeń WebSocket i działań związanych ze schowkiem lub screenshotami,
objąć repozytoria i pipeline’y CI/CD kontrolą integralności oraz detekcją anomalii publikacyjnych,
przygotować procedury reagowania specyficzne dla incydentów supply chain, w tym szybkie unieważnianie tokenów i analizę historii publikacji.

Warto również rozwijać praktyki podpisywania commitów, podpisywania publikacji pakietów oraz segmentacji dostępu między narzędziami deweloperskimi a środowiskami produkcyjnymi. Im mniejszy zakres uprawnień posiada pojedyncze konto lub host, tym trudniej przełożyć lokalną kompromitację na pełnoskalowy incydent łańcucha dostaw.

Podsumowanie

GlassWorm pokazuje, że programiści i ich narzędzia pracy stali się jednym z najważniejszych celów nowoczesnych kampanii cyberprzestępczych. Połączenie kradzieży poświadczeń, modułów RAT, rozszerzeń przeglądarkowych oraz wielokanałowej infrastruktury C2 tworzy zagrożenie wykraczające poza klasyczny model infekcji stacji roboczej.

Skoordynowane przejęcie lub zakłócenie kanałów sterowania ogranicza możliwości dalszego prowadzenia kampanii, ale nie eliminuje ryzyka wtórnych nadużyć wynikających z już zdobytych danych i dostępów. Dla organizacji to kolejny sygnał, że bezpieczeństwo procesu wytwarzania oprogramowania musi obejmować nie tylko kod i pipeline, lecz także codzienne środowisko pracy deweloperów.

Źródła

https://thehackernews.com/2026/05/glassworm-malware-takedown-disrupts.html
https://www.crowdstrike.com/
https://www.endorlabs.com/
https://www.truesec.com/

Rzekoma baza 340 mln profili OnlyFans: rekonstrukcja tożsamości z wycieków zamiast bezpośredniego włamania

Wprowadzenie do problemu / definicja

Na cyberprzestępczych forach pojawiła się oferta sprzedaży zbioru danych rzekomo powiązanego z 340 milionami profili OnlyFans. Dostępne informacje wskazują jednak, że nie musi chodzić o klasyczny wyciek wynikający z kompromitacji infrastruktury platformy, lecz o agregację danych pochodzących z wcześniejszych naruszeń, publicznych profili oraz informacji skorelowanych między wieloma źródłami.

Taki model działania wpisuje się w rosnący trend rekonstrukcji tożsamości cyfrowej, w którym atakujący budują profile użytkowników nie przez jedno spektakularne włamanie, ale przez łączenie fragmentów danych z różnych miejsc. Z punktu widzenia prywatności skutki mogą być równie poważne jak w przypadku potwierdzonego wycieku z jednej platformy.

W skrócie

Sprzedający początkowo twierdził, że oferowany zbiór pochodzi z wewnętrznych systemów OnlyFans i zawiera dane osobowe, aktywność kont oraz wybrane pola związane z płatnościami. Później miał jednak przyznać, że baza nie została pozyskana w wyniku włamania, lecz została zbudowana przez łączenie starszych wycieków i danych publicznych.

mowa o zbiorze obejmującym nawet 340 milionów rekordów,
pochodzenie całej bazy pozostaje niezweryfikowane,
próbki sugerują, że część danych może odnosić się do realnych kont,
największe ryzyko dotyczy deanonimizacji, phishingu i szantażu.

Kontekst / historia

Podziemny rynek danych od lat zmienia swój charakter. Dawniej najwyższą wartość miały pełne zrzuty baz danych i listy loginów z hasłami. Dziś równie cenne są zbiory wzbogacone kontekstowo, które łączą adresy e-mail, numery telefonów, pseudonimy, profile społecznościowe oraz informacje o aktywności online.

W analizowanym przypadku kluczowe znaczenie ma rozbieżność między pierwotną narracją sprzedającego a późniejszym wyjaśnieniem źródła danych. Taka zmiana często sugeruje próbę zwiększenia atrakcyjności oferty przez przedstawienie agregatu danych jako rezultatu bezpośredniego włamania. Dla kupujących na forach przestępczych liczy się bowiem nie tylko objętość bazy, ale też wiarygodność jej pochodzenia i możliwość wykorzystania operacyjnego.

Analiza techniczna

Opublikowane próbki mają cechy płaskiego, tekstowego zbioru rekordów, a nie natywnego eksportu z nowoczesnej produkcyjnej bazy danych. Wśród pól miały znajdować się nazwy użytkowników, adresy e-mail, numery telefonów, daty dołączenia, liczby obserwujących, liczby polubień, metryki aktywności, powiązane profile społecznościowe oraz typ konta.

To istotny sygnał, ponieważ część takich informacji może być publicznie widoczna lub możliwa do ustalenia na podstawie otwartych źródeł. Po połączeniu ich z wcześniejszymi wyciekami możliwe staje się stworzenie spójnego profilu użytkownika. Tego typu korelacja zwykle opiera się na wspólnych identyfikatorach, takich jak adres e-mail, alias, numer telefonu, nazwa użytkownika albo odnośniki do kont w innych serwisach.

Dodatkowe wątpliwości budzi obecność pól o niejednoznacznym pochodzeniu, w tym wartości opisywanych jako odnoszące się do ostatnich czterech cyfr karty płatniczej. Bez niezależnej walidacji nie można potwierdzić, czy są to autentyczne elementy danych finansowych, artefakty z wcześniejszych wycieków, czy po prostu wartości dodane w celu podniesienia ceny zbioru. Obecność pól pustych lub zastępczych może również wskazywać na automatyczne scalanie rekordów z różnych źródeł bez pełnej normalizacji.

Technicznie taki zestaw mógł powstać w procesie przypominającym przestępcze ETL: ekstrakcję danych z archiwalnych wycieków, transformację, deduplikację i wzbogacanie rekordów informacjami z OSINT. W efekcie powstaje baza, która może nie zawierać pełnych danych rozliczeniowych ani haseł, ale nadal ma wysoką wartość dla atakujących.

Konsekwencje / ryzyko

Największym zagrożeniem nie jest sam rozmiar rzekomego zbioru, ale możliwość skutecznej deanonimizacji użytkowników. Połączenie pseudonimów z adresami e-mail, numerami telefonów i profilami społecznościowymi pozwala przygotowywać wiarygodne scenariusze ataków socjotechnicznych i kampanii ukierunkowanych.

precyzyjny spear phishing oparty na znajomości aktywności ofiary,
kampanie sextortion i szantaż reputacyjny,
nękanie, stalking oraz podszywanie się pod użytkowników,
próby przejęcia kont przez reset haseł lub ataki na numer telefonu,
dalsze wzbogacanie profili ofiar przez korelację z innymi wyciekami.

Nawet jeśli tylko część rekordów okaże się prawdziwa, taki zbiór może służyć jako baza referencyjna do wyboru celów o wysokiej wartości. W przypadku platform związanych z treściami wrażliwymi skutki prywatnościowe i reputacyjne mogą być nieproporcjonalnie duże względem stopnia kompletności samych danych.

Rekomendacje

Operatorzy platform internetowych powinni traktować podobne incydenty jako sygnał ostrzegawczy i wzmacniać monitoring wycieków wtórnych oraz prób korelacji danych użytkowników. Ochrona nie może ograniczać się wyłącznie do infrastruktury i kontroli dostępu.

monitorowanie forów cyberprzestępczych i kanałów obrotu danymi,
wykrywanie masowego scrapingu oraz nadużyć interfejsów API,
ograniczanie publicznej ekspozycji metadanych użytkowników,
wdrażanie mechanizmów utrudniających łączenie tożsamości między usługami,
szybką komunikację z użytkownikami w razie podejrzenia nadużyć.

Użytkownicy również powinni podjąć działania ograniczające ryzyko:

zmienić hasła, jeśli były używane ponownie w wielu serwisach,
włączyć uwierzytelnianie wieloskładnikowe,
zachować ostrożność wobec wiadomości nawiązujących do aktywności na platformie,
monitorować e-mail i numer telefonu pod kątem prób przejęcia kont,
ograniczyć możliwość łatwego powiązania profili między różnymi serwisami.

Z perspektywy zespołów bezpieczeństwa najważniejszy wniosek jest szerszy: przyszłe incydenty coraz częściej będą polegały nie na jednym wycieku z jednego systemu, lecz na inteligentnej rekonstrukcji tożsamości z wielu pozornie niegroźnych fragmentów danych.

Podsumowanie

Sprawa rzekomej sprzedaży bazy 340 milionów profili OnlyFans pokazuje zmianę w krajobrazie cyberzagrożeń. Coraz większą rolę odgrywa nie bezpośrednie włamanie do systemu, lecz korelacja danych z archiwalnych wycieków i źródeł publicznych. Takie zbiory mogą być mniej spektakularne niż klasyczne naruszenia, ale z perspektywy prywatności i ryzyka nadużyć pozostają równie niebezpieczne.

Dla obrońców oznacza to konieczność myślenia szerzej niż tylko o ochronie bazy danych czy panelu administracyjnego. Równie ważne staje się ograniczanie ekspozycji metadanych, utrudnianie korelacji informacji oraz szybkie reagowanie na wtórne wykorzystanie danych już krążących w cyberprzestępczym obiegu.

Źródła

Security Affairs — https://securityaffairs.com/192643/cyber-crime/340-million-onlyfans-profiles-allegedly-rebuilt-from-leaks.html
HackRead — https://hackread.com/

Lazarus rozwija bezplikowego RAT-a RemotePE, by skuteczniej omijać detekcję

Wprowadzenie do problemu / definicja

Bezplikowe złośliwe oprogramowanie to jedna z najbardziej wymagających kategorii zagrożeń dla zespołów bezpieczeństwa. W odróżnieniu od klasycznego malware, które zapisuje swoje komponenty na dysku, narzędzia tego typu działają głównie lub wyłącznie w pamięci operacyjnej. Taki model znacząco utrudnia wykrywanie, analizę incydentów oraz odtwarzanie pełnego przebiegu ataku.

Najświeższe ustalenia dotyczące grupy Lazarus wskazują, że operatorzy rozwinęli nowy pamięciowy trojan zdalnego dostępu o nazwie RemotePE. Narzędzie zostało zaprojektowane z myślą o skrytym utrzymaniu dostępu do środowiska ofiary, ograniczeniu śladów na dysku oraz omijaniu mechanizmów bezpieczeństwa stosowanych na stacjach roboczych i serwerach.

W skrócie

Badacze opisują trzyetapowy łańcuch infekcji obejmujący komponenty DPAPILoader, RemotePELoader oraz finalny moduł RemotePE. Pierwszy etap odszyfrowuje kolejny komponent przy użyciu mechanizmów DPAPI, drugi odpowiada za komunikację z infrastrukturą C2 i przygotowanie środowiska, a trzeci realizuje właściwe funkcje trojana zdalnego dostępu wykonywanego wyłącznie w pamięci.

Cały zestaw został przygotowany tak, aby ograniczyć skuteczność klasycznych metod detekcji. W praktyce oznacza to mniejszą liczbę artefaktów plikowych, utrudnioną analizę statyczną oraz zastosowanie technik unikania rozwiązań EDR, w tym usuwania hooków w przestrzeni użytkownika i ograniczania widoczności zdarzeń telemetrycznych.

Kontekst / historia

Grupa Lazarus od lat pozostaje jednym z najlepiej rozpoznanych aktorów APT, kojarzonych z operacjami wymierzonymi w instytucje finansowe, firmy związane z kryptowalutami oraz organizacje o wysokiej wartości operacyjnej. Nowe ustalenia wskazują, że RemotePE wpisuje się w długofalowy rozwój narzędzi tej grupy, zwłaszcza w obszarze ataków prowadzonych w sposób selektywny i ukierunkowany.

Analizowane kampanie mają wykorzystywać dobrze znany schemat wejścia do środowiska ofiary, oparty na socjotechnice, fałszywych procesach rekrutacyjnych oraz komunikacji biznesowej prowadzonej przez komunikatory. Po uzyskaniu wstępnego dostępu starsze komponenty miały zostać zastąpione bardziej zaawansowanym, modułowym zestawem działającym w pamięci, rozwijanym co najmniej od połowy 2023 do połowy 2024 roku.

Analiza techniczna

Łańcuch rozpoczyna się od komponentu DPAPILoader, czyli biblioteki DLL odpowiedzialnej za odszyfrowanie kolejnego etapu przy użyciu Windows Data Protection API. Takie podejście wiąże materiał kryptograficzny z konkretnym systemem ofiary, przez co przechwycone próbki są znacznie mniej użyteczne poza zainfekowanym hostem. Dodatkowo utrudnia to tworzenie skutecznych detekcji opartych wyłącznie na hashach i prostych sygnaturach.

DPAPILoader był maskowany jako legalny komponent systemowy i uruchamiany z wykorzystaniem usługi Windows. Następnie wyszukiwał dane w określonych lokalizacjach systemowych, odszyfrowywał kolejny moduł i ładował go refleksyjnie do pamięci. W części przypadków po odszyfrowaniu stosowano dodatkową warstwę XOR, pełniącą funkcję lekkiej obfuskacji.

Drugim etapem jest RemotePELoader. To właśnie on odpowiada za komunikację z serwerem C2, pobranie finalnego ładunku oraz przygotowanie procesu do dalszych działań. Loader dynamicznie rozwiązuje numery wywołań systemowych i remapuje biblioteki z KnownDlls, co ma pomóc w usunięciu hooków nakładanych przez oprogramowanie ochronne w przestrzeni użytkownika. Równolegle modyfikuje funkcje związane z ETW, ograniczając widoczność aktywności procesu dla narzędzi telemetrycznych.

Konfiguracja C2 jest przechowywana lokalnie i również chroniona za pomocą DPAPI. Zawiera m.in. parametry opóźnień, adresy serwerów sterujących, ustawienia proxy i identyfikatory niezbędne do komunikacji. Wymiana danych odbywa się przez HTTP POST, a część informacji o hoście trafia do nagłówków Cookie. Po zestawieniu sesji loader cyklicznie odpytuje serwer i oczekuje na finalny ładunek szyfrowany z użyciem AES-GCM oraz kodowany w Base64.

Sam RemotePE to wielowątkowy RAT napisany w C++, wykonywany całkowicie w pamięci. Oferuje zestaw funkcji typowych dla dojrzałego narzędzia post-exploitation, w tym wykonywanie poleceń systemowych, zarządzanie plikami, uruchamianie procesów, ładowanie dodatkowych bibliotek DLL oraz obsługę konfiguracji. Może również przygotowywać dane do eksfiltracji i rozszerzać możliwości poprzez dynamicznie rejestrowane moduły.

Na uwagę zasługuje także mechanizm bezpiecznego usuwania plików. RemotePE wielokrotnie nadpisuje dane przed zmianą nazwy i usunięciem pliku, co utrudnia odzyskanie dowodów i wpisuje się w techniki obserwowane we wcześniejszych rodzinach malware przypisywanych Lazarusowi.

Istotnym elementem operacyjnym jest również sposób dostarczania finalnego payloadu. Badacze zaobserwowali, że serwer C2 nie zawsze przekazywał ładunek automatycznie po rejestracji klienta. Sugeruje to model operator-in-the-loop, w którym człowiek po stronie atakującego decyduje o momencie dalszej eskalacji działań.

Konsekwencje / ryzyko

RemotePE zwiększa skuteczność działań APT na kilku poziomach jednocześnie. Bezplikowy model wykonania ogranicza ślady dostępne dla klasycznej analizy dyskowej, wykorzystanie DPAPI utrudnia badanie próbek poza środowiskiem ofiary, a techniki unhookingu i osłabiania telemetryki zmniejszają szansę wykrycia przez standardowe mechanizmy ochronne.

Dla organizacji oznacza to podwyższone ryzyko długotrwałej, niezauważonej obecności napastnika. Taki implant może posłużyć do rekonesansu, eksfiltracji danych, kradzieży poświadczeń, wdrożenia kolejnych modułów lub przeprowadzenia finalnej operacji finansowej. Szczególnie narażone pozostają środowiska przetwarzające wrażliwe dane, systemy uprzywilejowane oraz infrastruktura związana z aktywami finansowymi i kryptowalutowymi.

Rekomendacje

W obliczu zagrożeń takich jak RemotePE organizacje powinny rozszerzyć monitoring poza tradycyjne wskaźniki plikowe. Kluczowe staje się obserwowanie zachowań procesów, działań w pamięci oraz nietypowego użycia mechanizmów DPAPI. Szczególną uwagę warto zwracać na biblioteki DLL podszywające się pod legalne usługi systemowe, anomalie w katalogach systemowych oraz nietypowe wzorce ładowania modułów.

Na poziomie endpointów zalecane jest monitorowanie prób modyfikacji ETW, remapowania bibliotek systemowych i zachowań sugerujących reflective loading. Warto również wdrożyć mechanizmy inspekcji pamięci, kontrolę aplikacyjną oraz analitykę umożliwiającą wykrywanie nadużyć związanych z bezpośrednimi syscallami.

Po stronie sieci istotne będzie profilowanie ruchu HTTP, identyfikacja długotrwałych sesji beaconingowych oraz analiza niestandardowego wykorzystania nagłówków Cookie. Sama komunikacja może przypominać legalny ruch korporacyjny, dlatego duże znaczenie ma korelacja danych sieciowych z kontekstem procesowym i hostowym.

wzmocnienie ochrony stacji uprzywilejowanych i systemów obsługujących aktywa finansowe,
ograniczenie uruchamiania nieautoryzowanych bibliotek DLL oraz wdrożenie kontroli aplikacyjnej,
pełne logowanie zdarzeń procesowych i sieciowych z centralną korelacją,
regularne polowania zagrożeń pod kątem pamięciowych RAT-ów i nadużyć DPAPI,
szkolenia przeciwko socjotechnice wykorzystującej fałszywe procesy rekrutacyjne i komunikację biznesową.

Podsumowanie

RemotePE pokazuje, że Lazarus konsekwentnie inwestuje w narzędzia zapewniające skrytość, odporność na analizę i długotrwałe utrzymanie dostępu. Połączenie szyfrowania z użyciem DPAPI, działania wyłącznie w pamięci, mechanizmów unikania EDR oraz ręcznie sterowanego dostarczania ładunku tworzy zagrożenie szczególnie istotne dla organizacji o wysokiej wartości biznesowej.

Dla obrońców najważniejszy wniosek jest jasny: skuteczna detekcja nowoczesnych kampanii APT wymaga odejścia od podejścia opartego wyłącznie na plikach i hashach. Coraz większe znaczenie mają monitoring pamięci, analiza zachowań procesów oraz identyfikowanie subtelnych wzorców komunikacji z infrastrukturą sterującą.

Źródła

Atak na dostawcę zewnętrznego ujawnił dane pacjentów The Oncology Institute

Wprowadzenie do problemu / definicja

Incydenty bezpieczeństwa po stronie dostawców zewnętrznych należą dziś do najpoważniejszych zagrożeń dla sektora ochrony zdrowia. W takim scenariuszu organizacja medyczna nie musi paść ofiarą bezpośredniego włamania do własnej infrastruktury, aby doszło do naruszenia poufnych informacji. Wystarczy kompromitacja partnera technologicznego, który przetwarza dane pacjentów lub obsługuje kluczowe procesy biznesowe.

Przypadek The Oncology Institute pokazuje, że ryzyko łańcucha dostaw jest realne i może dotyczyć danych szczególnie wrażliwych, w tym informacji identyfikacyjnych i zdrowotnych. To kolejny sygnał ostrzegawczy dla placówek medycznych korzystających z rozbudowanego ekosystemu dostawców oprogramowania i usług.

W skrócie

The Oncology Institute potwierdził, że incydent cyberbezpieczeństwa po stronie zewnętrznego dostawcy oprogramowania objął dane pacjentów. Organizacja już wcześniej informowała o zdarzeniu, jednak dopiero późniejsze ustalenia wykazały, że nieautoryzowany podmiot uzyskał dostęp do systemów zawierających informacje związane z pacjentami.

Sprawa jest łączona z szerszym incydentem dotyczącym TriZetto Provider Solutions, podmiotu należącego do Cognizant. To sugeruje, że skutki naruszenia mogą wykraczać poza pojedynczą organizację i obejmować większą liczbę podmiotów sektora ochrony zdrowia.

Kontekst / historia

The Oncology Institute to amerykańska organizacja świadcząca usługi onkologiczne w modelu ambulatoryjnym. W 2025 roku spółka ujawniła, że bada incydent bezpieczeństwa związany z zewnętrznym dostawcą usług programowych, jednak na tamtym etapie nie było jeszcze potwierdzenia, czy doszło do naruszenia danych osobowych pacjentów.

Sytuacja zmieniła się w maju 2026 roku, kiedy organizacja otrzymała zaktualizowane informacje wskazujące, że doszło do nieautoryzowanego dostępu do systemów zawierających dane należące do spółki, w tym dane pacjentów. Z dostępnych informacji wynika, że naruszenie może mieć związek z incydentem o szerszej skali, obejmującym również inne organizacje ochrony zdrowia korzystające z usług tego samego dostawcy.

Szczególnie niepokojący jest możliwie długi czas obecności intruza w środowisku dostawcy. Tego rodzaju opóźnione wykrycie zwiększa ryzyko szerokiej eksfiltracji danych oraz utrudnia dokładne oszacowanie skali incydentu i jego skutków.

Analiza techniczna

Z technicznego punktu widzenia zdarzenie wpisuje się w kategorię ataków na łańcuch dostaw. Napastnik nie musiał uzyskiwać bezpośredniego dostępu do infrastruktury każdej organizacji medycznej osobno. Wystarczające było przełamanie zabezpieczeń dostawcy, który centralnie przetwarzał dane wielu podmiotów i pośredniczył w realizacji procesów operacyjnych.

W tego typu incydentach możliwe wektory ataku obejmują przejęcie kont uprzywilejowanych, wykorzystanie błędnej konfiguracji środowiska, nadużycie podatności aplikacyjnych lub uzyskanie dostępu do zaplecza systemów przetwarzających rekordy pacjentów. Jeżeli celem był portal wykorzystywany przez świadczeniodawców, atakujący mógł uzyskać szeroki wgląd w dane przechowywane i przesyłane przez wiele organizacji jednocześnie.

Według ujawnionych informacji zagrożone mogły być dane osobowe i zdrowotne, takie jak imiona i nazwiska, adresy, daty urodzenia, numery Social Security, informacje ubezpieczeniowe oraz dane świadczeniodawców. Taki zestaw informacji ma wysoką wartość na cyberprzestępczym rynku, ponieważ może zostać wykorzystany do kradzieży tożsamości, oszustw ubezpieczeniowych, kampanii phishingowych i dalszych operacji socjotechnicznych.

Na obecnym etapie nie wskazano publicznie sprawcy ani nie przypisano ataku konkretnej grupie. Brak informacji o ransomware lub żądaniu okupu nie oznacza jednak, że incydent miał ograniczony charakter. Coraz częściej celem atakujących jest cicha eksfiltracja danych i ich późniejsze wykorzystanie bez konieczności zakłócania pracy systemów.

Konsekwencje / ryzyko

Dla organizacji medycznych skutki takiego naruszenia są wielowymiarowe. Obejmują obowiązki notyfikacyjne, ryzyko regulacyjne, koszty obsługi prawnej, wydatki na monitoring tożsamości osób poszkodowanych oraz długoterminowe straty reputacyjne. W sektorze ochrony zdrowia konsekwencje są szczególnie dotkliwe, ponieważ wyciek dotyczy danych wrażliwych, które mogą pozostawać użyteczne dla przestępców przez wiele lat.

Dla pacjentów zagrożenie nie kończy się na samym ujawnieniu danych. Połączenie informacji identyfikacyjnych z danymi dotyczącymi leczenia lub ubezpieczenia może umożliwić prowadzenie wyjątkowo wiarygodnych kampanii phishingowych, podszywanie się pod placówki medyczne, wyłudzenia płatności oraz próby przejmowania kont i świadczeń.

Z perspektywy zarządzania bezpieczeństwem incydent pokazuje, że nawet dobrze chroniona organizacja pozostaje narażona, jeśli krytyczny dostawca nie utrzymuje porównywalnego poziomu zabezpieczeń, monitoringu i kontroli dostępu. To właśnie dlatego ryzyko third-party breach stało się jednym z głównych obszarów zainteresowania zespołów bezpieczeństwa i compliance.

Rekomendacje

Organizacje ochrony zdrowia powinny traktować bezpieczeństwo dostawców jako integralny element zarządzania ryzykiem operacyjnym. Samo spełnianie wymogów formalnych nie wystarcza, jeśli partner technologiczny ma dostęp do danych pacjentów lub obsługuje procesy krytyczne dla działalności organizacji.

przeprowadzenie pełnej inwentaryzacji dostawców przetwarzających dane pacjentów i klasyfikacja ich według krytyczności,
wymaganie stosowania wieloskładnikowego uwierzytelniania, szyfrowania danych, segmentacji środowisk oraz rejestrowania dostępu uprzywilejowanego,
wprowadzenie do umów precyzyjnych wymagań dotyczących zgłaszania incydentów, dostępności logów i współpracy w analizie powłamaniowej,
regularna weryfikacja integracji z zewnętrznymi portalami i aplikacjami pod kątem minimalizacji zakresu udostępnianych danych,
wdrożenie monitorowania anomalii w komunikacji z systemami partnerów oraz kontroli transferów danych,
opracowanie scenariuszy reagowania na incydenty po stronie dostawców, obejmujących komunikację z pacjentami, prawnikami i regulatorami.

Osoby, których dane mogły zostać objęte naruszeniem, powinny zachować szczególną ostrożność wobec wiadomości dotyczących leczenia, płatności i ubezpieczenia. W praktyce oznacza to konieczność weryfikowania każdej prośby o dodatkowe dane osobowe oraz monitorowania historii kredytowej i aktywności na kontach związanych z opieką zdrowotną.

Podsumowanie

Incydent dotyczący The Oncology Institute to kolejny przykład, że bezpieczeństwo danych medycznych zależy nie tylko od ochrony własnej infrastruktury, ale również od dojrzałości cyberbezpieczeństwa dostawców zewnętrznych. Kompromitacja jednego partnera może przełożyć się na naruszenie danych wielu organizacji i tysięcy pacjentów.

Dla sektora ochrony zdrowia oznacza to konieczność traktowania bezpieczeństwa łańcucha dostaw jako obszaru krytycznego. Bez realnej kontroli nad ryzykiem po stronie podmiotów trzecich nawet najlepiej zaprojektowane mechanizmy ochrony wewnętrznej mogą okazać się niewystarczające.

Źródła

https://securityaffairs.com/192679/data-breach/third-party-cyberattack-impacts-patient-information-at-the-oncology-institute.html
https://www.sec.gov/Archives/edgar/data/1795091/000095017026076071/toi-20260522.htm
https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf
https://trizettodatabreach.com/

Chińscy operatorzy phishingowi stawiają na przechwytywanie poświadczeń w czasie rzeczywistym

Wprowadzenie do problemu / definicja

Nowa fala kampanii phishingowych przypisywanych chińskojęzycznym operatorom pokazuje wyraźne odejście od klasycznych, statycznych stron wyłudzających dane logowania. Coraz częściej stosowany jest model przechwytywania poświadczeń w czasie rzeczywistym, oparty na technice adversary-in-the-middle (AiTM), w którym atakujący pośredniczy w całym procesie uwierzytelniania.

W praktyce oznacza to, że ofiara może widzieć interfejs bardzo podobny do legalnej strony logowania, ale cała komunikacja przechodzi przez infrastrukturę kontrolowaną przez przestępców. Dzięki temu napastnicy są w stanie zebrać nie tylko login i hasło, lecz także kody MFA oraz tokeny sesyjne.

W skrócie

Operatorzy phishingowi odchodzą od prostych stron podszywających się pod portale logowania.
Coraz częściej wykorzystywany jest model AiTM umożliwiający przechwytywanie poświadczeń i sesji w czasie rzeczywistym.
Takie kampanie mogą skutecznie omijać tradycyjne mechanizmy MFA oparte na kodach SMS, OTP i powiadomieniach push.
Napastnicy stosują przekierowania, mechanizmy antybotowe i ukrywanie infrastruktury, aby utrudnić wykrycie operacji.

Kontekst / historia

Phishing AiTM nie jest zjawiskiem nowym, jednak w ostatnich latach wyraźnie przeszedł z kategorii bardziej zaawansowanych operacji do modelu szerzej dostępnego na rynku cyberprzestępczym. Rozwój phishing-as-a-service sprawił, że gotowe zestawy narzędzi do przechwytywania sesji i poświadczeń stały się łatwiejsze do wdrożenia także dla mniej wyspecjalizowanych grup.

Obecne kampanie przypisywane chińskojęzycznym operatorom wpisują się w ten trend, ale jednocześnie pokazują rosnącą dojrzałość operacyjną. Zmianie ulega nie tylko sama technika wyłudzania danych, ale również sposób dostarczania przynęt, maskowania zaplecza i utrudniania analizy prowadzonej przez zespoły bezpieczeństwa.

Analiza techniczna

W schemacie adversary-in-the-middle serwer atakującego działa jak reverse proxy pomiędzy użytkownikiem a prawdziwą usługą logowania. Ofiara wpisuje dane na stronie przynęty, które są natychmiast przekazywane do legalnego dostawcy tożsamości. Odpowiedzi serwera wracają tą samą drogą, dzięki czemu cały proces wygląda wiarygodnie.

Typowy łańcuch ataku rozpoczyna się od wiadomości zawierającej link do przynęty. Użytkownik może zostać przeprowadzony przez kilka etapów przekierowań, które mają utrudnić analizę automatyczną i obejść zabezpieczenia filtrujące. Następnie trafia na stronę pośredniczącą, która wizualnie odtwarza legalny portal logowania.

Po wpisaniu loginu i hasła dane są przekazywane dalej do rzeczywistej usługi uwierzytelniania. Jeżeli konto jest chronione MFA, ofiara wykonuje standardowy krok weryfikacyjny, nie mając świadomości, że kod lub potwierdzenie również przechodzi przez infrastrukturę atakującego. Najbardziej krytyczny moment następuje po poprawnym zalogowaniu, gdy legalna usługa wystawia token lub cookie sesyjne, które może zostać przechwycone i wykorzystane do przejęcia aktywnej sesji.

Nowoczesne platformy phishingowe wykorzystują ponadto dodatkowe warstwy utrudniające wykrycie. Wśród nich znajdują się:

mechanizmy CAPTCHA i filtry antybotowe,
selekcja ruchu na podstawie adresu IP, geolokalizacji i cech przeglądarki,
wieloetapowe przekierowania i usługi pośredniczące,
krótkotrwałe domeny oraz infrastruktura efemeryczna,
dynamiczne ładowanie paneli phishingowych dopiero po przejściu kontroli.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takich kampanii jest możliwość obejścia powszechnie stosowanych metod MFA, szczególnie tych, które można zrelayować w czasie rzeczywistym. Oznacza to, że nawet organizacje korzystające z dodatkowego składnika uwierzytelniania mogą pozostać podatne na przejęcie konta.

Ryzyko nie kończy się na samym logowaniu. Po uzyskaniu dostępu do aktywnej sesji napastnik może przejąć skrzynkę pocztową, konto w usłudze chmurowej, system SSO lub panel administracyjny. W dalszej kolejności możliwe są ataki typu business email compromise, kradzież danych, resetowanie haseł w innych systemach, eskalacja uprawnień i ruch boczny w organizacji.

Dodatkowym problemem jest trudniejsza detekcja incydentu. Ponieważ logowanie odbywa się wobec prawdziwej usługi, część sygnałów może wyglądać jak legalna aktywność użytkownika. Bez korelacji telemetrycznej z warstwy tożsamości, urządzenia, lokalizacji i zachowania sesji przejęcie tokenu może przez pewien czas pozostać niezauważone.

Rekomendacje

Organizacje powinny traktować phishing AiTM jako zagrożenie wymierzone przede wszystkim w warstwę tożsamości i sesji, a nie wyłącznie w pocztę elektroniczną. Obrona musi obejmować zarówno etap dostarczenia przynęty, jak i kontrolę procesu logowania oraz aktywności po uwierzytelnieniu.

Kluczowe znaczenie ma wdrażanie metod uwierzytelniania odpornych na phishing, takich jak FIDO2, WebAuthn, passkeys czy klucze sprzętowe. Rozwiązania bazujące wyłącznie na SMS lub kodach OTP nie powinny być uznawane za wystarczające zabezpieczenie dla kont uprzywilejowanych i krytycznych zasobów.

Warto również rozwijać polityki dostępu warunkowego oraz monitoring sesji. Dobre praktyki obejmują:

ograniczanie dostępu do wrażliwych aplikacji wyłącznie z urządzeń zarządzanych,
wymuszanie dodatkowej weryfikacji przy nowych lokalizacjach, sieciach i urządzeniach,
monitorowanie nietypowych adresów IP, ASN, User-Agentów i anomalii geograficznych,
unieważnianie tokenów sesyjnych po podejrzanych zdarzeniach,
wymuszanie ponownego uwierzytelnienia dla operacji uprzywilejowanych.

Istotna pozostaje także edukacja użytkowników. Szkolenia powinny obejmować scenariusze z wykorzystaniem komunikatorów, kodów QR, stron pośredniczących i przekierowań, a nie tylko klasyczne wiadomości e-mail. Organizacja powinna mieć też jasne procedury zgłaszania incydentów oraz szybkiej reakcji po wykryciu potencjalnego przejęcia sesji.

Podsumowanie

Obserwowane kampanie pokazują istotną zmianę jakościową w działaniach phishingowych. Zamiast prostego wyłudzania haseł operatorzy coraz częściej przechwytują cały proces logowania w czasie rzeczywistym, co znacząco zwiększa skuteczność ataków i osłabia ochronę opartą na tradycyjnym MFA.

Dla zespołów bezpieczeństwa oznacza to konieczność przesunięcia nacisku z ochrony wyłącznie poczty na kompleksowe zabezpieczenie tożsamości, urządzeń i sesji. W praktyce to dojrzałość procesów IAM, wdrożenie phishing-resistant MFA oraz szybka analiza anomalii po zalogowaniu będą decydować o odporności organizacji na nowoczesne kampanie AiTM.

Źródła

https://www.infosecurity-magazine.com/news/chinese-phishing-live-credential/
https://www.cyber.gc.ca/sites/default/files/itsm.30.031-e.pdf
https://blog.sekoia.io/wp-content/uploads/2025/06/Sekoia_io___Global_analysis_of_Adversary_in_the_Middle_phishing_threats.pdf
https://sec.okta.com/articles/uncloakingvoidproxy/
https://www.csoonline.com/article/4056512/voidproxy-phishing-as-a-service-operation-steals-microsoft-google-login-credentials.html