Вымогатели за десять дней уничтожили виртуальную инфраструктуру организации, не используя уязвимости гипервизора. Атака шла через штатные интерфейсы управления VMware: похищенные учётные данные, vCenter и удалённый доступ к хостам ESXi. Исследователи восстановили хронологию по журналам и отметили, что такие действия трудно заметить обычными средствами защиты.
По данным Securelist, атака затронула четыре хоста ESXi, все виртуальные машины на них, оба vCenter Server Appliance и всю подключённую инфраструктуру резервного копирования. Злоумышленники действовали через легитимные интерфейсы: ни эксплойтов гипервизора, ни побегов из гостевых систем, ни повреждения памяти не было. Записки с требованием выкупа указывали на BlackNevas; после утечки кода Babuk в 2021 году на его основе появилось минимум десять семейств шифровальщиков для ESXi.
В организацию попали через учётные данные, похищенные из систем вне виртуализации: одни и те же административные аккаунты использовались в разных сегментах инфраструктуры. Отдельным путём стала среда резервного копирования - получив права на сервере бэкапов, злоумышленники вытащили из него сохранённые учётные данные. Уязвимости ESXi в этом инциденте не эксплуатировались, хотя в целом публичные уязвимости виртуализации остаются частым способом входа.
На vCenter злоумышленники закрепились через SSH: вошли под root, установили агент MeshAgent из легитимного инструмента удалённого управления и обратный туннель Ligolo-ng, оформленный как системная служба. Службу замаскировали под компонент VMware: похожее имя, расположение рядом со служебными файлами и автоперезапуск. После этого интерактивным SSH почти не пользовались, поэтому наблюдение только за входами в консоль такие действия пропускает.
Скомпрометированный vCenter стал инструментом атаки: через профили хостов злоумышленники включили SSH на хостах ESXi. От чтения конфигурации до прямого удалённого доступа прошло около 11 минут, а подключения шли с адреса vCenter, которому в управляющей сети обычно доверяют. Централизованные механизмы соответствия не спасают, если скомпрометирован сам инструмент управления.
Сначала злоумышленники разрушили путь восстановления: за несколько дней до финала отключили антивирус в среде бэкапа, остановили службы, зашифровали инфраструктуру восстановления и нарушили административный доступ. Затем через штатные SSH, vim-cmd и API на хостах погасили виртуальные машины, удалили снимки и повредили datastore, а полезную нагрузку доставили по SFTP. Примерно за три часа до запуска они проверили её на совместимость, а в итоге оказались перезаписаны первые 2 КБ файлов виртуальных дисков.
Восстановить картину помогли штатные журналы ESXi и vCenter: события аутентификации, командная оболочка, задачи и изменения профилей хостов. Но ESXi хранит логи в оперативной памяти, которая очищается при перезагрузке, поэтому без удалённого сбора через syslog свидетельства исчезают. Исследователи советуют настраивать централизованное логирование заранее и не перезагружать хосты до сбора данных.
Защиту исследователи предлагают строить вокруг управления, идентичностей и восстановления: vCenter стоит считать активом первого уровня, а учётные записи виртуализации - отделять от обычных. Прямой SSH на ESXi стоит держать в исключениях, а резервное копирование - выносить в отдельный контур с независимыми идентичностями. Полностью пропатченный гипервизор всё равно может стать точкой максимального ущерба, если захвачен инструмент, который им управляет.
