Вымогательское ПО на уровне гипервизора: атаки с применением штатных механизмов ESXi и vCenter

Недавно глобальная команда экстренного реагирования на киберинциденты «Лаборатории Касперского» (GERT) расследовала случай, в ходе которого злоумышленники на протяжении десяти дней разрушали виртуализированную инфраструктуру организации. Вредоносная кампания охватила четыре хоста ESXi и все размещенные на них виртуальные машины (ВМ), два экземпляра vCenter Server Appliance и всю подключенную инфраструктуру резервного копирования. Сообщения о выкупе указывали на группу BlackNevas, впервые замеченную в ноябре 2024 года. Интересно, что атакующие не эксплуатировали никакие уязвимости на уровне виртуализации: не использовались ни побег из гостевой ОС на хост (guest-to-host), ни повреждение памяти гипервизора. Каждое вредоносное действие в отношении ESXi производилось через легитимные интерфейсы управления VMware.

В сентябре 2021 года в открытый доступ утекли исходные коды программы-вымогателя Babuk, в том числе версии для ESXi, в результате чего ESXi-вымогатель оказался в распоряжении киберпреступников со сравнительно низким уровнем технических навыков. Не менее десяти появившихся впоследствии семейств программ-вымогателей полагались на эти исходники. Часть из них была связана с группами, которые без такой помощи были неспособны на разработку ESXi-совместимого блокировщика с нуля. Несколько операторов, по данным наших наблюдений, сочетали ESXi-блокировщики на основе Babuk со сборками LockBit для Windows, которые стали доступны в результате утечек. Стоит отметить, что версия Babuk для ESXi эффективна против как устаревших, так и регулярно обновляемых систем, однако в данном случае атакованные организации работали с неподдерживаемыми версиями ESXi, более уязвимыми к атакам.

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

Как гипервизор меняет экономику вымогательских кампаний

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

Согласно глобальному отчету «Лаборатории Касперского» о предоставлении услуг кибербезопасности, программы-вымогатели фигурировали в 39,4% инцидентов, обработанных GERT в 2025 году, и данные на начало 2026 года показывают, что эта угроза по-прежнему остается серьезной. Еще в 2023 году компания SentinelOne опубликовала отчет о том, что ESXi-версии ряда семейств вымогательского ПО основаны на утекшем в Сеть исходном коде Babuk, который существенно упростил разработку собственных ESXi-образцов для групп без соответствующих навыков. С тех пор программы-вымогатели для виртуализированных сред стали доступны более широкому кругу злоумышленников, и эта тенденция сохраняется по сей день.

«Полупрозрачность» ESXi

ESXi — специализированный гипервизор, основанный на проприетарном ядре VMkernel компании VMware. Он имеет некоторое сходство с Linux (и другими Unix-подобными системами), принимает команды Linux и выполняет некоторые Linux-подобные программы, но отличается от дистрибутивов Linux общего назначения. В справочной статье Broadcom указано, что готовые средства безопасности, разработанные для ОС общего назначения, не могут работать на ESXi в штатном режиме и что прямая установка сторонних агентов и антивирусов на ESXi и vCenter Server Appliance (VCSA) не поддерживается. Следовательно, ИБ-специалисты вынуждены в значительной мере полагаться на встроенные механизмы усиления защиты, телеметрию уровня управления, интеграцию безагентных решений безопасности и сбор телеметрии из инфраструктуры за пределами хостов ESXi.

Гостевые операционные системы, как правило, защищены с помощью EDR, но когда процесс на стороне ESXi изменяет диск виртуальной машины (VMDK) или связанный файл хранилища данных, агент EDR внутри гостевой ОС не может напрямую наблюдать за процессом гипервизора, выполняющим операцию, или определить его происхождение. В телеметрии гостевой ОС могут быть зафиксированы последствия, например ошибки ввода-вывода или внезапная остановка, однако сами вредоносные операции выполняются за ее периметром. Именно поэтому в рассматриваемом инциденте в основе восстановленной хронологии событий лежит телеметрия самого хоста и уровня управления.

Как злоумышленники проникают на уровень виртуализации

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

• эксплуатация уязвимостей;
• использование учетных данных из Windows-инфраструктуры;
• злоупотребление интеграцией с Active Directory;
• использование учетных данных из инфраструктуры резервного копирования в качестве моста к другим системам.

Эксплуатация уязвимостей

В ходе расследования этого инцидента мы не нашли доказательств того, что атакующие использовали уязвимости ESXi в качестве вектора первоначального доступа. Тем не менее не стоит недооценивать важность публично раскрытых уязвимостей, поскольку именно с их помощью была скомпрометирована инфраструктура управления виртуализацией. Эксплойты для таких уязвимостей широко доступны в Сети, поэтому они считаются одним из наиболее вероятных путей входа. Ниже мы приводим несколько примеров уязвимостей в средах виртуализации, которыми успешно пользовались злоумышленники. Например, группа Twelve выстроила цепочку из уязвимостей CVE-2021-21972 и CVE-2021-22005, чтобы разместить веб-шелл непосредственно на узле vCenter. Затем веб-шелл загрузил бэкдор, который внедрил разделяемый объект в демон SSH, обеспечив закрепление в системе. Обратите внимание, что эти уязвимости не связаны с рассматриваемым инцидентом и приведены исключительно в качестве иллюстрации данного вектора первоначального доступа. Эти сведения могут помочь специалистам по ИБ точнее определить поверхность атаки в своей организации и правильно приоритизировать установку исправлений.

