CVE-2026-59310: Útok na VMware vCenter zasáhl 361 IP adres ve 47 zemích

Broadcom vydal opravené verze, ale neposkytl žádné náhradní řešení. Oficiální nápravou je proto instalace aktualizací uvedených výrobcem.

Oprava byla dostupná dříve než útok

Broadcom chybu zveřejnil a opravy vydal 29. července. Společnost QUIRSO následně informovala o známkách aktivního zneužívání od 3. srpna a o rychlém rozšíření kampaně.

Tato časová posloupnost je důležitá pro reakci na incident. Systém aktualizovaný po 3. srpnu nelze automaticky považovat za čistý jen proto, že aktualizace proběhla úspěšně. Správci musí oddělit dvě úlohy: odstranit zranitelnost a ověřit, zda útočník před instalací opravy nezískal přístup.

Rozsah kampaně: 361 IP adres ve 47 zemích

Výzkumníci spojili aktivitu s 361 pozorovanými IP adresami ve 47 zemích. Německo, Spojené státy, Turecko, Írán a Francie měly podle dostupných zpráv představovat více než polovinu sledovaného souboru.

Čísla je ale třeba interpretovat opatrně. Jedna IP adresa nemusí znamenat jednu firmu nebo instituci, takže 361 IP adres není důkazem 361 samostatných obětí. Dostupná zjištění přesto ukazují na rozsáhlou kampaň proti systémům vCenter dostupným z internetu nebo vystaveným z jiných sítí.

Proč se mluví o vazbě na Čínu

QUIRSO vyhodnotila vazbu kampaně na Čínu s mírnou mírou jistoty. Mezi uváděné indicie patří artefakty v čínštině, používané nástroje a veřejně recyklovaný výzkum, aktivita odpovídající pracovní době v časovém pásmu UTC+08:00 a struktura obětí, z níž podle všeho vypadla pevninská Čína.

Tyto indicie podporují regionální nebo jazykové hodnocení, samy o sobě však neidentifikují konkrétní čínskou státní skupinu ani nedokazují řízení operace vládou. Přisuzování útoků na základě malwarových artefaktů, časových vzorců a výběru cílů se může s novými důkazy změnit. Nejpřesnější je proto hovořit o „aktérovi s podezřelou vazbou na Čínu“, nikoli o potvrzené státem sponzorované operaci.

Jak podle výzkumníků útok probíhal

Kampaň zřejmě využila CVE-2026-59310 ke spuštění kódu a následně do napadených systémů nasadila několik vrstev persistence a vzdáleného přístupu:

1. Directory traversal: Speciálně vytvořené požadavky na službu Syslog umožnily opustit určenou cestu a zapsat obsah ovládaný útočníkem.
2. Perzistence přes cron: Útočníci údajně vytvořili poškozené nebo nestandardní záznamy v cronu, aby plánované úlohy spouštěly další příkazy.
3. Doručení backdooru: Podle popisů průniků nástroje curl nebo wget stáhly backdoor linuxFile využívající WebSocket a XOR obfuskaci.
4. Reverse SSH: Útočníci nainstalovali nástroje pro reverse SSH, které vytvářejí odchozí spojení zpět k infrastruktuře útočníka. Shadowserver uvedl, že tento mechanismus persistence byl nalezen u všech obětí v jeho zvláštní zprávě.
5. Zneužití účtů a přihlašovacích údajů: Vyšetřovatelé popsali neoprávněné účty administrátorů vCenter a ESXi i zneužití přihlašovacích údajů služby VMware Directory Service.
6. Nasazení ransomwaru: Některé zprávy aktivitu spojily s variantou ransomwaru odvozenou od Babuku, která přidává příponu .babyk.

Nejdůležitějším zjištěním je reverse SSH. Podle závěru Shadowserveru je nutné systémy, na nichž byl tento mechanismus nasazen, považovat za plně kompromitované. Samotné odstranění binárního souboru nebo smazání úlohy v cronu nestačí. Obnova musí zahrnovat obnovení důvěry v zařízení a změnu privilegovaných přihlašovacích údajů.

Ransomware mohl sloužit i k zahlazování stop

Aktivita spojená s příponou .babyk nemusí představovat klasickou ransomwarovou kampaň zaměřenou především na plošné šifrování a vydírání. Analytici se domnívají, že selektivní šifrování logů ESXi mohlo narušit vyšetřování a zakrýt důkazy o průniku.

