Гипервизоры — это основа современных виртуализированных сред, но в случае взлома они могут стать мощным инструментом в руках злоумышленников. Одна брешь на этом уровне может подвергнуть риску десятки или даже сотни виртуальных машин. В отличие от традиционных конечных устройств, гипервизоры часто работают в условиях ограниченной видимости и защиты, а это значит, что обычные средства безопасности могут не заметить атаку, пока не станет слишком поздно.
Злоумышленники всё чаще используют гипервизоры для масштабного распространения программ-вымогателей. В частности, в 2025 году данные Huntress о случаях использования программ-вымогателей на гипервизорах показали ошеломляющий рост: их роль в злонамеренном шифровании выросла с 3 % в первой половине года до 25 % во второй половине.
Основным фактором, определяющим эту тенденцию, является деятельность группы Akira, занимающейся программами-вымогателями. Этот сдвиг подчеркивает важность защиты уровня гипервизора с той же тщательностью, что и конечных точек и серверов.
В этой статье описываются угрозы, с которыми столкнулись, и практические рекомендации по защите инфраструктуры гипервизора: от установки исправлений и контроля доступа до усиления защиты во время выполнения и надёжных стратегий восстановления.
Гипервизоры: новое поле битвы в сфере программ-вымогателей
В последние несколько месяцев 2025 года компания Huntress наблюдала, как злоумышленники атакуют гипервизоры в попытке обойти средства контроля безопасности конечных точек и сети.
И в этом есть смысл: по мере того как защитники продолжают укреплять конечные устройства и серверы, злоумышленники всё чаще переключают своё внимание на уровень гипервизора — основу виртуализированной инфраструктуры. Гипервизор типа 1 («голый металл») — это основа, установленная непосредственно на серверном оборудовании, а гипервизор типа 2 («размещённый») — это приложение, работающее поверх операционной системы вашего обычного компьютера. Этот переход происходит по знакомой схеме.
Сталкивались с этим при атаках на устройства VPN: злоумышленники понимают, что операционная система хоста часто является проприетарной или ограниченной, а это значит, что защитники не могут установить критически важные средства контроля безопасности, такие как EDR. Это создаёт серьёзную брешь в системе защиты.
Тот же принцип применим к гипервизорам первого типа; они представляют собой идеальную цель для «захвата и расширения», до которой зачастую не может добраться традиционная система безопасности конечных точек.
Мы также наблюдали несколько случаев, когда операторы программ-вымогателей развертывали программы-вымогатели непосредственно через гипервизоры, полностью обходя традиционные средства защиты конечных точек.
В некоторых случаях злоумышленники используют встроенные инструменты, такие как openssl, для шифрования томов виртуальной машины, что позволяет им не загружать собственные двоичные файлы программ-вымогателей.
- Попав в сеть, злоумышленники часто переключаются на гипервизоры, используя скомпрометированные учетные данные для внутренней аутентификации в средах, где сегментация сети не позволяет предотвратить горизонтальное перемещение к странице управления гипервизором. Это дает им расширенный контроль над несколькими гостевыми системами с помощью одного интерфейса управления.
- Мы сталкивались с неправомерным использованием утилит управления Hyper-V для изменения настроек виртуальных машин и нарушения функций безопасности. Это включает в себя отключение средств защиты конечных точек, вмешательство в работу виртуальных коммутаторов и подготовку виртуальных машин к масштабному развертыванию программ-вымогателей.
Рис. 1. Фрагмент платформы Huntress, на котором показано, как злоумышленник манипулирует Hyper-V
Этот сдвиг подчёркивает растущую и вызывающую беспокойство тенденцию: злоумышленники нацеливаются на инфраструктуру, которая управляет всеми хостами, и, получив доступ к гипервизору, значительно усиливают эффект от своего вторжения.
Обеспечьте безопасный доступ, применяйте принцип наименьших привилегий и разделите уровни управления
Если злоумышленник получит административные учетные данные для гипервизора, он сможет развернуть программы-вымогатели, которые затронут все виртуальные машины на хосте. Кроме того, использование учетных записей, присоединенных к домену (например, учетных записей Active Directory (AD) для ESXi), повышает риск горизонтального перемещения.
Что делать:
- Используйте локальные учётные записи ESXi. Не используйте для управления учётные записи администраторов домена общего назначения. Вместо этого создайте выделенные локальные учётные записи ESXi или строго ограниченные, проверенные учётные записи домена с необходимыми разрешениями. Если учётная запись администратора домена будет скомпрометирована, такое разделение предотвратит немедленный несанкционированный доступ к гипервизору и его виртуальным машинам.
- Обеспечьте многофакторную аутентификацию (MFA). Это обязательное условие для всей критически важной инфраструктуры. Обеспечьте MFA для интерфейсов управления хостами и доступа к vCenter, чтобы защититься от кражи учётных данных. Злоумышленник, получивший доступ к имени пользователя и паролю, будет заблокирован, что значительно повысит вероятность успешного взлома. Этот контроль обеспечивает надежную защиту от распространенных видов фишинга и атак методом перебора. Используйте надежные пароли, хранящиеся в защищенном хранилище паролей. Учетные данные ESXi должны быть максимально надежными и храниться только в специальном хранилище паролей, а не в общих документах или менее защищенных местах. Это предотвращает раскрытие учетных данных с помощью распространенных векторов атак, таких как скомпрометированные общие папки или небезопасные методы управления паролями.
- Изолируйте сеть управления хостом. Отделите сеть управления гипервизором от рабочей сети и сетей обычных пользователей. Создайте выделенную виртуальную локальную сеть или сегмент сети, которые будут логически и/или физически отделены. Ограничив количество конечных точек, которые могут даже пытаться подключиться к интерфейсу управления гипервизором, вы значительно сократите потенциальную поверхность атаки.
- Разверните промежуточный сервер или бастионный сервер. Чтобы обеспечить аудит и контроль всего административного доступа, разверните промежуточный сервер или бастионный сервер, к которому ИТ-администраторы должны подключаться в первую очередь, прежде чем переходить к гипервизору. Такая настройка исключает прямые подключения с потенциально менее защищенных рабочих станций администратора. Окно перехода действует как контролируемая контрольная точка, позволяя записывать сеансы, протоколировать все команды и применять политики безопасности перед предоставлением доступа к критически важной инфраструктуре.
- Применяйте принцип наименьших привилегий (PoLP). Строго ограничьте доступ к уровню управления (vCenter и отдельным хостам). Предоставьте администраторам и служебным учетным записям только минимально необходимые роли для выполнения административных функций, таких как управление ресурсами или установка исправлений. Внедрение PoLP гарантирует, что потенциальная компрометация одной учетной записи не приведет к массовым изменениям во всей виртуализированной среде.
- Ограничьте доступ к управлению выделенными административными устройствами. Ограничьте доступ к интерфейсу управления ESXi определенными административными устройствами со статическими IP-адресами. Это создает дополнительный барьер, гарантирующий, что только известные авторизованные конечные точки смогут подключиться к гипервизору, что еще больше снижает вероятность атаки.
Защитите среду выполнения гипервизора и обеспечьте контроль над кодом и его выполнением
Одна из уникальных угроз, связанных с программами-вымогателями на уровне гипервизора, заключается в том, что, проникнув на хост, злоумышленник может запускать код на уровне гипервизора, обходя средства контроля гостевой ОС. Вам необходимо усилить защиту хоста, чтобы он запускал только ожидаемый, подписанный код и доверенные модули.
Что делать:
- Включите расширенную настройку хоста VMkernel.Boot.execInstalledOnly = TRUE, чтобы на хосте можно было запускать только двоичные файлы, установленные с помощью подписанных VIB-файлов. Это предотвратит запуск пользовательских вредоносных двоичных файлов на хосте.
- Отключайте/закрывайте ненужные службы, такие как SSH или ESXi Shell, когда они не используются; включите режим блокировки.
Убедитесь, что гипервизор обновлен и защищен, а открытые поверхности сведены к минимуму
Злоумышленники активно атакуют хосты ESXi, используя известные уязвимости для массового шифрования. 0-дневные уязвимости и CVE вряд ли станут наиболее распространенной/реальной причиной взлома, скорее всего, это будут пробелы в сегментации безопасности. Тем не менее установка обновлений крайне важна.
Например, CVE-2024-37085 прекрасно иллюстрирует этот риск, связанный с гипервизором. Эта уязвимость позволяет злоумышленникам с соответствующими разрешениями в Active Directory обходить аутентификацию и мгновенно получать полный административный контроль над хостом ESXi, что приводит к массовому шифрованию всех виртуальных машин за считанные секунды.
Эксплойт работает, потому что уязвимые хосты ESXi автоматически предоставляют полные права администратора группе AD «Администраторы ESX». Злоумышленники просто воссоздают эту группу, чтобы сразу получить доступ к управлению.
Такие первоначальные компрометирующие действия часто начинаются с незащищённых интерфейсов управления или открытых протоколов, таких как Service Location Protocol (SLP), которые обеспечивают лёгкую точку входа.
Что делать:
- Ведите учёт всех хостов ESXi (и связанных с ними компонентов управления, таких как vCenter) и их версий.
- Отдавайте приоритет исправлениям и обновлениям системы безопасности от производителя, особенно в отношении уязвимостей, связанных с гипервизором.
- Отключите или ограничьте доступ к службам, которые вам не нужны, или убедитесь, что они не доступны извне. Протокол определения местоположения служб (SLP/порт 427) используется такими группами вымогателей, как ESXArgs, и должен быть отключен. Следуйте официальным рекомендациям VMware по устранению уязвимостей.
- Убедитесь, что хосты ESXi не подключены напрямую к интернету для управления. Используйте VPN, бастионные хосты или изолированные сети управления.
Стратегия резервного копирования, неизменяемые снимки и возможность быстрого восстановления
Даже при надежной защите риск сохраняется. Уровень гипервизора подвержен высокому риску; резервное копирование обязательно. Во многих руководствах подчеркивается, что восстановление — это последняя линия защиты. Программы-вымогатели, нацеленные на ESXi, обычно шифруют VMDK и файлы хоста; без надежного резервного копирования вам, возможно, придется заплатить.
Что делать:
- Используйте правило резервного копирования «3-2-1»: храните как минимум три копии данных на двух разных носителях и одну копию вне офиса/вне сети гипервизора.
- Используйте неизменяемые резервные копии или моментальные снимки, чтобы программы-вымогатели не могли их изменить или удалить.
- Не подключайте хранилище резервных копий к Active Directory или любой другой централизованной системе управления идентификацией. Вместо этого используйте отдельные локальные учетные записи, не присоединенные к домену, чтобы предотвратить распространение программ-вымогателей непосредственно в критически важном хранилище резервных копий с помощью скомпрометированных учетных данных AD.
- Убедитесь, что резервные копии содержат полные образы виртуальных машин и соответствующее состояние гипервизора, чтобы можно было быстро выполнить восстановление.
- Регулярно проверяйте резервные копии. Убедитесь не только в том, что вы можете подключить резервную копию и получить доступ к файлам, но и в том, что ваша операционная система полностью запускается и вы можете войти в систему, используя известные учётные данные.
- Как минимум, проводите учения по полному восстановлению раз в год. Предположения приводят к увеличению времени простоя. Вот несколько дополнительных рекомендаций:
- Проводили ли вы тестирование в удаленных и/или резервных местах?
- Можете ли вы подтвердить, что ваши серверы подключены к нужной сети? Можете ли вы получить доступ к этим резервным серверам с рабочих конечных точек?
- Есть ли в брандмауэре резервного сайта/резервного места необходимые списки разрешенных IP-адресов и правила брандмауэра для обеспечения надлежащей связи с критически важными инструментами, такими как EDR, RMM и VPN-клиенты?
Отслеживайте, выявляйте аномалии и предполагайте наличие взлома (многоуровневая защита)
Поскольку уровень гипервизора часто менее заметен для традиционных инструментов обеспечения безопасности конечных точек, таких как EDR, вам нужна альтернативная стратегия обнаружения. Злоумышленники часто выполняют такие действия, как изменение уровня принятия VIB, включение SSH, отключение режима блокировки или создание новых учетных записей администратора, чтобы подготовить почву для развертывания программ-вымогателей.
Без мониторинга вы можете обнаружить событие только после завершения шифрования.
Что делать:
- Направляйте журналы ESXi в SIEM и создавайте оповещения о ключевых подозрительных событиях (таких как новый вход в систему с правами root, включение службы, изменение статуса принятия VIB, отключение хранилища данных).
- Отслеживайте изменения в конфигурациях. Если на каком-либо хосте отключен режим блокировки, включен SSH или отключено execInstalledOnly, отметьте его для проверки.
- Контролируйте сетевой трафик. Помните, мы рекомендовали размещать панели управления ESXi и другой критически важной инфраструктурой в отдельной виртуальной локальной сети или сегменте сети? Теперь пришло время искать необычные IP-адреса источников, обращающихся к интерфейсу управления гипервизором (в идеале следует разрешать доступ только с промежуточного сервера), попытки горизонтального перемещения или большие объёмы операций ввода-вывода в хранилище данных, характерные для шифрования виртуальных машин.
- Используйте модель нулевого доверия для управления гипервизором. Предполагайте, что учётные данные могут быть скомпрометированы, и настраивайте оповещения соответствующим образом.
- В отличие от традиционных форматов системного журнала, ESXi разделяет журналы по конкретным действиям на отдельные файлы. Ниже перечислены наиболее важные файлы журналов для обнаружения и расследования случаев компрометации гипервизора: /var/log/auth.log (события аутентификации), /var/log/hostd.log (активность агента хоста), /var/log/shell.log (команды оболочки ESXi) и /var/log/vobd.log (демон наблюдателя VMware). Инструкции по настройке журналов см. в документации Broadcom и стратегиях защиты ESXi от Sygnia.
При сотрудничестве со сторонним поставщиком услуг SOC или MDR рассмотрите возможность внедрения модели совместной ответственности. У вашего внешнего партнера по обеспечению безопасности не будет необходимого бизнес-контекста, чтобы отличить плановое внутреннее обслуживание от взлома в два часа ночи.
Это различие имеет решающее значение: сторонний SOC лучше всего подходит для выявления универсальных угроз, таких как программы-вымогатели. Кроме того, мы рекомендуем вашей службе внутренней безопасности сосредоточиться на выявлении внутренних угроз и действий, контекст которых могут определить только они, например поздний вход в систему с последующим включением SSH.
Чтобы эта модель работала эффективно, ИТ-команды должны строго соблюдать процедуры контроля изменений и сообщать о всех ожидаемых изменениях в гипервизоре службе внутренней безопасности. Это гарантирует, что SOC будет в курсе всех планируемых действий, а все стороны смогут сосредоточить свои усилия на наиболее эффективных задачах.
Заключение
Для защиты гипервизоров на «голом железе», таких как ESXi, от программ-вымогателей требуется многоуровневый упреждающий подход. От установки исправлений и контроля доступа до усиления защиты во время выполнения и обеспечения готовности к восстановлению, а также обнаружения и ведения журналов — необходимо предусмотреть все варианты.
Если вам нужны более подробные инструкции по подготовке к худшему сценарию, ознакомьтесь с нашим руководством по планированию аварийного восстановления. Сейчас самое время спросить у руководства вашей организации: когда мы в последний раз полностью обновляли и тестировали наши планы восстановления и аварийного восстановления, в частности проверяли возможность восстановления и запуска всех гостевых виртуальных машин?
Несмотря на все наши усилия по предотвращению и обнаружению угроз, организациям следует быть готовыми к возможному успешному взлому. Если вы столкнулись со взломом среды ESXi, рекомендуем ознакомиться с этим подробным руководством по реагированию на инциденты в среде ESXi. В руководстве подробно описаны процедуры реагирования на инциденты и криминалистические артефакты, специально предназначенные для сред ESXi.
Используя Huntress, вы уже можете применять многие из этих методов на уровне операционной системы или конечной точки. Но гипервизор требует такого же тщательного подхода (а зачастую и более строгого) из-за возможности массового воздействия.
Если вы внедрите рекомендации по защите, изложенные в этой статье, в свою среду и процессы обеспечения безопасности, вы значительно повысите уровень защиты от программ-вымогателей.
По данным Huntress Labs.