CVE	Уровень	Влияние на безопасность	KEV*	Релевантность
CVE-2021-21974	OpenSLP в ESXi	Удаленное выполнение кода в уязвимой службе OpenSLP	Нет	Ранее фигурировала в контексте обсуждения программы-вымогателя ESXiArgs.
CVE-2021-22005	vCenter Server	Загрузка произвольного файла, ведущая к удаленному выполнению кода	Да	Задокументировано применение в вымогательских операциях.
CVE-2021-21972	Плагин vCenter	Удаленное выполнение кода через плагин vSphere Client без аутентификации	Да	Задокументировано применение в вымогательских операциях.
CVE-2021-21985	Плагин vCenter VSAN Health Check	Удаленное выполнение кода	Да	Задокументировано применение в вымогательских операциях.
CVE-2023-34048	DCERPC в vCenter	Удаленное выполнение кода при записи за пределы допустимого диапазона	Да	Затрагивающая vCenter известная уязвимость, которая реально эксплуатировалась. Несмотря на отсутствие данных о применении таких эксплойтов в инцидентах с программами-вымогателями, эту уязвимость стоит иметь в виду из-за ее связи с уровнем управления виртуализацией.
CVE-2024-37085	Интеграция AD в ESXi	Наличие привилегий в AD может обеспечить полные административные права в среде ESXi	Да	Задокументировано применение в вымогательских операциях. Также наличие этой уязвимости подчеркивает риски связывания идентификаторов AD с административным доступом к ESXi.
CVE-2024-38812 / 38813	DCERPC в vCenter	Удаленное выполнение кода / повышение привилегий до root	Да	Затрагивающие vCenter известные уязвимости, которые реально эксплуатировались. Несмотря на отсутствие данных о применении таких эксплойтов в инцидентах с программами-вымогателями, эти уязвимости стоит иметь в виду из-за их связи с уровнем управления виртуализацией.
CVE-2025-22224 / 22225 / 22226	ESXi/Workstation/Fusion	Цепочка для побега из гостевой ОС на хост (guest-to-host), требующая наличия привилегий в гостевой ОС	Да	Известные уязвимости, позволяющие выполнить цепочку атаки guest-to-host, которые реально эксплуатировались. Эксплуатация CVE-2025-22225 наблюдалась в инцидентах с программами-вымогателями. Однако эта цепочка атак требует привилегированного доступа к гостевой ВМ, из-за чего она считается менее критичной, чем удаленное выполнение кода без аутентификации.

* База данных Known Exploited Vulnerabilities (KEV), поддерживаемая американским Агентством по кибербезопасности и защите инфраструктуры (CISA). Отметка в колонке KEV указывает, что эксплуатация этой уязвимости наблюдалась в реальных атаках, но не обязательно в контексте вымогательского ПО. Если существует задокументированная связь с программами-вымогателями, об этом упоминается отдельно. Ни отметка KEV, ни факт эксплуатации этой уязвимости операторами программ-вымогателей не означают, что она была задействована в рассматриваемом инциденте.

Интеграция с Active Directory

Уязвимость CVE-2024-37085 наглядно демонстрирует, почему так важно разграничивать аутентификацию в различных системах, даже если на гипервизор установлены актуальные исправления безопасности. Эта уязвимость затрагивает хосты ESXi, на которых управление пользователями реализовано через AD. По данным Microsoft, она эксплуатировалась операторами программ-вымогателей, в том числе Akira и Black Basta, которые использовали особенности поведения группы ESX Admins для получения полных администраторских привилегий в ESXi. Агентство CISA включило эту уязвимость в свой каталог KEV и отметило, что она применялась в инцидентах с программами-вымогателями.

Уязвимость была исправлена в ESXi версии 8.0 U3. Для более старых систем Broadcom рекомендует следующие обходные меры:

• изменить значение esxAdminsGroupAutoAdd с true на false;
• изменить authValidateInterval с 1440 на 90 минут;
• по возможности убрать назначение группы ESX Admins по умолчанию.

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

Рекомендации для ИБ-специалистов

Избегайте ненужной прямой зависимости хостов ESXi от Active Directory. Если такая зависимость продиктована бизнес-требованиями, соблюдайте принцип минимальных привилегий: добавляйте в административные группы только те учетные записи, которым действительно нужен такой уровень доступа; используйте отдельные административные аккаунты с независимыми учетными данными для домена и для гипервизоров; ограничьте доступ к интерфейсам управления ESXi и vCenter лишь необходимыми для администрирования сегментами сети, учетными записями и рабочими станциями и непрерывно контролируйте изменения прав в ESXi. Настройте в vCenter управление доступом на основе ролей (RBAC) и федеративную идентификацию в качестве механизма доступа к администрированию виртуализации и не используйте обычные корпоративные учетные данные и неспециализированные группы домена для привилегированного доступа к vCenter или ESXi.

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

Третий путь не связан с уязвимостями. Административные учетные данные, хранящиеся на контроллерах домена, jump-серверах, в системах резервного копирования, в инфраструктуре идентификации или на рабочих станциях администраторов, могут предоставить доступ к vCenter или ESXi, если одни и те же учетные записи применяются в разных сегментах инфраструктуры. В базе MITRE ATT&CK указано, что техника Valid Accounts («Действительные учетные записи») применима к ESXi, и отдельно отмечено, что скомпрометированные учетные записи по умолчанию или доменные учетные записи могут обеспечить привилегированный доступ к другим системам.

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

Использование учетных данных из инфраструктуры резервного копирования в качестве моста к другим системам

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

Закрепление на уровне управления

