Sajber bezbednost
Upadi u VMware vCenter i Babuk-slican ransomware pokazuju zasto samo patch prozor nije dovoljan

Novo izvestavanje o zloupotrebi VMware vCenter-a pokazuje neprijatnu istinu za infrastrukturne timove: najopasniji period nije samo pre nego sto zakrpa postoji, nego i u danima odmah posle njenog izlaska. U opisanom lancu napada akteri sa verovatnim China-nexus poreklom iskoristili su sveze zakrpljene vCenter slabosti, dobili duboku kontrolu nad appliance-om i zatim otvorili put ka Babuk-slicnom ransomware-u na nizvodnoj infrastrukturi. Za firme koje vCenter tretiraju kao obican admin sistem, ovo je podsetnik da virtualizaciona kontrolna ravan spada u najosetljivije tacke cele platforme.
Operativno je vazna kombinacija tehnika. Po javnim nalazima, kampanja je koristila CVE-2026-59310 za remote code execution, uz tragove aktivnosti oko CVE-2026-59309, dok su napadaci istovremeno prikrivali tragove VMware-slicnim imenima, zloupotrebljavali cron, ubacivali backdoor-e i pravili privilegovane naloge. To nije jednostavan upad i bekstvo. To vise lici na plansku kompromitaciju management sloja sa ciljem da se pristup zadrzi, prosiri i iskoristi kasnije za destruktivne ili ucene radnje.
Zasto je ovo mnogo vise od jednog vCenter patcha
Kompromitovan vCenter retko ostaje samo problem jednog hosta. On stoji blizu ESXi administracije, vidljivosti workload-a, poverenja naloga i automatizacije koja dodiruje veliki deo okruzenja. Kada napadac dodje do tog sloja, cesto moze da predje sa management pristupa na akcije koje pogadjaju mnogo sistema pod centralnom kontrolom. Zato je post-exploitation higijena podjednako vazna kao i samo patchovanje.
- vCenter je kontrolna tacka visokog uticaja pa kompromitacija moze da se prelije na veliki broj hostova i workload-a.
- Perzistencija kroz cron i lazno predstavljanje servisa otezavaju ciscenje vise nego obicno uklanjanje IOC-eva.
- Novi admin nalozi i kradja kredencijala mogu ostaviti pristup zivim i kada je pocetni ulaz zatvoren.
- Ransomware nad ESXi okruzenjem ili povezanom infrastrukturom pretvara platformski problem u poslovni incident kontinuiteta.
Sta virtualizacioni i security timovi treba odmah da urade
1) Patch tretirati kao pocetak odgovora, ne kao kraj
Ako je tim zakrpio ranjive vCenter sisteme, to je neophodno ali nije dovoljno. Treba pregledati period izmedju objave propusta i implementacije zakrpe, sacuvati logove sa pratecih sistema dok jos postoje i traziti neobicne cron jobove, sumnjive nazive servisa, neocekivano kreiranje administratora, web shell-ove i outbound konekcije sa appliance-a. Zakrpljen, ali vec kompromitovan vCenter ostaje stratesko uporiste napadaca.
2) Ponovo proveriti putanje poverenja od vCenter-a ka ESXi-ju i identity sistemima
Opisane aktivnosti ukljucuju manipulaciju nalozima i tehnike koje podrzavaju dalje sirenje kroz virtualizacioni sloj. Zato treba proveriti lokalne naloge na ESXi hostovima, pregledati privilegovane grupe, rotirati izlozene kredencijale gde je moguce i analizirati API aktivnost povezanu sa vSphere otkrivanjem i daljinskom administracijom. Incident response mora obuhvatiti ceo management lanac, ne samo jedan image appliance-a.
3) Spremiti se za destruktivne naredne korake
Babuk-slicna enkripcija jeste naslov, ali je veca lekcija da kompromitacija management sloja veoma brzo moze prerasti u recovery krizu. Proverite immutable backup-e, testirajte korake vracanja hostova, potvrdite da su offline kopije zaista izolovane i proverite da recovery runbook-ovi ne zavise od iste management platforme koja moze biti kompromitovana. Timovi te rupe obicno otkriju tek kada je vec kasno.
Hitna response checklista
| Patch status | Eksploatacija je krenula vrlo brzo posle javnog otkrivanja | Potvrditi da je svaki internet-izlozen i interni vCenter na ispravljenoj verziji i odmah dokumentovati zaostatke |
|---|---|---|
| Provera perzistencije | cron zloupotreba i lazna imena servisa mogu preziveti prvo ciscenje | Traziti sumnjive cron fajlove, systemd izmene, JSP fajlove i neovlasceno kreiranje admin naloga |
| Identity i API aktivnost | Kompromitacija vCenter-a moze se preliti na sire kontrolne putanje | Pregledati SSO clanstva, discovery pozive i nove lokalne ili directory-backed administratore |
| ESXi i workload uticaj | Blast radius moze ici dalje od appliance-a | Proveriti ESXi hostove na rogue naloge, ransomware tragove i neocekivane alate za daljinski pristup |
| Recovery spremnost | Incident u management sloju lako postaje platformski zastoj | Validirati integritet backup-a, redosled oporavka i offline restore opcije pre narednog incidenta |
Zakljucak
Ova VMware vCenter kampanja je korisno upozorenje za enterprise operatere zato sto pokazuje koliko brzo zakrpljiv propust moze prerasti u siri kompromis platforme. Security i infrastrukturni timovi zato ne smeju da se zaustave na proveri verzije. Potrebni su hunting nad management slojem, pregled kredencijala, provera ESXi posledica i recovery planiranje pod pretpostavkom da je napadac pokusavao da dobije trajan i dubok pristup mnogo pre nego sto se ransomware pojavio kao vidljivi signal.