Jde však o odhad, nikoli o potvrzené vyjádření útočníků. Obránci by proto měli prověřit obě možnosti: dopad ransomwaru na virtuální stroje i záměrné pozměňování nebo ničení logů s cílem ztížit forenzní analýzu.

Nástroje maskované na GitHubu

Zprávy rovněž spojily operaci s repozitářem na GitHubu, který binární soubory reverse SSH vydával za nástroj pro čištění dočasných souborů v Linuxu. Maskování nástroje pro udržení přístupu za administrativní nebo úklidový program může usnadnit jeho šíření a snížit šanci, že bude při běžné kontrole odhalen. Dostupné důkazy však samy o sobě neprokazují, kdo repozitář provozoval, takže jeho existence není důkazem připsání útoku konkrétnímu aktérovi.

Dopad na Broadcom a VMware

Akcie Broadcomu 14. srpna klesly přibližně o 5 až 6 % v době, kdy se mezi investory rozšířily zprávy o aktivním zneužívání VMware. Jeden z popisů uvádí pokles z 417,82 na 392,99 dolaru během dané seance.

Bezpečnostní zprávy byly jedním z faktorů poklesu, nikoli však nutně jediným. Současná tržní publicita zmiňovala také širší obavy, mimo jiné zadlužení spojené s umělou inteligencí. Nebylo by proto přesné připsat celou změnu ceny akcií nebo konkrétní výši ztracené tržní hodnoty výhradně chybě CVE-2026-59310.

Dostupné zprávy neposkytují dostatek důkazů k závěru, že kampaň už způsobila měřitelný pokles tržeb VMware. Bezprostřednějšími a lépe doložitelnými dopady jsou náklady zákazníků na nápravu, riziko provozních výpadků a reputační tlak. Případný dlouhodobější dopad na tržby by vyžadoval firemní zveřejnění nebo další finanční podklady.

Co mají správci vCenter udělat

Aktualizace je první krok, nikoli konec řešení. Organizace by měly:

1. Okamžitě nainstalovat opravené verze Broadcomu na všechny dotčené instance vCenter a přednostně aktualizovat systémy dostupné z internetu nebo z rozsáhlých interních sítí. Broadcom neuvádí žádné náhradní řešení.
2. Považovat systém za kompromitovaný, pokud se objeví indikátory průniku, například nečekané změny cronu, artefakty reverse SSH, soubor linuxFile, nevysvětlená stažení přes curl nebo wget, neznámé účty administrátorů vCenter či ESXi nebo podezřelá aktivita VMware Directory Service.
3. Izolovat podezřelá zařízení vCenter a před případnou obnovou uchovat obrazy disků, logy a volatilní důkazy, pokud to provozní situace dovolí.
4. Změnit privilegované přihlašovací údaje, včetně účtů vCenter SSO, VMware Directory Service, ESXi nebo root, API účtů, servisních účtů a propojených administrátorských účtů. Zneplatnit aktivní relace a prověřit federované přístupy.
5. Systémy s potvrzenou persistencí raději znovu sestavit než pouze „vyčistit“. Odstranění neoprávněných účtů, úloh cronu, binárních souborů, klíčů SSH a tunelů musí být součástí zdokumentované reakce na incident.
6. Prověřit celou virtualizovanou infrastrukturu kvůli aktivitě .babyk, neočekávaným odchozím spojením SSH nebo WebSocket, neznámým účtům a známkám manipulace s logy ESXi.
7. Obnovit důvěryhodná data a telemetrii ze známých, neměnných záloh, pokud byly logy nebo konfigurace pozměněny.
8. Omezit budoucí vystavení systémů tím, že přístup ke správě vCenter přesunete do segmentovaných administračních sítí a budete sledovat odchozí spojení ze systémů vCenter a ESXi.

Závěr

Každý zranitelný systém vCenter je nutné aktualizovat, ale úspěšná instalace opravy neznamená, že je prostředí čisté. Kombinace rychlého zneužití, persistence přes reverse SSH a hlášeného zneužití přihlašovacích údajů znamená, že správci by měli vystavená zařízení prověřovat jako potenciálně plně kompromitovaná.