Wprowadzenie do problemu / definicja
Nowo załatana podatność w VMware vCenter stała się wektorem aktywnych ataków, w których napastnicy uzyskują zdalne wykonanie kodu na krytycznych systemach zarządzających środowiskiem wirtualnym. To szczególnie groźny scenariusz, ponieważ przejęcie vCenter może otworzyć drogę do pełnej kompromitacji infrastruktury vSphere, hostów ESXi oraz zarządzanych maszyn wirtualnych.
W analizowanej kampanii atakujący nie ograniczali się do jednorazowego włamania. Po uzyskaniu dostępu wdrażali mechanizmy trwałości, przejmowali poświadczenia, tworzyli konta administracyjne i finalnie uruchamiali ransomware wywodzące się z rodziny Babuk.
W skrócie
- Kampania wykorzystuje podatność CVE-2026-59310 w VMware vCenter.
- Ataki powiązano z podejrzewanym aktorem APT operującym w środowisku chińskojęzycznym.
- Po kompromitacji wdrażany był backdoor umożliwiający zdalne wykonywanie poleceń.
- Napastnicy tworzyli trwałość z użyciem cron i systemd oraz pozyskiwali poświadczenia vCenter.
- Końcowym etapem było szyfrowanie hostów ESXi ransomwarem bazującym na kodzie Babuk.
Kontekst / historia
Podatność CVE-2026-59310 została załatana pod koniec lipca 2026 roku, a aktywność ofensywna rozpoczęła się zaledwie kilka dni po upublicznieniu szczegółów błędu. Taki odstęp czasu potwierdza, że cyberprzestępcy bardzo szybko adaptują publicznie znane luki, zwłaszcza gdy dotyczą one systemów centralnie zarządzających infrastrukturą IT.
Z ustaleń badaczy wynika, że kampania obejmowała setki unikalnych adresów IP w dziesiątkach krajów. W części incydentów zauważono także ślady wykorzystania CVE-2026-59309, czyli błędu obejścia uwierzytelniania. Sugeruje to, że napastnicy testowali równolegle kilka ścieżek wejścia i dostosowywali techniki do konfiguracji konkretnej ofiary.
Atrybucja do aktora powiązanego z Chinami pozostaje oceną analityczną, a nie jednoznacznym przypisaniem. Wskazują na nią między innymi artefakty językowe, wzorce operacyjne, dobór narzędzi oraz profil zaatakowanych organizacji.
Analiza techniczna
Kluczowym elementem incydentu było wykorzystanie CVE-2026-59310, opisywanej jako podatność typu directory traversal w VMware vCenter Server. W praktyce umożliwiała ona osiągnięcie zdalnego wykonania kodu w kontekście root na urządzeniu VCSA, bez potrzeby wcześniejszej lokalnej eskalacji uprawnień.
Zaobserwowany łańcuch ataku rozpoczynał się od utworzenia spreparowanego pliku cron, którego nazwa nawiązywała do identyfikatora CVE. Następnie wykonywano pobranie zewnętrznego ładunku przy użyciu standardowych narzędzi systemowych, takich jak curl lub wget. W jednym ze scenariuszy wdrażany był implant określany jako linuxFile, pełniący rolę backdoora umożliwiającego zdalne wykonywanie poleceń.
Malware zestawiał połączenie z serwerem sterującym przez WebSocket, odbierał instrukcje operatora, uruchamiał je przez powłokę systemową i odsyłał wyniki. Istotnym elementem była obfuskacja adresu C2 oraz zastosowanie własnej warstwy kryptograficznej dla komunikacji aplikacyjnej. Próbki zawierały też funkcje ponownego łączenia po zerwaniu sesji oraz mechanizmy trwałości oparte na systemd i cron.
Cron był intensywnie wykorzystywany również do dalszych działań po uzyskaniu dostępu. Napastnicy używali go do pobierania dodatkowych skryptów, instalowania binariów reverse SSH dopasowanych do architektury systemu, tworzenia zadań podszywających się pod legalne komponenty VMware, wdrażania web shella w postaci pliku JSP oraz uruchamiania skryptów zakodowanych w Base64.
Szczególnie niebezpieczny był etap pozyskiwania danych uwierzytelniających do usług katalogowych vCenter. Atakujący uzyskiwali informacje pozwalające na modyfikację katalogu, a następnie dodawali własne tożsamości do grup administracyjnych. Zidentyfikowano również tworzenie nowych kont w vSphere oraz lokalnych kont na hostach ESXi, co przygotowywało środowisko do dalszej eksploatacji.
W końcowej fazie operacji na hostach ESXi uruchamiano ransomware szyfrujące pliki z rozszerzeniem „.babyk”, kojarzone z wariantami wywodzącymi się z kodu Babuk. Badacze zwracają uwagę, że szyfrowanie mogło pełnić nie tylko funkcję wymuszenia okupu, ale również maskowania wcześniejszych działań poprzez utrudnienie analizy logów i rekonstrukcji przebiegu ataku.
Konsekwencje / ryzyko
Kompromitacja VMware vCenter niesie bardzo wysokie ryzyko operacyjne i biznesowe, ponieważ system ten stanowi centralny punkt zarządzania środowiskiem wirtualnym. Udany atak może przełożyć się na pełne przejęcie warstwy administracyjnej, kradzież kont uprzywilejowanych oraz rozszerzenie dostępu na hosty ESXi i maszyny wirtualne.
- Przejęcie warstwy zarządzania vSphere.
- Kradzież poświadczeń administracyjnych i usługowych.
- Tworzenie ukrytych kont o trwałych uprawnieniach.
- Rozprzestrzenienie dostępu na hosty ESXi i środowiska produkcyjne.
- Wdrożenie ransomware i paraliż kluczowych usług.
- Utrata widoczności telemetrycznej wskutek usuwania lub szyfrowania logów.
Dla przedsiębiorstw oznacza to ryzyko przestojów, utraty integralności systemów, kosztownego procesu odtwarzania środowiska oraz możliwych skutków regulacyjnych i reputacyjnych. Dodatkowym problemem jest stosowanie narzędzi podszywających się pod legalne komponenty VMware, co znacząco utrudnia detekcję.
Rekomendacje
Organizacje korzystające z VMware vCenter powinny potraktować ten typ incydentów priorytetowo i połączyć działania naprawcze z aktywnym poszukiwaniem oznak kompromitacji.
- Niezwłocznie wdrożyć poprawki bezpieczeństwa dla wszystkich instancji vCenter i VCSA.
- Sprawdzić obecność nietypowych plików w katalogach cron, nowych usług systemd, nieautoryzowanych kluczy SSH i podejrzanych plików JSP.
- Przeanalizować logi CROND, shell history, zdarzenia API vSphere oraz operacje katalogowe vmdir.
- Zweryfikować nowe konta w vSphere, SSO, LDAP i na hostach ESXi.
- Przeprowadzić rotację haseł i sekretów po wykryciu jakichkolwiek oznak naruszenia.
- Ograniczyć ekspozycję vCenter do Internetu, wdrożyć segmentację sieci i dostęp uprzywilejowany przez bastion.
- Przygotować odseparowane kopie zapasowe oraz procedury izolacji i odbudowy hostów ESXi i VCSA.
Podsumowanie
Kampania wykorzystująca CVE-2026-59310 pokazuje, jak szybko krytyczne luki w systemach zarządzania wirtualizacją są uzbrajane przez zaawansowanych napastników. W tym przypadku exploit przeciwko VMware vCenter prowadził do wykonania kodu jako root, wdrożenia backdoora, kradzieży poświadczeń, tworzenia kont administracyjnych i ostatecznie do infekcji hostów ESXi ransomwarem pochodnym od Babuk.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że vCenter należy traktować jako zasób o najwyższym priorytecie ochrony. Szybkie łatanie, monitoring kont uprzywilejowanych, analiza artefaktów trwałości oraz ograniczenie ekspozycji administracyjnej pozostają kluczowe dla zminimalizowania skutków podobnych operacji.