Безопасность систем виртуализации: атаки на разных уровнях и последствия ошибок в конфигурации

Введение

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

Недавно глобальная команда экстренного реагирования на киберинциденты «Лаборатории Касперского» (GERT) расследовала два инцидента с программами-вымогателями в инфраструктурах ESXi и Proxmox. В обоих случаях слабый контроль доступа, недостаточная сегментация сети, открытые службы администрирования и небрежное управление привилегированными учетными данными позволили злоумышленникам совершить атаки с ощутимым ущербом. В одном из случаев система мониторинга с доступом к уровню виртуализации содержала пароль пользователя root, который также применялся в других системах. Когда злоумышленник использовал эту цепочку атаки, ему хватило стандартного административного доступа, чтобы скомпрометировать сразу несколько хостов — без побега из виртуальной машины (ВМ).

Эти инциденты наглядно демонстрируют, почему установка исправлений и безопасная конфигурация должны идти рука об руку. Полностью обновленный гипервизор все равно можно скомпрометировать через общий пароль, учетную запись мониторинга с избыточными привилегиями, открытый SSH-доступ или интерфейс администрирования, доступный из общей серверной сети. В руководстве NIST безопасные базовые конфигурации, ограниченный административный доступ, актуальные обновления и мониторинг всех уровней представлены как часть единого комплекса надлежащих практик безопасности.

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

Организация защиты сложносоставной системы

Виртуальная среда предприятия — это не только инфраструктура Hyper-V, VMware или Docker, а целый стек, состоящий из взаимосвязанных компонентов. Над гипервизорами и средами выполнения контейнеров располагаются административные консоли, инструменты оркестрации, платформы мониторинга и учетные записи автоматизации. Уровни связаны между собой через реестры, хранилища образов, виртуальные коммутаторы, хранилища данных и системы резервного копирования. Приложения и бизнес-сервисы располагаются внизу стека, тогда как значительная часть административных полномочий сконцентрирована на вершине.

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

Первый случай: от сетевого мониторинга к шифрованию среды ESXi

Исходной точкой расследования стали следы активности программы-вымогателя BlackNevas, обнаруженные на Windows-системе в сегменте с виртуальным контроллером домена. В артефактах UserAssist были зафиксированы запуски RMM-инструмента AnyDesk и исполняемых файлов GMER. Кроме того, выяснилось, что для мониторинга виртуальной инфраструктуры в среде применялась платформа PRTG Network Monitor.

Артефакты UserAssist

По имеющимся уликам мы установили, что развернутая система PRTG имела широкий доступ к хостам ESXi, а один и тот же пароль для пользователя root использовался на разных узлах. Получив доступ к среде мониторинга, злоумышленник извлек учетные данные ESXi и через SSH подключился к хостам, на которых использовался тот же пароль. Таким образом, платформа мониторинга, хранилище учетных данных и средства прямого администрирования составили единую цепочку атаки.

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

Атакующий получил root-доступ к хостам ESXi и с помощью команды esxcli обошел системное ограничение, отключив политику execInstalledOnly, чтобы запустить исполняемый файл шифровальщика, а также удалить логи для сокрытия следов. Рассмотрим подробнее хронологию начальной компрометации хоста.

Временная шкала ESXi (192.168.*.*)

В это же время на другом хосте с тем же паролем пользователя root были зафиксированы следующие действия:

Временная шкала ESXi (172.16.*.*)

Второй случай: как заметки с учетными данными привели к компрометации Proxmox

Команда GERT расследовала инцидент с вымогательством, связанный с группой The Gentlemen. В ходе инцидента атакующие получили доступ к среде Proxmox, используя информацию, собранную за время пребывания в системе между начальным доступом и активными действиями. На скомпрометированной рабочей станции системного администратора злоумышленники обнаружили административные учетные данные, сохраненные в заметках в открытом виде. Именно эти записи позволили им войти в Proxmox от имени учетной записи root.

Затем злоумышленники с помощью скомпрометированной учетной записи root активировали VNC через WebSocket, получив широкие возможности управления средой Proxmox. Такой уровень доступа впоследствии позволил им загрузить и запустить программу-вымогатель внутри кластера, в результате чего была зашифрована вся виртуальная среда. Ниже приведены записи логов, в которых учетная запись root используется для доступа к другим хостам при помощи VNC через WebSocket.

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

