VMware vCenter -haavoittuvuutta hyödynnettiin vain viisi päivää korjauksen jälkeen

Broadcom julkaisi korjatut versiot, mutta ei kiertotapaa. Virallinen korjaus on siten toimittajan ilmoittamien päivitysten asentaminen.

Hyökkäykset alkoivat viisi päivää korjauksen jälkeen

Broadcom ilmoitti haavoittuvuudesta ja julkaisi korjaukset 29. heinäkuuta. QUIRSO raportoi aktiivisen hyväksikäytön merkkejä 3. elokuuta, minkä jälkeen kampanja laajeni nopeasti.

Aikajana on tärkeä myös tapahtumien jälkiselvityksessä. Jos järjestelmä päivitettiin vasta 3. elokuuta jälkeen, onnistunut päivitys ei vielä osoita ympäristöä puhtaaksi. Haavoittuvuuden korjaaminen ja mahdollisen murtautumisen selvittäminen ovat kaksi eri tehtävää: ensin vika on paikattava, minkä jälkeen on tutkittava, ehtikö hyökkääjä muodostaa järjestelmään pysyvän pääsyn.

361 IP-osoitetta 47 maassa

Tutkijat yhdistivät toimintaan 361 havaittua kohteena ollutta IP-osoitetta 47 maassa. Saksan, Yhdysvaltojen, Turkin, Iranin ja Ranskan kerrotaan muodostaneen yli puolet havaituista kohteista.

Lukua on tulkittava varoen: yksi IP-osoite ei välttämättä vastaa yhtä organisaatiota. Siksi 361 IP-osoitetta ei tarkoita varmasti 361:tä eri yritystä tai laitosta. Raportit osoittavat silti laajaa kampanjaa, joka kohdistui internetiin tai muuten verkkoon paljastettuihin vCenter-järjestelmiin.

Miksi tutkijat puhuvat Kiina-yhteydestä?

QUIRSO arvioi kampanjalla olevan Kiina-yhteys kohtalaisella varmuudella. Arvion taustalla ovat muun muassa kiinankieliset artefaktit, työkalut ja julkisesti uudelleen käytetty tutkimusmateriaali, UTC+08.00-aikavyöhykkeen työaikoja muistuttava toiminta sekä kohdejoukko, josta Manner-Kiinan järjestelmät näyttivät puuttuvan.

Havainnot tukevat alueellista tai kielellistä arviota, mutta ne eivät nimeä tiettyä kiinalaista valtiollista ryhmää eivätkä todista viranomaisten ohjausta. Attribuutio voi muuttua uuden näytön myötä. Varovaisin kuvaus onkin ”epäilty Kiina-yhteyksinen toimija”, ei vahvistettu valtiollinen operaatio.

Raportoitu hyökkäysketju

Kampanja näyttää käyttäneen CVE-2026-59310:tä alkuperäiseen koodin suorittamiseen ja asentaneen sen jälkeen useita pysyvyyden ja etäkäytön kerroksia:

1. Hakemistopolun ylitys: Syslog-palvelulle lähetetyillä muotoilluilla pyynnöillä pyrittiin poistumaan tarkoitetusta hakemistosta ja kirjoittamaan hyökkääjän hallitsemaa sisältöä.
2. Cron-pysyvyys: Hyökkääjät loivat raporttien mukaan virheellisiä cron-merkintöjä, joiden avulla seuraavat komennot voitiin käynnistää ajastetusti.
3. Takaoven toimitus: curl- tai wget-komennoilla ladattiin WebSocket-yhteyttä käyttävä ja XOR:lla obfuskoitu linuxFile-takaovi.
4. Käänteinen SSH: Järjestelmiin asennettiin reverse SSH -työkaluja, jotka muodostivat ulospäin lähtevän yhteyden hyökkääjän infrastruktuuriin. Shadowserverin mukaan mekanismi löytyi kaikilta sen erityisraportissa käsitellyiltä uhreilta.
5. Tunnusten ja tilien väärinkäyttö: Tutkijat raportoivat luvattomista vCenter- ja ESXi-ylläpitäjätileistä sekä VMware Directory Service -tunnusten väärinkäytöstä.
6. Lunnasohjelma: Ainakin osa raporteista yhdisti toimintaan Babukista johdetun lunnasohjelmaversion, joka lisää tiedostojen perään .babyk-tunnisteen.

Käänteinen SSH-yhteys on havaintona erityisen merkittävä. Shadowserverin johtopäätöksen mukaan järjestelmät, joihin tämä mekanismi on asennettu, on käsiteltävä täysin vaarantuneina. Yksittäisen binääritiedoston tai cron-tehtävän poistaminen ei riitä palauttamaan luottamusta laitteeseen, vaan myös etuoikeutetut tunnukset on vaihdettava ja järjestelmä on tarvittaessa rakennettava uudelleen.

Oliko lunnasohjelma myös jälkien peittämistä?

Raportoitu .babyk-toiminta ei välttämättä ollut perinteinen lunnasohjelmakampanja, jonka päätavoitteena on laaja salaus ja kiristys. Analyytikot ovat esittäneet, että ESXi-lokien valikoivalla salaamisella saatettiin vaikeuttaa tutkintaa ja peittää todisteita.

