Wat de wereldwijde VMware vCenter-campagne onthult over CVE-2026-59310

In de praktijk kan een blootgestelde vCenter-appliance zo veranderen in een toegangspoort tot de virtuele infrastructuur. Meldingen over de campagne beschrijven code-uitvoering in de rootcontext van de appliance. De meest gezaghebbende beschrijvingen van Broadcom en de NVD bevestigen in elk geval het risico op willekeurige code-uitvoering, zonder alle rechten en stappen van elke afzonderlijke inbraak volledig vast te leggen.

Broadcom heeft oplossingen uitgebracht, maar geen workaround beschikbaar gesteld. Het installeren van de door de leverancier genoemde updates is daarom de officiële herstelmaatregel.

Patch beschikbaar, aanval vijf dagen later

Broadcom publiceerde de kwetsbaarheid en de patches op 29 juli. QUIRSO meldde aanwijzingen voor actieve uitbuiting vanaf 3 augustus, waarna de campagne snel uitbreidde.

Die tijdlijn is belangrijk voor incidentrespons. Een systeem dat na 3 augustus is gepatcht, is niet automatisch schoon. Organisaties moeten twee zaken uit elkaar houden: het dichten van de kwetsbaarheid en het vaststellen van een mogelijke inbraak. Installeer de patch, maar onderzoek daarna ook of aanvallers al toegang hadden verkregen of persistentie hadden ingericht.

De omvang van de campagne

Onderzoekers brachten de activiteit in verband met 361 waargenomen IP-adressen in 47 landen. Duitsland, de Verenigde Staten, Turkije, Iran en Frankrijk zouden samen meer dan de helft van de waargenomen systemen vertegenwoordigen.

Dat cijfer vraagt om enige nuance. Eén IP-adres staat niet noodzakelijk voor één organisatie. Er is dus geen bewijs dat precies 361 bedrijven of instellingen zijn getroffen. De beschikbare meldingen wijzen wel op een brede campagne tegen via internet of andere netwerken bereikbare vCenter-systemen.

Waarom onderzoekers spreken van een China-link

QUIRSO beoordeelde de mogelijke China-link met matige zekerheid. De genoemde aanwijzingen zijn onder meer Chineestalige artefacten, tooling en publiek hergebruikte onderzoeksinformatie, activiteit die past bij werktijden in UTC+08:00 en een slachtoffergroep waarin het Chinese vasteland volgens de onderzoekers leek te ontbreken.

Deze signalen ondersteunen een regionale of taalkundige beoordeling, maar identificeren geen specifieke Chinese staatsgroep en bewijzen geen aansturing door een overheid. Attributie op basis van malwarekenmerken, tijdspatronen en doelwitten kan bovendien veranderen wanneer nieuw bewijs beschikbaar komt. De meest zorgvuldige omschrijving blijft daarom: een vermoedelijke actor met een China-link, niet een bevestigde staatsgesteunde operatie.

Zo verliep de gemelde aanval

Volgens de beschikbare meldingen werd CVE-2026-59310 gebruikt voor de eerste code-uitvoering. Daarna bouwden de aanvallers verschillende lagen van persistentie en toegang op:

1. Directory traversal: speciaal samengestelde verzoeken aan de Syslog-service werden gebruikt om het bedoelde pad te verlaten en inhoud onder controle van de aanvaller weg te schrijven.
2. Persistentie via cron: de aanvallers zouden gemanipuleerde cron-vermeldingen hebben aangemaakt, zodat geplande taken vervolgopdrachten konden starten.
3. Aflevering van een backdoor: met curl of wget werd volgens de meldingen een via WebSocket werkende en met XOR versleutelde linuxFile-backdoor opgehaald.
4. Reverse SSH: reverse-SSH-tooling zorgde voor uitgaande verbindingen terug naar infrastructuur van de aanvallers. Shadowserver meldde dat dit persistentiemechanisme op alle slachtoffers in zijn speciale rapport werd aangetroffen.
5. Misbruik van accounts en toegangsgegevens: onderzoekers meldden ongeautoriseerde vCenter- en ESXi-beheerdersaccounts en misbruik van inloggegevens voor VMware Directory Service.
6. Inzet van ransomware: ten minste een deel van de meldingen koppelde de activiteit aan een van Babuk afgeleide ransomwarevariant die bestanden de extensie .babyk geeft.

Voor beheerders is vooral de reverse-SSH-bevinding van belang. Volgens Shadowserver moeten systemen waarop dit mechanisme is geplaatst als volledig gecompromitteerd worden beschouwd. Alleen een bestand verwijderen of een cron-taak wissen is geen afdoende herstel. De betrouwbaarheid van de appliance moet opnieuw worden vastgesteld en bevoorrechte wachtwoorden en sleutels moeten worden vervangen.