Почему ошибки в конфигурации привели к масштабным последствиям

В обоих случаях проявились небезопасные практики конфигурирования, усугубившие последствия для хостов. Далее мы разберем каждую ошибку конфигурации, чтобы показать, как она способствовала развитию компрометации, и расскажем, как избежать ее.

Наследование избыточных привилегий платформой мониторинга

В первом случае платформа мониторинга имела полномочия, выходящие за рамки сбора данных о состоянии и производительности. На ней хранились или могли использоваться учетные данные с правами, обеспечивающими прямой доступ к ESXi. Как следствие, компрометация системы мониторинга обернулась компрометацией плоскости управления. Учетные записи мониторинга следует выделять под конкретные задачи и наделять только теми правами, которые необходимы развернутым сенсорам.

Использование неуникальных учетных данных

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

Прямой root-доступ в обход централизованного управления

Используя прямой SSH-доступ, злоумышленники аутентифицировались с root-правами, загрузили бинарный файл и изменили параметры безопасности, обойдя ограничения для ролей vCenter. Broadcom, материнская компания VMware, рекомендует управлять vSphere через vCenter, отключать SSH в штатном режиме работы и везде, где это уместно, использовать режим изоляции (Lockdown Mode). Служебные учетные записи, действительно необходимые для работы, должны быть оформлены как явные исключения, а не включены в общую группу администраторов.

Нехватка строгих механизмов безопасности

Первая попытка запуска была заблокирована политикой execInstalledOnly, но у злоумышленников было достаточно привилегий, чтобы ее отключить. Согласно документации Broadcom, существуют принудительные настройки, сочетающие политику execInstalledOnly с UEFI Secure Boot и защитой конфигурации на базе TPM. Эти меры безопасности нужно включить, проверить и отслеживать на предмет изменений. Механизм защиты, для незаметного отключения которого достаточно той же учетной записи, что применяется в повседневном администрировании, станет лишь незначительным препятствием на пути злоумышленника, скомпрометировавшего эту учетную запись.

Незащищенное хранение учетных данных

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

Как перекрыть эту цепочку атаки

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