Разобравшись с потенциальными рисками, вернемся к нашему случаю. Злоумышленникам удалось скомпрометировать через SSH узел vCenter, отвечающий за аварийное восстановление виртуализации, и установить на нем два уровня закрепления. Первый представляет собой MeshAgent — компонент легитимной платформы удаленного управления MeshCentral, устанавливаемый на конечные устройства. Второй — обратный туннель на базе Ligolo-ng, реализованный в виде службы systemd. Данное закрепление соответствует двум техникам MITRE ATT&CK: Systemd Service («Служба systemd», T1543.002) и Protocol Tunneling («Туннелирование протокола», T1572).

Хронология атаки была следующей. Злоумышленники аутентифицировались на узле vCenter с root-правами через SSH. Через 43 секунды они загрузили и развернули MeshAgent с помощью шелл-скрипта. Сессия SSH продлилась в общей сложности 2 минуты и 26 секунд. После ее завершения злоумышленники больше не подключались к скомпрометированному узлу через SSH, что снизило полезность мониторинга, охватывающего только интерактивные сессии SSH. Примерно через четыре часа они вернулись в систему через MeshAgent и установили туннель Ligolo-ng в качестве постоянной службы systemd.

Артефакт закрепления на узле vCenter: /etc/systemd/system/vmware-vdma.service

В unit-файле указан префикс, имитирующий принадлежность к VMware, задан путь к бинарному файлу — /opt/vmware/bin/, описаны правдоподобные сервисные функции узла, установлен параметр Restart=always. Не всякая нераспознанная служба с VMware-подобным именем является вредоносной — в среде могут также присутствовать пользовательские интеграции. Но если ее нет в списке доверенных служб организации — можно с высокой степенью уверенности сказать, что это признак компрометации, требующий немедленной проверки.

Выходя за рамки рассматриваемого инцидента, отметим, что в публичных источниках задокументированы и более продвинутые техники закрепления в ESXi-среде. Например, Mandiant зафиксировала использование вредоносных установочных пакетов vSphere Installation Bundle (VIB) в качестве механизма закрепления на скомпрометированных хостах ESXi. Это наглядный пример того, как злоумышленники с административными привилегиями могут закрепиться на уровне гипервизора, в том числе с сохранением доступа после перезагрузки хоста. Однако, как показывает наш случай, для этих целей бывает достаточно стандартных средств удаленного управления и службы systemd, если vCenter считается доверенным узлом и его мониторинг не ведется на должном уровне.

Трансформация vCenter в узел управления атакой

Одна из примечательных зафиксированных в инциденте техник — применение профилей хостов (Host Profile) vCenter. Профили хостов позволяют сохранять конфигурации и принудительно применять их к хостам ESXi. Профиль может распространяться на отдельные хосты, кластеры или все привязанные к нему хосты. Также он может включать подпрофили, охватывающие конкретные аспекты конфигурации, например аутентификацию. В частности, профили хостов могут содержать параметры режима техподдержки (TSM) и TSM-SSH.
В рассматриваемом инциденте злоумышленник использовал профили хостов, чтобы изменить состояние службы TSM-SSH и включить SSH на целевых хостах ESXi. В логах зафиксирована следующая последовательность действий:

Момент фиксации события	Источник	Наблюдаемое событие	Основной артефакт
T + 0	vCenter	Чтение конфигурации хоста через механизм профилей хостов	vpxa.log
T + 10 мин. 18 с.	vCenter	Передача измененной конфигурации для включения SSH	vpxa.log
T + 10 мин. 51 с.	vCenter/ESXi	Переход службы TSM-SSH в состояние «работает», то есть связь по SSH на хосте включена и он открыт для удаленного доступа	vpxa.log + vobd.log

Последовательность операций с профилем хоста, зафиксированная перед прямым доступом к ESXi

Обратите внимание, что 33-секундный интервал между передачей конфигурации и переходом TSM-SSH в состояние «работает» достаточно короток, что позволило нам быстро установить связь между этими событиями путем сравнения логов из разных источников. В общей сложности через 11 минут с момента первоначального чтения конфигурации злоумышленникам удалось перенастроить хост с отключенным в политиках SSH и активировать на нем поддержку прямого удаленного доступа. В дальнейшем атакующие инициировали прямой SSH-доступ к целевым хостам ESXi с IP-адреса узла vCenter, который, как правило, считается высокодоверенным источником подключения в управляющей сети.

Почему изменение конфигурации ESXi через vCenter нарушает периметр доверия?

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

Поэтому vCenter следует рассматривать как актив уровня Tier 0, требующий максимальной защиты. Административные учетные записи уровня управления нужно изолировать от обычного корпоративного администрирования, сетевой доступ — ограничить выделенными каналами управления, высокорисковые изменения конфигурации — привязать к строгой аутентификации и мониторингу, а трафик от vCenter к ESXi — не расценивать по умолчанию как доверенный, а тщательно сопоставлять с базовым профилем активности (паттерны соединений, порты, протоколы, исходные и целевые системы). Все значимые расхождения следует считать подозрительными и расследовать.

Способ высокоточного детектирования

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

Использование легитимных инструментов при компрометации ESXi и параметры, которые нужно отслеживать в связи с этим

Как только атакующие получают административные права в ESXi, для многих деструктивных действий им уже не требуются эксплойты. В каталоге проекта LOLESXi перечислены нативные бинарные файлы и скрипты ESXi, которые эксплуатировали злоумышленники. Среди этих файлов есть и административные утилиты, которые могут составлять список виртуальных машин, останавливать их и изменять конфигурацию. Использование этих инструментов аналогично технике Living-off-the-Land в Windows, только в данном случае целью является уровень управления гипервизором.

