9 октября 2026Команда Сарнас

Побег из виртуальной машины на ESXi: как устроена атака MAESTRO

Инцидент с побегом из виртуальной машины на гипервизоре ESXi демонстрирует, как цепочка от скомпрометированного VPN через контроллер домена доводит атакующего до root-доступа на хосте. Разбор по шагам показывает нестандартные приёмы — отключение драйверов VMCI, обход проверки подписи драйверов и манипуляции с памятью процесса VMX — которые превращают гостевую систему в точку входа для полного контроля над инфраструктурой виртуализации.

Разбираем механику реальной атаки, в которой злоумышленник прошёл путь от скомпрометированного VPN до root на гипервизоре ESXi. Интересна она не самим фактом эксплуатации, а тем, как устроен каждый шаг: почему атакующему пришлось отключать драйверы, зачем ему точная версия сборки гипервизора и как из памяти процесса виртуальной машины получается интерактивный shell на хосте.

Цепочка атаки: от VPN до контроллера домена

Первичный доступ, по оценке Huntress, вероятно, произошёл через скомпрометированный SonicWall VPN. Дальше атакующий использовал скомпрометированную учётную запись Domain Admin и переместился по RDP на резервный контроллер домена. Там он попытался сменить пароль Domain Admin на Password01$ через Impacket, но попытка была заблокирована Huntress managed Microsoft Defender for Endpoint (MDE). На том же резервном контроллере развернулись инструменты разведки — Advanced_Port_Scanner и SoftPerfect Network Scanner, — а затем ShareFinder перечислил сетевые ресурсы, записав результат в C:\ProgramData\shares.txt.

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

Для получения root на ESXi-хосте использовались три инструмента: devcon.exe disable отключал устройства VMCI, kdu.exe обходил Driver Signature Enforcement — механизм ядра Windows, который разрешает загрузку только драйверов с действительной цифровой подписью, — и загружал неподписанный драйвер MyDriver.sys, а exploit.exe (MAESTRO) оркестрировал побег из виртуальной машины и установку бэкдора на гипервизоре.

Почему ESXi — приоритетная цель

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

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

Поверхность атаки: процесс VMX и каналы связи

VMX — это процесс, который выполняется на хосте ESXi для каждой виртуальной машины. Он отвечает за ввод-вывод к некритичным по производительности устройствам и за взаимодействие с пользовательскими интерфейсами, менеджерами снимков и удалённой консолью, включая буфер обмена, drag-and-drop и связь с VMware Tools. У каждой запущенной ВМ есть собственный процесс VMX.

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

Для связи гостя с хостом используется VMware VMCI. Эксплойт отключает гостевые драйверы VMCI (PCI-устройство VMware VMCI и ROOT\VMWVMCIHOSTDEV), чтобы получить монопольный доступ к аппаратуре VMCI через I/O-порты, и использует VMware backdoor для чтения и записи памяти процесса VMX.

После компрометации VSOCKpuppet слушает на VSOCK-порту 10000, а клиент из гостевой ВМ подключается к CID 2 и получает интерактивный shell.

VMware backdoor: 95-байтовый заголовок и регистры VMCI

Взаимодействие с хостом идёт по двум каналам. Для VMCI-устройства эксплойт после получения адреса BAR0 использует x86-инструкции IN/OUT для прямого обращения к регистрам:

BAR0 + 0x04  VMCI_CONTROL_ADDR     запись 1 сбрасывает устройство
BAR0 + 0x10  VMCI_DATA_OUT_ADDR    отправка данных в VMCI
BAR0 + 0x14  VMCI_DATA_IN_ADDR     приём данных из VMCI
BAR0 + 0x1C  VMCI_RESULT_LOW_ADDR  чтение результата операции

