Ransomware BlackNevas zničil ESXi i zálohy: útočníci zapnuli SSH přes Host Profiles ve vCenter

Co se stalo

Tým pro reakci na incidenty Kaspersky GERT zveřejnil 13. listopadu 2026 rozbor útoku, při kterém skupina BlackNevas zničila celé virtualizované prostředí oběti: čtyři hostitele ESXi se všemi virtuálními stroji, obě appliance vCenter Server (VCSA) a navázanou zálohovací infrastrukturu. Od prvního přístupu do ničivé fáze uběhlo asi 10 dní. Kdo byla oběť a kdy se útok stal, zpráva neuvádí.

K útoku se skupina přihlásila jménem v poznámkách s výkupným. Podle Kaspersky byla BlackNevas poprvé pozorována v listopadu 2024; zpráva cituje SentinelOne, podle kterého jde o odvozeninu ransomwaru Trigona s verzemi pro ESXi.

Hlavní zjištění: zranitelnost ESXi jako vstupní bod se nenašla. Útočníkům stačily přihlašovací údaje ukradené z jiných systémů a funkce, které správci vSphere používají každý den.

Jak útok probíhal

Appliance vCenter. Útočník se přihlásil přes SSH jako root a za 43 sekund skriptem nasadil MeshAgent (klient nástroje MeshCentral pro vzdálenou správu). Asi o čtyři hodiny později přes něj nainstaloval tunel Ligolo-ng 0.8.2 jako službu systemd vmware-vdma.service s popisem „DNS, time, VM settings sync“, který se tváří jako součást VMware.

Hostitelé ESXi. SSH na hostitelích útočník zapnul přes Host Profiles – změnil v profilu stav služby TSM-SSH. Spojení na ESXi pak přicházela z IP adresy appliance vCenter, takže v síti vypadala jako běžná správa. Stopy jsou podle Kaspersky v vpxa.log, vobd.log a hostprofiletrace.log.

Zálohy jako první. Před zásahem do ESXi útočníci vypnuli antivir v zálohovacím prostředí, zastavili služby záloh, zašifrovali obnovovací infrastrukturu a narušili přístup správců. Další přihlašovací údaje získali právě ze zálohovací infrastruktury.

Šifrování. Šifrovač se na ESXi dostal přes SFTP do /tmp (identifikátor klienta odpovídá knihovně FlowSsh od Bitvise). Asi tři hodiny před útokem ho útočník spustil v testovacím režimu, nejspíš kvůli ověření kompatibility s verzí ESXi. Potom se na hostiteli pro obnovu po havárii během 23 sekund zastavily všechny virtuální stroje a útočník spustil šifrovač nad svazky VMFS. Přepsány byly asi první 2 KB souborů virtuálních disků. Kaspersky dodává, že metadata oddílů tím nemusí být nenávratně ztracená, protože záložní hlavičky GPT mohou přežít.

Jak poznat napadení

Indikátory z rozboru (zneškodněné). Kaspersky upozorňuje, že jsou vázané na tento incident. Hashe šifrovače pro ESXi, tunelu Ligolo-ng ani instalačních skriptů k dispozici nejsou.

api.cloudvflare[.]com
45.149.154[.]135
91.92.242[.]121
31.41.33[.]212
188.240.57[.]94

SHA-256  15dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574baf
SHA-256  5a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78
SHA-1    28f8da19ddcdf26e426875c7a834b34a79bc1c33   svhost.exe / lock.exe

Služby:  vmware-vdma, vspbind
Soubory: /etc/systemd/system/vmware-vdma.service
         /opt/vmware/bin/agent
         /tmp/esx64

Spolehlivější než hashe je hlídat chování. Kaspersky doporučuje alarmy na:

• Host Profiles → SSH: úprava profilu, která mimo schválené okno přepne TSM nebo TSM-SSH na spuštěno, zvlášť když hned následuje SSH z vCenter.
• Nové služby systemd v /etc/systemd/system na VCSA, které spouštějí neznámé binárky v cestách podobných VMware.
• Oslabení ESXi: vypnutí execInstalledOnly nebo snížení úrovně přijímaných balíčků (acceptance level).
• Soubor spuštěný z /tmp a následný přístup do /vmfs – kritická sekvence těsně před útokem.
• Hromadné vypínání virtuálních strojů během pár minut.
• Zastavení zálohovacích služeb nebo bezpečnostních nástrojů krátce před změnami na hypervisoru.

Logy nebo export ze SIEM můžete vložit do našeho extraktoru IOC, který z nich vytáhne IP adresy, domény a hashe přímo ve vašem prohlížeči.

Co udělat

Doporučení Kaspersky doplněná o dokumentaci Broadcomu:

1. Berte vCenter jako nejcitlivější systém (Tier 0): samostatné účty správců, MFA odolné proti phishingu, omezená správní síť, sledování privilegovaných relací.
2. Oddělte účty pro virtualizaci a zálohy od běžné domény a nepoužívejte pro ně účty doménových administrátorů. Zálohy patří na samostatné účty a síť; obnovu zkoušejte i pro případ, že vCenter a produkční AD nejsou dostupné.
3. Omezte přímé SSH na ESXi a kde to provoz dovolí, použijte Lockdown Mode.
4. Nechte zapnuté execInstalledOnly. Podle Broadcomu je v ESXi 8.0 a novějších ve výchozím stavu zapnuté a jeho vypnutí zvyšuje riziko ransomwaru.
5. ESXi připojené do AD: podle Broadcom KB 369707 nastavte esxAdminsGroupAutoAdd na false a zkraťte authValidateInterval.
6. Posílejte logy ESXi a VCSA mimo virtualizaci, aby je útočník nemohl smazat spolu s prostředím.
7. Opravte známé zranitelnosti vCenter, ESXi a Veeam, které zpráva uvádí jako běžné cesty k hypervisoru (v tomto incidentu se nepoužily).
8. Při incidentu nejdřív zajistěte logy a důkazy, teprve pak měňte hesla. ESXi nerestartujte jen kvůli ukončení relace útočníka.

Incident v Česku hlaste NÚKIB, na Slovensku SK-CERT. Zničení ESXi jako poslední krok útoku jsme nedávno popsali i u útoků na brány Check Point.

Časová osa

• listopad 2024 – první pozorování skupiny BlackNevas (podle Kaspersky).
• neuvedeno – incident: asi 10 dní od prvního přístupu po zničení prostředí.
• 13. 11. 2026 – Kaspersky GERT zveřejnil rozbor s indikátory a pravidly detekce.

Ověřeno ze zdrojů 13. 11. 2026.