Существуют два механизма защиты ESXi, изменение которых можно расценивать как крайне подозрительное. Уровень допуска (acceptance level) определяет, какие пакеты VIB разрешено устанавливать на хост, а настройка execInstalledOnly — могут ли выполняться бинарные файлы, не входящие в перечень установленных. В документации Broadcom указано, что опция среды выполнения execInstalledOnly включена по умолчанию в ESXi 8, и приведено предупреждение, что ее отключение позволяет выполнять неизвестные не установленные в системе бинарные файлы и повышает риск запуска программы-вымогателя. Существует также одноименная принудительная настройка на уровне ядра (kernel enforcement). Она связана с опцией среды выполнения, но имеет некоторые отличия и может потребовать перезагрузки в случае изменения.

Параметр безопасности	За что отвечает	Почему его изменение подозрительно	Полезные артефакты
Уровень допуска хоста	Какие пакеты VIB можно устанавливать.	Понижение до менее доверенного уровня расширяет перечень принимаемых хостом пакетов.	esxcli / события конфигурации / esxupdate.log
execInstalledOnly (среда выполнения)	Выполнение бинарных файлов, не установленных через пакеты VIB.	Значение 0/FALSE позволяет выполнять код не установленных в системе программ.	vobd.log + расширенные настройки
execInstalledOnly (ядро)	Более строгая принудительная настройка на уровне загрузки VMkernel: допускается выполнение только тех файлов, которые были установлены через пакеты VIB и впоследствии не модифицировались.	Ослабление параметра может требовать перезагрузки и меняет базовый профиль безопасности.	Настройки ядра + история загрузки

Параметры безопасности ESXi, которые могут попытаться ослабить злоумышленники

Этап воздействия в среде ESXi

Остановка виртуальных машин перед разрушительным воздействием

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

Семейство вымогательского ПО	Наблюдавшийся или задокументированный подход к остановке ВМ
GwisinLocker, LockBit, Conti	Составление списка миров (процессов ВМ) с помощью команды esxcli vm process list и принудительное завершение отдельных миров командой esxcli vm process kill.
AvosLocker, RedAlert (также известно как N13V)	Единая цепочка команд консоли, выполняющая обе операции: составление списка миров и их принудительное завершение.
Hive, fcker.py	Выполнение команды vim-cmd vmsvc/power.off для зарегистрированных виртуальных машин.
Сборки RansomHub для ESXi	Собственная логика на C++, способная составлять список машин и останавливать их, не полагаясь на последовательность команд esxcli или vim-cmd.

Как различные семейства ESXi-блокировщиков завершают работу ВМ перед началом деструктивных файловых операций

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

Доставка полезной нагрузки и поведение FlowSsh

Злоумышленники доставили полезную нагрузку на ESXi через SFTP. В файле лога аутентификации (auth.log) содержался идентификатор клиента, связанный с FlowSsh — SSH-библиотекой компании Bitvise для C, C++ и .NET. FlowSsh поддерживает SFTP, запросы на удаленное выполнение, сессии интерактивной консоли и туннелирование — все эти возможности соответствуют наблюдавшейся модели доставки. При этом стоит отметить, что идентификация библиотеки должна опираться в первую очередь на идентификатор клиента, извлеченный из артефактов, а не только на поведенческие признаки.

После доставки полезной нагрузки атакующие выполнили приведенную ниже последовательность команд. Мы восстановили ее преимущественно по лог-файлу shell.log.

Момент фиксации события	Зафиксированная команда	Аналитическое примечание
T + 0	true	Проверка связи без выполнения действий (no-op) в отдельной сессии.
T + 1 с.	chmod +x /tmp/esx64	Отдельная сессия выполнения.
T + 1 мин. 48 с.	true	Вторая проверка no-op.
T + 1 мин. 49 с.	./tmp/esx64 /selftest	Отдельная сессия выполнения; этап валидации полезной нагрузки.

Перед каждой парой команд инициировалась сессия, в которой выполнялась только команда true. Этот повторяющийся паттерн характерен для автоматизированной настройки канала FlowSsh, но сам по себе не является надежным индикатором использования этого инструмента. Операторы могли вводить true и вручную, а проверки доступности могли генерироваться и другими средствами автоматизации. Поэтому эту последовательность нужно отслеживать как поведенческий шаблон, а не как уникальную сигнатуру FlowSsh. Ее ценность возрастает в сочетании с необычным идентификатором клиента SSH, размещением файлов в /tmp через SFTP, командой chmod и последующим самотестированием или запуском полезной нагрузки.

Трехчасовое окно самотестирования

Выполнение /selftest длилось примерно 16 секунд и произошло примерно за три часа до выполнения разрушительных действий (детонации). Предварительный тестовый запуск может указывать на то, что оператор проверял совместимость с целевой сборкой ESXi перед переходом к деструктивным операциям.

Возможность детектирования до этапа воздействия

Неожиданное появление исполняемого файла в /tmp с последующим его выполнением и доступом к /vmfs следует рассматривать как последовательность критической важности, предшествующую этапу воздействия. Хотя отдельные индикаторы, такие как chmod +x, могут выглядеть неоднозначно в отрыве от контекста, внезапный запуск только что размещенного в /tmp исполняемого файла сам по себе является серьезным индикатором вредоносной активности. Для большей уверенности нужно воссоздать по артефактам полную последовательность операций: промежуточное размещение полезной нагрузки, ее выполнение, валидацию и последующий доступ к уровню хранения ВМ.