Для backdoor-канала чтение и запись работают через 95-байтовый заголовок. При записи заголовок содержит тип команды 2, размер записываемых данных и целевой адрес в памяти VMX; заголовок отправляется первым, а сами данные идут по второму каналу. При чтении заголовок содержит тип команды 3 и целевой адрес, а эксплойт получает обратно 8 байт с данными по этому адресу.

В более раннем описании механизма (2014 год) передача данных между гостем и хостом реализована через GuestRpc, который по сути является командой (0x1E) BackDoor I/O. Для drag-and-drop и общего буфера обмена используются транспортные интерфейсы dnd.transport и copypaste.transport, причём каждый имеет свои наборы команд, передаваемые в служебных заголовках пакета с данными.

Как драйвер находит устройство и забирает его у vmci.sys

Драйвер эксплойта сканирует PCI-шину, чтобы найти устройство VMCI. После получения адреса BAR0 он использует инструкции x86 IN/OUT для прямой связи с аппаратными регистрами по смещениям, приведённым выше.

Ключевая деталь: когда загружен vmci.sys, он владеет адаптером VMCI и активно использует те же порты ввода-вывода. Два драйвера не могут безопасно совместно использовать одно и то же оборудование — если оба попытаются отправлять команды одновременно, состояние устройства испортится и система упадёт. Поэтому эксплойт сначала отключает vmci.sys и только потом получает эксклюзивный доступ к оборудованию VMCI. Именно для этого в цепочке фигурирует devcon.exe disable.

Зачем эксплойту точная версия сборки ESXi

Разные сборки ESXi имеют разную раскладку памяти, поэтому эксплойту требуются смещения, специфичные для версии. смещения. Драйвер запрашивает версию хоста через документированную команду VMware Guest SDK guestlib.stat.get text session, которая возвращает строку вида «VMware ESX 8.0.0 build-24022510». Эксплойт разбирает ответ, чтобы извлечь версию и номер сборки.

Дальше он ищет в таблице предварительно вычисленные смещения для этой сборки. В эксплойт встроена жёстко заданная таблица из 155 поддерживаемых сборок ESXi от версий 5.1 до 8.0. Каждая запись хранит номер сборки и 17 специфичных для версии смещений, необходимых для поиска структур процесса VMX. Эти смещения меняются между сборками из-за модификаций кода и различий компилятора.

Если обнаруженная сборка отсутствует в таблице, эксплуатация не удаётся — типичное ограничение эксплойтов, основанных на смещениях. Кроме того, при утечке базового адреса VMX функция выбирает размер сообщения в зависимости от версии ESXi: для ESXi 5.x и 6.x — 50616 байт, для ESXi 7.0 и 8.0 — 50624 байта.

Регистрация VSOCK как Winsock-провайдера

После установки драйвера клиент регистрирует библиотеку VMware VSOCK как Winsock-провайдер с помощью API WSCInstallProvider64_32, что позволяет осуществлять обмен данными через сокеты поверх VMCI. Это нужно, чтобы клиент мог подключаться к бэкдору по VSOCK простым синтаксисом командной строки — client SERVER_CID:PORT. Поскольку CID 2 зарезервирован за гипервизором, подключение к бэкдору выполняется как client.exe 2:10000.

Протокол начинается с рукопожатия: клиент отправляет «test», затем «ok» и ждёт подтверждения «ok» от сервера. Дальше связь идёт сообщениями с префиксом длины, а крупные передачи разбиваются на блоки по 32 КБ, каждый из которых подтверждается «ok» перед отправкой следующего. Клиент повторяет набор команд бэкдора: get скачивает файлы с ESXi в виртуальную машину, post загружает файлы из ВМ на ESXi, а всё остальное передаётся как shell-команда для выполнения на гипервизоре.

Первый шаг эксплуатации: включение drag-and-drop

Критичная команда на этом этапе — tools.capability.hgfs_server toolbox-dnd 1. Она включает функцию передачи файлов drag-and-drop между хостом и гостем, которая является частью Host-Guest File System (HGFS) VMware и позволяет перетаскивать файлы из рабочего стола в окно виртуальной машины.

