- 27,543
- 46
- 8 Ноя 2022
Обнаружены следы использования 0Day в VMware ESXi за год до официального раскрытия.
Виртуальные машины часто воспринимают как надежные «контейнеры» для проверки риска, даже если внутри что-то пошло не так. Но в декабре 2025 года команда Huntress столкнулась с инцидентом, который напомнил неприятную вещь. Иногда атакующему достаточно вырваться из одной гостевой VM, чтобы добраться до самого гипервизора VMware ESXi и получить контроль над всем хостом.
По оценке Huntress Tactical Response, начальная точка входа почти наверняка была куда прозаичнее, чем последующие трюки с виртуализацией. Злоумышленники, судя по индикаторам и тактикам, попали в сеть через скомпрометированный SonicWall VPN . Дальше, уже имея привилегии администратора домена, они начали перемещаться по инфраструктуре через RDP, в том числе на резервный и основной контроллеры домена.
На резервном контроллере домена атакующие пытались сменить пароль учетной записи администратора на Password01$ с помощью Impacket, но попытку заблокировали средства защиты. Параллельно злоумышленники запускали обычные инструменты разведки сети, например Advanced Port Scanner и SoftPerfect Network Scanner, а затем использовали ShareFinder, чтобы собрать список общих сетевых ресурсов и выгрузить его в файл.
На основном контроллере домена они развернули набор эксплойтов для VMware ESXi и примерно через 20 минут изменили правила Windows Firewall так, чтобы отрезать машину от внешних сетей, сохранив связь с внутренними диапазонами. Подобные настройки часто встречаются в атаках, когда цель состоит в том, чтобы усложнить жертве обращение за помощью и одновременно не мешать злоумышленнику распространяться по сети. После этого, по данным Huntress, началась подготовка к выносу данных. Для упаковки использовали WinRAR и сетевые шары.
Самое интересное началось в момент запуска набора, который должен был «вывести» атакующего за пределы виртуальной машины. В схеме фигурирует отключение компонентов VMware VMCI через devcon.exe, а затем загрузка неподписанного драйвера с помощью KDU, известного инструмента класса BYOVD , когда для обхода Driver Signature Enforcement используется уязвимый, но легитимно подписанный драйвер. Оркестратор атаки, который в отчете получил имя MAESTRO, управляет цепочкой действий, следит за прогрессом и после успешного взлома даже включает обратно отключенные драйверы VMware, чтобы снаружи все выглядело более «нормально».
Huntress считает, что набор, вероятно, использует связку из трех уязвимостей, закрытых VMware в бюллетене VMSA-2025-0004 от 4 марта 2025 года. Речь про CVE-2025-22226 с утечкой данных из процесса vmx, CVE-2025-22224 , которая помогает повредить память и добиться исполнения кода, и CVE-2025-22225 , позволяющую выбраться из песочницы vmx на уровень ядра гипервизора. В отчете подчеркивают, что эксплойт ориентирован на огромный парк версий. Внутри обнаружили таблицу с поддержкой 155 сборок ESXi от 5.1 до 8.0, а это значит, что многие устаревшие инсталляции остаются под ударом в принципе без шансов на исправление.
После компрометации гипервизора атакующие, по описанию, устанавливали бэкдор под Linux, ведь ESXi основан на Linux-подобном ядре и может запускать ELF-бинарники. Для удаленного управления использовался VSOCK, это быстрый канал связи между виртуальными машинами и хостом, который не проходит через привычный сетевой стек. Из-за этого трафик такого бэкдора не видят межсетевые экраны и сетевые IDS, то есть стандартный мониторинг "по проводу" здесь может просто промолчать.
Huntress отдельно обращает внимание на практическую проблему защиты. Если атака уходит в VSOCK, ловить ее надо на самом ESXi, а не только на периметре. В качестве одного из вариантов проверки упоминается поиск необычных процессов и открытых VMCI-сокетов прямо на хосте, например через lsof -a.
В наборе нашлись следы разработки с упрощенными китайскими строками в путях, включая папку с названием на китайском языке. В PDB-путях также фигурируют даты сборки – 2 ноября 2023 года и 19 февраля 2024 года. Это заметно раньше публичного раскрытия уязвимостей VMware и наводит на мысль, что эксплойт мог существовать как потенциальный zero-day больше года, а сам разработчик был явно хорошо обеспечен ресурсами и, вероятно, работал в китайскоязычной среде.
По оценке Huntress, цепочка вполне могла закончиться шифровальщиком. Захват ESXi удобен для выведения из строя сразу множества виртуальных серверов, а это любимая цель вымогателей . Но в этом случае атаку остановили специалисты Huntress Tactical Response и SOC, не дав сценарию дойти до финала.
Вывод у истории одновременно простой и неприятный. Самые "космические" эксплойты нередко начинаются с приземленных вещей вроде взломанного <span class="vpn-highlight" title="Использование VPN может нарушать законодательство РФ">VPN</span>, а изоляция виртуальных машин не является абсолютной защитой. Поэтому патчи ESXi стоит ставить максимально быстро, старые версии выводить из эксплуатации, а мониторинг дополнять контролем того, что происходит непосредственно на гипервизорах, иначе часть активности может пройти мимо любых сетевых датчиков.
Виртуальные машины часто воспринимают как надежные «контейнеры» для проверки риска, даже если внутри что-то пошло не так. Но в декабре 2025 года команда Huntress столкнулась с инцидентом, который напомнил неприятную вещь. Иногда атакующему достаточно вырваться из одной гостевой VM, чтобы добраться до самого гипервизора VMware ESXi и получить контроль над всем хостом.
По оценке Huntress Tactical Response, начальная точка входа почти наверняка была куда прозаичнее, чем последующие трюки с виртуализацией. Злоумышленники, судя по индикаторам и тактикам, попали в сеть через скомпрометированный SonicWall VPN . Дальше, уже имея привилегии администратора домена, они начали перемещаться по инфраструктуре через RDP, в том числе на резервный и основной контроллеры домена.
На резервном контроллере домена атакующие пытались сменить пароль учетной записи администратора на Password01$ с помощью Impacket, но попытку заблокировали средства защиты. Параллельно злоумышленники запускали обычные инструменты разведки сети, например Advanced Port Scanner и SoftPerfect Network Scanner, а затем использовали ShareFinder, чтобы собрать список общих сетевых ресурсов и выгрузить его в файл.
На основном контроллере домена они развернули набор эксплойтов для VMware ESXi и примерно через 20 минут изменили правила Windows Firewall так, чтобы отрезать машину от внешних сетей, сохранив связь с внутренними диапазонами. Подобные настройки часто встречаются в атаках, когда цель состоит в том, чтобы усложнить жертве обращение за помощью и одновременно не мешать злоумышленнику распространяться по сети. После этого, по данным Huntress, началась подготовка к выносу данных. Для упаковки использовали WinRAR и сетевые шары.
Самое интересное началось в момент запуска набора, который должен был «вывести» атакующего за пределы виртуальной машины. В схеме фигурирует отключение компонентов VMware VMCI через devcon.exe, а затем загрузка неподписанного драйвера с помощью KDU, известного инструмента класса BYOVD , когда для обхода Driver Signature Enforcement используется уязвимый, но легитимно подписанный драйвер. Оркестратор атаки, который в отчете получил имя MAESTRO, управляет цепочкой действий, следит за прогрессом и после успешного взлома даже включает обратно отключенные драйверы VMware, чтобы снаружи все выглядело более «нормально».
Huntress считает, что набор, вероятно, использует связку из трех уязвимостей, закрытых VMware в бюллетене VMSA-2025-0004 от 4 марта 2025 года. Речь про CVE-2025-22226 с утечкой данных из процесса vmx, CVE-2025-22224 , которая помогает повредить память и добиться исполнения кода, и CVE-2025-22225 , позволяющую выбраться из песочницы vmx на уровень ядра гипервизора. В отчете подчеркивают, что эксплойт ориентирован на огромный парк версий. Внутри обнаружили таблицу с поддержкой 155 сборок ESXi от 5.1 до 8.0, а это значит, что многие устаревшие инсталляции остаются под ударом в принципе без шансов на исправление.
После компрометации гипервизора атакующие, по описанию, устанавливали бэкдор под Linux, ведь ESXi основан на Linux-подобном ядре и может запускать ELF-бинарники. Для удаленного управления использовался VSOCK, это быстрый канал связи между виртуальными машинами и хостом, который не проходит через привычный сетевой стек. Из-за этого трафик такого бэкдора не видят межсетевые экраны и сетевые IDS, то есть стандартный мониторинг "по проводу" здесь может просто промолчать.
Huntress отдельно обращает внимание на практическую проблему защиты. Если атака уходит в VSOCK, ловить ее надо на самом ESXi, а не только на периметре. В качестве одного из вариантов проверки упоминается поиск необычных процессов и открытых VMCI-сокетов прямо на хосте, например через lsof -a.
В наборе нашлись следы разработки с упрощенными китайскими строками в путях, включая папку с названием на китайском языке. В PDB-путях также фигурируют даты сборки – 2 ноября 2023 года и 19 февраля 2024 года. Это заметно раньше публичного раскрытия уязвимостей VMware и наводит на мысль, что эксплойт мог существовать как потенциальный zero-day больше года, а сам разработчик был явно хорошо обеспечен ресурсами и, вероятно, работал в китайскоязычной среде.
По оценке Huntress, цепочка вполне могла закончиться шифровальщиком. Захват ESXi удобен для выведения из строя сразу множества виртуальных серверов, а это любимая цель вымогателей . Но в этом случае атаку остановили специалисты Huntress Tactical Response и SOC, не дав сценарию дойти до финала.
Вывод у истории одновременно простой и неприятный. Самые "космические" эксплойты нередко начинаются с приземленных вещей вроде взломанного <span class="vpn-highlight" title="Использование VPN может нарушать законодательство РФ">VPN</span>, а изоляция виртуальных машин не является абсолютной защитой. Поэтому патчи ESXi стоит ставить максимально быстро, старые версии выводить из эксплуатации, а мониторинг дополнять контролем того, что происходит непосредственно на гипервизорах, иначе часть активности может пройти мимо любых сетевых датчиков.
- Источник новости
- www.securitylab.ru