Команда детонации и степень уверенности в индикаторах

Злоумышленники инициировали деструктивную активность следующей командой:

Зафиксированная команда детонации ESXi

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

Параметр	Зафиксированное в инциденте или подтвержденное по другим источникам действие	Степень уверенности в интерпретации
/p /vmfs/	Целевой путь — корень VMFS, где находятся файлы виртуальных машин.	Высокая: прямая команда + штатный путь платформы.
/depth 5	Глубина рекурсии по каталогам.	Высокая: стандартное значение аргумента и наблюдавшееся в инциденте расположение.
/wipe	Перезапись/стирание данных; артефакты ._wipe присутствовали во всех хранилищах данных.	Высокая для деструктивного поведения, средняя для конкретной реализации.
/allsys	Включение системных файлов. Основано на публично задокументированном поведении семейств BlackNevas/Trigona.	Средняя: оценка основана на сравнении с публично задокументированным поведением семейства вредоносного ПО; невозможно подтвердить напрямую из-за отсутствия бинарного файла.
/detach	Отсоединение от консоли; активность продолжалась после закрытия SSH-сессии.	Высокая: на основе внешних публикаций + зафиксировано продолжение активности в инциденте.
/-showvolumes	Отключение вывода списка томов согласно задокументированным параметрам семейства.	Средняя: только на основе сопоставления с публикациями.

Стиль аргументов с косой чертой (/) напоминает командную строку семейств Trigona и BlackNevas. По данным SentinelOne, семейство BlackNevas является производным Trigona и включает ESXi-совместимые сборки со специализированными флагами, в частности /p или /path, /wipe, /depth и /detach. Такое сходство повышает надежность идентификации, но не заменяет атрибуцию на основе хэша бинарного файла или реверс-инжиниринга образца.

Частичная перезапись первых двух килобайт: что она означает

На основе артефактов инцидента мы установили, что злоумышленники перезаписали примерно первые 2 КБ файлов виртуальных дисков. Повреждение начала диска может уничтожить защитную MBR, основной заголовок GPT и другие структуры, связанные с ранними стадиями загрузки или файловой системой, сразу после чего гостевая система может перестать загружаться. Однако спецификация UEFI требует, чтобы на GPT-носителях основной и резервный заголовки GPT, а также массивы записей разделов хранились в разных местах. Если основной заголовок GPT поврежден, а резервный цел, GPT-совместимое ПО должно использовать резервный, что может помочь восстановить основной. Следовательно, сама по себе перезапись первых 2 КБ не гарантирует невозможность восстановления метаданных разделов. На практике шансы на восстановление зависят от того, были ли также модифицированы дополнительные загрузочные записи, метаданные файловой системы, структуры томов, дескрипторы или прикладные данные, а также от особенностей структуры виртуального диска.

Первоочередное уничтожение среды восстановления

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

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

Две недавние уязвимости в Veeam — наглядный тому пример. Хотя ни одна из них не задействовалась атакующими в анализируемом случае, обе связаны с плохо проработанной политикой управления привилегиями, что позволяет эксплуатировать эти уязвимости любому пользователю домена, в том числе с минимальными правами. CVE-2024-40711 внесена в базу данных KEV CISA как уязвимость, которая эксплуатировалась в вымогательских атаках. CVE-2025-23120 новее и пока отсутствует в KEV, однако стоит отметить, что, согласно Veeam, она открывает возможность удаленного выполнения кода, но при этом затрагивает только подключенные к домену серверы резервного копирования. Отсюда можно извлечь общий урок, не привязанный к конкретному поставщику: система восстановления, зависящая от того же уровня идентификации, что и производственная среда, может быть скомпрометирована злоумышленниками и послужить их целям.

Детектирование и расследование

В ESXi предусмотрено множество лог-файлов, в которых регистрируются события системы. Эти источники позволяют восстановить ход деструктивного инцидента на гипервизоре даже в том случае, если на ESXi не развернут агент для защиты рабочих мест. Однако доступность логов ограничена режимом хранения (retention). В базе знаний Broadcom сказано, что ESXi пишет логи на внутренний ramdisk (виртуальный диск в оперативной памяти), ограниченный по объему и очищающийся при перезагрузке, и что для сохранения логов после перезагрузки и при потере локального хранилища требуется постоянное scratch-хранилище или удаленный syslog. Мы рекомендуем пересылать логи в удаленное хранилище, чтобы обеспечить возможность криминалистического анализа инцидентов с ESXi.

Приоритет	Источник	Что регистрирует	Риск потери	Примечание по извлечению
1	auth.log	Аутентификация SSH, источник, время сессии, идентификаторы клиента	Средний	Переслать в удаленное хранилище; сохранить до ротации.
1	shell.log	Все команды консоли ESXi Shell, а также ее включение и отключение	Средний	Самый ценный источник выполнявшихся команд.
1	vpxa.log	Действия vCenter на стороне хоста, в том числе управляющие рабочие процессы	Средний	Сопоставлять с событиями и задачами vCenter.
1	vobd.log	Изменения состояния служб и безопасности, события execInstalledOnly	Средний	Полезный высоконадежный источник улик, связанных с конфигурацией.
1	События/задачи vCenter	Субъект, объект и административное действие	Средний	Экспортировать немедленно, если узел vCenter по-прежнему доступен.
1	systemd + файловая система VCSA	Unit-файлы закрепления и связанные бинарные файлы	Средний	Для /etc/systemd/system и /opt/vmware: сверить текущее состояние файловой системы и конфигурацию служб с утвержденным организацией состоянием.
2	vmkernel.log / vmkwarning.log	Хранилище, жизненный цикл миров, предупреждения ядра	Средний	Позволяет подтвердить масштаб воздействия и поведение хоста.
2	vmksummary.log	Почасовые записи количества работающих ВМ и сигнальные сообщения (heartbeat) хоста	Средний	Надежный источник для оценки масштаба воздействия; низкая детализация по времени.
2	esxupdate.log	Операции по установке VIB/исправлений	Средний	Критически важный источник при подозрении на установку вредоносных VIB-пакетов.
2	vmware.log для каждой ВМ	События управления питанием и устройствами для конкретной ВМ	Средний	Под угрозой, если хранилище данных зашифровано или стерто.
2	hostprofiletrace.log	Применение профиля хоста / операции контроля конфигурации	Средний	Сохранить при подозрении на манипуляции профилем хоста.
3	fdm.log / vmauthd.log / syslog.log	HA-подсистема, порт 902 и общий контекст демонов	Средний	Полезны для подтверждения находок после извлечения артефактов с приоритетом 1 и 2.