После этого эксплойт открывает шесть каналов backdoor-связи и закрывает два из них (каналы 2 и 4). Термин «backdoor» — это собственная терминология VMware для механизма связи гость-хост, работающего через доступ к I/O-порту 0x5658. На физической машине этот порт ни к чему не подключён, но внутри виртуальной машины гипервизор перехватывает доступ к нему и использует как командный канал.

Через канал отправляется большой буфер нулей (~50 КБ), а затем строка «OK ATR toolbox-dnd» для инициализации операции drag-and-drop HGFS. Далее эксплойт формирует и отправляет полезную нагрузку, вызывающую out-of-bounds read. Это соответствует CVE-2025-22226 — уязвимости раскрытия информации из-за out-of-bounds read в HGFS, позволяющей злоумышленнику с административными привилегиями в виртуальной машине утечь память из процесса vmx.

От чтения/записи памяти VMX к root на хосте

Доступ к памяти процесса VMX эксплойт получает через бэкдор-каналы: для записи формируется 95-байтовый заголовок с типом команды 2, размером данных и целевым адресом в памяти VMX, затем данные отправляются по второму каналу; для чтения заголовок содержит тип команды 3 и целевой адрес, и возвращается 8 байт данных. Эта возможность чтения/записи, по оценке, обеспечивается CVE-2025-22224 («out-of-bounds write»).

Порядок действий такой. Сначала эксплойт записывает в память VMX три полезные нагрузки: Stage 1 shellcode, Stage 2 shellcode и ELF-бэкдор VSOCKpuppet. Затем перезаписывает указатель на функцию внутри VMX: сначала сохраняет исходное значение указателя, затем заменяет его адресом шелл-кода, после чего отправляет сообщение VMCI на хост, чтобы VMX при обработке сообщения перешёл по испорченному указателю на шелл-код атакующего. Этот финальный этап соответствует CVE-2025-22225 («arbitrary write vulnerability», позволяющей «escaping the sandbox»).

Stage 1 shellcode выполняется внутри процесса VMX и через системные вызовы VMkernel извлекает базовые адреса, чтобы вычислить, куда писать в память ядра.

Stage 2 shellcode создаёт файл /var/run/a с правами 0777, записывает в него VSOCKpuppet, добавляет в /var/run/inetd.conf строку:

ftp stream tcp nowait root /var/run/a a ++group=host/vim/vimuser/terminal/ssh

Затем читает /var/run/inetd.pid, посылает inetd SIGHUP для перезагрузки конфигурации, после чего подключается к 127.0.0.1:21, чтобы активировать бэкдор, и восстанавливает исходное содержимое inetd.conf.

Как работает бэкдор на порту 21

Бэкдор перехватывает порт 21 (FTP): любое TCP-соединение к этому порту выполняет /var/run/a от имени root.

Активация конфигурации устроена так: шелл-код читает /var/run/inetd.pid, разбирает PID и посылает SIGHUP (сигнал 1) процессу inetd — стандартный Unix-сигнал перезагрузки конфигурации. После короткой паузы он локально подключается к 127.0.0.1:21, чтобы запустить бэкдор. Затем восстанавливает исходное содержимое /var/run/inetd.conf, удаляя вредоносную запись, — это затрудняет форензику, так как файл конфигурации выглядит нетронутым.

Артефакты на хосте и их связь с этапами цепочки

Атакующий оставляет несколько типов следов. Во-первых, модификация конфигурации inetd: запись перенаправляет порт 21 на исполнение /var/run/a от имени root, а затем исходное содержимое inetd.conf восстанавливается. Во-вторых, создаётся VSOCKpuppet — 64-битный ELF-исполняемый файл, обеспечивающий постоянный удалённый доступ через VSOCK; он привязывается к порту 10000 с context ID −1 (VMADDR_CID_ANY), позволяя любой виртуальной машине на хосте связываться с ним. В-третьих, на хосте появляются процессы с открытыми VMCI-сокетами. В-четвёртых, на клиентской стороне (в Windows VM) устанавливаются модифицированные драйверы VMware через InfDefaultInstall.exe с файлами vmci.inf и vsock.inf.

