LIMB
Описание
В декабре 2025 года Huntress обнаружила вторжение, которое привело к развертыванию эксплойтов для VMware ESXi.
На основании наблюдаемых нами признаков, включая имя рабочей станции, с которой действовал злоумышленник, и другие тактические приемы, группа быстрого реагирования Huntress с высокой степенью уверенности оценивает, что первоначальный доступ был осуществлен через VPN-соединение SonicWall.
Анализируемый в этом отчете набор инструментов также включает в себя строки на упрощенном китайском языке в своих путях разработки, в том числе папку с названием «全版本逃逸--交付» (переводится как "Побег из всех версий — доставка"), и имеются свидетельства, указывающие на то, что он потенциально был создан как эксплойт нулевого дня более чем за год до публичного раскрытия информации компанией VMware, что указывает на наличие хорошо обеспеченного ресурсами разработчика, вероятно, работающего в китайскоязычном регионе.
Учитывая особенности эксплуатации уязвимостей ESXi, эта деятельность могла бы завершиться атакой с использованием программ-вымогателей, но она была пресечена группой тактического реагирования Huntress и Центром оперативного управления безопасностью (SOC). Ниже приведено краткое изложение наших наблюдений.
Ключевые моменты
- Первоначальный доступ, вероятно, осуществлялся через VPN. Несмотря на изощренность способа обхода виртуальной машины, злоумышленники проникли внутрь через скомпрометированный VPN-сервер SonicWall. Основные моменты по-прежнему имеют значение.
- Изоляция виртуальных машин не является абсолютной. Уязвимости гипервизора могут позволить злоумышленникам выйти из гостевых виртуальных машин и скомпрометировать все рабочие нагрузки на хосте.
- Активно обновляйте ESXi. Этот набор инструментов для эксплуатации уязвимостей поддерживает 155 сборок ESXi, охватывающих версии от 5.1 до 8.0. Если вы используете версии, поддержка которых прекращена, вы уязвимы, и исправление для них недоступно.
- В сетевом мониторинге есть "слепые зоны". Трафик VSOCK между виртуальными машинами и гипервизором невидим для межсетевых экранов и систем обнаружения вторжений. Для мониторинга необычных процессов на хостах ESXi используйте команду "lsof -a".
- Остерегайтесь методов BYOD (использование личных устройств на рабочем месте). Использование KDU для загрузки неподписанных драйверов обходит Проверку Подписи Драйверов. Следите за загрузкой известных уязвимых драйверов.
Что вообще произошло ?
Резервный контроллер домена
Злоумышленник, используя скомпрометированную учетную запись администратора домена (DA), переместился на резервный контроллер домена через RDP. Он попытался изменить пароль DA на Password01$ с помощью Impacket, но эта попытка была предотвращена управляемым Huntress модулем Microsoft Defender for Endpoint (MDE).
Были задействованы следующие средства разведки:
- C:\Users\User\Downloads\Advanced_Port_Scanner_2.5.3869.exe
- C:\Program Files\SoftPerfect Network Scanner\netscan.exe
Затем хакер запустил программу ShareFinder для перечисления сетевых ресурсов, выведя результаты в файл C:\ProgramData\shares.txt.
Основной контроллер домена
Используя ту же скомпрометированную учетную запись DA, злоумышленник переместился на основной контроллер домена и развернул набор эксплойтов VMware ESXi. Примерно через 20 минут он изменил настройки брандмауэра Windows, чтобы изолировать хост от внешних сетей, сохраняя при этом внутреннюю связь, с помощью приведенных ниже команд:
- netsh advfirewall firewall add rule "name=Allow Local Network-2" dir=out action=allow remoteip=10.xxx/8 profile=any
- netsh advfirewall firewall add rule "name=Block External Outbound" dir=out action=block remoteip=0.0.0.0-255.255.255.255 profile=any
- netsh advfirewall firewall add rule "name=Allow Local Network-3" dir=out action=allow remoteip=172.xxx/12 profile=any
Подобные модификации брандмауэра часто встречаются при вторжениях и направлены на предотвращение доступа жертвы к внешним ресурсам для получения помощи или отправки запросов средствам безопасности на серверы, при этом позволяя злоумышленнику перемещаться по внутренним сетям для максимального увеличения радиуса поражения.
После внесения изменений в настройки брандмауэра, хакер начал подготовку данных для эксфильтрации с помощью WinRAR:
"C:\Program Files\WinRAR\WinRAR.exe" a -ep1 -scul -r0 -iext -imon1 -- . "Mapped Network Share"
Команды эксплойта:
- devcon.exe disable “PCI\VEN_15AD&DEV_0740” — отключает устройство VMware VMCI PCI для получения прямого доступа к оборудованию.
- devcon.exe disable “ROOT\VMWVMCIHOSTDEV” - отключает драйвер хоста VMware VMCI.
- kdu.exe -prv 1 -map MyDriver.sys - использует утилиту драйверов ядра (KDU) для обхода проверки подписи драйверов и загрузки неподписанного эксплойт-драйвера в память ядра.
- exploit.exe (MAESTRO) организует атаку по выходу из виртуальной машины и устанавливает бэкдор на гипервизор ESXi.
Потенциально используемые уязвимости
4 марта 2025 года компания VMware выпустила уведомление о безопасности VMSA-2025-0004 , касающееся трех уязвимостей, о которых сообщило Управление по анализу угроз Microsoft. Все три уязвимости были подтверждены как используемые злоумышленниками:
- CVE-2025-22226 (CVSS 7.1): Выход за пределы допустимого диапазона чтения в HGFS, который приводит к утечке памяти из процесса VMX.
- CVE-2025-22224 (CVSS 9.3): Уязвимость TOCTOU в VMCI, приводящая к записи за пределы допустимого диапазона, что позволяет выполнять код от имени процесса VMX.
- CVE-2025-22225 (CVSS 8.2): Уязвимость произвольной записи в ESXi, позволяющая выйти за пределы песочницы VMX и перейти в ядро.
На основе анализа поведения эксплойта, использования им HGFS для утечки информации, VMCI для повреждения памяти и шеллкода, проникающего в ядро, группа тактического реагирования Huntress с умеренной степенью уверенности оценивает, что этот набор инструментов использует указанные три уязвимости CVE.
Что такое VMX?
VMX (Virtual Machine Executable) — это процесс, который запускается на хосте ESXi для каждой виртуальной машины. Согласно документации VMware - (https://knowledge.broadcom.com/external/article/339468/interpreting-virtual-machine-monitor-and.html), VMX "отвечает за обработку операций ввода-вывода для устройств, не критически важных для производительности", и "взаимодействует с пользовательскими интерфейсами, менеджерами моментальных снимков и удаленной консолью". Это включает в себя такие функции, как совместное использование буфера обмена, перетаскивание и взаимодействие с VMware Tools — именно те функции, на которые нацелена эта уязвимость.
Каждая запущенная виртуальная машина имеет свой собственный процесс VMX. С точки зрения злоумышленника, VMX является первой целью для выхода из виртуальной машины, поскольку он обрабатывает недоверенные входные данные от гостевой системы. Однако VMX работает внутри песочницы на ESXi, поэтому для его взлома требуется дополнительный шаг для получения полного доступа к хосту.
Инструменты для эксплуатации уязвимостей VMWare
Если эта блок-схема вызывает у вас головокружение, не волнуйтесь, оставайтесь со мной, и к концу все станет понятно, надеюсь. Цвета не обозначают ничего конкретного, они просто помогают легче следить за ходом событий.
Оркестрация эксплойтов
exploit.exe (MAESTRO)
Исполняемый файл exploit.exe, который мы назвали MAESTRO, служит оркестратором всей атаки по выходу из виртуальной машины. Он не содержит фактической логики эксплуатации, вместо этого он подготавливает среду, развертывает драйвер эксплойта, отслеживает ход выполнения и выполняет последующую очистку.
Исполняемый файл содержит 4 встроенных двоичных файла во встроенных ресурсах:
- MyDriver.sys — неподписанный драйвер ядра, содержащий эксплойт для выхода из виртуальной машины.
- kdu.exe — утилита для управления драйверами ядра (инструмент загрузки BYOD)
- devcon.exe — Microsoft Device Console, утилита для управления устройствами.
- drv64.dll - библиотека поддержки KDU
Этап 1: Отключение драйверов VMware VMCI
Эксплойт начинается с отключения драйверов VMCI для гостевой системы VMware с помощью утилиты devcon.exe от Microsoft. Отключаются два экземпляра устройств:
- PCI\VEN_15AD&DEV_0740 — PCI-устройство VMware VMCI (Vendor 0x15AD = VMware, Device 0x0740 = VMCI)
- ROOT\VMWVMCIHOSTDEV — драйвер хост-устройства VMware VMCI.
Что такое VMCI?
Интерфейс связи виртуальных машин VMware (VMCI) — это высокоскоростной механизм связи, который обеспечивает взаимодействие между виртуальной машиной и ее хостом ESXi, а также прямую связь между виртуальными машинами на одном хосте.
Зачем отключать драйвер VMCI?
Для работы эксплойт-драйвера необходимо напрямую взаимодействовать с оборудованием VMCI, используя низкоуровневые инструкции ввода-вывода. Если мы посмотрим на файл "MyDriver.sys" (вредоносный драйвер), то после обнаружения устройства VMCI на шине PCI он считывает регистр базового адреса устройства (BAR0), чтобы получить базовый адрес порта ввода-вывода.
Получив адрес BAR0, эксплойт использует инструкции x86 "IN/OUT" для прямой связи с аппаратными регистрами VMCI:
При загрузке vmci.sys он получает контроль над адаптером VMCI и активно использует те же порты ввода-вывода. Два драйвера не могут безопасно использовать одно и то же оборудование; если оба попытаются одновременно отправлять команды, это приведет к повреждению состояния устройства и сбою системы. Отключив vmci.sys в первую очередь, эксплойт получает эксклюзивный доступ к оборудованию VMCI.
Загрузка неподписанного драйвера через BYOD
Поскольку файл "MyDriver.sys" не подписан, его невозможно загрузить обычным способом в системах с включенной проверкой подписи драйверов (DSE). Эксплойт использует KDU (Kernel Driver Utility), инструмент с открытым исходным кодом для загрузки неподписанных драйверов в память ядра.
- kdu.exe -prv 1 -map MyDriver.sys , где:
-- prv 1 - Используйте поставщика №1, драйвер с легитимной подписью, но уязвимый.
-- map — Вручную сопоставить неподписанный драйвер с памятью ядра.
KDU использует уязвимость в подписанном драйвере для получения доступа к выполнению кода ядра, а затем использует этот доступ для загрузки файла MyDriver.sys. Шестисекундная задержка после выполнения дает драйверу время для инициализации и начала процесса эксплуатации уязвимости.
Мониторинг хода выполнения эксплойта
После загрузки MyDriver.sys создает объект устройства, доступный по символической ссылке \\.\TDLD (Рисунок 2). Оркестратор (exploit.exe) открывает это устройство и опрашивает его каждые 4 секунды, и когда драйвер возвращает значение состояния 2, эксплуатация завершена, и цикл завершается.
Восстановление драйверов VMware
После успешной эксплуатации (статус == 2) оркестратор повторно включает драйверы VMware VMCI. Это восстановление, вероятно, служит для обеспечения операционной безопасности: виртуальная машина продолжает нормально функционировать с работающими инструментами VMware Tools, что снижает подозрения в совершении каких-либо вредоносных действий.
Эксплуотирование драйвера
MyDriver.sys
Разобравшись с уровнем оркестровки, давайте перейдем к MyDriver.sys, драйверу ядра, который выполняет фактическое освобождение виртуальной машины. Этот драйвер содержит следующую основную логику эксплуатации:
- Использование бэкдора VMware для сбора информации
- Манипулирование оборудованием VMCI для активации уязвимостей
- Чтение и запись памяти процесса VMX
- Развертывание шеллкода ESXi
Прежде чем начать эксплуатацию уязвимости, драйверу необходимо определить точную версию ESXi, работающую на хосте. Различные сборки ESXi имеют разную структуру памяти, поэтому эксплойт требует смещений, специфичных для каждой версии. Драйвер запрашивает версию хоста ESXi, используя документированную команду VMware Guest SDK "guestlib.stat.get text session". Эта команда, обычно используемая VMware Tools и сторонними агентами для целей мониторинга, возвращает информацию о хосте, включая точную строку версии ESXi (например, "VMware ESX 8.0.0 build-24022510"). Эксплойт анализирует этот ответ, чтобы извлечь номер версии и сборки.
После определения версии и номера сборки ESXi драйвер обращается к таблице предварительно вычисленных смещений, специфичных для данной сборки. Эксплойт внедряет жестко закодированную таблицу, содержащую 155 поддерживаемых сборок ESXi, охватывающих версии от 5.1 до 8.0.
Каждая запись хранит номер сборки и 17 смещений, специфичных для версии, необходимых для обнаружения структур процесса VMX. Эти смещения изменяются между сборками ESXi из-за модификаций кода и различий в компиляторах. Если обнаруженная сборка отсутствует в таблице, эксплойт не срабатывает, что является распространенным ограничением эксплойтов, основанных на смещениях.
Утечка базового адреса VMX
После загрузки смещений, специфичных для каждой версии, следующим шагом является утечка базового адреса процесса VMX для обхода ASLR. Поскольку таблица смещений содержит относительные смещения, а не абсолютные адреса, эксплойт должен определить, где VMX загружен в память, прежде чем он сможет вычислить точные места для записи шеллкода и повреждения структур. Приведенная ниже функция выполняет последовательность операций с бэкдором, связанных с HGFS, для запуска раскрытия информации.
Функция выполняет последовательность операций, связанных с бэкдором HGFS, для запуска раскрытия информации. Функция начинается с выделения буфера размером 64 КБ и выбора размера сообщения в зависимости от версии ESXi. Для ESXi 5.x и 6.x размер сообщения составляет 50616 байт. Для ESXi 7.0 и 8.0 — 50624 байта. Далее, ряд команд RPC настраивает состояние VMware Tools в процессе VMX:
Критически важная команда — tools.capability.hgfs_server toolbox-dnd 1 , которая позволяет использовать функцию перетаскивания файлов между хостом и гостевой системой. Эта функциональность является частью файловой системы Host-Guest File System (HGFS) от VMware и позволяет пользователям перетаскивать файлы со своего рабочего стола в окно виртуальной машины. Согласно бюллетеню безопасности VMware VMSA-2025-0004, CVE-2025-22226 — это уязвимость раскрытия информации, вызванная чтением за пределы допустимого диапазона в HGFS. В бюллетене говорится, что "злоумышленник с административными привилегиями в виртуальной машине может использовать эту уязвимость для утечки памяти из процесса vmx". Хотя мы не можем подтвердить точную первопричину, использование эксплойтом HGFS и вызванная этим утечка памяти соответствуют этому описанию.
Затем эксплойт открывает шесть каналов связи через бэкдор и закрывает два из них (каналы 2 и 4). Термин "бэкдор", по-видимому, является собственной терминологией VMware для механизма связи между гостевой системой и хостом. Он работает за счет доступа к порту ввода-вывода 0x5658 на физической машине; этот порт ни к чему не подключен, но внутри виртуальной машины VMware гипервизор перехватывает доступ к нему и использует его в качестве канала команд. Именно так VMware Tools реализует такие функции, как совместное использование буфера обмена, перетаскивание и изменение размера экрана.
Через канал отправляется большой буфер из нулей (~50 КБ), за которым следует строка "OK ATR toolbox-dnd" для инициализации операции перетаскивания в HGFS.
Наконец, эксплойт формирует и отправляет полезную нагрузку, которая запускает чтение за пределы допустимого диапазона:
4F 4B 20 00 00 00 00 FF 00 00 00 A5 C5 00 00 A4 C5 00 00 00 00 00 80 29 00 00 00 + [50573 нули]
Перед использованием полученного указателя эксплойт проверяет его, сравнивая биты 8-11 с ожидаемым значением из таблицы смещений. Для сборки 24022510 маскирование обоих значений значением 0xF00 должно дать совпадающие результаты. После проверки базовый адрес VMX вычисляется путем вычитания известного смещения (0x01590300) из полученного указателя:
vmxBase = leakedPtr - 0x01590300
В таблице смещений хранится известный адрес внутри VMX для каждой поддерживаемой сборки. Утечка указателя указывает на предсказуемое местоположение внутри VMX. Вычитая это известное смещение, эксплойт определяет, где VMX загружен в память, тем самым обходя ASLR.
Запись шелл-кода в память VMX
Зная базовый адрес VMX, эксплойт теперь может считывать и записывать данные непосредственно в память VMX.
Обе операции работают путем формирования 95-байтового заголовка и его отправки через каналы бэкдора VMware. При записи заголовок содержит команду типа 2, размер записываемых данных и целевой адрес в памяти VMX. Сначала отправляется заголовок, а затем сами данные по второму каналу. При чтении заголовок содержит команду типа 3 и целевой адрес, и эксплойт получает обратно 8 байт, содержащих данные по этому адресу.
Мы считаем, что возможность чтения/записи обеспечивается уязвимостью CVE-2025-22224, которую VMware описывает как уязвимость, "приводящую к записи за пределы допустимого диапазона".
Таким образом, эксплойт записывает три полезных нагрузки в память VMX:
- Шеллкод первого этапа
- Шеллкод второго этапа
- ELF Backdoor
Бэкдор ELF, который мы назвали "VSOCKpuppet", представляет собой исполняемый файл Linux, поскольку ESXi работает на ядре на основе Linux, поэтому нативные бинарные файлы Linux могут выполняться непосредственно на гипервизоре.
После записи полезной нагрузки эксплойт перезаписывает указатель на функцию внутри VMX. Сначала он сохраняет исходное значение указателя, а затем перезаписывает его адресом шеллкода. После этого эксплойт отправляет хосту сообщение VMCI для запуска VMX. Когда VMX обрабатывает сообщение, он следует по поврежденному указателю и переходит к шеллкоду злоумышленника вместо легитимного кода.
Этот заключительный этап соответствует уязвимости CVE-2025-22225, которую VMware описывает как "уязвимость произвольной записи", позволяющую "выйти за пределы песочницы".
Шеллкод 1
Первый этап выполнения шеллкода происходит внутри процесса VMX и использует системные вызовы VMkernel для запроса информации о внутреннем устройстве ядра. Шеллкод циклически повторяет поиск до 4902 раз, ища объект с именем "general", затем запрашивает информацию о "vmkernel" и "vmci". Найдя их, он извлекает их базовые адреса.
- vmkernel base: %p, qpBrokerList: %p
Эти адреса имеют решающее значение для следующего этапа, поскольку позволяют эксплойту рассчитать, куда записывать данные в память ядра, чтобы выйти из песочницы VMX.
Шеллкод 2
На втором этапе шеллкод устанавливает точку опоры на хосте ESXi, используя стандартные системные вызовы Linux. Он создает файл бэкдора в /var/run/a с полными правами доступа (0777), а затем записывает в него полезную нагрузку VSOCKpuppet. Далее он изменяет файл конфигурации /var/run/inetd.conf, предназначенный для демона сетевой службы inetd на ESXi, добавляя следующую строку:
- ftp stream tcp nowait root /var/run/aa ++group=host/vim/vimuser/terminal/ssh
Этот механизм перехватывает порт 21 (FTP), любое TCP-соединение с этим портом запускает /var/run/a от имени root. Параметр ++group=host/vim/vimuser/terminal/ssh предоставляет бэкдору повышенный доступ к хосту.
Для активации конфигурации шеллкод считывает файл /var/run/inetd.pid, анализирует идентификатор процесса и отправляет сигнал SIGHUP (сигнал 1) в inetd — стандартный сигнал Unix для перезагрузки конфигурации. После короткой паузы он подключается к локальному IP-адресу 127.0.0.1:21 , чтобы запустить бэкдор.
Наконец, шеллкод восстанавливает исходное содержимое файла /var/run/inetd.conf, удаляя вредоносную запись. Этот этап очистки затрудняет криминалистический анализ, поскольку после эксплуатации файл конфигурации остается нетронутым.
VSOCKpuppet: удаленный доступ на основе VSOCK
VSOCKpuppet — это 64-битный исполняемый файл ELF, обеспечивающий постоянный удаленный доступ к хосту ESXi. Вместо использования традиционных сетевых сокетов, бэкдор взаимодействует через VSOCK (Virtual Sockets), высокоскоростной интерфейс VMware для связи между гостевыми виртуальными машинами и гипервизором. Это делает трафик бэкдора невидимым для инструментов мониторинга сети.
При запуске бэкдор получает семейство адресов VSOCK, открывая /dev/vsock или /vmfs/devices/char/vsock/vsock и выполняя команду ioctl VMCI_SOCKETS_GET_AF_VALUE (0x7B8). Эта команда ioctl запрашивает у драйвера vsock правильный номер протокола для передачи функции socket(), поскольку номер протокола VSOCK динамически назначается при загрузке модуля ядра и различается в Linux (обычно 40) и ESXi.
Бэкдор привязывается к порту VSOCK 10000 с контекстным идентификатором -1 (VMADDR_CID_ANY), позволяя любой виртуальной машине на хосте взаимодействовать с ним.
Бэкдор ожидает двухбайтового триггера "ok", затем запускает дочерний процесс для обработки команд. Он поддерживает три операции: GET считывает файл с хоста ESXi и отправляет его содержимое обратно злоумышленнику, разрешая передачу данных. POST принимает данные и записывает их в указанный путь к файлу на хосте. Любой другой ввод рассматривается как команда оболочки, бэкдор записывает её в /tmp/input , выполняет через /bin/sh и возвращает результат.
Почему именно VSOCK?
VSOCK обеспечивает прямую связь между гостевыми виртуальными машинами и гипервизором без прохождения через сетевой стек. В отличие от трафика TCP/IP, связь VSOCK не генерирует сетевые пакеты, видимые для традиционных инструментов анализа сетевого трафика, межсетевых экранов или систем обнаружения вторжений.
Специалисты по защите могут обнаруживать процессы с открытыми сокетами VMCI с помощью команды lsof -a на хосте ESXi, которая отображает записи типа SOCKET_VMCI. Однако вывод отображает только идентификаторы процессов и общие описания, такие как {нет имени файла}; для идентификации фактического вредоносного исполняемого файла специалистам по защите необходимо получить дамп памяти процесса для дальнейшего анализа. Компания Mandiant опубликовала подробные рекомендации по обнаружению бэкдоров VMCI и компрометации ESXi в своих статьях в блоге, посвященных обнаружению и усилению защиты гипервизора ESXi и обнаружению, локализации и усилению защиты VMware - https://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-detection-hardening.
Отлично, у нас есть лазейка... теперь как ею воспользоваться?
После компрометации гипервизора ESXi и прослушивания VSOCKpuppet на порту 10000, злоумышленнику по-прежнему необходим способ взаимодействия с ним. Поскольку VSOCK обеспечивает прямой канал связи между гостевыми виртуальными машинами и гипервизором, он может запустить клиент из любой виртуальной машины Windows на этом хосте для отправки команд обратно на скомпрометированный ESXi. Именно здесь на помощь приходит client.exe или плагин GetShell (находится в бинарном архиве, распространяемом злоумышленником), простой клиент VSOCK для Windows, обеспечивающий интерактивный доступ к командной оболочке бэкдора.
Исполняемый файл содержит информативный путь к PDB-файлу, позволяющий заглянуть в среду разработки злоумышленника:
- C:\Users\test\Desktop\2023_11_02\vmci_vm_escape\getshell\source\client\x64\Release\client.pdb
Путь указывает на то, что это было собрано 2 ноября 2023 года в рамках более широкого набора инструментов vmci_vm_escape с компонентом getshell. Сам client.exe не содержит кода эксплойта, это просто универсальный инструмент связи VSOCK, работающий с любой версией ESXi. Это потенциально указывает на модульный подход: злоумышленник поддерживает многоразовые инструменты постэксплуатации, отдельные от самих эксплойтов, что позволяет ему заменять уязвимости новыми, сохраняя при этом ту же инфраструктуру.
Установка драйверов
Прежде чем начнется обмен данными через VSOCK, необходимо наличие соответствующих драйверов VMware. Клиент проверяет наличие VMCI и устанавливает драйверы при необходимости.
Если драйвер VMCI недоступен, клиент выполняет установку драйвера с помощью файла "InfDefaultInstall.exe".
C:\Windows\System32\InfDefaultInstall.exe C:\Windows\vmci.inf
C:\Windows\System32\InfDefaultInstall.exe C:\Windows\vsock.inf
В папке Binary также находятся модифицированные пакеты драйверов VMware. Изучение обоих INF-файлов выявляет идентичные изменения, как показано ниже.
В обоих файлах прослеживается одна и та же закономерность: заголовок об авторских правах был изменен на "XLab", в то время как строки поставщика, версии драйверов, ключи реестра и определения служб остались неизменными по сравнению с легитимными пакетами VMware. Злоумышленник просто отредактировал комментарии об авторских правах и включил в пакет оригинальные подписанные драйверы.
После установки драйвера клиент регистрирует библиотеку VSOCK от VMware в качестве поставщика Winsock, используя API WSCInstallProvider64_32 , что позволяет осуществлять сокетную связь через VMCI.
Использование и протокол
Клиент ожидает простой аргумент командной строки, указывающий целевой CID и порт:
- client SERVER_CID:PORT
В архитектуре VSOCK от VMware идентификатор CID 2 всегда зарезервирован для хоста гипервизора, поэтому подключение к бэкдору осуществляется очень просто:
- client.exe 2:10000
Протокол начинается с рукопожатия: клиент отправляет "test", за которым следует "ok", затем ожидает подтверждения "ok" от сервера, прежде чем продолжить. После рукопожатия обмен данными осуществляется с использованием сообщений с префиксом длины. Для больших объемов данных они разбиваются на фрагменты по 32 КБ, каждый из которых подтверждается сообщением "ok" перед отправкой следующего.
Клиент дублирует набор команд бэкдора: получает файлы для скачивания с ESXi на виртуальную машину, отправляет файлы для загрузки с виртуальной машины на ESXi, а все остальное передается в виде команд оболочки для выполнения на гипервизоре.
Что интересно, в папке Binary находится файл README с инструкциями по использованию, позволяющий нам напрямую ознакомиться с предполагаемым рабочим процессом.
Кто это сделал? Хороший вопрос.
В исполняемых файлах эксплойта содержатся пути к PDB-файлам, позволяющие получить представление о среде разработки.
MyDriver.sys:
C:\Users\test\Desktop\2024_02_19\全版本逃逸--交付\report\ESXI_8.0u3\
Название папки переводится как "All version escape - delivery", что указывает на то, что это был пакет, предназначенный для ESXi 8.0 Update 3. Дата в пути (19 февраля 2024 г.) более чем на год опережает публичное раскрытие информации VMware, подтверждая, что это было разработано как потенциальная уязвимость нулевого дня.
Интересно, что, хотя в описании этапов разработки используется упрощенный китайский язык, в комплект инструментария входит файл README на английском языке с инструкциями по использованию. Такое сочетание — китайские материалы разработки и английская документация — может указывать на то, что инструментарий предназначался для продажи или распространения среди более широкой аудитории.
Что касается пакетов драйверов, то файлы vmci.inf и vsock.inf содержат измененный заголовок об авторских правах, ссылающийся на "XLab", значение этой строки неясно. В ходе нашего исследования мы отметили, что XLab — это также название исследовательской группы по кибербезопасности в компании Qi An Xin, крупной китайской компании, занимающейся вопросами безопасности. Однако "XLab" — это общий термин, и у нас нет доказательств, связывающих этот набор инструментов с этой организацией или какой-либо другой конкретной структурой.
Использование упрощенного китайского языка в процессе разработки, в сочетании с уровнем сложности и потенциальным доступом к уязвимостям нулевого дня за несколько месяцев до их публичного раскрытия, указывает на то, что разработчик, вероятно, обладает значительными ресурсами и работает в китайскоязычном регионе.
Заключение
Это вторжение демонстрирует сложную многоступенчатую цепочку атак, разработанную для обхода изоляции виртуальных машин и компрометации базового гипервизора ESXi. Благодаря утечке информации, повреждению памяти и выходу из песочницы, злоумышленник добился того, чего боится каждый администратор виртуальных машин: полного контроля над гипервизором изнутри гостевой виртуальной машины.
Использование VSOCK для бэкдор-коммуникации вызывает особую обеспокоенность, поскольку оно полностью обходит традиционный сетевой мониторинг, что значительно затрудняет обнаружение. Кроме того, инструментарий отдает приоритет скрытности, а не сохранению: он восстанавливает inetd.conf после запуска бэкдора и помещает исполняемый файл в /var/run/, который не сохраняется после перезагрузки. Это говорит о том, что злоумышленник намеревался быстро достичь своих целей, а не поддерживать долгосрочный доступ.
Хронология разработки, раскрытая в путях PDB, говорит о том, что эта уязвимость потенциально существовала как уязвимость нулевого дня более года до публичного раскрытия информации компанией VMware, что подчеркивает сохраняющуюся угрозу со стороны хорошо обеспеченных ресурсами субъектов, имеющих доступ к незащищенным уязвимостям.
Рекомендация
Организациям, использующим VMware ESXi 7.0 или 8.0, следует немедленно установить последние обновления. Поддержка ESXi 6.x и более ранних версий прекращена, и обновления для них не установлены. Дополнительные рекомендации по усилению защиты см. в нашей статье о защите гипервизоров от программ-вымогателей, нацеленных на ESXi .
Обнаружение
Яра правила
Сигма
Правила для обнаружения некоторых ключевых особенностей работы exploit.exe, позволяющих осуществить эксплуатацию уязвимости ESXi и покинуть виртуальную машину:
https://github.com/huntresslabs/threat-intel/blob/main/2026/2026-01/vm_escape/sigma/proc_creation_win_devcon_disable_vmci_driver.yml
Автор перевода - @yashechka.
Источник - https://www.huntress.com/blog/esxi-vm-escape-exploit
В декабре 2025 года Huntress обнаружила вторжение, которое привело к развертыванию эксплойтов для VMware ESXi.
На основании наблюдаемых нами признаков, включая имя рабочей станции, с которой действовал злоумышленник, и другие тактические приемы, группа быстрого реагирования Huntress с высокой степенью уверенности оценивает, что первоначальный доступ был осуществлен через VPN-соединение SonicWall.
Анализируемый в этом отчете набор инструментов также включает в себя строки на упрощенном китайском языке в своих путях разработки, в том числе папку с названием «全版本逃逸--交付» (переводится как "Побег из всех версий — доставка"), и имеются свидетельства, указывающие на то, что он потенциально был создан как эксплойт нулевого дня более чем за год до публичного раскрытия информации компанией VMware, что указывает на наличие хорошо обеспеченного ресурсами разработчика, вероятно, работающего в китайскоязычном регионе.
Учитывая особенности эксплуатации уязвимостей ESXi, эта деятельность могла бы завершиться атакой с использованием программ-вымогателей, но она была пресечена группой тактического реагирования Huntress и Центром оперативного управления безопасностью (SOC). Ниже приведено краткое изложение наших наблюдений.
Ключевые моменты
- Первоначальный доступ, вероятно, осуществлялся через VPN. Несмотря на изощренность способа обхода виртуальной машины, злоумышленники проникли внутрь через скомпрометированный VPN-сервер SonicWall. Основные моменты по-прежнему имеют значение.
- Изоляция виртуальных машин не является абсолютной. Уязвимости гипервизора могут позволить злоумышленникам выйти из гостевых виртуальных машин и скомпрометировать все рабочие нагрузки на хосте.
- Активно обновляйте ESXi. Этот набор инструментов для эксплуатации уязвимостей поддерживает 155 сборок ESXi, охватывающих версии от 5.1 до 8.0. Если вы используете версии, поддержка которых прекращена, вы уязвимы, и исправление для них недоступно.
- В сетевом мониторинге есть "слепые зоны". Трафик VSOCK между виртуальными машинами и гипервизором невидим для межсетевых экранов и систем обнаружения вторжений. Для мониторинга необычных процессов на хостах ESXi используйте команду "lsof -a".
- Остерегайтесь методов BYOD (использование личных устройств на рабочем месте). Использование KDU для загрузки неподписанных драйверов обходит Проверку Подписи Драйверов. Следите за загрузкой известных уязвимых драйверов.
Что вообще произошло ?
Резервный контроллер домена
Злоумышленник, используя скомпрометированную учетную запись администратора домена (DA), переместился на резервный контроллер домена через RDP. Он попытался изменить пароль DA на Password01$ с помощью Impacket, но эта попытка была предотвращена управляемым Huntress модулем Microsoft Defender for Endpoint (MDE).
Были задействованы следующие средства разведки:
- C:\Users\User\Downloads\Advanced_Port_Scanner_2.5.3869.exe
- C:\Program Files\SoftPerfect Network Scanner\netscan.exe
Затем хакер запустил программу ShareFinder для перечисления сетевых ресурсов, выведя результаты в файл C:\ProgramData\shares.txt.
Основной контроллер домена
Используя ту же скомпрометированную учетную запись DA, злоумышленник переместился на основной контроллер домена и развернул набор эксплойтов VMware ESXi. Примерно через 20 минут он изменил настройки брандмауэра Windows, чтобы изолировать хост от внешних сетей, сохраняя при этом внутреннюю связь, с помощью приведенных ниже команд:
- netsh advfirewall firewall add rule "name=Allow Local Network-2" dir=out action=allow remoteip=10.xxx/8 profile=any
- netsh advfirewall firewall add rule "name=Block External Outbound" dir=out action=block remoteip=0.0.0.0-255.255.255.255 profile=any
- netsh advfirewall firewall add rule "name=Allow Local Network-3" dir=out action=allow remoteip=172.xxx/12 profile=any
Подобные модификации брандмауэра часто встречаются при вторжениях и направлены на предотвращение доступа жертвы к внешним ресурсам для получения помощи или отправки запросов средствам безопасности на серверы, при этом позволяя злоумышленнику перемещаться по внутренним сетям для максимального увеличения радиуса поражения.
После внесения изменений в настройки брандмауэра, хакер начал подготовку данных для эксфильтрации с помощью WinRAR:
"C:\Program Files\WinRAR\WinRAR.exe" a -ep1 -scul -r0 -iext -imon1 -- . "Mapped Network Share"
Команды эксплойта:
- devcon.exe disable “PCI\VEN_15AD&DEV_0740” — отключает устройство VMware VMCI PCI для получения прямого доступа к оборудованию.
- devcon.exe disable “ROOT\VMWVMCIHOSTDEV” - отключает драйвер хоста VMware VMCI.
- kdu.exe -prv 1 -map MyDriver.sys - использует утилиту драйверов ядра (KDU) для обхода проверки подписи драйверов и загрузки неподписанного эксплойт-драйвера в память ядра.
- exploit.exe (MAESTRO) организует атаку по выходу из виртуальной машины и устанавливает бэкдор на гипервизор ESXi.
Потенциально используемые уязвимости
4 марта 2025 года компания VMware выпустила уведомление о безопасности VMSA-2025-0004 , касающееся трех уязвимостей, о которых сообщило Управление по анализу угроз Microsoft. Все три уязвимости были подтверждены как используемые злоумышленниками:
- CVE-2025-22226 (CVSS 7.1): Выход за пределы допустимого диапазона чтения в HGFS, который приводит к утечке памяти из процесса VMX.
- CVE-2025-22224 (CVSS 9.3): Уязвимость TOCTOU в VMCI, приводящая к записи за пределы допустимого диапазона, что позволяет выполнять код от имени процесса VMX.
- CVE-2025-22225 (CVSS 8.2): Уязвимость произвольной записи в ESXi, позволяющая выйти за пределы песочницы VMX и перейти в ядро.
На основе анализа поведения эксплойта, использования им HGFS для утечки информации, VMCI для повреждения памяти и шеллкода, проникающего в ядро, группа тактического реагирования Huntress с умеренной степенью уверенности оценивает, что этот набор инструментов использует указанные три уязвимости CVE.
Что такое VMX?
VMX (Virtual Machine Executable) — это процесс, который запускается на хосте ESXi для каждой виртуальной машины. Согласно документации VMware - (https://knowledge.broadcom.com/external/article/339468/interpreting-virtual-machine-monitor-and.html), VMX "отвечает за обработку операций ввода-вывода для устройств, не критически важных для производительности", и "взаимодействует с пользовательскими интерфейсами, менеджерами моментальных снимков и удаленной консолью". Это включает в себя такие функции, как совместное использование буфера обмена, перетаскивание и взаимодействие с VMware Tools — именно те функции, на которые нацелена эта уязвимость.
Каждая запущенная виртуальная машина имеет свой собственный процесс VMX. С точки зрения злоумышленника, VMX является первой целью для выхода из виртуальной машины, поскольку он обрабатывает недоверенные входные данные от гостевой системы. Однако VMX работает внутри песочницы на ESXi, поэтому для его взлома требуется дополнительный шаг для получения полного доступа к хосту.
Инструменты для эксплуатации уязвимостей VMWare
Не удалось прогрузить медиа
Если эта блок-схема вызывает у вас головокружение, не волнуйтесь, оставайтесь со мной, и к концу все станет понятно, надеюсь. Цвета не обозначают ничего конкретного, они просто помогают легче следить за ходом событий.
Оркестрация эксплойтов
exploit.exe (MAESTRO)
Исполняемый файл exploit.exe, который мы назвали MAESTRO, служит оркестратором всей атаки по выходу из виртуальной машины. Он не содержит фактической логики эксплуатации, вместо этого он подготавливает среду, развертывает драйвер эксплойта, отслеживает ход выполнения и выполняет последующую очистку.
Исполняемый файл содержит 4 встроенных двоичных файла во встроенных ресурсах:
- MyDriver.sys — неподписанный драйвер ядра, содержащий эксплойт для выхода из виртуальной машины.
- kdu.exe — утилита для управления драйверами ядра (инструмент загрузки BYOD)
- devcon.exe — Microsoft Device Console, утилита для управления устройствами.
- drv64.dll - библиотека поддержки KDU
Не удалось прогрузить медиа
Этап 1: Отключение драйверов VMware VMCI
Эксплойт начинается с отключения драйверов VMCI для гостевой системы VMware с помощью утилиты devcon.exe от Microsoft. Отключаются два экземпляра устройств:
- PCI\VEN_15AD&DEV_0740 — PCI-устройство VMware VMCI (Vendor 0x15AD = VMware, Device 0x0740 = VMCI)
- ROOT\VMWVMCIHOSTDEV — драйвер хост-устройства VMware VMCI.
Что такое VMCI?
Интерфейс связи виртуальных машин VMware (VMCI) — это высокоскоростной механизм связи, который обеспечивает взаимодействие между виртуальной машиной и ее хостом ESXi, а также прямую связь между виртуальными машинами на одном хосте.
Зачем отключать драйвер VMCI?
Для работы эксплойт-драйвера необходимо напрямую взаимодействовать с оборудованием VMCI, используя низкоуровневые инструкции ввода-вывода. Если мы посмотрим на файл "MyDriver.sys" (вредоносный драйвер), то после обнаружения устройства VMCI на шине PCI он считывает регистр базового адреса устройства (BAR0), чтобы получить базовый адрес порта ввода-вывода.
Не удалось прогрузить медиа
Получив адрес BAR0, эксплойт использует инструкции x86 "IN/OUT" для прямой связи с аппаратными регистрами VMCI:
Не удалось прогрузить медиа
При загрузке vmci.sys он получает контроль над адаптером VMCI и активно использует те же порты ввода-вывода. Два драйвера не могут безопасно использовать одно и то же оборудование; если оба попытаются одновременно отправлять команды, это приведет к повреждению состояния устройства и сбою системы. Отключив vmci.sys в первую очередь, эксплойт получает эксклюзивный доступ к оборудованию VMCI.
Загрузка неподписанного драйвера через BYOD
Поскольку файл "MyDriver.sys" не подписан, его невозможно загрузить обычным способом в системах с включенной проверкой подписи драйверов (DSE). Эксплойт использует KDU (Kernel Driver Utility), инструмент с открытым исходным кодом для загрузки неподписанных драйверов в память ядра.
- kdu.exe -prv 1 -map MyDriver.sys , где:
-- prv 1 - Используйте поставщика №1, драйвер с легитимной подписью, но уязвимый.
-- map — Вручную сопоставить неподписанный драйвер с памятью ядра.
KDU использует уязвимость в подписанном драйвере для получения доступа к выполнению кода ядра, а затем использует этот доступ для загрузки файла MyDriver.sys. Шестисекундная задержка после выполнения дает драйверу время для инициализации и начала процесса эксплуатации уязвимости.
Мониторинг хода выполнения эксплойта
После загрузки MyDriver.sys создает объект устройства, доступный по символической ссылке \\.\TDLD (Рисунок 2). Оркестратор (exploit.exe) открывает это устройство и опрашивает его каждые 4 секунды, и когда драйвер возвращает значение состояния 2, эксплуатация завершена, и цикл завершается.
Восстановление драйверов VMware
После успешной эксплуатации (статус == 2) оркестратор повторно включает драйверы VMware VMCI. Это восстановление, вероятно, служит для обеспечения операционной безопасности: виртуальная машина продолжает нормально функционировать с работающими инструментами VMware Tools, что снижает подозрения в совершении каких-либо вредоносных действий.
Эксплуотирование драйвера
MyDriver.sys
Разобравшись с уровнем оркестровки, давайте перейдем к MyDriver.sys, драйверу ядра, который выполняет фактическое освобождение виртуальной машины. Этот драйвер содержит следующую основную логику эксплуатации:
- Использование бэкдора VMware для сбора информации
- Манипулирование оборудованием VMCI для активации уязвимостей
- Чтение и запись памяти процесса VMX
- Развертывание шеллкода ESXi
Прежде чем начать эксплуатацию уязвимости, драйверу необходимо определить точную версию ESXi, работающую на хосте. Различные сборки ESXi имеют разную структуру памяти, поэтому эксплойт требует смещений, специфичных для каждой версии. Драйвер запрашивает версию хоста ESXi, используя документированную команду VMware Guest SDK "guestlib.stat.get text session". Эта команда, обычно используемая VMware Tools и сторонними агентами для целей мониторинга, возвращает информацию о хосте, включая точную строку версии ESXi (например, "VMware ESX 8.0.0 build-24022510"). Эксплойт анализирует этот ответ, чтобы извлечь номер версии и сборки.
Не удалось прогрузить медиа
После определения версии и номера сборки ESXi драйвер обращается к таблице предварительно вычисленных смещений, специфичных для данной сборки. Эксплойт внедряет жестко закодированную таблицу, содержащую 155 поддерживаемых сборок ESXi, охватывающих версии от 5.1 до 8.0.
Не удалось прогрузить медиа
Каждая запись хранит номер сборки и 17 смещений, специфичных для версии, необходимых для обнаружения структур процесса VMX. Эти смещения изменяются между сборками ESXi из-за модификаций кода и различий в компиляторах. Если обнаруженная сборка отсутствует в таблице, эксплойт не срабатывает, что является распространенным ограничением эксплойтов, основанных на смещениях.
Утечка базового адреса VMX
После загрузки смещений, специфичных для каждой версии, следующим шагом является утечка базового адреса процесса VMX для обхода ASLR. Поскольку таблица смещений содержит относительные смещения, а не абсолютные адреса, эксплойт должен определить, где VMX загружен в память, прежде чем он сможет вычислить точные места для записи шеллкода и повреждения структур. Приведенная ниже функция выполняет последовательность операций с бэкдором, связанных с HGFS, для запуска раскрытия информации.
Не удалось прогрузить медиа
Функция выполняет последовательность операций, связанных с бэкдором HGFS, для запуска раскрытия информации. Функция начинается с выделения буфера размером 64 КБ и выбора размера сообщения в зависимости от версии ESXi. Для ESXi 5.x и 6.x размер сообщения составляет 50616 байт. Для ESXi 7.0 и 8.0 — 50624 байта. Далее, ряд команд RPC настраивает состояние VMware Tools в процессе VMX:
Не удалось прогрузить медиа
Критически важная команда — tools.capability.hgfs_server toolbox-dnd 1 , которая позволяет использовать функцию перетаскивания файлов между хостом и гостевой системой. Эта функциональность является частью файловой системы Host-Guest File System (HGFS) от VMware и позволяет пользователям перетаскивать файлы со своего рабочего стола в окно виртуальной машины. Согласно бюллетеню безопасности VMware VMSA-2025-0004, CVE-2025-22226 — это уязвимость раскрытия информации, вызванная чтением за пределы допустимого диапазона в HGFS. В бюллетене говорится, что "злоумышленник с административными привилегиями в виртуальной машине может использовать эту уязвимость для утечки памяти из процесса vmx". Хотя мы не можем подтвердить точную первопричину, использование эксплойтом HGFS и вызванная этим утечка памяти соответствуют этому описанию.
Затем эксплойт открывает шесть каналов связи через бэкдор и закрывает два из них (каналы 2 и 4). Термин "бэкдор", по-видимому, является собственной терминологией VMware для механизма связи между гостевой системой и хостом. Он работает за счет доступа к порту ввода-вывода 0x5658 на физической машине; этот порт ни к чему не подключен, но внутри виртуальной машины VMware гипервизор перехватывает доступ к нему и использует его в качестве канала команд. Именно так VMware Tools реализует такие функции, как совместное использование буфера обмена, перетаскивание и изменение размера экрана.
Через канал отправляется большой буфер из нулей (~50 КБ), за которым следует строка "OK ATR toolbox-dnd" для инициализации операции перетаскивания в HGFS.
Наконец, эксплойт формирует и отправляет полезную нагрузку, которая запускает чтение за пределы допустимого диапазона:
4F 4B 20 00 00 00 00 FF 00 00 00 A5 C5 00 00 A4 C5 00 00 00 00 00 80 29 00 00 00 + [50573 нули]
Перед использованием полученного указателя эксплойт проверяет его, сравнивая биты 8-11 с ожидаемым значением из таблицы смещений. Для сборки 24022510 маскирование обоих значений значением 0xF00 должно дать совпадающие результаты. После проверки базовый адрес VMX вычисляется путем вычитания известного смещения (0x01590300) из полученного указателя:
vmxBase = leakedPtr - 0x01590300
В таблице смещений хранится известный адрес внутри VMX для каждой поддерживаемой сборки. Утечка указателя указывает на предсказуемое местоположение внутри VMX. Вычитая это известное смещение, эксплойт определяет, где VMX загружен в память, тем самым обходя ASLR.
Запись шелл-кода в память VMX
Зная базовый адрес VMX, эксплойт теперь может считывать и записывать данные непосредственно в память VMX.
Обе операции работают путем формирования 95-байтового заголовка и его отправки через каналы бэкдора VMware. При записи заголовок содержит команду типа 2, размер записываемых данных и целевой адрес в памяти VMX. Сначала отправляется заголовок, а затем сами данные по второму каналу. При чтении заголовок содержит команду типа 3 и целевой адрес, и эксплойт получает обратно 8 байт, содержащих данные по этому адресу.
Мы считаем, что возможность чтения/записи обеспечивается уязвимостью CVE-2025-22224, которую VMware описывает как уязвимость, "приводящую к записи за пределы допустимого диапазона".
Не удалось прогрузить медиа
Таким образом, эксплойт записывает три полезных нагрузки в память VMX:
- Шеллкод первого этапа
- Шеллкод второго этапа
- ELF Backdoor
Бэкдор ELF, который мы назвали "VSOCKpuppet", представляет собой исполняемый файл Linux, поскольку ESXi работает на ядре на основе Linux, поэтому нативные бинарные файлы Linux могут выполняться непосредственно на гипервизоре.
После записи полезной нагрузки эксплойт перезаписывает указатель на функцию внутри VMX. Сначала он сохраняет исходное значение указателя, а затем перезаписывает его адресом шеллкода. После этого эксплойт отправляет хосту сообщение VMCI для запуска VMX. Когда VMX обрабатывает сообщение, он следует по поврежденному указателю и переходит к шеллкоду злоумышленника вместо легитимного кода.
Этот заключительный этап соответствует уязвимости CVE-2025-22225, которую VMware описывает как "уязвимость произвольной записи", позволяющую "выйти за пределы песочницы".
Шеллкод 1
Первый этап выполнения шеллкода происходит внутри процесса VMX и использует системные вызовы VMkernel для запроса информации о внутреннем устройстве ядра. Шеллкод циклически повторяет поиск до 4902 раз, ища объект с именем "general", затем запрашивает информацию о "vmkernel" и "vmci". Найдя их, он извлекает их базовые адреса.
- vmkernel base: %p, qpBrokerList: %p
Эти адреса имеют решающее значение для следующего этапа, поскольку позволяют эксплойту рассчитать, куда записывать данные в память ядра, чтобы выйти из песочницы VMX.
Не удалось прогрузить медиа
Шеллкод 2
На втором этапе шеллкод устанавливает точку опоры на хосте ESXi, используя стандартные системные вызовы Linux. Он создает файл бэкдора в /var/run/a с полными правами доступа (0777), а затем записывает в него полезную нагрузку VSOCKpuppet. Далее он изменяет файл конфигурации /var/run/inetd.conf, предназначенный для демона сетевой службы inetd на ESXi, добавляя следующую строку:
- ftp stream tcp nowait root /var/run/aa ++group=host/vim/vimuser/terminal/ssh
Этот механизм перехватывает порт 21 (FTP), любое TCP-соединение с этим портом запускает /var/run/a от имени root. Параметр ++group=host/vim/vimuser/terminal/ssh предоставляет бэкдору повышенный доступ к хосту.
Для активации конфигурации шеллкод считывает файл /var/run/inetd.pid, анализирует идентификатор процесса и отправляет сигнал SIGHUP (сигнал 1) в inetd — стандартный сигнал Unix для перезагрузки конфигурации. После короткой паузы он подключается к локальному IP-адресу 127.0.0.1:21 , чтобы запустить бэкдор.
Наконец, шеллкод восстанавливает исходное содержимое файла /var/run/inetd.conf, удаляя вредоносную запись. Этот этап очистки затрудняет криминалистический анализ, поскольку после эксплуатации файл конфигурации остается нетронутым.
Не удалось прогрузить медиа
VSOCKpuppet: удаленный доступ на основе VSOCK
VSOCKpuppet — это 64-битный исполняемый файл ELF, обеспечивающий постоянный удаленный доступ к хосту ESXi. Вместо использования традиционных сетевых сокетов, бэкдор взаимодействует через VSOCK (Virtual Sockets), высокоскоростной интерфейс VMware для связи между гостевыми виртуальными машинами и гипервизором. Это делает трафик бэкдора невидимым для инструментов мониторинга сети.
При запуске бэкдор получает семейство адресов VSOCK, открывая /dev/vsock или /vmfs/devices/char/vsock/vsock и выполняя команду ioctl VMCI_SOCKETS_GET_AF_VALUE (0x7B8). Эта команда ioctl запрашивает у драйвера vsock правильный номер протокола для передачи функции socket(), поскольку номер протокола VSOCK динамически назначается при загрузке модуля ядра и различается в Linux (обычно 40) и ESXi.
Не удалось прогрузить медиа
Бэкдор привязывается к порту VSOCK 10000 с контекстным идентификатором -1 (VMADDR_CID_ANY), позволяя любой виртуальной машине на хосте взаимодействовать с ним.
Бэкдор ожидает двухбайтового триггера "ok", затем запускает дочерний процесс для обработки команд. Он поддерживает три операции: GET считывает файл с хоста ESXi и отправляет его содержимое обратно злоумышленнику, разрешая передачу данных. POST принимает данные и записывает их в указанный путь к файлу на хосте. Любой другой ввод рассматривается как команда оболочки, бэкдор записывает её в /tmp/input , выполняет через /bin/sh и возвращает результат.
Почему именно VSOCK?
VSOCK обеспечивает прямую связь между гостевыми виртуальными машинами и гипервизором без прохождения через сетевой стек. В отличие от трафика TCP/IP, связь VSOCK не генерирует сетевые пакеты, видимые для традиционных инструментов анализа сетевого трафика, межсетевых экранов или систем обнаружения вторжений.
Специалисты по защите могут обнаруживать процессы с открытыми сокетами VMCI с помощью команды lsof -a на хосте ESXi, которая отображает записи типа SOCKET_VMCI. Однако вывод отображает только идентификаторы процессов и общие описания, такие как {нет имени файла}; для идентификации фактического вредоносного исполняемого файла специалистам по защите необходимо получить дамп памяти процесса для дальнейшего анализа. Компания Mandiant опубликовала подробные рекомендации по обнаружению бэкдоров VMCI и компрометации ESXi в своих статьях в блоге, посвященных обнаружению и усилению защиты гипервизора ESXi и обнаружению, локализации и усилению защиты VMware - https://cloud.google.com/blog/topics/threat-intelligence/esxi-hypervisors-detection-hardening.
Отлично, у нас есть лазейка... теперь как ею воспользоваться?
После компрометации гипервизора ESXi и прослушивания VSOCKpuppet на порту 10000, злоумышленнику по-прежнему необходим способ взаимодействия с ним. Поскольку VSOCK обеспечивает прямой канал связи между гостевыми виртуальными машинами и гипервизором, он может запустить клиент из любой виртуальной машины Windows на этом хосте для отправки команд обратно на скомпрометированный ESXi. Именно здесь на помощь приходит client.exe или плагин GetShell (находится в бинарном архиве, распространяемом злоумышленником), простой клиент VSOCK для Windows, обеспечивающий интерактивный доступ к командной оболочке бэкдора.
Исполняемый файл содержит информативный путь к PDB-файлу, позволяющий заглянуть в среду разработки злоумышленника:
- C:\Users\test\Desktop\2023_11_02\vmci_vm_escape\getshell\source\client\x64\Release\client.pdb
Путь указывает на то, что это было собрано 2 ноября 2023 года в рамках более широкого набора инструментов vmci_vm_escape с компонентом getshell. Сам client.exe не содержит кода эксплойта, это просто универсальный инструмент связи VSOCK, работающий с любой версией ESXi. Это потенциально указывает на модульный подход: злоумышленник поддерживает многоразовые инструменты постэксплуатации, отдельные от самих эксплойтов, что позволяет ему заменять уязвимости новыми, сохраняя при этом ту же инфраструктуру.
Установка драйверов
Прежде чем начнется обмен данными через VSOCK, необходимо наличие соответствующих драйверов VMware. Клиент проверяет наличие VMCI и устанавливает драйверы при необходимости.
Не удалось прогрузить медиа
Если драйвер VMCI недоступен, клиент выполняет установку драйвера с помощью файла "InfDefaultInstall.exe".
C:\Windows\System32\InfDefaultInstall.exe C:\Windows\vmci.inf
C:\Windows\System32\InfDefaultInstall.exe C:\Windows\vsock.inf
В папке Binary также находятся модифицированные пакеты драйверов VMware. Изучение обоих INF-файлов выявляет идентичные изменения, как показано ниже.
Не удалось прогрузить медиа
В обоих файлах прослеживается одна и та же закономерность: заголовок об авторских правах был изменен на "XLab", в то время как строки поставщика, версии драйверов, ключи реестра и определения служб остались неизменными по сравнению с легитимными пакетами VMware. Злоумышленник просто отредактировал комментарии об авторских правах и включил в пакет оригинальные подписанные драйверы.
После установки драйвера клиент регистрирует библиотеку VSOCK от VMware в качестве поставщика Winsock, используя API WSCInstallProvider64_32 , что позволяет осуществлять сокетную связь через VMCI.
Использование и протокол
Клиент ожидает простой аргумент командной строки, указывающий целевой CID и порт:
- client SERVER_CID:PORT
В архитектуре VSOCK от VMware идентификатор CID 2 всегда зарезервирован для хоста гипервизора, поэтому подключение к бэкдору осуществляется очень просто:
- client.exe 2:10000
Протокол начинается с рукопожатия: клиент отправляет "test", за которым следует "ok", затем ожидает подтверждения "ok" от сервера, прежде чем продолжить. После рукопожатия обмен данными осуществляется с использованием сообщений с префиксом длины. Для больших объемов данных они разбиваются на фрагменты по 32 КБ, каждый из которых подтверждается сообщением "ok" перед отправкой следующего.
Не удалось прогрузить медиа
Не удалось прогрузить медиа
Клиент дублирует набор команд бэкдора: получает файлы для скачивания с ESXi на виртуальную машину, отправляет файлы для загрузки с виртуальной машины на ESXi, а все остальное передается в виде команд оболочки для выполнения на гипервизоре.
Что интересно, в папке Binary находится файл README с инструкциями по использованию, позволяющий нам напрямую ознакомиться с предполагаемым рабочим процессом.
Не удалось прогрузить медиа
Кто это сделал? Хороший вопрос.
В исполняемых файлах эксплойта содержатся пути к PDB-файлам, позволяющие получить представление о среде разработки.
MyDriver.sys:
C:\Users\test\Desktop\2024_02_19\全版本逃逸--交付\report\ESXI_8.0u3\
Название папки переводится как "All version escape - delivery", что указывает на то, что это был пакет, предназначенный для ESXi 8.0 Update 3. Дата в пути (19 февраля 2024 г.) более чем на год опережает публичное раскрытие информации VMware, подтверждая, что это было разработано как потенциальная уязвимость нулевого дня.
Интересно, что, хотя в описании этапов разработки используется упрощенный китайский язык, в комплект инструментария входит файл README на английском языке с инструкциями по использованию. Такое сочетание — китайские материалы разработки и английская документация — может указывать на то, что инструментарий предназначался для продажи или распространения среди более широкой аудитории.
Что касается пакетов драйверов, то файлы vmci.inf и vsock.inf содержат измененный заголовок об авторских правах, ссылающийся на "XLab", значение этой строки неясно. В ходе нашего исследования мы отметили, что XLab — это также название исследовательской группы по кибербезопасности в компании Qi An Xin, крупной китайской компании, занимающейся вопросами безопасности. Однако "XLab" — это общий термин, и у нас нет доказательств, связывающих этот набор инструментов с этой организацией или какой-либо другой конкретной структурой.
Использование упрощенного китайского языка в процессе разработки, в сочетании с уровнем сложности и потенциальным доступом к уязвимостям нулевого дня за несколько месяцев до их публичного раскрытия, указывает на то, что разработчик, вероятно, обладает значительными ресурсами и работает в китайскоязычном регионе.
Заключение
Это вторжение демонстрирует сложную многоступенчатую цепочку атак, разработанную для обхода изоляции виртуальных машин и компрометации базового гипервизора ESXi. Благодаря утечке информации, повреждению памяти и выходу из песочницы, злоумышленник добился того, чего боится каждый администратор виртуальных машин: полного контроля над гипервизором изнутри гостевой виртуальной машины.
Использование VSOCK для бэкдор-коммуникации вызывает особую обеспокоенность, поскольку оно полностью обходит традиционный сетевой мониторинг, что значительно затрудняет обнаружение. Кроме того, инструментарий отдает приоритет скрытности, а не сохранению: он восстанавливает inetd.conf после запуска бэкдора и помещает исполняемый файл в /var/run/, который не сохраняется после перезагрузки. Это говорит о том, что злоумышленник намеревался быстро достичь своих целей, а не поддерживать долгосрочный доступ.
Хронология разработки, раскрытая в путях PDB, говорит о том, что эта уязвимость потенциально существовала как уязвимость нулевого дня более года до публичного раскрытия информации компанией VMware, что подчеркивает сохраняющуюся угрозу со стороны хорошо обеспеченных ресурсами субъектов, имеющих доступ к незащищенным уязвимостям.
Рекомендация
Организациям, использующим VMware ESXi 7.0 или 8.0, следует немедленно установить последние обновления. Поддержка ESXi 6.x и более ранних версий прекращена, и обновления для них не установлены. Дополнительные рекомендации по усилению защиты см. в нашей статье о защите гипервизоров от программ-вымогателей, нацеленных на ESXi .
Обнаружение
Яра правила
Не удалось прогрузить медиа
Yara-Rules/ESXiExploitToolkit/win_mal_GetShellPlugin.yar at main · RussianPanda95/Yara-Rules
Repository of Yara Rules. Contribute to RussianPanda95/Yara-Rules development by creating an account on GitHub.
Не удалось прогрузить медиа
github.com
Не удалось прогрузить медиа
Yara-Rules/ESXiExploitToolkit/win_mal_MAESTRO.yar at main · RussianPanda95/Yara-Rules
Repository of Yara Rules. Contribute to RussianPanda95/Yara-Rules development by creating an account on GitHub.
Не удалось прогрузить медиа
github.com
Не удалось прогрузить медиа
Yara-Rules/ESXiExploitToolkit/linux_mal_VSOCKpuppet.yar at main · RussianPanda95/Yara-Rules
Repository of Yara Rules. Contribute to RussianPanda95/Yara-Rules development by creating an account on GitHub.
Не удалось прогрузить медиа
github.com
Не удалось прогрузить медиа
Yara-Rules/ESXiExploitToolkit/win_mal_MyDriverSYS.yar at main · RussianPanda95/Yara-Rules
Repository of Yara Rules. Contribute to RussianPanda95/Yara-Rules development by creating an account on GitHub.
Не удалось прогрузить медиа
github.com
Сигма
Правила для обнаружения некоторых ключевых особенностей работы exploit.exe, позволяющих осуществить эксплуатацию уязвимости ESXi и покинуть виртуальную машину:
https://github.com/huntresslabs/threat-intel/blob/main/2026/2026-01/vm_escape/sigma/proc_creation_win_devcon_disable_vmci_driver.yml
Не удалось прогрузить медиа
threat-intel/2026/2026-01/vm_escape/sigma/proc_creation_win_kdu_driver_tool_execution.yml at main · huntresslabs/threat-intel
This repository contains supplemental items including IOCs, and signatures discussed in Huntress blogposts, and other media. - huntresslabs/threat-intel
Не удалось прогрузить медиа
github.com
Автор перевода - @yashechka.
Источник - https://www.huntress.com/blog/esxi-vm-escape-exploit
👍10
❤️1
😁2
😢2