Шифровальщики поднялись по стеку: гипервизоры выросли с 3% до 25% случаев
У Huntress есть цифра, которая заслуживает большего внимания, чем получила. Среди инцидентов со злонамеренным шифрованием, которые Huntress разбирала в 2025 году, доля случаев с участием гипервизора выросла с 3 % в первом полугодии до 25 % во втором, и основной вклад внесла группа Akira. 1
Это восьмикратный рост доли случаев, доходящих до слоя виртуализации, за один год. Это телеметрия одного вендора, а не перепись всей отрасли, но направление не заметить трудно.
Чистая экономика
Зашифровав гостевую виртуальную машину, вы получаете данные одной жертвы и должны пробить защиту одной жертвы. Компрометация гипервизора открывает атакующему путь сразу ко всем гостям на этой машине, а собственная защита гостей — их EDR, их фаервол, их аккуратные патчи — уже не имеет значения: вы работаете под всем этим.
Хранилище виртуальных машин — тоже сосредоточенная мишень. Лежат ли диски файлами qcow2, томами LVM, датастором VMFS или образами Ceph, данные множества клиентов обычно оказываются в одном месте под одним административным управлением. С хоста компрометация пятидесяти клиентов — это не пятьдесят отдельных компрометаций.
Плоскость управления гипервизором слишком часто воспринимают как сантехнику, а не как главную драгоценность: плоские сети управления, общие административные учётные данные, неспешные патчи и мониторинг, нацеленный на гостей, а не на хост.
Усугубляет всё это резервное копирование
В апреле мы писали о компрометации службы поддержки, которая за этим стоит. Перехват сессии дал посторонним доступ к системе поддержки Virtualizor, где примерно в 1500 старых тикетах — часть из них старше года — лежали root-пароли открытым текстом, вставленные самими клиентами при обращении за помощью. В Virtualizor прямо заявили, что уязвимости в их программном обеспечении не было и что скомпрометированы оказались те серверы, где пароли ни разу не меняли, а панели управления и SSH не были закрыты фаерволом. 2 Дальше по цепочке появились сообщения об атаках шифровальщиков на несколько хостинг-провайдеров с потерей клиентских данных. 3
Схема в этих инцидентах повторяется, и дело в ней вовсе не в шифровании.
У провайдера были резервные копии. Копии были доступны из скомпрометированной среды, а учётные данные к ним дала та же компрометация. Резервные копии внутри того же контура доверия падают вместе с ним — и именно отсюда, а не от шифрования, берётся безвозвратная потеря.
Резервная копия, у которой общие с продакшеном учётные данные, сетевое доверие или административная граница, может отказать ровно тогда, когда понадобится. Это вторая копия в том же радиусе поражения.
Пять мер, которые работают
Важнее всего копии за пределами провайдера — и именно их чаще всего пропускают. Не другой том, не другой регион и не другой продукт того же вендора, а совершенно другой провайдер, учётные данные которого не встречаются нигде в вашем продакшене.
Отделите продакшен от полномочий над копиями. Направление передачи важно меньше, чем модель прав: продакшен не должен иметь возможности уничтожить историю. Чище всего, когда система резервного копирования сама приходит и забирает данные, а у продакшена нет вообще никаких учётных данных. Учётная запись, которая может писать, но не может удалять, даёт то же свойство там, где без push-модели не обойтись. Не работает схема, в которой учётные данные, лежащие на продакшен-машине, способны опустошить и хранилище копий: шифровальщик на этой машине наследует их.
Неизменяемость — object-lock или хранилище только на дозапись, чтобы атакующий даже с действующими учётными данными не мог стереть историю.
Учения по восстановлению, потому что непроверенная копия — это гипотеза. Восстанавливайте что-то настоящее, по расписанию, и засекайте время.
Шифрование до отправки, чтобы компрометация провайдера резервных копий стала проблемой доступности, а не разглашения.
KVM и один пункт против наших собственных интересов
Две вещи стоит сказать прямо, потому что это устройство системы, а не обещания.
У нас полноценная виртуализация KVM, а не общие контейнеры. Изоляция между клиентами держится на аппаратной виртуализации и границе гипервизора, а не на пространствах имён и не на модели прав панели управления. Это не иммунитет: скомпрометированный хост остаётся скомпрометированным хостом на любой платформе. Но граница изоляции между вами и соседним клиентом проходит по слою виртуализации, а не через общее ядро гостевых систем. Общего ядра, которое могло бы пересечь локальное повышение привилегий, здесь просто нет.
Ещё вы получаете доступ к виртуальной консоли из личного кабинета. У каждого VPS и VDS в нашем нынешнем каталоге есть консоль noVNC, так что при восстановлении вы не зависите ни от работающего SSH, ни от вменяемой сети, ни от необходимости кому-то передавать пароль.
А вот часть, которая идёт против наших коммерческих интересов: не держите единственную резервную копию у нас. У нас четыре страны, и второй VPS на другой нашей площадке, от 5 €/мес., годится как отдельная копия, переживающая региональный или юрисдикционный отказ. Управляемого продукта для резервного копирования мы не продаём — такую схему вы строите сами. И она не спасёт, если откажем мы сами. Для этого нужна копия у провайдера, чьих учётных данных мы никогда не видели.
Любая хостинговая компания, которая говорит иначе, продаёт вам единую точку отказа с наклейкой «резервирование».
Вопрос, который стоит задать провайдеру
Если сегодня ночью скомпрометируют плоскость управления вашим гипервизором, что из моего уцелеет и сколько времени займёт вернуть это обратно?
Спрашивать вы вправе. Ответ — и то, как быстро он придёт, — скажет вам почти всё, что нужно знать.