CVE-2026-59310: Hvad VMware vCenter-kampagnen afslører

Broadcom har leveret rettede versioner, men ingen workaround. Den officielle afhjælpning er derfor at installere de opdateringer, der fremgår af leverandørens sikkerhedsmeddelelse.

Tidslinjen: Rettelse først – udnyttelse fem dage senere

Broadcom offentliggjorde CVE-2026-59310 og udsendte patches den 29. juli. QUIRSO rapporterede tegn på aktiv udnyttelse fra den 3. august, hvorefter kampagnen voksede hurtigt.

Det er afgørende for håndteringen af et muligt indbrud. En installation, der blev opdateret efter den 3. august, kan ikke automatisk anses for ren, blot fordi opdateringen blev gennemført uden fejl. Organisationer skal skelne mellem at lukke sårbarheden og at undersøge, om angribere allerede havde etableret adgang.

Kampagnens omfang

Forskere kædede aktiviteten sammen med 361 observerede offer-IP-adresser i 47 lande. Tyskland, USA, Tyrkiet, Iran og Frankrig stod ifølge rapporteringen for mere end halvdelen af det observerede antal.

Tallet skal læses med en vigtig reservation: Én IP-adresse er ikke nødvendigvis lig med én organisation. De 361 adresser dokumenterer derfor ikke 361 forskellige virksomheder eller institutioner. Rapporteringen peger dog på en bred kampagne mod internettilgængelige eller på anden måde netværkseksponerede vCenter-systemer.

Hvorfor forskere ser en mulig Kina-forbindelse

QUIRSO vurderede med moderat sikkerhed, at kampagnen har en Kina-forbindelse. De rapporterede indikatorer omfatter kinesisksprogede artefakter, værktøjer og genbrugt offentligt tilgængelig forskning, aktivitet der passer med arbejdstider i UTC+08:00, samt et offerbillede, der tilsyneladende ikke omfattede det kinesiske fastland.

Indikatorerne understøtter en regional eller sproglig vurdering, men identificerer ikke en navngiven kinesisk statsgruppe og beviser ikke, at operationen blev styret af en regering. Attribution baseret på malware, tidsmønstre og målvalg kan ændre sig, når nye oplysninger kommer frem. Den mest forsigtige beskrivelse er derfor en mistænkt Kina-relateret aktør – ikke en bekræftet statssponsoreret operation.

Den rapporterede angrebskæde

Kampagnen ser ud til at have brugt CVE-2026-59310 til den første kodekørsel og derefter installeret flere lag af persistens og adgang:

1. Directory traversal: Specialfremstillede forespørgsler til Syslog-tjenesten blev brugt til at bevæge sig ud af den tilsigtede sti og skrive angriberstyret indhold.
2. Persistens via cron: Angriberne oprettede ifølge rapporteringen fejlformaterede cron-poster, så planlagte opgaver kunne starte efterfølgende kommandoer.
3. Levering af bagdør: curl eller wget hentede en WebSocket-baseret og XOR-obfuskeret linuxFile-backdoor, ifølge rapporteringen om de observerede indbrud.
4. Reverse SSH: Angriberne installerede reverse-SSH-værktøjer, der oprettede udgående forbindelser tilbage til angribernes infrastruktur. Shadowserver rapporterede, at denne persistensmekanisme blev fundet hos alle ofrene i den særlige rapport.
5. Misbrug af legitimationsoplysninger og konti: Efterforskere rapporterede uautoriserede vCenter- og ESXi-administratorkonti samt misbrug af legitimationsoplysninger fra VMware Directory Service.
6. Ransomware: Mindst en del af rapporteringen kædede aktiviteten sammen med en Babuk-afledt ransomware-variant, der tilføjer filendelsen .babyk.

Fundet af reverse SSH er særligt vigtigt. Shadowservers konklusion er, at systemer, hvor mekanismen er installeret, skal behandles som fuldt kompromitterede. Det er ikke tilstrækkeligt blot at slette en binær fil eller en cron-jobpost uden også at genopbygge tilliden til appliance’en og udskifte privilegerede legitimationsoplysninger.

Ransomware kan have haft et anti-forensisk formål

Den rapporterede .babyk-aktivitet beskriver ikke nødvendigvis en traditionel ransomwarekampagne, hvis primære mål er bred kryptering og afpresning. Analytikere har foreslået, at selektiv kryptering af ESXi-logfiler kan have haft til formål at vanskeliggøre efterforskningen og skjule spor.