Телеметрия уровня виртуализации, ранжированная по криминалистической ценности (срок хранения зависит от среды; удаленная пересылка снижает риск потери улик вместе с хостом)

Организация детектирования с высокой степенью уверенности

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

Обнаружение	Поведение	Телеметрия	Важность
Профиль хоста → TSM-SSH	Применение профиля хоста в рамках контроля конфигурации (remediation) переводит TSM-SSH из состояния «отключено по политике» в состояние «работает» вне утвержденного окна изменения.	События vCenter, vpxa.log и vobd.log	Критическая
Прямая сессия SSH, исходящая от vCenter	Появление новой SSH-сессии с vCenter на ESXi после изменения состояния безопасности.	auth.log + сетевой поток	Критическая
Новая служба systemd с VMware-подобным именем	Новый или измененный unit-файл в /etc/systemd/system, ссылающийся на бинарный файл вне списка базового профиля по VMware-подобному пути.	Файловая система VCSA / аудит VCSA	Высокая
Ослабление параметра execInstalledOnly	Значение /User/execInstalledOnly изменено на 0/FALSE или отключена принудительная настройка на уровне ядра.	vobd.log + аудит конфигурации	Критическая
Понижение уровня допуска (acceptance level)	Уровень допуска хоста изменяется на менее доверенный вне окна технического обслуживания.	Конфигурация vCenter/ESXi	Высокая
Последовательность автоматизированной проверки SSH	Сессия, содержащая только команды true, за которой через несколько секунд следует выполнение команды exec или chmod с того же источника/клиента.	auth.log + shell.log	Высокая в сочетании с другими
Валидация полезной нагрузки	Исполняемый файл в каталоге /tmp выполняет краткое самотестирование, а затем обращается к /vmfs.	shell.log	Критическая
Массовая остановка ВМ	Множество операций остановки виртуальных машин или завершения миров в течение нескольких секунд/минут.	shell.log, hostd.log и задачи vCenter	Критическая
Первоочередной удар по резервным копиям	Службы резервного копирования остановлены или средства безопасности отключены незадолго до изменений на гипервизоре.	Телеметрия Windows / резервного копирования + vCenter	Критическая
Артефакты стирания данных в хранилище	Быстрое появление маркеров стирания или деструктивные операции записи на нескольких томах VMFS.	Файловая система + vobd/vmkernel	Критическая

Примеры корреляционной логики

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

Пример 1. Вмешательство в профили хоста для организации прямого доступа к ESXi

Пример 2. Размещение полезной нагрузки ESXi до этапа воздействия

Реагирование на инциденты на уровне виртуализации

Этот раздел содержит рекомендуемые действия при реагировании на инцидент с вымогательским ПО для ESXi.

Первые 30 минут после обнаружения инцидента

1. Изолируйте административный доступ к vCenter от обычных корпоративных сегментов, сохранив при этом доступ для команды реагирования через контролируемый канал.
2. Экспортируйте события и задачи vCenter, записи аудита SSO, активные сессии и текущие определения профилей хостов до того, как изменения в ходе применения профилей хостов в рамках контроля конфигурации сотрут контекст.
3. Извлеките файлы auth.log, shell.log, vpxa.log, vobd.log, hostd.log, vmkernel.log, vmkwarning.log, vmksummary.log, esxupdate.log и hostprofiletrace.log с каждого затронутого хоста ESXi.
4. Сохраните содержимое путей VCSA /etc/systemd/system и /opt/vmware, с которыми связаны ранее неизвестные или неутвержденные unit-файлы, а также историю команд консоли, wtmp, логи аутентификации и копии или хэши подозрительных бинарных файлов.
5. Соберите телеметрию серверов резервного копирования, состояние служб, артефакты хранилища учетных данных и сетевые логи до перестройки инфраструктуры или ротации учетных данных.
6. Зафиксируйте текущее состояние execInstalledOnly, уровень допуска хоста, состояние SSH / ESXi Shell, режим изоляции (Lockdown Mode), членство в домене и распределение прав ESXi.

Не начинайте с перезагрузки ESXi только ради того, чтобы оборвать сессию злоумышленника. Наличие логов ESXi зависит от конфигурации scratch-хранилища и syslog, а перезагрузка может уничтожить улики, находящиеся на внутреннем виртуальном диске (ramdisk). Убедитесь, что критически важные логи скопированы или сохранены удаленно до принятия мер по сдерживанию деструктивной активности. Исключение составляют случаи, когда продолжающееся воздействие требует немедленного отключения систем.

