Что показала кампания против VMware vCenter с использованием CVE-2026-59310

CVE-2026-59310 перестала быть просто уязвимостью, которую нужно срочно закрыть патчем. Broadcom раскрыла информацию о критическом дефекте в Syslog Server VMware vCenter и выпустила исправления 29 июля 2026 года. Однако уже 3 августа исследователи зафиксировали первые признаки эксплуатации — всего через пять дней после публикации исправления. Кампания затронула 361 наблюдаемый IP-адрес в 47 странах, а для сохранения доступа злоумышленники использовали reverse SSH. Shadowserver рекомендует считать такие системы полностью скомпрометированными.

Что позволяет CVE-2026-59310

Broadcom и Национальная база данных уязвимостей США (NVD) описывают CVE-2026-59310 как уязвимость обхода каталогов в Syslog Server VMware vCenter. Атакующему, имеющему сетевой доступ к vCenter, не требуется аутентификация: эксплуатация дефекта может привести к выполнению произвольного кода в уязвимой системе. Оценка CVSS составляет 9,8 из 10 — это критический уровень опасности.

На практике ошибка способна превратить доступный из сети виртуальный управляющий сервер в точку входа для закрепления злоумышленника и дальнейшего проникновения в виртуальную инфраструктуру. В описаниях отдельных инцидентов говорится о выполнении кода с правами root, однако наиболее авторитетные формулировки Broadcom и NVD подтверждают прежде всего риск выполнения произвольного кода, не раскрывая полностью уровень привилегий во всех случаях компрометации.

Broadcom выпустила исправленные версии, но не предложила обходного решения. Официальный способ устранения уязвимости — установить обновления, перечисленные в бюллетене производителя.

Пять дней между патчем и атакой

Broadcom сообщила о CVE-2026-59310 и выпустила патчи 29 июля. По данным QUIRSO, активная эксплуатация началась 3 августа, после чего кампания быстро расширилась.

Для реагирования на инциденты этот промежуток имеет принципиальное значение. Если систему обновили уже после 3 августа, успешная установка патча не доказывает, что она чиста. Устранение уязвимости и проверка на компрометацию — разные задачи: сначала нужно закрыть дыру, а затем выяснить, не успел ли атакующий закрепиться в системе.

Масштаб кампании

Исследователи связали активность с 361 наблюдаемым IP-адресом в 47 странах. На Германию, США, Турцию, Иран и Францию, по имеющимся данным, пришлось более половины наблюдаемого набора.

При этом цифру важно трактовать осторожно. Один IP-адрес не обязательно соответствует одной организации, поэтому 361 адрес не означает 361 пострадавшую компанию или учреждение. Доступные данные все же указывают на широкую кампанию против доступных из интернета или иначе открытых по сети систем vCenter.

Почему говорят о китайском следе

QUIRSO оценила связь кампании с Китаем как вероятную с умеренной степенью уверенности. Среди приведенных признаков — артефакты на китайском языке, инструменты и повторно использованные общедоступные исследования, активность в рабочие часы, соответствующие часовому поясу UTC+08:00, а также набор жертв, из которого, судя по всему, исключен материковый Китай.

Эти признаки поддерживают региональную или лингвистическую гипотезу, но не позволяют назвать конкретную китайскую государственную группу или доказать, что операцией руководило государство. Атрибуция по вредоносным артефактам, времени активности и выбору целей может измениться по мере появления новых свидетельств. Наиболее корректное описание — «предположительно связанный с Китаем атакующий», а не подтвержденная государственная операция.

Как развивалась атака

Судя по опубликованным данным, CVE-2026-59310 использовалась для первоначального выполнения кода, после чего злоумышленники устанавливали несколько уровней закрепления и удаленного доступа:

1. Обход каталогов. Специально сформированные запросы к Syslog Server позволяли выйти за пределы предназначенного пути и записать содержимое под контролем атакующего.
2. Закрепление через cron. По данным исследователей, злоумышленники создавали некорректные записи cron, чтобы запускать последующие команды по расписанию.
3. Доставка бэкдора. С помощью curl или wget загружался бэкдор linuxFile, использующий WebSocket-соединение и XOR-обфускацию.
4. Reverse SSH. На системы устанавливались инструменты обратного SSH-соединения, создававшие исходящий канал связи с инфраструктурой атакующего. Shadowserver сообщил, что этот механизм закрепления присутствовал у всех жертв из его специального отчета.
5. Злоупотребление учетными данными. Следователи сообщили о несанкционированных учетных записях администраторов vCenter и ESXi, а также об использовании учетных данных VMware Directory Service.
6. Развертывание шифровальщика. По меньшей мере некоторые публикации связывают активность с вариантом шифровальщика на базе Babuk, который добавляет к файлам расширение .babyk.