Kyse on kuitenkin päätelmästä, ei vahvistetusta tiedosta hyökkääjien tarkoituksesta. Puolustajien kannattaa tutkia molemmat vaihtoehdot: virtuaalikoneisiin kohdistuneet lunnasohjelmavaikutukset sekä tarkoituksellinen lokien muuttaminen tunkeutumisen peittämiseksi.

GitHubissa työkalu naamioitiin puhdistusohjelmaksi

Raporttien mukaan operaatioon liittyi myös GitHub-repositorion sisältöä, jossa reverse SSH -binäärit esitettiin Linuxin väliaikaistiedostojen puhdistustyökaluna. Pysyvyystyökalun naamioiminen ylläpito- tai puhdistusohjelmaksi voi helpottaa sen jakelua ja tehdä siitä vähemmän epäilyttävän tavanomaisissa tarkistuksissa. Saatavilla oleva näyttö ei kuitenkaan yksin vahvista, kuka repositorion takana oli, joten sen olemassaoloa ei pidä käyttää attribuution todisteena.

Vaikutus Broadcomiin ja VMware-liiketoimintaan

Broadcomin osake laski noin 5–6 prosenttia 14. elokuuta, kun tiedot VMware-haavoittuvuuden aktiivisesta hyväksikäytöstä saavuttivat sijoittajat. Erään raportin mukaan kurssi liikkui saman kaupankäyntipäivän aikana 417,82 dollarista 392,99 dollariin.

Tietoturvaraportit olivat yksi laskuun vaikuttanut tekijä, mutta eivät välttämättä ainoa. Samanaikaisissa uutisissa mainittiin myös laajempia huolia, kuten tekoälyhankkeisiin liittyvä velkariski. Siksi koko kurssilaskua tai tarkkaa markkina-arvon menetystä ei ole perusteltua kohdistaa yksin CVE-2026-59310:een.

Saatavilla oleva näyttö ei riitä osoittamaan, että kampanja olisi jo aiheuttanut mitattavan laskun VMware-liikevaihtoon. Lyhyellä aikavälillä uskottavimpia vaikutuksia ovat asiakkaiden korjauskustannukset, toimintahäiriöiden riski ja mainehaitta. Pidemmän aikavälin liikevaihtovaikutukset vaatisivat yhtiön omia ilmoituksia tai muuta taloudellista näyttöä.

Mitä vCenter-ylläpitäjien kannattaa tehdä?

Päivitys on vasta ensimmäinen askel. Organisaatioiden tulisi:

1. Asentaa Broadcomin korjatut versiot välittömästi kaikkiin vaikutuksen alaisiin vCenter-instansseihin. Etusijalle on asetettava internetiin näkyvät järjestelmät ja laitteet, joihin pääsee laajoista sisäverkoista. Broadcom ei ilmoita kiertotapaa.
2. Olettaа järjestelmä vaarantuneeksi, jos merkkejä löytyy, kuten odottamattomia cron-muutoksia, reverse SSH -artefakteja, linuxFile-tiedostoja, selittämättömiä curl- tai wget-latauksia, tuntemattomia vCenter- tai ESXi-ylläpitäjiä tai poikkeavaa VMware Directory Service -toimintaa.
3. Eristää epäilyttävät laitteet ja säilyttää levykuvat, lokit sekä haihtuva todistusaineisto ennen uudelleenrakentamista, jos se on toiminnan kannalta mahdollista.
4. Vaihtaa kaikki etuoikeutetut tunnukset, mukaan lukien vCenter SSO-, VMware Directory Service-, ESXi- ja root-tunnukset sekä API-, palvelu- ja yhdistetyt ylläpitotunnukset. Aktiiviset istunnot on mitätöitävä ja federaatiopolut tarkistettava.
5. Rakentaa vahvistetusti vaarantuneet järjestelmät uudelleen sen sijaan, että niitä vain ”siivotaan”. Luvattomien tilien, cron-tehtävien, binäärien, SSH-avainten ja tunnelien poistamisen on oltava osa dokumentoitua tietoturvaloukkausten käsittelyä.
6. Etsiä merkkejä koko virtualisoidusta infrastruktuurista, kuten .babyk-tiedostoja, odottamattomia SSH- tai WebSocket-yhteyksiä, luvattomia tilejä ja ESXi-lokien muuttamista.
7. Palauttaa luotettava telemetria ja data tunnetusti puhtaista, muuttumattomista varmuuskopioista, jos lokit tai määritykset ovat muuttuneet.
8. Pienentää tulevaa altistumista rajaamalla vCenterin hallinta eriytettyihin ylläpitoverkkoihin ja valvomalla vCenterin sekä ESXi-isäntien ulospäin suuntautuvaa liikennettä.

Käytännön johtopäätös on yksinkertainen: päivitä jokainen haavoittuva vCenter-järjestelmä, mutta älä pidä onnistunutta päivitystä todisteena puhtaasta ympäristöstä. Nopea hyväksikäyttö, pysyväksi tarkoitettu käänteinen SSH-yhteys ja raportoidut tunnusväärinkäytökset tarkoittavat, että altistuneet laitteet on tutkittava mahdollisina täydellisinä vaarantumisina.