Приоритеты сдерживания

• Отзовите скомпрометированные учетные данные или проведите их ротацию, затем устраните пути доступа, находящиеся под контролем злоумышленника, однако сначала сохраните записи аутентификации и задач.
• Отключите несанкционированный доступ к TSM-SSH и ESXi Shell после сбора улик; убедитесь, что профили хостов или другие автоматизированные механизмы не активируют их снова.
• Удалите неутвержденные службы systemd и агенты удаленного управления с VCSA, предварительно создав их образы или сохранив unit-файлы и связанные с ними бинарные файлы.
• Восстановите настройки execInstalledOnly и уровня допуска до утвержденного базового профиля, предварительно убедившись, что это не помешает сбору улик и работе критических средств восстановления.
• Выделите в отдельный сегмент или отключите скомпрометированную инфраструктуру резервного копирования от производственной среды и разверните чистый уровень управления среды восстановления перед попыткой крупномасштабного восстановления.

Рекомендации по повышению устойчивости архитектуры с учетом данного инцидента

Рассматривайте vCenter как актив уровня Tier 0

Узел VMware vCenter — не просто консоль инвентаризации. Он может обладать полномочиями по конфигурированию хостов, управлению идентификаторами, управлению питанием ВМ, применению профилей хостов и контролю доступа во всей виртуальной среде. Рассматриваемый инцидент продемонстрировал, как компрометация vCenter подрывает механизмы безопасности, применяемые через уровень управления виртуализацией: атакующие получают достаточно привилегий, чтобы конфигурировать хосты, управлять ВМ и изменять значимые с точки зрения безопасности настройки во всей виртуальной среде, что потенциально позволяет вывести из строя или уничтожить всю виртуализированную среду за считаные минуты. Для защиты vCenter используйте выделенные административные идентификаторы, устойчивый к фишингу механизм MFA через поддерживаемую федеративную идентификацию, ограничение доступа в управляющей сети, мониторинг привилегированных сессий и тщательный контроль изменений на уровне профилей хостов и кластеров.

Изолируйте учетные данные среды виртуализации от обычного корпоративного администрирования

Избегайте повсеместного использования учетных данных администратора домена или администратора рабочей станции для виртуализации. Если ESXi подключен к домену, задайте безопасную конфигурацию Active Directory в соответствии с рекомендациями Broadcom и непрерывно проводите аудит прав всех групп. Следует учитывать, что техника «Существующие учетные записи» также применима к средам ESXi. Более того, в качестве примера подтехники «Учетные записи по умолчанию» в базе MITRE ATT&CK отдельно упоминается учетная запись vpxuser, используемая vCenter для управления хостами.

Сократите число прямых каналов управления ESXi до минимума

Протокол SSH полезен для устранения неполадок, но администраторам следует использовать его лишь в исключительных случаях, а не для штатного повседневного доступа. Несанкционированное включение SSH на хостах ESXi — как напрямую, так и через vCenter — должно выявляться с помощью мониторинга изменений TSM-SSH и рассматриваться как подозрительное событие. Для дальнейшего усиления защиты хостов ESXi используйте Lockdown Mode всюду, где это уместно с эксплуатационной точки зрения: предоставляйте доступ только небольшому числу явно авторизованных пользователей, применяйте фильтрацию управляющей сети, а также политику одобрения и отслеживания любых изменений, особенно при включении доступа через консоль.

Сделайте хранение логов независимым от затронутых хостов

Удаленный журнал syslog с ESXi и vCenter должен храниться в инфраструктуре за пределами доверенной области виртуализации. Постоянное scratch-хранилище повышает сохраняемость логов после перезагрузки, но локальные артефакты все еще могут быть утрачены в случае уничтожения хранилища данных или хоста. Рекомендуется использовать централизованное логирование (например, на базе SIEM), охватывающее телеметрию аутентификации, консоли, управления хостами, профилей хостов и задач vCenter. Правильное логирование следует настроить заранее, до возникновения любого инцидента, чтобы в случае чрезвычайной ситуации у команды реагирования была полная картина произошедшего.

Проектируйте резервное копирование как отдельный периметр безопасности

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

Заключение

Главный вывод из этого инцидента заключается вовсе не в необходимости устанавливать на ESXi дополнительное агентское ПО, а в том, что безопасность виртуализации зависит от целостности уровня управления, системы идентификации и средств восстановления одновременно. Даже со всеми исправлениями и полной защитой гипервизор все равно может принять на себя весь ущерб от вымогательского ПО, если управляющая система уже скомпрометирована. Злоумышленникам не пришлось взламывать криптографию VMware или «сбегать» из гостевой ОС. Стоило им получить доступ к привилегированным средствам управления vCenter, как легитимный механизм контроля конфигурации позволил изменить состояние хоста, включить SSH и проложить путь в среду ESXi — при том, что каждое из этих действий структурно походило на обычную административную операцию.

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

Следовательно, устойчивая защита — вопрос архитектуры. Рассматривайте vCenter как актив уровня Tier 0. Изолируйте учетные данные среды виртуализации от обычного корпоративного администрирования. Сократите число прямых каналов доступа к ESXi до минимума. Сохраняйте нативные логи за пределами затронутой платформы. Детектируйте высокорисковые изменения конфигурации на основе последовательности операций, а не отдельных команд. И проектируйте среду восстановления так, чтобы компрометация учетных данных производственной среды или управления виртуализацией не давала атакующим достаточно полномочий для уничтожения систем, без которых невозможно восстановить скомпрометированную инфраструктуру.