Соотнесение с этапами: модификация inetd и VSOCKpuppet — этап закрепления и удалённого доступа после побега; установка драйверов — этап подготовки канала связи; открытые VMCI-сокеты — индикатор компрометации на этапе эксплуатации.

Обнаружение VMCI-бэкдоров

Защитник может обнаружить процессы с открытыми VMCI-сокетами на хосте ESXi с помощью команды lsof -a, которая показывает записи с типом SOCKET_VMCI. Однако вывод отображает только идентификаторы процессов и общие описания вроде {no file name}, поэтому для идентификации фактического вредоносного бинарника нужно выгрузить память процесса для дальнейшего анализа. Mandiant опубликовал подробное руководство по обнаружению VMCI-бэкдоров и компрометации ESXi.

Меры защиты и против каких шагов они работают

Микросегментация с распределёнными межсетевыми экранами (VMware NSX или решения на базе Open vSwitch) фильтрует трафик между ВМ на уровне виртуальных портов по логическим тегам, а не по IP-адресам, и изолирует ВМ даже внутри одного хоста — это противодействует горизонтальному перемещению.

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

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

Мониторинг изменений критичных файлов гипервизора — появление новых исполняемых файлов, модификация системных компонентов, изменения в файлах конфигурации ВМ (например, .vmx) — выявляет установку бэкдора или внедрение руткита после успешного побега из виртуальной машины. Зеркалирование портов виртуальных коммутаторов передаёт копии внутреннего трафика на IDS/IPS или системы анализа и выявляет подозрительные взаимодействия между ВМ и признаки горизонтального перемещения.

Уязвимости и патчи

В VMSA-2023-0023 описаны две уязвимости vCenter Server. Затронуты VMware vCenter Server и VMware Cloud Foundation. CVE-2023-34056 — partial information disclosure с серьёзностью Moderate и максимальным CVSSv3 4.3; атакующий с неадминистративными привилегиями может получить доступ к неавторизованным данным. CVE-2023-34048 — out-of-bounds write в реализации протокола DCERPC с критической серьёзностью и максимальным CVSSv3 9.8; атакующий с сетевым доступом может вызвать out-of-bounds write, что потенциально ведёт к удалённому выполнению кода.

Отдельный инцидент — Vercel, подтвердившая уязвимость нулевого дня в KVM после заявления специалиста Паулоса Йибело о полном выходе из гостевой системы на хост с правами root; подтверждение поступило 4 октября. Йибело описал результат как переход «guest → host root» в распространённых гипервизорах, а находка была сделана в рамках Vercel Sandbox, где пользовательский код и ИИ-агенты запускаются внутри Firecracker microVM. За побег Vercel выплатила максимальную награду, детали дыры держит закрытыми, техническая цепочка пока не опубликована. Vercel обещала отдельный технический разбор, который должен раскрыть причину ошибки, затронутые конфигурации и исправление. Конкретные затронутые конфигурации не названы: неизвестно, какие версии Linux, KVM или Firecracker затронуты, нужны ли права администратора внутри гостевой системы и зависит ли атака от конкретного процессора.

Атрибуция и оговорки

На связь с китайскоязычным разработчиком указывают упрощённый китайский в путях разработки, уровень сложности и доступ к zero-day задолго до публичного раскрытия. В PDB-пути MyDriver.sys папка названа «全版本逃逸--交付», что переводится как «All version escape - delivery», а дата 19 февраля 2024 года предшествует публичному раскрытию VMware более чем на год, что подтверждает разработку как потенциального zero-day.

