Через свежую брешь в системах виртуализации атакованы серверы в 47 странах
Фото: Scott Rodgerson / Unsplash
Атака строится на уязвимости обхода каталога в vCenter Server — центральном компоненте управления виртуальной инфраструктурой VMware. Брешь получила идентификатор CVE-2026-59310 и 9,8 балла из 10 по шкале CVSS: она позволяет выполнить произвольный код на сервере. Broadcom выпустил исправление 29 июля 2026 года, однако первые попытки эксплуатации были зафиксированы всего через пять календарных дней после публикации сведений об ошибке.
О кампании рассказали специалисты немецкой компании по реагированию на инциденты QUIRSO. По их версии, со средней степенью уверенности за атаками стоит китаеязычная группировка, предположительно работающая в часовом поясе UTC+08:00. Основанием для такого вывода назвали китайскоязычные артефакты в скриптах злоумышленников, заимствования из публикации китайского профильного издания, регулярное использование китайского инструментария и картину жертв, в которой отсутствует материковый Китай.
По подсчётам исследователей, скомпрометирован 361 уникальный IP-адрес в 47 странах. Больше всего заражений пришлось на Германию (55), США (41), Турцию (38), Иран (26) и Францию (25).
Цепочка захвата сервера
Первым признаком компрометации становится некорректный файл задания в системном планировщике cron с именем zz-poc59310-syslog.log. Как утверждают в QUIRSO, атакующие злоупотребили механизмом удалённого журналирования виртуального модуля vCenter, чтобы записать файл в привилегированный каталог /etc/cron.d. Дальше выполняется команда curl или wget, которая загружает бэкдор с узла 5.34.177[.]38:9861 и запускает его, после чего исходный файл удаляется.
Бэкдор, встречающийся под именами linuxFile, systemlog и linux_x86, закрепляется в системе через службу systemd и связывается с управляющим сервером по протоколу WebSocket. Затем через тот же планировщик загружается сценарий esxi.sh с адреса 185.144.28[.]120:3232, который устанавливает клиент обратного SSH-подключения под конкретную архитектуру процессора. В одном из эпизодов операторы допустили промах: каталог с их инструментарием оказался открыт для свободного просмотра через файловый веб-интерфейс.
Отдельные задания маскировались под штатные службы платформы — vmware-vpxd-stats, vmware-perf-collect и vmware-perf-sync. Через них в систему добавлялся SSH-ключ атакующих, размещался веб-шелл на JSP и создавались учётные записи adminuser и vcadmin с правами администратора vSphere. Для закрепления привилегий создавался файл /etc/sudoers.d/vmware-perf, дающий сервисной учётной записи perfcharts беспарольный доступ к root, а сценарий /tmp/.vmware-perf-upd.sh извлекал учётные данные службы каталогов vmdir.
На том же сервере эксперты обнаружили следы эксплуатации второй уязвимости — CVE-2026-59309, позволяющей обойти аутентификацию. С её помощью 1 августа была создана учётная запись vcenter_admin, а спустя двое суток злоумышленники изучали инфраструктуру через REST API, маскируя запросы под легитимный трафик системы централизованного управления VCF Fleet.
Эксплуатация CVE-2026-59310 дала атакующим немедленное выполнение кода в контексте root на сервере vCenter. Все последующие команды выполнялись уже с максимальными правами — без необходимости сначала захватывать непривилегированную учётную запись и повышать привилегии.
Майке Орликовски, исследователь компании QUIRSO
Финал — шифрование виртуальных машин
Получив контроль над сервером управления, атакующие создавали локальные учётные записи на хостах гипервизора ESXi. Итогом становился запуск шифровальщика, присваивающего файлам расширение .babyk — оно характерно для вредоносов, собранных на основе утёкшего исходного кода Babuk. Исследователи не берутся утверждать, что шифрование было конечной целью кампании: по их словам, знакомый рынку шифровальщик мог быть выбран как случайно, так и намеренно, чтобы запутать расследование.
Что делать защитникам
Базовая мера — установить июльские обновления Broadcom для vCenter, закрывающие обе бреши. Для организаций, у которых нет штатного доступа к обновлениям вендора, на первый план выходят компенсирующие меры: жёсткое ограничение сетевого доступа к интерфейсу управления, вынос его в отдельный сегмент и запрет публикации в интернет.
Дальше — проверка на признаки компрометации. Стоит просмотреть содержимое каталогов /etc/cron.d и /etc/sudoers.d, список юнитов systemd и файл authorized_keys; поискать в vSphere SSO неизвестные учётные записи, в том числе adminuser, vcadmin и vcenter_admin; проверить исходящие соединения на нетипичные порты. Отдельного внимания требуют хосты ESXi: включённый режим блокировки, контроль локальных учётных записей и резервные копии, хранящиеся офлайн, остаются главным барьером между инцидентом и остановкой всей виртуальной инфраструктуры.
