Wprowadzenie do problemu / definicja
Najnowsza kampania wymierzona w niezałatane bramy bezpieczeństwa Check Point pokazuje, jak szybko podatności w urządzeniach brzegowych mogą zostać przekształcone w pełnoskalowe naruszenie bezpieczeństwa. Atakujący wykorzystali luki określane jako PHP2Shell do uzyskania dostępu początkowego, a następnie lokalną podatność eskalacji uprawnień w systemie Gaia OS, aby przejąć pełną kontrolę nad urządzeniem, utrwalić obecność i przejść do działań destrukcyjnych w środowisku VMware ESXi.
W skrócie
- Celem kampanii były niezałatane systemy Check Point.
- Ataki rozpoczęły się pod koniec października 2026 roku i szybko rozszerzyły się na wiele krajów oraz sektorów.
- Napastnicy łączyli exploit PHP2Shell z lokalną eskalacją uprawnień do poziomu root.
- Po przejęciu urządzeń wdrażali web shella PHP, backdoora TSGA oraz komponent TSProxy.
- W wybranych przypadkach dochodziło do ruchu bocznego na hosty ESXi i użycia malware typu wiper do niszczenia plików.
Kontekst / historia
Urządzenia sieciowe, zapory oraz bramy dostępu zdalnego od lat pozostają atrakcyjnym celem dla grup prowadzących operacje szpiegowskie, sabotażowe i dla brokerów dostępu początkowego. Ich znaczenie wynika z uprzywilejowanej pozycji w architekturze organizacji, dostępu do krytycznego ruchu oraz częstego wystawienia usług do internetu.
W tej kampanii kluczową rolę odegrały luki z rodziny PHP2Shell, pozwalające na przejęcie kontroli nad podatnymi portalami Mobile Access. Według ustaleń badaczy pierwsze działania odnotowano 30 października 2026 roku, zaledwie około tydzień po udostępnieniu poprawek. Druga fala, z 2 listopada 2026 roku, miała już znacznie szerszy charakter i wskazywała na oportunistyczne poszukiwanie podatnych systemów bez wyraźnej selekcji geograficznej.
Analiza techniczna
Łańcuch ataku był wieloetapowy. Najpierw wykorzystywano podatności PHP2Shell, powiązane z błędami CVE-2026-109618 oraz CVE-2026-109619, aby uzyskać wstępny dostęp do bramy Check Point. Następnie operatorzy sięgali po CVE-2026-123039 w komponencie DynamicCLI systemu Gaia OS. To luka typu missing authorization, która umożliwia lokalną eskalację uprawnień do root po wcześniejszym uzyskaniu wykonania kodu.
Po uzyskaniu pełnych uprawnień napastnicy instalowali web shella PHP służącego do wykonywania poleceń i przesyłania plików. Kolejnym krokiem było wdrożenie TSGA, czyli pasywnego backdoora dla systemów Linux przystosowanego do środowiska Check Point. Implant działał pod nazwą przypominającą legalny komponent systemowy, co miało utrudnić jego wykrycie. Jego możliwości obejmowały zdalny dostęp, kradzież konfiguracji, utrwalanie obecności z wykorzystaniem mechanizmów kopii i snapshotów oraz manipulację logami zapory.
Istotnym elementem zestawu narzędzi był także TSProxy. Komponent ten wstrzykiwał bibliotekę do wybranych procesów i przechwytywał funkcje sieciowe, aby obsługiwać specjalnie oznaczone połączenia atakującego bez zakłócania normalnego ruchu. Taka metoda pozwala ukryć kanał komunikacyjny w istniejących usługach appliance’a, co znacznie utrudnia wykrywanie anomalii na poziomie sieci.
W dalszej fazie ataku obserwowano rozpoznanie zasobów wewnętrznych oraz ruch boczny do hostów VMware ESXi przez SSH. Do uwierzytelnienia wykorzystywano konto usługowe vpxuser. Na hostach ESXi uruchamiano następnie wiper destroy_v6, który rekurencyjnie przeglądał katalogi, nadpisywał pliki zerami i usuwał je niezależnie od rozszerzenia. W części lokalizacji pozostawiano także notę tekstową o charakterze politycznym.
Badacze wskazują na podobieństwa tej kampanii do zestawu narzędzi PhiliKit, jednak dostępne dane nie pozwalają na jednoznaczne przypisanie całej operacji konkretnemu aktorowi. Szczególnie ważne jest to, że część działań miała charakter destrukcyjny, co może sugerować zarówno działanie jednego podmiotu, jak i przekazanie dostępu innemu operatorowi.
Konsekwencje / ryzyko
Skala ryzyka dla organizacji korzystających z podatnych urządzeń Check Point jest wysoka. Kompromitacja bramy brzegowej daje przeciwnikowi uprzywilejowany punkt wejścia do sieci, często z dostępem do danych uwierzytelniających, konfiguracji oraz ruchu administracyjnego. Możliwość eskalacji do root oznacza z kolei pełne przejęcie appliance’a i znacząco utrudnia usunięcie śladów incydentu.
Dodatkowe zagrożenie wynika z funkcji TSGA i TSProxy. Nie jest to wyłącznie prosty web shell, lecz rozbudowany zestaw służący do utrwalenia obecności i ukrytej komunikacji. Może on wspierać długotrwałe szpiegostwo, kradzież konfiguracji i dalsze operacje w sieci ofiary. Jeżeli napastnik uzyska dostęp do warstwy wirtualizacyjnej, skutki incydentu gwałtownie rosną. Destrukcja plików na hostach ESXi może przełożyć się na niedostępność wielu maszyn wirtualnych jednocześnie, a więc na realne ryzyko przestoju operacyjnego, utraty danych i kosztownego odtwarzania środowiska.
Rekomendacje
Organizacje powinny niezwłocznie zweryfikować, czy wszystkie instancje Check Point Security Gateway, serwery zarządzające i powiązane komponenty działają na wersjach zawierających aktualne poprawki bezpieczeństwa. Priorytetem jest usunięcie ekspozycji związanej z PHP2Shell oraz aktualizacja systemów podatnych na CVE-2026-123039.
Równolegle warto przeprowadzić przegląd śladów kompromitacji. W praktyce oznacza to:
- analizę logów dostępu do portali Mobile Access,
- wyszukiwanie nietypowych artefaktów PHP,
- kontrolę nowych lub podszywających się pod systemowe plików wykonywalnych,
- weryfikację integralności konfiguracji appliance’a,
- sprawdzenie hostów ESXi pod kątem nietypowych logowań, nieautoryzowanych binariów i masowych operacji na plikach.
Z perspektywy obronnej warto wdrożyć segmentację administracyjną, ograniczyć zaufanie między bramą a systemami zaplecza oraz zminimalizować możliwość bezpośredniego ruchu z urządzeń brzegowych do platform wirtualizacyjnych. Należy również egzekwować ścisłe zasady dostępu uprzywilejowanego, rotację poświadczeń kont usługowych oraz monitorowanie aktywności SSH. Mechanizmy detekcji powinny korelować próby eksploatacji znanych luk, lokalną eskalację uprawnień, modyfikacje procesów systemowych i transfer do hostów ESXi.
W przypadku potwierdzonej kompromitacji sama aktualizacja urządzenia nie wystarczy. Incydent należy traktować jako pełne naruszenie strefy zaufanej, odizolować system, zabezpieczyć materiał do analizy śledczej, odbudować środowisko z zaufanego źródła oraz przeprowadzić przegląd potencjalnego ruchu bocznego i utraconych danych uwierzytelniających.
Podsumowanie
Opisana kampania pokazuje dojrzały, wieloetapowy model ataku: od szybkiego wykorzystania świeżo ujawnionych luk w urządzeniach brzegowych, przez lokalną eskalację uprawnień i trwałe ukrycie obecności, aż po działania destrukcyjne w warstwie wirtualizacyjnej. Dla zespołów bezpieczeństwa to wyraźny sygnał, że patch management dla appliance’y wystawionych do internetu musi być realizowany natychmiast, a monitoring tych systemów powinien obejmować nie tylko próby eksploatacji, ale też wskaźniki utrwalenia, ruchu bocznego i sabotażu operacyjnego.
Źródła
- The Hacker News — https://thehackernews.com/2026/11/hackers-exploit-php2shell-flaws-in.html
- Check Point Support: CVE-2026-123039 Security Advisory — https://support.checkpoint.com/results/sk/sk183463
- NVD: CVE-2026-123039 — https://nvd.nist.gov/vuln/detail/CVE-2026-123039