Huntress оговаривает, что сочетание китайских артефактов разработки с англоязычным README может говорить о намерении продать или распространить toolkit более широкой аудитории. Отдельная оговорка касается строки «XLab» в изменённых заголовках авторских прав vmci.inf и vsock.inf: значение этой строки неясно, и хотя XLab — название команды кибербезопасности в Qi An Xin, «XLab» является общим термином, и доказательств связи toolkit с этой организацией или любой другой конкретной структурой нет.

Чем изоляция ВМ отличается от контейнерной

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

Контейнеризация изолирует процессы на уровне ядра хостовой ОС: все контейнеры используют общее ядро, а изоляция строится на namespaces, cgroups и среде выполнения. Из-за этого поверхность атаки распределена между множеством компонентов, каждый из которых представляет собственную поверхность атаки. Побег из контейнера — это атака на ядро хоста через уязвимости среды выполнения, например runc, используемой Docker, Kubernetes и другими платформами; эксплуатация может позволить выйти за пределы контейнера и получить привилегии root на хосте.

Кейсы компрометации контейнерных сред

Первый кейс — CVE-2025-54410 в Docker Engine, позволяющая обойти изоляцию bridge-сетей. При перезагрузке firewalld Docker не может восстановить критические правила iptables, обеспечивающие сетевой разрыв между контейнерами, и контейнеры из разных bridge-сетей получают доступ к портам друг друга. Трафик при этом не покидает хост, поэтому традиционные периметровые средства защиты его не видят.

Второй кейс — атака на CI/CD-конвейер Aqua Security в марте 2026 года: злоумышленники загрузили вредоносные версии сканера Trivy в официальный репозиторий Docker Hub для кражи секретов CI/CD, облачных учётных данных и SSH-ключей. Через месяц аналогичная атака затронула Checkmarx; инфраструктура Docker Hub не была взломана — использовались украденные учётные данные легитимных издателей.

Уроки, переносимые на защиту гипервизоров: контроль изменений критичных файлов (например, .vmx) для обнаружения бэкдоров или руткитов после побега из ВМ, мониторинг аномалий в поведении учётных записей и сетевой активности. Для защиты от атак на цепочку поставок через небезопасные шаблоны рекомендуется отслеживать изменения в репозиториях эталонных образов, отклонения конфигурации новых ВМ от эталона и соединения с недоверенными внешними IP-адресами.

Что из этого следует на практике

Атака MAESTRO показывает, что побег из ВМ — это не одна уязвимость, а конвейер из нескольких шагов, каждый из которых опирается на предыдущий. Отключение vmci.sys через devcon.exe disable нужно, чтобы забрать у легитимного драйвера эксклюзивный доступ к оборудованию. Точная версия сборки ESXi нужна, чтобы выбрать из таблицы 155 сборок правильные 17 смещений — без совпадения эксплуатация просто не удаётся. Команда tools.capability.hgfs_server toolbox-dnd 1 открывает путь к HGFS, через который проходит out-of-bounds read. А запись в память VMX и перезапись указателя на функцию превращают утечку памяти в выполнение кода внутри процесса VMX.

Для защитника это означает, что обнаружение нужно строить на нескольких уровнях сразу. lsof -a покажет открытые VMCI-сокеты, но только с PID и без имени файла — для идентификации бинарника нужен дамп памяти процесса. Восстановленный inetd.conf выглядит нетронутым, поэтому контроль целостности конфигурации его не поймает — зато поймает появление новых исполняемых файлов вроде /var/run/a. А изменения в .vmx и модификация системных компонентов указывают на этап закрепления после побега.

Наконец, атрибуция в этом случае остаётся вероятностной: китайские артефакты разработки и дата в PDB-пути указывают на хорошо обеспеченного разработчика, но строка «XLab» в заголовках драйверов — общий термин, и доказательств связи с конкретной организацией нет.