Щоб знищити це середовище VMware, зловмисникам не знадобилося виходити з віртуальної машини на хост. Вони отримали адміністративний доступ, через штатні налаштування vCenter увімкнули SSH на хостах і пошкодили контур відновлення ще до фінального удару. У розслідуванні Kaspersky від 13 листопада описано десятиденне вторгнення, що зачепило чотири хости ESXi, їхні віртуальні машини, обидва сервери vCenter та підключену інфраструктуру резервування. У записках із вимогою викупу фігурувала BlackNevas; звіт не стверджує, що атака сталася цього тижня.
Сервер резервування відкрив шлях до робочих систем
Доступ перетнув кілька адміністративних меж. Облікові дані, отримані із систем поза контуром віртуалізації, дали змогу підключитися до vCenter. Виконання команд із правами адміністратора на інфраструктурі резервування відкрило інші збережені облікові дані. Отже, система для відновлення робочих сервісів могла допомогти ними керувати.
На сервері vCenter аварійного відновлення після SSH-входу як root минуло лише 43 секунди до встановлення MeshAgent — легітимного агента віддаленого керування. Приблизно через чотири години зловмисник додав зворотний тунель Ligolo-ng під правдоподібною назвою служби vmware-vdma. Виконуваний файл розмістили в /opt/vmware/bin/.
Коротка SSH-сесія вже не відображала всіх шляхів доступу. Додаткові канали вимагали перевіряти служби та вихідні з’єднання поряд з інтерактивними входами. Схожа на VMware назва сама по собі не доводить шкідливість: важливі походження служби та її наявність у затвердженій конфігурації.
Host Profiles знову ввімкнули закриту службу
Профілі хостів vCenter Host Profiles дають адміністраторам змогу застосовувати спільну конфігурацію. Зловмисник використав ці повноваження, щоб увімкнути TSM-SSH — службу віддаленої оболонки ESXi. Журнали пов’язали надсилання конфігурації з переходом служби в робочий стан через 33 секунди. Подальші прямі SSH-підключення надходили з IP-адреси самого vCenter.
Саме тому перевірки «SSH вимкнений» було б замало. Обліковий запис, який задає потрібну конфігурацію, може змінити цей стан. З’єднання з довіреного сервера керування може виглядати звичним, якщо окремо не перевірити, хто ініціював зміну і чи відповідала вона погодженій роботі.
Це інший епізод, ніж попередній випадок BlackNevas з обліковими даними PRTG. Там дослідники простежили повторне використання пароля root та вимкнення обмеження після заблокованого запуску. Новий звіт показує шлях через централізовані повноваження керування.
Перед руйнуванням був тестовий запуск
Зловмисник передав виконуваний файл esx64 через SFTP. Журнали хоста зафіксували запуск /selftest тривалістю близько 16 секунд приблизно за три години до руйнівного виконання. Це важливий проміжок для розслідування: поява файла, зміна дозволів і несподіваний тест могли залишити сліди до удару по сховищу віртуальних машин.
Зв’язок із BlackNevas у звіті спирається на записки з вимогою викупу та характерні параметри командного рядка. Самого бінарного файла дослідники не мали, тож не могли перевірити реалізацію кожного параметра. Так само перезапис приблизно перших 2 КБ віртуальних дисків не означає стирання кожного байта чи можливості відновити будь-який диск. Результат залежить від структури диска та інших пошкоджень.
Контур відновлення атакували заздалегідь
До фінального удару по ESXi оператор вимкнув антивірус у середовищі резервування, зупинив служби резервного копіювання, зашифрував інфраструктуру відновлення та порушив адміністративний доступ. Послідовність принципова: копія може існувати, але системи й облікові записи для її відновлення вже недоступні. Окреме розслідування The Gentlemen також показує, чому сховищам копій та їхнім обліковим даним потрібна власна межа захисту.
Для адміністратора, який розслідує подібний ланцюжок, докази містяться з обох боків керування: Events і Tasks vCenter показують обліковий запис ініціатора; vpxa.log і vobd.log — конфігурацію хоста та зміни служб; auth.log і shell.log — подальші входи й команди. Зіставляйте ці події з погодженими змінами та зберігайте журнали поза ураженою інфраструктурою. SSH можуть увімкнути і під час звичайного обслуговування, тому пов’язана послідовність інформативніша за окреме сповіщення про стан служби.
Практичне питання — чи не використовують звичайне адміністрування, керування віртуалізацією та відновлення ті самі облікові дані й доступні мережеві маршрути. Розділіть ці повноваження, обмежте прямий доступ до хостів і перевірте відновлення через незалежний контур. Оновлення залишаються необхідними; цей випадок показує, чому паролі та адміністративні права потребують такої самої уваги.
Джерела
- Elsayed Elrefaei та Mohamed Ghobashy, Kaspersky GERT. Ransomware at the hypervisor layer: how attackers use ESXi and vCenter features for malicious purposes. Securelist, 13 листопада 2026 року; перевірено 14 листопада 2026 року. Розслідування, хронологія та індикатори інциденту.
