CVE-2026-59310: що показала атака на VMware vCenter

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. Розгортання ransomware. Щонайменше частина повідомлень пов’язує активність із варіантом ransomware на основі Babuk, який додає до файлів розширення .babyk.

Особливу увагу варто звернути на reverse SSH. Висновок Shadowserver однозначний із практичної точки зору: системи, де виявлено цей механізм, слід вважати повністю скомпрометованими. Видалити один файл або cron-завдання недостатньо — потрібно відновити довіру до системи та змінити привілейовані облікові дані.

Чи був ransomware інструментом приховування слідів

Повідомлення про активність із розширенням .babyk не обов’язково описують звичайну ransomware-кампанію, головною метою якої є масове шифрування даних і вимагання грошей. Аналітики припустили, що вибіркове шифрування журналів ESXi могло бути спрямоване на перешкоджання розслідуванню та приховування доказів.

Це залишається висновком аналітиків, а не підтвердженою заявою нападників. Захисникам варто перевіряти обидва сценарії: вплив ransomware на віртуальні машини та навмисне пошкодження журналів для приховування проникнення.

GitHub-репозиторій і маскування інструментів

У повідомленнях також згадується GitHub-репозиторій, де бінарні файли reverse SSH подавалися як утиліта для очищення тимчасових файлів Linux. Маскування інструмента закріплення під адміністративну або «очисну» програму може спростити його поширення та зробити менш помітним під час звичайної перевірки. Водночас доступні докази не дають змоги незалежно встановити, хто керував цим репозиторієм, тому його існування не можна вважати доказом атрибуції.

Що це означає для Broadcom

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

Звіти про кібербезпеку були одним із факторів падіння, але не обов’язково єдиним. У тогочасних матеріалах також згадувалися ширші побоювання інвесторів, зокрема ризики, пов’язані з борговим навантаженням у сфері штучного інтелекту. Тому некоректно приписувати саме CVE-2026-59310 весь рух котирувань або конкретну суму втраченої ринкової вартості.

Наявних даних недостатньо, щоб стверджувати про вимірюване падіння доходів VMware через цю кампанію. Найбільш обґрунтовані короткострокові наслідки — витрати клієнтів на реагування, ризик операційних перебоїв і репутаційний тиск. Для висновків про довгостроковий вплив на виручку потрібні розкриття самої компанії або додаткові фінансові докази.

Що робити адміністраторам vCenter

Патч — це лише перший крок, а не фінальна крапка. Організаціям варто:

1. Негайно встановити виправлені версії Broadcom на всі вразливі екземпляри vCenter, насамперед на доступні з інтернету системи та пристрої, до яких мають доступ широкі внутрішні мережі. Broadcom не вказує обхідного рішення.
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 і повідомлень про зловживання обліковими даними означає, що відкриті пристрої потрібно перевіряти як потенційно повністю скомпрометовані.