Уязвимость в VMware vCenter под номером CVE-2026-59310 начали эксплуатировать всего через пять дней после публикации, и не рядовые вымогатели, а группировка, которую связывают с Китаем. Немецкая фирма QUIRSO размотала кампанию, охватившую 361 IP-адрес в 47 странах и закончившуюся развёртыванием шифровальщика на основе Babuk прямо на гипервизорах ESXi. Но самое интересное в другом: похоже, вымогательство здесь было не целью, а прикрытием. Для любой компании, чья инфраструктура крутится в виртуализации, это тревожный сигнал.

Что за уязвимость

CVE-2026-59310 — это обход каталога (directory traversal) в сервере vCenter с оценкой CVSS 9.8, который позволяет выполнить произвольный код. Broadcom выпустила исправление 29 июля, а уже через пять календарных дней после раскрытия уязвимость взяли в оборот. vCenter служит центральным пультом управления всей виртуальной средой: через него администрируют десятки и сотни виртуальных машин и сами гипервизоры ESXi. Компрометация vCenter — это не «ещё один взломанный сервер», а ключ ко всему виртуальному парку сразу.

Чтобы оценить масштаб, стоит вспомнить, как устроена виртуализация. ESXi — это гипервизор, тонкая прослойка, на которой запущены десятки виртуальных машин: серверы приложений, базы данных, контроллеры домена. vCenter управляет этими гипервизорами централизованно. Тот, кто контролирует vCenter, фактически держит руку на рубильнике всей инфраструктуры, не входя ни в одну гостевую систему по отдельности.

Почему гипервизор — идеальная мишень

Зашифровав ESXi, атакующий одним ударом выводит из строя все работающие на нём виртуальные машины сразу, в обход защиты, установленной внутри гостевых систем. Антивирус на виртуальном сервере бесполезен, если шифруется сам гипервизор под ним. Поэтому операторы вымогателей давно целятся именно в уровень виртуализации: одна успешная атака на ESXi эквивалентна одновременному выводу из строя десятков серверов, и восстановление превращается в многодневный кошмар.

Добавьте к этому скорость. Пять дней от раскрытия до атаки — это темп, при котором плановое обновление «на ближайшем окне обслуживания» безнадёжно опаздывает. Как только появляется рабочий эксплойт под критическую уязвимость в таком продукте, по открытым в интернет vCenter немедленно проходит волна сканирования. Отсюда и география кампании: 361 адрес в 47 странах — это не точечная операция, а веерный сбор всего, что удалось достать.

Шифрование как дымовая завеса

Ключевой вывод исследователей: судя по разобранному инциденту, вымогательство не было главной целью. Развёртывание шифровальщика выглядело как отвлекающий манёвр, призванный замаскировать саму суть вторжения и затруднить последующий разбор, ведь зашифрованные данные — это в том числе уничтоженные логи и стёртые следы. Пока жертва в панике занимается расшифровкой и решает вопрос с выкупом, настоящая операция, шпионаж или кража данных, остаётся незамеченной.

Это меняет отношение к инциденту. Если раньше шифровальщик читался однозначно, «нас взломали ради денег», то теперь он может означать «нас взломали ради данных, а шифрование включили, чтобы мы не поняли, что именно унесли». Для реагирования разница принципиальная: восстановить из бэкапа мало, нужно ещё понять, что происходило до шифрования и не остались ли у атакующего доступы. Компания, которая просто расшифровалась и выдохнула, рискует не заметить, что её продолжают читать.

Бэкапы по правилу 3-2-1

Разговор про защиту от шифровальщиков всегда упирается в бэкапы, но здесь важны детали. Классическое правило звучит как «3-2-1»: три копии данных, на двух разных типах носителей, одна из них вне площадки. Но против современных вымогателей этого мало, потому что они первым делом ищут и шифруют сами бэкапы. Спасает только копия, до которой шифровальщик физически не дотянется: офлайн-носитель или неизменяемое хранилище, где данные нельзя переписать в течение заданного срока.

И ещё одно, о чём вспоминают в самый неподходящий момент: бэкап, который ни разу не восстанавливали, это не бэкап, а надежда. Регулярная проверка восстановления должна быть таким же рутинным процессом, как и само резервное копирование. Иначе есть риск в разгар инцидента обнаружить, что копии повреждены или неполны.

Что должно быть в плане реагирования

Скорость атаки на vCenter показывает, что импровизировать во время инцидента не стоит. План реагирования должен существовать заранее и отвечать на конкретные вопросы. Кто принимает решения и кого поднимают ночью? Как изолировать заражённый сегмент, не отключив заодно половину бизнеса? Где лежат логи и достаточно ли их для разбора? Как и в какой момент уведомлять руководство, клиентов и регулятора?

Отдельно важно сохранить улики. Соблазн быстро всё «почистить и поднять» велик, но при этом уничтожаются следы, по которым только и можно понять, что именно унесли. В сценарии, где шифрование служит дымовой завесой, поспешное восстановление играет на руку атакующему. Поэтому первым делом фиксируют состояние, а уже потом восстанавливают.

Изоляция плоскости управления

Отдельно стоит сказать про изоляцию. Плоскость управления виртуализацией, то есть vCenter и интерфейсы ESXi, не должна быть доступна из общей пользовательской сети, а тем более из интернета. Доступ к ней стоит держать в отдельном сегменте, за отдельной аутентификацией, желательно с многофакторным входом и строгим списком тех, кому он вообще нужен. Это не устраняет саму уязвимость, но резко сужает круг тех, кто может до неё дотянуться. Если бы управляющий интерфейс не торчал наружу, значительная часть жертв кампании просто не попала бы под удар.

Что делать

• Срочно обновить vCenter до исправленной версии и изолировать плоскость управления виртуализацией от общей сети, а тем более от интернета.
• Проверить бэкапы: они должны быть офлайн или неизменяемыми, чтобы шифровальщик до них не дотянулся, и должны реально восстанавливаться, а не просто числиться.
• Не ограничиваться расшифровкой: при инциденте разбирать, что делал злоумышленник до неё, не потеряны ли данные и доступы.
• Заранее проверять устойчивость виртуальной и сетевой инфраструктуры — это пентест облачной инфраструктуры, тестирование сети и Red Team.

Вывод

Пять дней от раскрытия до атаки на гипервизоры — это темп, в котором плановое обновление уже опаздывает. А использование шифровальщика как дымовой завесы напоминает: за громким инцидентом может прятаться тихая кража данных. Обновляйте vCenter, изолируйте управление виртуализацией, берегите бэкапы и разбирайте инциденты глубже, чем «расшифровали и забыли». Методики и цены на тестирование есть и у коллег из SecurityLab.