• Разделите мониторинг и администрирование. Создайте выделенные учетные записи мониторинга для каждой платформы и ограничьте их минимальным набором объектов и действий, необходимых для работы сенсоров. Не используйте для планового опроса хостов root-доступ к ESXi и другие учетные записи, предусмотренные для экстренных случаев. Не допускайте интерактивных административных сессий с серверов мониторинга, если они не предусмотрены отдельно утвержденным сценарием поддержки. Этот же принцип следует применять и за пределами VMware.
• Смените хранящиеся root-пароли. Найдите все вхождения учетных данных гипервизоров, систем управления, хранилищ данных и систем резервного копирования в инструментах мониторинга, скриптах, запланированных задачах, менеджерах подключений и конфигурациях служб. Замените использование статических паролей на получение секретов из хранилища, идентификацию через брокер удостоверений или ограниченные API-токены, если это поддерживает платформа. Фиксируйте каждое обращение к секрету и выполняйте его ротацию после использования в экстренных случаях и после компрометации.
• Ограничьте прямой доступ к хостам. Проводите штатное администрирование ESXi через vCenter и включайте соответствующий Lockdown Mode после проверки зависимостей мониторинга, резервного копирования и восстановления. SSH и ESXi Shell должны быть отключены по умолчанию. Если для поддержки требуется доступ по SSH, включайте его на заданный период, ограничив допустимые исходные адреса и настроив оповещения об активации служб, root-входе и изменениях в списке пользователей, которым разрешено подключение по SSH.
• Используйте специализированное защитное решение. В нашем портфолио есть решение Kaspersky Cloud Workload Security (KCWS), которое снижает риски атак в виртуальных средах. Оно включает два продукта: Kaspersky Security для виртуальных и облачных сред (KHCS) и Kaspersky Container Security (KCS). Kaspersky Security для виртуальных и облачных сред предназначен для защиты виртуализированной инфраструктуры, частных ЦОД и гибридного облака. Запатентованная архитектура Легкого агента создает минимальную нагрузку на ресурсы и не снижает производительность, а подробная визуализация инфраструктуры в единой консоли позволяет администраторам видеть всю гибридную сеть и полностью контролировать ее. Kaspersky Container Security охватывает все этапы жизненного цикла контейнерных приложений — от разработки до эксплуатации. В числе прочего решение позволяет выявлять ошибки в конфигурации с помощью специализированного сканера образов, файловых систем и репозиториев, содержащих IaC-файлы, такие как Terraform, CloudFormation, шаблоны Azure ARM, пакеты Helm (Helm charts) и Dockerfiles.
• Рассматривайте изменения конфигурации как события безопасности. Настройте оповещения об изменениях параметров execInstalledOnly, Secure Boot, Lockdown Mode, SSH, локальных учетных записей, списков пользователей с особыми правами, правил сетевого экрана и настроек удаленного логирования. Зафиксируйте базовое состояние конфигурации и проверьте, сможет ли команда безопасности обнаружить несанкционированное изменение. Настроенная единожды безопасная конфигурация не гарантирует, что заданные параметры по-прежнему действуют на хосте.
• Изолируйте административную сеть. Администрирование гипервизоров, мониторинга, резервного копирования, хранилищ и кластеров должно вестись через изолированные сети управления с ограниченным доступом. Должны быть разрешены только необходимые для работы комбинации исходных и целевых служб. Административные рабочие места должны подключаться через защищенные jump-хосты с использованием именных учетных записей и многофакторной аутентификации.
• Защищайте логи и системы резервного копирования и восстановления. Пересылайте логи мониторинга, идентификации и сетевой активности ESXi, vCenter и Proxmox в защищенное хранилище, которое нельзя будет удалить через скомпрометированную учетную запись администратора. Для платформ резервного копирования необходимо предусмотреть отдельные учетные записи, ограничения маршрутов администрирования и хранение копий для восстановления за пределами обычного административного доступа.

Проверки конфигурации при мониторинге среды виртуализации

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

Более широкая поверхность атаки

Даже защищенность маршрутов мониторинга и передачи учетных данных сама по себе не обеспечивает безопасность среды. Виртуализация также полагается на границы изоляции, доверенные образы, API управления, виртуальные сети, хранилища и резервные копии. Каждый уровень требует отдельного механизма контроля и оставляет цифровые следы в разных местах.

Побег из ВМ и контейнеров

При побеге из ВМ код в гостевой системе преодолевает границу виртуализации и влияет на хост или другую гостевую систему. Соответствующая уязвимость может скрываться в виртуальном устройстве, компоненте интеграции, интерфейсе hypercall или другом компоненте, транслирующем запросы гостевой системы на хост. Если такой побег возможен, получение контроля над одной ВМ может привести к контролю над физическим сервером и всеми рабочими нагрузками на нем. Уязвимость CVE-2025-22224 в VMware наглядно продемонстрировала этот риск: атакующий с правами администратора внутри ВМ мог выполнить код от имени процесса VMX на хосте, при этом Broadcom подтвердила эксплуатацию этой уязвимости в реальных условиях.

Побег из контейнера может привести к сопоставимым последствиям, но отправная точка в этом случае другая. В отличие от ВМ, контейнеры Linux используют ядро хоста совместно, поэтому их изоляция строится по иной модели. Пространства имен (namespace) ограничивают, какие объекты видны процессам; контролируемые группы (cgroups) управляют распределением ресурсов; возможности (capabilities) разбивают привилегии root на отдельные права. Уязвимость ядра или среды выполнения может нарушить эту изоляцию. Уязвимость Copy Fail (CVE-2026-31431) — пример такой ошибки в ядре Linux. Если код уже выполнялся в контейнере, он мог через сокет шифрования AF_ALG изменить страницы в общем кэше страниц ядра Linux. Поскольку хост и другие контейнеры могут обращаться к тем же кэшированным страницам, воздействие не было ограничено рамками одного контейнера. Исправление было реализовано в обновлении ядра, а в Docker Engine 29.4.3 были изменены профили с ужесточением параметров безопасности по умолчанию, чтобы снизить риски на хостах без соответствующего обновления.

