Уязвимость CVE-2026-59310 в VMware vCenter Server получила оценку 9,8 по CVSS: обход каталогов позволял удалённо выполнить произвольный код внутри vCenter Server Appliance (VCSA). Broadcom выпустила исправление 29 июля 2026 года, но примерно 3 августа, через пять календарных дней после раскрытия проблемы, началась эксплуатация. Злоумышленнику не требовались учётная запись с низкими привилегиями и последующее повышение прав: команды, зафиксированные CROND, сразу исполнялись от root. По оценке немецкой компании реагирования на инциденты QUIRSO, были скомпрометированы 361 уникальный IP-адрес в 47 странах: 55 в Германии, 41 в США, 38 в Турции, 26 в Иране и 25 во Франции.
Исследователи QUIRSO Maike Orlikowski, Çağatay Yürekli и Denis Szadkowski со средней уверенностью связали операцию с китаеязычным участником, предположительно работающим в часовом поясе UTC+08:00. На это указывали китайские фрагменты в созданных атакующим сценариях, возможное заимствование материалов из китайской публикации по безопасности, китайскоязычные инструменты и программы управления, рабочий ритм операций и отсутствие жертв в материковом Китае. Назвать конкретную APT-группу исследователи не смогли, поэтому речь идёт об аналитической атрибуции, а не о доказанном происхождении оператора.
На одном изученном VCSA обнаружилась ещё одна линия атаки, связанная с CVE-2026-59309, уязвимостью обхода аутентификации, которую к тому времени уже активно сканировали. С адреса 146.59.252[.]178 был создан администратор vcenter_admin, хотя входа под законной учётной записью, якобы выполнившей это действие, журналы не содержали. 3 августа тот же источник проводил разведку через vSphere REST API с User-Agent GoodMoodle-VCFleet/1.0. Название маскировалось под VCF Fleet, средство централизованного управления, появившееся в VMware Cloud Foundation 9.0 и охватывающее VCF Operations, VCF Automation, vCenter, NSX Manager, vSphere Cluster и workload domains. Учётная запись vcenter_admin позже не использовалась, а пересечений с цепочкой CVE-2026-59310 QUIRSO не нашла. Не исключено, что сервер независимо заинтересовал разных операторов.
Первым заметным следом эксплуатации CVE-2026-59310 стал ошибочно сформированный cron-файл zz-poc59310-syslog.log в /etc/cron.d. Число 59310 отсылало к идентификатору уязвимости, poc — к proof of concept, а окончание -syslog.log имитировало принятую в vCSA схему имён удалённого syslog. Вероятнее всего, механизм syslog заставляли помещать файлы прямо в привилегированный каталог cron. Часть заданий оказалась синтаксически неверной, но хотя бы одно сработало: через curl либо wget с 5.34.177[.]38:9861 загрузился имплант linuxFile, после запуска связанный журнал удалили. Бэкдор принимал команды по WebSocket, передавал их в /bin/sh, возвращал результат и восстанавливал соединение после обрыва; закрепление выполнялось через systemd и cron. По словам Denis Szadkowski, адрес управляющего сервера был скрыт XOR, расшифровывался во время работы, а данные защищались собственной криптографией прикладного уровня даже поверх незашифрованного ws://.
Через cron атакующий скачал с 185.144.28[.]120:3232 сценарий . Он подбирал архитектурно подходящую сборку reverse_ssh, устанавливал её и создавал постоянный обратный SSH-канал. Другие задания готовили каталоги, загружали программы, меняли разрешения и запускали файлы с инфраструктуры 192.255.141[.]13:8080 и 5.34.176[.]100:5244. Последний сервер по оплошности оставил набор reverse_ssh доступным через открытый листинг AList. В материалах также фигурирует WebSocket-адрес :8080/ws и закрепление посредством службы systemd, однако фрагмент с названием подключавшегося компонента отсутствует, поэтому приписывать endpoint определённому файлу нельзя.
Три серии cron-заданий выглядели как штатные службы VMware. vmware-vpxd-stats- организовывала SSH-доступ и добавляла открытый ключ атакующего в authorized_keys. vmware-perf-collect- размещала JSP-веб-шелл vmware-perf-update.jsp. vmware-perf-sync- устанавливала тот же веб-шелл, исполняла Base64-сценарий, добиралась до учётных данных и создавала adminuser в группе vSphere SSO Administrators. Локальные аккаунты adminuser затем появились на ESXi и помогли запустить шифрование. Отдельная Base64-кодированная программа на Python, записанная bash-командами и вызванная из cron, добавила во vSphere пользователя vcadmin. Ещё один администратор возник через внешний LDAP-запрос Add к VMware Directory Service (vmdir) с удалённого клиента: для этого уже была захвачена существующая административная учётная запись.
Для служебного пользователя perfcharts атакующие создали файл /etc/sudoers.d/vmware-perf, разрешив ему без пароля и интерактивного подтверждения выполнять любые команды от root. Сценарий /tmp/.vmware-perf-upd.sh пытался извлечь секреты vmdir из HKEY_THIS_MACHINE\services\vmdir. Если обращение к реестру не удавалось, он искал Python-модуль vmafd и вызывал GetMachineName(), GetMachinePassword() и GetDomainName(). Так оператор получал distinguished name машинной учётной записи vCenter и её пароль, после чего мог менять каталог с высокими привилегиями, в частности включить adminuser в Administrators. Для разведки применялся vSphere API, а для перехода на ESXi — , reverse_ssh и локальные аккаунты.
На ESXi в итоге запустили шифровальщик, добавлявший к файлам расширение .babyk, характерное для производных Babuk. QUIRSO подробно исследовала только одну заражённую систему и не установила, появился ли locker на остальных 360 адресах. Неясно и то, был ли он конечной целью, случайно выбранным инструментом или способом сбить атрибуцию. Denis Szadkowski сравнил шифрование с дымовой завесой: уничтожение журналов ESXi лишает защитников телеметрии и мешает восстановить ход более продолжительной операции, связанной с доступом, закреплением либо разведкой. Поэтому громкий эпизод с Babuk мог прикрывать действия, ради которых сервер взломали изначально.
14 августа 2026 года появилась связанная с инфраструктурой учётная запись GitHub с репозиторием, описанным как «Автоматический демон очистки /tmp для Linux (Go)». Его обнаружили после того, как оператор настраивал репозиторий командой link внутри уже отслеживаемой сети reverse_ssh. QUIRSO изучила релизы и независимо подтвердила: опубликованные бинарные файлы были сборками reverse_ssh, связанными с атакующим. Находившаяся там служба systemd каждый час сканировала /tmp и удаляла файлы, символические ссылки, сокеты и прочие объекты, если с момента изменения прошло не менее 24 часов. Именно в /tmp размещалась большая часть найденных вредоносных артефактов. Релиз tmpclean v3.0.0 содержал обновлённые reverse_ssh-бинарники, то есть репозиторий мог одновременно служить уборщиком следов и площадкой доставки новых сборок. Почему всё это разместили публично, неизвестно; одна из версий — оператор следил за публикациями и поспешно добавлял очистку после раскрытия кампании.
Набор проверяемых индикаторов включает 146.59.252[.]178, 5.34.177[.]38:9861, 185.144.28[.]120:3232, 192.255.141[.]13:8080, 5.34.176[.]100:5244 и :8080/ws; файлы zz-poc59310-syslog.log, linuxFile, , reverse_ssh и vmware-perf-update.jsp; пути /etc/cron.d, /etc/sudoers.d/vmware-perf, /tmp/.vmware-perf-upd.sh и /tmp; задания vmware-vpxd-stats-, vmware-perf-collect- и vmware-perf-sync-; аккаунты vcenter_admin, adminuser, vcadmin и perfcharts. Защитникам также стоит искать GoodMoodle-VCFleet/1.0, обращения к HKEY_THIS_MACHINE\services\vmdir, вызовы GetMachineName(), GetMachinePassword(), GetDomainName(), LDAP Add к vmdir, неожиданные SSH-ключи, службы systemd и файлы с расширением.babyk. Материал The Hacker News после публикации был дополнен сведениями QUIRSO; при этом открытыми остались происхождение двух цепочек CVE, масштаб установки Babuk, причина появления GitHub-репозитория и реальная задача всей операции.
Изображение носит иллюстративный характер
Исследователи QUIRSO Maike Orlikowski, Çağatay Yürekli и Denis Szadkowski со средней уверенностью связали операцию с китаеязычным участником, предположительно работающим в часовом поясе UTC+08:00. На это указывали китайские фрагменты в созданных атакующим сценариях, возможное заимствование материалов из китайской публикации по безопасности, китайскоязычные инструменты и программы управления, рабочий ритм операций и отсутствие жертв в материковом Китае. Назвать конкретную APT-группу исследователи не смогли, поэтому речь идёт об аналитической атрибуции, а не о доказанном происхождении оператора.
На одном изученном VCSA обнаружилась ещё одна линия атаки, связанная с CVE-2026-59309, уязвимостью обхода аутентификации, которую к тому времени уже активно сканировали. С адреса 146.59.252[.]178 был создан администратор vcenter_admin, хотя входа под законной учётной записью, якобы выполнившей это действие, журналы не содержали. 3 августа тот же источник проводил разведку через vSphere REST API с User-Agent GoodMoodle-VCFleet/1.0. Название маскировалось под VCF Fleet, средство централизованного управления, появившееся в VMware Cloud Foundation 9.0 и охватывающее VCF Operations, VCF Automation, vCenter, NSX Manager, vSphere Cluster и workload domains. Учётная запись vcenter_admin позже не использовалась, а пересечений с цепочкой CVE-2026-59310 QUIRSO не нашла. Не исключено, что сервер независимо заинтересовал разных операторов.
Первым заметным следом эксплуатации CVE-2026-59310 стал ошибочно сформированный cron-файл zz-poc59310-syslog.log в /etc/cron.d. Число 59310 отсылало к идентификатору уязвимости, poc — к proof of concept, а окончание -syslog.log имитировало принятую в vCSA схему имён удалённого syslog. Вероятнее всего, механизм syslog заставляли помещать файлы прямо в привилегированный каталог cron. Часть заданий оказалась синтаксически неверной, но хотя бы одно сработало: через curl либо wget с 5.34.177[.]38:9861 загрузился имплант linuxFile, после запуска связанный журнал удалили. Бэкдор принимал команды по WebSocket, передавал их в /bin/sh, возвращал результат и восстанавливал соединение после обрыва; закрепление выполнялось через systemd и cron. По словам Denis Szadkowski, адрес управляющего сервера был скрыт XOR, расшифровывался во время работы, а данные защищались собственной криптографией прикладного уровня даже поверх незашифрованного ws://.
Через cron атакующий скачал с 185.144.28[.]120:3232 сценарий . Он подбирал архитектурно подходящую сборку reverse_ssh, устанавливал её и создавал постоянный обратный SSH-канал. Другие задания готовили каталоги, загружали программы, меняли разрешения и запускали файлы с инфраструктуры 192.255.141[.]13:8080 и 5.34.176[.]100:5244. Последний сервер по оплошности оставил набор reverse_ssh доступным через открытый листинг AList. В материалах также фигурирует WebSocket-адрес :8080/ws и закрепление посредством службы systemd, однако фрагмент с названием подключавшегося компонента отсутствует, поэтому приписывать endpoint определённому файлу нельзя.
Три серии cron-заданий выглядели как штатные службы VMware. vmware-vpxd-stats- организовывала SSH-доступ и добавляла открытый ключ атакующего в authorized_keys. vmware-perf-collect- размещала JSP-веб-шелл vmware-perf-update.jsp. vmware-perf-sync- устанавливала тот же веб-шелл, исполняла Base64-сценарий, добиралась до учётных данных и создавала adminuser в группе vSphere SSO Administrators. Локальные аккаунты adminuser затем появились на ESXi и помогли запустить шифрование. Отдельная Base64-кодированная программа на Python, записанная bash-командами и вызванная из cron, добавила во vSphere пользователя vcadmin. Ещё один администратор возник через внешний LDAP-запрос Add к VMware Directory Service (vmdir) с удалённого клиента: для этого уже была захвачена существующая административная учётная запись.
Для служебного пользователя perfcharts атакующие создали файл /etc/sudoers.d/vmware-perf, разрешив ему без пароля и интерактивного подтверждения выполнять любые команды от root. Сценарий /tmp/.vmware-perf-upd.sh пытался извлечь секреты vmdir из HKEY_THIS_MACHINE\services\vmdir. Если обращение к реестру не удавалось, он искал Python-модуль vmafd и вызывал GetMachineName(), GetMachinePassword() и GetDomainName(). Так оператор получал distinguished name машинной учётной записи vCenter и её пароль, после чего мог менять каталог с высокими привилегиями, в частности включить adminuser в Administrators. Для разведки применялся vSphere API, а для перехода на ESXi — , reverse_ssh и локальные аккаунты.
На ESXi в итоге запустили шифровальщик, добавлявший к файлам расширение .babyk, характерное для производных Babuk. QUIRSO подробно исследовала только одну заражённую систему и не установила, появился ли locker на остальных 360 адресах. Неясно и то, был ли он конечной целью, случайно выбранным инструментом или способом сбить атрибуцию. Denis Szadkowski сравнил шифрование с дымовой завесой: уничтожение журналов ESXi лишает защитников телеметрии и мешает восстановить ход более продолжительной операции, связанной с доступом, закреплением либо разведкой. Поэтому громкий эпизод с Babuk мог прикрывать действия, ради которых сервер взломали изначально.
14 августа 2026 года появилась связанная с инфраструктурой учётная запись GitHub с репозиторием, описанным как «Автоматический демон очистки /tmp для Linux (Go)». Его обнаружили после того, как оператор настраивал репозиторий командой link внутри уже отслеживаемой сети reverse_ssh. QUIRSO изучила релизы и независимо подтвердила: опубликованные бинарные файлы были сборками reverse_ssh, связанными с атакующим. Находившаяся там служба systemd каждый час сканировала /tmp и удаляла файлы, символические ссылки, сокеты и прочие объекты, если с момента изменения прошло не менее 24 часов. Именно в /tmp размещалась большая часть найденных вредоносных артефактов. Релиз tmpclean v3.0.0 содержал обновлённые reverse_ssh-бинарники, то есть репозиторий мог одновременно служить уборщиком следов и площадкой доставки новых сборок. Почему всё это разместили публично, неизвестно; одна из версий — оператор следил за публикациями и поспешно добавлял очистку после раскрытия кампании.
Набор проверяемых индикаторов включает 146.59.252[.]178, 5.34.177[.]38:9861, 185.144.28[.]120:3232, 192.255.141[.]13:8080, 5.34.176[.]100:5244 и :8080/ws; файлы zz-poc59310-syslog.log, linuxFile, , reverse_ssh и vmware-perf-update.jsp; пути /etc/cron.d, /etc/sudoers.d/vmware-perf, /tmp/.vmware-perf-upd.sh и /tmp; задания vmware-vpxd-stats-, vmware-perf-collect- и vmware-perf-sync-; аккаунты vcenter_admin, adminuser, vcadmin и perfcharts. Защитникам также стоит искать GoodMoodle-VCFleet/1.0, обращения к HKEY_THIS_MACHINE\services\vmdir, вызовы GetMachineName(), GetMachinePassword(), GetDomainName(), LDAP Add к vmdir, неожиданные SSH-ключи, службы systemd и файлы с расширением.babyk. Материал The Hacker News после публикации был дополнен сведениями QUIRSO; при этом открытыми остались происхождение двух цепочек CVE, масштаб установки Babuk, причина появления GitHub-репозитория и реальная задача всей операции.
