«Пароль01» и дырявый VPN. Как пустить хакеров в сеть, чтобы они сломали вообще всё (пошаговая инструкция)

Виртуальные машины часто воспринимают как надежные «контейнеры» для проверки риска, даже если внутри что-то пошло не так. Но в декабре 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, не дав сценарию дойти до финала.

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