Небезопасные конфигурации также могут создать пробелы в защитном периметре. Привилегированный режим, избыточные права, смонтированные каталоги хоста с доступом на запись или доступ к сокету Docker могут нарушить изоляцию без какого-либо программного эксплойта. Например, уязвимость CVE-2024-21626 в runc была связана с утечкой файловых дескрипторов, которые могли обеспечить вредоносному образу или процессу контейнера доступ к файловой системе хоста.

Различия в моделях изоляции влияют на ход расследования. ВМ часто рассматривают как отдельный компьютер со своим ядром, памятью и диском. Контейнер — это набор процессов хоста, изолированных в пространствах имен. Если ИБ-эксперты соберут улики только из файловой системы контейнера, они могут упустить оставшиеся на хосте ключевые артефакты процессов, сокетов и управляющей плоскости.

Образы и шаблоны

Скомпрометированный золотой образ ВМ или базовый образ контейнера может распространяться через обычные механизмы автоматизации. Типичные риски связаны с неофициальными публичными образами, изменяемыми (mutable) тегами, токенами сборки с избыточными полномочиями, а также с возможностью извлечения секретов из устаревших слоев системы или восстановлением уязвимого ПО или забытых учетных записей из необновленных шаблонов. Сканирование отчасти помогает, однако оно не устанавливает источник артефакта и не гарантирует, что в рабочей среде развернут именно протестированный и согласованный образ. Следует применять контролируемые среды сборки, записи о происхождении, контроль цифровых подписей и плановую пересборку образов из доверенных источников.

Административные инструменты и API

Украденная учетная запись vCenter, открытый API Docker, роль Portainer с избыточными правами или скомпрометированная консоль резервного копирования могут обеспечить злоумышленнику менее сложную траекторию атаки, чем использование эксплойта для побега. В бюллетене Portainer GHSA-7fw3-x4r2-g7wc описана ошибка, при которой прокси валидировал только один формат bind-mount и пропускал эквивалентное API-представление, в результате чего аутентифицированный пользователь без административных привилегий, но с правом создания контейнеров, мог получить доступ к путям хоста. Запрос проходил в среду выполнения как корректный, хотя на уровне управления авторизация уже была отклонена.

Административные операции копирования файлов также заслуживают внимания. Компания Docker устранила уязвимости в обработке архивов и монтировании, описанные в CVE-2026-41567, CVE-2026-41568 и CVE-2026-42306. Эти случаи требовали особых условий, а также действий оператора или API. Их следует воспринимать как напоминание обновлять демон и записывать данные об операциях копирования: кто их инициировал, с каким контейнером они производились, исходные и целевые пути, а также результат.

Виртуальные сети, хранилища данных и резервные копии

Горизонтальный обмен данными между виртуальными рабочими нагрузками может не выходить за пределы одного хоста и ускользать от физического сенсора. Трафик управления, миграции, хранилищ данных и рабочих нагрузок должен быть разделен на отдельные зоны с фильтрацией между ними. Мгновенные снимки (snapshots) и файлы памяти могут содержать учетные данные, а недостаточно строгие права доступа к хранилищу данных могут обеспечить доступ к виртуальным дискам. Широкий доступ систем резервного копирования, необходимый для восстановления сервисов, делает их привлекательной целью для атакующего, стремящегося удалить точки восстановления или получить доступ к нескольким хостам.

Примеры поверхностей атаки по уровням

Систематизируем описанные векторы атаки и методы их нейтрализации:

Заключение

В описанных в статье инцидентах, расследованных командой GERT, злоумышленникам не пришлось ломать изоляцию ВМ. Они выстроили маршруты атак, эксплуатируя избыточные права мониторинговой системы, незащищенное хранение паролей, извлекаемые неуникальные учетные данные пользователя root, широкий доступ из сети управления и прямое администрирование по SSH. Отдельно каждый компонент выглядел легитимным, но в комплексе они позволили единичной компрометации достичь хостов виртуализации и их рабочих нагрузок.

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