Сопоставление с базой знаний MITRE ATT&CK

Техника	Название	Связь с инцидентом	Статус
T1078/T1078.002	Valid Accounts / Domain Accounts	Украденные корпоративные учетные данные обеспечили атакующим привилегированный доступ к инфраструктуре.	Наблюдалась / контекстуально связана
T1078.001	Valid Accounts: Default Accounts	Значима в контексте доверительных отношений root и vpxuser в среде ESXi.	Техника не наблюдалась в рассматриваемом инциденте, но релевантна для платформы ESXi.
T1021.004	Remote Services: SSH	Протокол SSH использовался для администрирования vCenter и ESXi; в базе MITRE он явно упоминается в контексте ESXi.	Наблюдалась
T1543.002	Create or Modify System Process: Systemd Service	Туннель Ligolo-ng был закреплен в VCSA как служба vmware-vdma.service.	Наблюдалась
T1572	Protocol Tunneling	Через Ligolo-ng был создан туннель в сегмент управляющей сети.	Наблюдалась
T1490	Inhibit System Recovery	Службы резервного копирования и инфраструктура восстановления были выведены из строя до оказания воздействия на производственную среду.	Наблюдалась
T1486	Data Encrypted for Impact	На этапе выполнения программы-вымогателя виртуализированные рабочие нагрузки стали недоступны.	Наблюдалось воздействие

Сопоставление с MITRE ATT&CK на основе наблюдаемого поведения и актуальных техник, применимых к ESXi, с консервативным подходом к классификации

Индикаторы инцидента

Приведенные ниже индикаторы были собраны в ходе расследования. Это артефакты, специфичные для данного инцидента, а не устойчивые сигнатуры BlackNevas или иного семейства программ-вымогателей. Злоумышленники могут переназначить или изменить имена служб, имена файлов, домены и инфраструктуру виртуальных выделенных серверов (VPS). Хэши шифровальщика ESXi, бинарного файла Ligolo-ng, скрипта установки агента и скрипта извлечения учетных данных не приводятся, поскольку исходные файлы были недоступны.

Тип	Индикатор	Контекст	Уверенность	Применимость
Служба	vmware-vdma	Служба systemd, маскирующаяся под службу VMware на VCSA.	Высокая	На уровне инцидента
Служба	vspbind	Служба Windows для агента удаленного управления.	Высокая	На уровне инцидента
Домен	api.cloudvflare[.]com	Командный сервер Ligolo-ng; тайпсквот cloudflare.com, отличающийся одной буквой.	Высокая	На уровне инцидента
IPv4	45.149.154[.]135	Командный сервер агента удаленного управления.	Высокая	На уровне инцидента
IPv4	91.92.242[.]121	VPS, использованный для первоначального доступа к порталу.	Высокая	На уровне инцидента
IPv4	31.41.33[.]212	VPS, использованный для первоначального доступа к порталу.	Высокая	На уровне инцидента
IPv4	188.240.57[.]94	VPS, использованный для первоначального доступа к порталу.	Высокая	На уровне инцидента
SHA-1	28f8da19ddcdf26e426875c7a834b34a79bc1c33	svhost.exe / lock.exe.	Высокая	На уровне образца
SHA-256	15dc419b7fbeb50c50820a7cd27997541deafa4fa710f074bb657f0149574baf	Агент удаленного управления.	Высокая	На уровне образца
SHA-256	5a9b7a0d3f25757aea957713d7e84cabec87597b3474368328a8fd5ed7a12f78	Установленная в системе разновидность агента удаленного управления.	Высокая	На уровне образца

Индикаторы инцидента для ретроспективного поиска

Минимальный набор собираемых криминалистических данных из инфраструктуры виртуализации

Уровень	Источник телеметрии	Ценность для расследования
Аутентификация ESXi	/var/run/log/auth.log	Исходные IP-адреса, пользователи, время сессий SSH и идентификаторы клиентов.
Команды ESXi	/var/run/log/shell.log	Точное содержание команд, выполненных через консоль ESXi Shell.
Управление хостом со стороны vCenter	vpxa.log + события и задачи vCenter	Применение профилей хостов в рамках контроля конфигурации, изменения служб и источник административных операций.
Наблюдение за безопасностью хоста	vobd.log	События execInstalledOnly, служб и изменения состояния безопасности.
Управление хостом	hostd.log	Задачи ВМ и хоста, взаимодействие API/управления.
Ядро/хранилище	vmkernel.log + vmkwarning.log	Сбои хранилища, жизненный цикл миров и предупреждения VMkernel.
Масштаб воздействия	vmksummary.log	Почасовые записи количества работающих ВМ и сигнальные сообщения (heartbeat) хоста.
История VIB	esxupdate.log	Установка исправлений/VIB.
Профиль хоста	hostprofiletrace.log	Применение профиля и операции контроля конфигурации.
Артефакты с каждой ВМ	vmware.log рядом с VMX	Операции управления питанием и устройствами отдельных ВМ.
Закрепление на VCSA	/etc/systemd/system + связанные бинарные файлы	Несанкционированные службы и пути закрепления.
Доступ к VCSA	Логи SSO, логи аутентификации, wtmp, история команд консоли	Контекст аутентификации, сессий и команд.
Уровень резервного копирования	Логи приложений + телеметрия Windows + улики из хранилища учетных данных	Компрометация среды восстановления и мост к другим системам через учетные данные.
Сеть	Сетевой экран / сетевые потоки / прокси / DNS	SSH-сессии от vCenter к ESXi, командный сервер, туннелирование и переходы через сегмент управляющей сети.

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