Was de ransomware vooral bedoeld om sporen uit te wissen?

De gemelde .babyk-activiteit wijst niet noodzakelijk op een klassieke ransomwarecampagne die primair gericht was op grootschalige versleuteling en afpersing. Analisten opperden dat selectieve versleuteling van ESXi-logbestanden bedoeld kan zijn geweest om onderzoek te bemoeilijken en bewijs te verbergen.

Dat blijft een interpretatie en geen bevestigde verklaring van de aanvallers. Verdedigers moeten daarom beide scenario’s onderzoeken: de mogelijke gevolgen van ransomware voor virtuele machines én doelbewuste manipulatie van logbestanden om de inbraak te verhullen.

Reverse-SSH-tooling vermomd op GitHub

Meldingen brachten de operatie ook in verband met een GitHub-repository waarop reverse-SSH-binaries werden gepresenteerd als een Linux-hulpprogramma voor het opruimen van tijdelijke bestanden. Een persistentietool vermommen als een administratief of opschoningsprogramma kan verspreiding vereenvoudigen en de tool minder opvallend maken bij routinecontroles. De beschikbare informatie bewijst niet zelfstandig wie de repository beheerde. Het bestaan ervan is daarom geen bewijs voor attributie.

Gevolgen voor Broadcom

Het aandeel Broadcom daalde op 14 augustus ongeveer 5 tot 6 procent toen berichten over actieve uitbuiting van VMware vCenter beleggers bereikten. Eén verslag beschreef een beweging van 417,82 dollar naar 392,99 dollar tijdens die handelsdag.

De beveiligingsmeldingen waren een factor in de koersdaling, maar waarschijnlijk niet de enige. In dezelfde berichtgeving werden ook bredere zorgen genoemd, waaronder de schuldenlast rond kunstmatige intelligentie. Het is daarom niet verantwoord om de volledige koersbeweging of een exact bedrag aan verloren beurswaarde uitsluitend aan CVE-2026-59310 toe te schrijven.

Er is in de beschikbare berichtgeving onvoldoende bewijs voor een meetbare daling van de VMware-omzet als gevolg van de campagne. De meest aannemelijke directe bedrijfseffecten zijn kosten voor klantremediatie, risico op operationele verstoring en reputatiedruk. Voor een structureel effect op de omzet zijn bedrijfsmededelingen of aanvullende financiële gegevens nodig.

Wat vCenter-beheerders nu moeten doen

P patchen is noodzakelijk, maar niet het laatste woord. Organisaties zouden de volgende stappen moeten nemen:

1. Installeer onmiddellijk de vaste releases van Broadcom op iedere getroffen vCenter-instantie. Geef prioriteit aan systemen die rechtstreeks vanaf internet bereikbaar zijn of vanuit brede interne netwerken kunnen worden benaderd. Broadcom noemt geen workaround.
2. Ga bij indicatoren uit van een inbraak. Let onder meer op onverwachte wijzigingen in cron, reverse-SSH-artefacten, linuxFile, onverklaarde downloads via curl of wget, onbekende vCenter- of ESXi-beheerders en afwijkende activiteit in VMware Directory Service.
3. Isoleer verdachte appliances en bewaar, waar operationeel haalbaar, schijfimages, logbestanden en vluchtige gegevens voordat systemen opnieuw worden opgebouwd.
4. Vervang alle bevoorrechte toegangsgegevens, waaronder vCenter SSO, VMware Directory Service, ESXi- en rootaccounts, API- en serviceaccounts en gekoppelde beheerdersaccounts. Trek actieve sessies in en controleer federatieve verbindingen.
5. Bouw bevestigde compromitteringen opnieuw op in plaats van systemen alleen op te schonen. Verwijder ongeautoriseerde accounts, cron-taken, binaries, SSH-sleutels en tunnels als onderdeel van een gedocumenteerd incidentresponsproces.
6. Onderzoek de volledige virtuele infrastructuur op .babyk-activiteit, onverwachte uitgaande SSH- of WebSocket-verbindingen, onbekende accounts en aanwijzingen voor manipulatie van ESXi-logs.
7. Herstel betrouwbare logging en configuraties uit bekende, onveranderbare back-ups wanneer logbestanden of instellingen zijn gewijzigd.
8. Beperk toekomstige blootstelling door vCenter-beheer uitsluitend toe te staan vanaf gescheiden beheernetwerken en uitgaande verbindingen vanaf vCenter- en ESXi-hosts actief te monitoren.

De kern voor organisaties is eenvoudig: update iedere kwetsbare vCenter-installatie, maar beschouw een geslaagde patch niet als bewijs dat de omgeving schoon is. De combinatie van snelle uitbuiting, reverse SSH en gemeld misbruik van beheerdersgegevens betekent dat blootgestelde appliances moeten worden onderzocht als mogelijke volledige compromitteringen.