Cybersecurity-onderzoekers hebben de exploitatie van een nieuw gepatcht beveiligingslek in Broadcom VMware vCenter toegeschreven aan een vermoedelijke China-nexus Advanced Persistent Threat (APT).
Bij de aanvallen wordt misbruik gemaakt van CVE-2026-59310 (CVSS-score: 9,8), een ernstige kwetsbaarheid bij directory-traversal in de VMware vCenter-server die door een kwaadwillende kan worden bewapend om willekeurige code uit te voeren. Een oplossing voor de fout werd op 29 juli 2026 door Broadcom vrijgegeven.
Het Duitse incidentresponsbedrijf QUIRSO oordeelde met gematigd vertrouwen dat de exploitatiecampagne gericht op CVE-2026-59310 wordt uitgevoerd door een Chineessprekende dreigingsacteur, waarschijnlijk werkzaam in de tijdzone UTC+08:00, die voornamelijk wordt gebruikt in Chineessprekende regio’s.
“Deze beoordeling is gebaseerd op de convergentie van Chineestalige artefacten in door de aanvaller gemaakte scripts, schijnbaar hergebruik van onderzoek uit een Chinese beveiligingspublicatie, herhaald operationeel gebruik van Chineestalige tools en beheersoftware, slachtofferschap met uitzondering van het vasteland van China, en activiteitspatronen die compatibel zijn met UTC+08:00 werkuren”, aldus QUIRSO-onderzoekers Maike Orlikowski, Çağatay Yürekli en Denis Szadkowski.
De activiteit, die vijf kalenderdagen na de publieke bekendmaking van de fout begon, heeft naar schatting 361 unieke IP-adressen van slachtoffers in 47 landen in gevaar gebracht, waarbij de meeste infecties verspreid waren over Duitsland (55), de VS (41), Turkije (38), Iran (26) en Frankrijk (25).
Exploitatie van CVE-2026-59309
Eén gecompromitteerde vCenter Server Appliance, geanalyseerd door QUIRSO, zou het doelwit zijn geweest van zowel CVE-2026-59310 als CVE-2026-59309, een authenticatie-bypass die ook getuige is geweest van actieve scaninspanningen. Er zijn aanwijzingen dat kwaadwillige activiteiten consistent zijn met de exploitatie van CVE-2026-59309 al op 1 augustus 2026, gevolgd door het aanmaken van een beheerdersaccount op vCenter.
Dat gezegd hebbende, zijn er geen inloggebeurtenissen waargenomen voor het legitieme beheerdersaccount dat werd gebruikt om dit nieuwe account aan te maken. Het aanmaken van het account was afkomstig van het IP-adres 146.59.252(.)178 en omvatte ook vSphere-detectie via de REST API op 3 augustus met behulp van User-Agent-strings zoals “GoodMoodle-VCFleet/1.0”, in een poging het voor te doen als VMware-gerelateerde activiteit.
Het is vermeldenswaard dat VCF Fleet een gecentraliseerde beheermogelijkheid is die door Broadcom is geïntroduceerd in VMware Cloud Foundation (VCF) versie 9.0 om meerdere VCF-instanties te implementeren, schalen, patchen en bedienen. Het omvat meerdere componenten, waaronder VCF Operations, VCF Automation, vCenter, NSX Manager, vSphere Cluster en werklastdomeinen.
QUIRSO zei dat er geen overlap is tussen deze activiteit en de reeks gebeurtenissen met betrekking tot misbruik van CVE-2026-59310 op hetzelfde systeem vanaf 3 augustus, waarbij werd toegevoegd dat het nieuw aangemaakte “vcenter_admin” beheerdersaccount niet werd gebruikt in de daaropvolgende fasen van de aanval.
Exploitatie van CVE-2026-59310
Wat de exploitatie van CVE-2026-59310 betreft, betrof de eerste activiteit de cron daemon (ook bekend als crond) die een verkeerd ingedeeld cron-bestand registreerde met de naam “zz-poc59310-syslog.log.” In de volgende stap wordt een curl-opdracht (of als alternatief een wget-opdracht) uitgevoerd om een achterdeur uit “5.34.177(.)38:9861” op te halen en uit te voeren, en vervolgens het logbestand te verwijderen.
De naamgevingsconventie van het logbestand is belangrijk omdat het een directe verwijzing is naar de CVE-identificator en omdat het een proof-of-concept (PoC) was, bedacht nadat de details van de fout publiekelijk bekend waren geworden.
“Het achtervoegsel ‘-syslog.log’ weerspiegelt ook de naamgevingsconventie voor externe syslog-bestanden van vCSA, maar het bestand verschijnt onder /etc/cron.d in plaats van in de geconfigureerde syslog-uitvoermap”, legt QUIRSO uit. “Dit suggereert dat de vCSA-syslog-server werd misbruikt om bestanden op een bevoorrechte uitvoeringslocatie te plaatsen. Hoewel sommige bestanden verkeerd waren ingedeeld en niet door cron werden uitgevoerd, werd ten minste één bestand met succes uitgevoerd en werd de ‘linuxFile’-achterdeur op het systeem geplaatst.”
Het LinuxFile-implantaat is ontworpen om de aanvaller mogelijkheden te bieden om opdrachten op afstand uit te voeren. Het brengt een verbinding tot stand met de controller via een WebSocket-kanaal om instructies te ontvangen, voert deze uit via /bin/sh en verzendt de resultaten terug naar de aanvaller.
“Het C2-adres (command-and-control) is XOR-versluierd en gedecodeerd tijdens runtime, terwijl de communicatie wordt beschermd met behulp van de eigen cryptografie op de applicatielaag van de malware, ondanks het gebruik van een niet-gecodeerd ws://-transport”, vertelde Szadkowski via e-mail aan The Hacker News. “Het maakt ook automatisch opnieuw verbinding bij storingen en bevat routines voor het tot stand brengen van persistentie via systemd en cron.”
De bedreigingsacteur achter de operatie vertrouwde ook uitgebreid op cron om kwaadaardige payloads uit te voeren, waaronder het ophalen en uitvoeren van een shellscript (“esxi.sh”) vanaf het IP-adres “185.144.28(.)120:3232.” Het shellscript dient vervolgens als downloader en persistentie-installatieprogramma voor een architectuurspecifiek reverse SSH (“reverse_ssh”) binair bestand dat wordt opgehaald uit dezelfde infrastructuur.
Andere cron-taken hadden betrekking op het maken van staging-mappen, het downloaden van uitvoerbare bestanden, het wijzigen van hun machtigingen en het uitvoeren ervan, terwijl werd verwezen naar servers op “192.255.141(.)13:8080” en “5.34.176(.)100:5244.” In wat een operationele veiligheidsblunder lijkt te zijn, is gebleken dat laatstgenoemde de omgekeerde SSH binaire toolset blootlegt via een AList-directorylijst.
Een korte beschrijving van enkele van de verschillende acties die door de dreigingsacteur worden uitgevoerd, is als volgt:
- Implementatie van “linuxFile” (ook bekend als systemlog of linux_x86), dat verbinding maakt met “ws://intel.se9ly9upbhay.shop:8080/ws” en persistentie tot stand brengt via een systemd-service.
- Drie cronjobs instellen die legitieme VMware-services nabootsen: vmware-vpxd-stats-* (faciliteert een op SSH gebaseerd kanaal voor externe toegang door de openbare SSH-sleutel van de aanvaller toe te voegen aan het bestand met geautoriseerde sleutels), vmware-perf-collect-* (laat een JSP-webshell vallen met de naam “vmware-perf-update.jsp”) en vmware-perf-sync-* (laat dezelfde webshell vallen en voert een Met Base64 gecodeerd script dat toegang tot referenties uitvoert en een nieuw account instelt met de naam ‘adminuser’, dat vervolgens wordt toegevoegd aan de groep vSphere SSO-beheerders.
- Twee extra accounts aanmaken: “vcadmin” toevoegen aan vSphere met een Base64-gecodeerd Python-script dat op schijf wordt neergezet via bash-opdrachten die in een cronjob worden uitgevoerd en een vSphere-beheerdersaccount aanmaken via een externe LDAP “Add” -bewerking tegen vCenter’s VMware Directory Service (vmdir) vanaf een externe client met behulp van een reeds bestaand maar gecompromitteerd beheerdersaccount.
- Een bestand maken met de naam “/etc/sudoers.d/vmware-perf” met een configuratie die het “perfcharts”-serviceaccount onbeperkte, niet-interactieve, wachtwoordloze sudo-toegang tot root verleent.
- Het uitvoeren van shell-scripts zoals “/tmp/.vmware-perf-upd.sh” om inloggegevens voor vmdir te verkrijgen door de registerlocatie HKEY_THIS_MACHINEservicesvmdir op te vragen. Als deze methode mislukt, wordt gezocht naar de vmafd Python-module van VMware en worden GetMachineName(), GetMachinePassword() en GetDomainName() aangeroepen om de unieke naam en het wachtwoord op te halen die aan het vCenter-machineaccount zijn gekoppeld. De gestolen inloggegevens worden gebruikt om geprivilegieerde directory-wijzigingen uit te voeren, waaronder het toevoegen van de eerder genoemde ‘adminuser’-identiteit aan de groep Administrators.
- Gebruik vSphere API om detectiebewerkingen uit te voeren en “esxi.sh” om de reverse_ssh-client te implementeren.
- Lokale accounts aanmaken op de ESXi-hosts (bijvoorbeeld “adminuser”) om ransomware-encryptie mogelijk te maken.
- Het nemen van stappen om detectie te omzeilen, de forensische zichtbaarheid te verminderen en op te gaan in de VMware-omgeving.
De aanval maakt uiteindelijk de weg vrij voor de inzet van ransomware op ESXi-hosts die bestanden codeert met de extensie “.babyk”, die doorgaans wordt geassocieerd met van Babuk afgeleide ransomware. Het is niet duidelijk of dit het einddoel van de campagne was, of dat de van Babuk afgeleide lading “opportunistisch of zelfs opzettelijk” werd geselecteerd om de attributie-inspanningen te verwarren.
QUIRSO vertelde de publicatie dat het in dit stadium niet kan beoordelen of de ransomware-variant op andere gecompromitteerde systemen is ingezet, aangezien de analyse beperkt was tot slechts één van de geïnfecteerde systemen. Op basis van het onderzoek tot nu toe wordt echter vermoed dat de inzet van het kluisje niet het hoofddoel van de campagne was.
Szadkowski vergeleek de inzet met een rookgordijn dat was ontworpen om verdedigers af te leiden van de belangrijkste inbraak en de analyse te dwarsbomen door de ESXi-logbestanden te versleutelen, waardoor de toegang tot telemetriegegevens werd verhinderd die meer inzicht hadden kunnen bieden in de activiteit van bedreigingsactoren.
“De exploitatie van CVE-2026-59310 voorzag de acteur van onmiddellijke, niet-interactieve code-uitvoering in een rootcontext op het vCenter Server-apparaat”, aldus de onderzoekers. “Daaropvolgende commando’s opgenomen door CROND werden daarom al als root uitgevoerd, waardoor de actor onbeperkte toegang kreeg tot de onderliggende VCSA zonder eerst een onbevoegd lokaal account in gevaar te brengen en daaruit te escaleren.”
Update
In een vervolganalyse zei QUIRSO dat het een GitHub-repository (“pikpak0066/tmpclean”) had geïdentificeerd die was gekoppeld aan dezelfde bedreigingsacteur en die op het eerste gezicht een Go-gebaseerd programma lijkt te zijn dat automatisch oude bestanden uit tijdelijke Linux-mappen verwijdert. De repository is gemaakt op 14 augustus 2026. Het draagt de beschrijving “Automatische /tmp schonere daemon voor Linux (Go).”
“We ontdekten de GitHub-repository in eerste instantie omdat we zagen dat de aanvaller deze instelde via het linkcommando van de bestaande reverse_ssh-infrastructuur die we in de gaten hielden”, vertelde Szadkowski aan The Hacker News. “Vervolgens hebben we de binaire bestanden die in de releases van de repository zijn gepubliceerd, geanalyseerd en aan reverse-engineering onderworpen. Dit bevestigde onafhankelijk dat het reverse_ssh-builds waren die verband hielden met de infrastructuur van de aanvaller.”
In de repository is een Linux-systemd-service aanwezig die de map “/tmp” scant en alle vermeldingen verwijdert, zoals bestanden, symlinks, sockets en andere, waarvan de wijzigingstijd minstens 24 uur oud is, en dit elk uur herhaalt. Gezien het feit dat het merendeel van de kwaadaardige artefacten die verband houden met de indringers zich op de “/tmp”-locatie bevinden, wordt aangenomen dat de bedreigingsactoren de tool mogelijk gebruiken als een manier om systematisch bewijsmateriaal van de inbraak te wissen en de analyse te bemoeilijken.
Bovendien is gebleken dat een releaseversie met de naam “tmpclean v3.0.0” bijgewerkte binaire bestanden “reverse_ssh” bevat, wat een poging suggereert om extra gecompileerde payloads te distribueren via de op GitHub gebaseerde vector.
Het is niet duidelijk wat de bedreigingsacteur ertoe heeft aangezet om de repository überhaupt op te zetten, hoewel een mogelijkheid is dat ze actief de openbaarmaking volgen en proberen nieuwe opruimmechanismen te introduceren om onder de radar te blijven.
(Het verhaal is na publicatie bijgewerkt met aanvullende inzichten van QUIRSO.)