Особенно тревожен именно reverse SSH. По оценке Shadowserver, системы, на которых был развернут этот механизм, следует считать полностью скомпрометированными. Удалить один бинарный файл или cron-задание недостаточно: необходимо заново выстроить доверие к устройству и сменить привилегированные учетные данные.

Шифровальщик мог скрывать следы атаки

Активность с расширением .babyk не обязательно была обычной кампанией вымогателей, главной целью которой являлись массовое шифрование данных и требование выкупа. Аналитики предположили, что выборочное шифрование журналов ESXi могло использоваться для нарушения расследования и сокрытия следов вторжения.

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

Репозиторий GitHub под видом средства очистки

В публикациях также упоминался репозиторий GitHub, где бинарные файлы reverse SSH выдавались за утилиту очистки временных файлов Linux. Такая маскировка может облегчить распространение инструмента и сделать его менее заметным при обычной административной проверке. Однако доступные данные не подтверждают, кто именно управлял репозиторием, поэтому сам факт его существования нельзя считать доказательством атрибуции.

Как отреагировал рынок

14 августа акции Broadcom подешевели примерно на 5–6% на фоне сообщений об эксплуатации уязвимости VMware. В одном из отчетов приводится снижение с 417,82 до 392,99 доллара за акцию в течение торговой сессии.

Однако приписывать все падение исключительно CVE-2026-59310 было бы неправильно. В тот же период инвесторы обсуждали и другие факторы, включая риски, связанные с долговой нагрузкой компании и ее ставкой на искусственный интеллект. Поэтому нельзя надежно связать с этой уязвимостью ни всю динамику котировок, ни конкретную сумму потерянной рыночной капитализации.

Доступных данных также недостаточно, чтобы утверждать о measurable-снижении выручки VMware из-за кампании. Более обоснованные краткосрочные последствия — расходы клиентов на устранение инцидентов, риск перебоев в работе и репутационное давление. Долгосрочное влияние на выручку потребовало бы дополнительных финансовых данных или раскрытия со стороны компании.

Что делать администраторам vCenter

Патч — необходимый первый шаг, но не финал расследования. Организациям следует:

1. Немедленно установить исправленные версии Broadcom на всех затронутых экземплярах vCenter, в первую очередь на доступных из интернета и широких внутренних сетей. Обходного решения производитель не указал.
2. Считать систему с признаками атаки скомпрометированной. К таким признакам относятся неожиданные изменения cron, артефакты reverse SSH, файл или процесс linuxFile, необъяснимые загрузки через curl или wget, неизвестные администраторы vCenter или ESXi и подозрительная активность VMware Directory Service.
3. Изолировать подозрительные устройства и, если это возможно с учетом работы инфраструктуры, сохранить образы дисков, журналы и данные из оперативной памяти до перестроения системы.
4. Сменить все привилегированные учетные данные, включая vCenter SSO, VMware Directory Service, ESXi и root, API-ключи, сервисные учетные записи и связанные административные доступы. Необходимо также завершить активные сессии и проверить федеративные связи.
5. Перестроить скомпрометированные системы, а не только «почистить» их. Удаление неизвестных учетных записей, cron-заданий, бинарных файлов, SSH-ключей и туннелей должно быть частью документированного процесса реагирования на инцидент.
6. Провести поиск по всей виртуальной инфраструктуре на предмет файлов .babyk, неожиданных исходящих SSH- и WebSocket-соединений, неизвестных учетных записей и признаков изменения журналов ESXi.
7. Восстановить доверенные данные и телеметрию из заведомо чистых неизменяемых резервных копий, если журналы или конфигурации были повреждены.
8. Сократить поверхность атаки в будущем: ограничить доступ к управлению vCenter выделенными сегментированными сетями администрирования и отслеживать исходящие соединения от vCenter и хостов ESXi.

Главный практический вывод прост: обновить нужно каждый уязвимый экземпляр vCenter, но успешная установка патча не равна чистой среде. Быстрая эксплуатация, постоянный reverse SSH и сообщения о злоупотреблении учетными данными означают, что доступные из сети устройства следует проверять как потенциально полностью скомпрометированные.