Forklaringen er fortsat en analytisk slutning og ikke en bekræftet udtalelse fra angriberne. Forsvarere bør derfor undersøge begge muligheder: ransomwarepåvirkning af virtuelle maskiner og bevidst manipulation af logfiler for at sløre indbruddet.

GitHub og genbrug af værktøjer

Rapporteringen kædede også operationen sammen med et GitHub-repository, hvor reverse-SSH-binære filer blev præsenteret som et Linux-værktøj til oprydning i midlertidige filer. Når et persistensværktøj forklædes som et administrativt værktøj eller et oprydningsprogram, kan det blive lettere at distribuere og mindre iøjnefaldende ved almindelige kontroller. De tilgængelige oplysninger fastslår dog ikke uafhængigt, hvem der drev repository’et, så dets eksistens kan ikke bruges som bevis for attribution.

Hvad betyder sagen for Broadcom?

Broadcom-aktien faldt omkring 5-6 procent den 14. august, da rapporter om aktiv udnyttelse af VMware-sårbarheden nåede investorerne. En opgørelse beskrev et fald fra 417,82 dollar til 392,99 dollar i løbet af handelsdagen.

Sikkerhedsrapporterne var én faktor i kursfaldet, men ikke nødvendigvis den eneste. Samtidig omtalte markedsdækningen bredere bekymringer, blandt andet gældseksponering relateret til kunstig intelligens. Det er derfor ikke forsvarligt at tilskrive hele kursbevægelsen eller et præcist tab i markedsværdi til CVE-2026-59310 alene.

Der er heller ikke tilstrækkeligt belæg i den tilgængelige rapportering til at konkludere, at kampagnen allerede har medført et mål- eller målbart fald i VMwares omsætning. De mest underbyggede kortsigtede forretningskonsekvenser er udgifter til kundernes afhjælpning, risiko for driftsforstyrrelser og øget omdømmepres. Eventuelle langsigtede omsætningseffekter kræver selskabsoplysninger eller yderligere finansiel dokumentation.

Anbefalet håndtering for vCenter-administratorer

Patching er første skridt – ikke det sidste. Organisationer bør:

1. Installere Broadcoms rettelser med det samme på alle berørte vCenter-instanser og prioritere internetvendte systemer samt appliances, der kan nås fra brede interne netværk. Broadcom har ikke angivet en workaround.
2. Antage kompromittering, når der findes indikatorer, herunder uventrede ændringer i cron, reverse-SSH-spor, linuxFile, uforklarede downloads via curl eller wget, ukendte vCenter- eller ESXi-administratorer og unormal aktivitet i VMware Directory Service.
3. Isolere mistænkelige appliances og, hvor det er praktisk muligt, sikre diskimages, logfiler og flygtige data, før systemerne genopbygges.
4. Udskifte privilegerede legitimationsoplysninger, herunder vCenter SSO, VMware Directory Service, ESXi- eller root-konti, API-konti, servicekonti og tilknyttede administrative konti. Ugyldiggør aktive sessioner, og gennemgå federationsforbindelser.
5. Genopbygge i stedet for blot at rense systemer med bekræftet persistens. Fjern uautoriserede konti, cron-jobs, binære filer, SSH-nøgler og tunneler som led i en dokumenteret incident-response-proces.
6. Lede efter spor i hele den virtuelle infrastruktur, herunder .babyk-aktivitet, uventede udgående SSH- eller WebSocket-forbindelser, uautoriserede konti og tegn på manipulation af ESXi-logfiler.
7. Gendanne pålidelige data og telemetri fra kendte, rene og uforanderlige sikkerhedskopier, hvis logfiler eller konfigurationer er blevet ændret.
8. Reducere den fremtidige eksponering ved at begrænse adgangen til vCenter-administration til segmenterede administrationsnetværk og overvåge udgående forbindelser fra vCenter- og ESXi-værter.

Den operationelle konklusion er enkel: Opdatér alle sårbare vCenter-systemer, men forveksl ikke en vellykket patch med et rent miljø. Kombinationen af hurtig udnyttelse, vedvarende reverse SSH og rapporteret misbrug af legitimationsoplysninger betyder, at eksponerede appliances bør undersøges som potentielt fuldt kompromitterede.