Skip to content
RiverCore
VMware vCenter CVE-2026-59310 під глобальною атакою APT-угруповання
VMware vCenter exploitCVE-2026-59310APT exploitationvCenter unauthenticated RCE global attackVMware hypervisor APT persistence reverse ssh

VMware vCenter CVE-2026-59310 під глобальною атакою APT-угруповання

14 сер 20266 хв. читанняAlex Drover

Кожен платформний лід, що керує віртуалізованою інфраструктурою, має один кошмарний сценарій: неавтентифікований RCE в площині управління гіпервізором. Цього місяця цей кошмар отримав номер CVE, і вже активно експлуатується в 47 країнах одним підозрюваним APT-угрупованням.

Коротко: VMware розкрила CVE-2026-59310 29 липня. До 3 серпня загрозливий актор вже перебував усередині реальних виробничих середовищ. До 4 серпня активність досягла піку. А атакуючий залишив persistence, що переживає патч, який ви збиралися розгорнути.

Що сталося

CVE-2026-59310 — критична вразливість обходу директорій у VMware vCenter з оцінкою CVSS 9.8. Як повідомляє Dark Reading, VMware (яка належить Broadcom) розкрила вразливість 29 липня, попередивши, що будь-який атакуючий з мережевим доступом до екземпляра vCenter може віддалено виконати довільний код у віртуальному середовищі цілі. Це найгірший клас вразливостей vCenter: неавтентифікований, віддалений і спрямований на площину управління всім флотом гіпервізорів.

П'ять днів по тому, 3 серпня, розпочалась експлуатація. Німецька компанія з реагування на інциденти QUIRSO виявила активність під час залучення клієнта та опублікувала свої висновки цього тижня. Їхня команда Threat Research приписує кампанію одному підозрюваному advanced persistent threat актору та відстежила удари по інфраструктурі в 47 різних країнах. США, Франція, Іран і Туреччина є найбільш ураженими. QUIRSO ідентифікувала 361 унікальну IP-адресу, що підключається до кампанії, хоча компанія зазначила, що деякі належать хмарним або хостинговим провайдерам, які спільно використовують інфраструктуру, тому кількість жертв не є відображенням один до одного.

Кампанія досягла піку 4 серпня і досі продовжується. «Ми все ще бачимо нових жертв, що підключаються до reverse_ssh-інфраструктури під контролем атакуючого, і атакуючі, схоже, не підозрюють, що ми її моніторимо», — розповів Dark Reading операційний директор і співзасновник QUIRSO Денис Шадковський. Він додав, що нові жертви продовжують з'являтися, просто повільнішим темпом, оскільки пул непропатченних систем зменшується. QUIRSO також зазначає можливість того, що актор знав про вразливість до публічного розкриття, хоча терміни чітко збігаються з patch-diffing після виходу повідомлення. Ви можете знайти запис у базі даних CVE, і ця вразливість має бути у каталозі CISA KEV, якщо її ще немає.

Технічна анатомія

Обхід директорій з переходом до RCE на площині управління не є екзотикою. Тут важливий другий етап. Загрозливий актор встановлює persistence після експлуатації через reverse_ssh — інструмент для тестування на проникнення з відкритим кодом, що створює вихідні канали управління з компрометованих систем. Вихідні. Ось у чому весь трюк.

Більшість розгортань vCenter, які я бачив у виробництві, заблоковані на вхідному трафіку. Управлінські VLAN, jump-хости, IP-списки дозволів на порту 443. Але вихідний трафік із самого vCenter-аплайєнсу? Зазвичай повністю відкритий для всього, що аплайєнс потребує для оновлень, телеметрії та NTP. reverse_ssh використовує цю асиметрію як зброю. Компрометований vCenter виходить на атакуючу інфраструктуру і тримає канал управління відкритим. Ваш брандмауер бачить встановлену вихідну сесію, а не вхідне вторгнення.

Ось що є особливо небезпечним з операційної точки зору: патч CVE-2026-59310 не виганяє атакуючого. Шадковський чітко заявив, що якщо reverse_ssh було встановлено до того, як ви пропатчили систему, «доступ атакуючого збережеться навіть після оновлення програмного забезпечення до виправленої версії». Тунель існує поза вразливим шляхом коду. Отримавши точку опори та вихідну досяжність, вразливість більше не потрібна.

Шадковський також спростовує припущення, що лише спеціалісти з VMware могли впоратися з цим за п'ять днів. «Кваліфіковані дослідники вразливостей та просунуті актори зазвичай виконують patch diffing після розкриття. Ми вважаємо розумним, що достатньо кваліфікований дослідник міг проаналізувати патч і розробити експлойт за п'ять днів між повідомленням і вторгненням, яке ми розслідували.» Переклад: як тільки Broadcom випустила виправлення, зворотний відлік почався. QUIRSO опублікувала YARA-правило для ідентифікації збірок reverse_ssh, що чітко відповідає технікам MITRE ATT&CK для інструментів віддаленого доступу та каналів командування і управління.

Моя думка: індустрія продовжує ставитися до «N-day» як до чогось, що означає тижні. П'ять днів — це новий N-day для всього з CVSS 9.8 і логотипом Broadcom.

Хто постраждає

vCenter — це головний скарб більшості корпоративних віртуалізованих середовищ. У виробничих інцидентах, які я бачив у фінтех- та iGaming-операторів, один компрометований vCenter — це не один сервер, це влада над кожною VM, кожним сховищем даних, кожною мережевою політикою, якою управляє vCenter. Метт Снайдер, провідний інженер та керівник із виявлення загроз і реагування в Aviatrix, висловився прямо: «Якщо зловмисник атакує vCenter, радіус ураження від одного неавтентифікованого RCE — це не один застосунок; це вся інфраструктура.»

Команди, що найбільше піддаються ризику зараз, — це ті, у кого найбільша проблема з вікнами технічного обслуговування. Регульовані галузі, iGaming-платформи в розпалі турнірів, платіжні процесори у піки навантаження, будь-яка організація, де переговори про простій займають тижні. Діагноз Снайдера щодо того, чому організації відстають із патчингом, є дискомфортно точним: «бо вікно технічного обслуговування — це розмова, яку ніхто не хоче мати». П'ять днів від розкриття до експлуатації фактично не дали жодній організації з цих категорій часу на проведення нормального процесу управління змінами.

Незручний висновок: якщо ваш vCenter був доступний з інтернету або досяжний з компрометованого jump-хосту 29 липня, а ви пропатчили, скажімо, 6 серпня — ви не обов'язково в безпеці. Ви потенційно пропатчені і скомпрометовані. Це зовсім інша вправа для tabletop. Форензик-тріаж самих аплайєнсів vCenter, а не просто підтвердження рядка версії, — єдиний спосіб дізнатися правду.

Географічна концентрація також має значення. Команди в США, Франції, Ірані та Туреччині є головними цілями за телеметрією QUIRSO. Якщо ваша інфраструктура знаходиться в одній із цих юрисдикцій і ви запускаєте vCenter з будь-якою зовнішньою досяжністю для управління, піднімайте це вище за рутинний тікет. Це ризик інциденту, видимий на рівні ради директорів, а не вівторковий патч.

Посібник для команд безпеки

Зробіть це цього тижня. Не цього спринту, цього тижня.

  • Негайно пропатчіть vCenter до виправленої версії. Якщо ви ще не застосували виправлення з повідомлення від 29 липня, це перший крок. Кожен день пул непропатченних систем зменшується, за даними QUIRSO, тобто ті, хто пізно патчиться, дедалі більше стають виключеннями.
  • Вважайте, що пропатчено не означає чисто. Запустіть опубліковане QUIRSO YARA-правило для збірок reverse_ssh проти ваших аплайєнсів vCenter і будь-яких хостів, суміжних із ними. Зробіть це до закриття тікету зміни.
  • Заблокуйте вихідний трафік із vCenter. Думка Снайдера: «Це операційне відставання — причина того, чому стратегії захисту повинні зосереджуватися на мережевому стримуванні як первинній лінії оборони». Аплайєнси vCenter не повинні мати загального вихідного доступу до інтернету. Дозвольте лише точні кінцеві точки для оновлень і телеметрії, яких вимагає Broadcom, і блокуйте все інше.
  • Шукайте вихідний SSH-подібний трафік із інтерфейсів управління vCenter та ESXi до незнайомих адресатів. Весь дизайн reverse_ssh — виглядати як нормальна вихідна сесія, тому звертайте увагу на репутацію адресата і тривалість з'єднання, а не лише на протокол.
  • Змініть облікові дані, що стосувалися аплайєнсу. Якщо persistence було встановлено, будь-які секрети, що зберігалися, кешувалися або вводилися у vCenter протягом вікна експлуатації, слід вважати скомпрометованими.
  • Домовтесь про форензик-розмову зараз. Як сказав Шадковський: «По суті, це гонка між експлуатацією та патчингом. Тому ми рекомендуємо форензик-розслідування потенційно постраждалих систем, щоб виключити наявний компроміс.» Якщо ви не можете зробити це внутрішньо, залучіть IR-ретейнер до того, як ваш бюджет на реагування на інциденти стане екстреним замовленням на закупівлю.

Висновок: патч, стримування вихідного трафіку, пошук persistence, зміна секретів. У такому порядку. Все, що менше — це оптимізм, замаскований під стратегію.

Ключові висновки

  • CVE-2026-59310 — це обхід директорій із CVSS 9.8 у VMware vCenter, розкритий 29 липня та активно експлуатований із 3 серпня, тобто п'ять днів по тому.
  • Одне підозрюване APT-угруповання проводить кампанію в 47 країнах, зафіксовано 361 унікальну IP-адресу, а США, Франція, Іран і Туреччина є головними цілями.
  • Persistence через reverse_ssh означає, що патч не виганяє атакуючого. Форензик-перевірка аплайєнсів vCenter є обов'язковою, а не опціональною.
  • П'ять днів від розкриття до експлуатації — це нова базова лінія для вразливостей із високим CVSS у повсюдному корпоративному програмному забезпеченні. Вікна управління змінами, що вимірюються тижнями, більше не є захистом.
  • Обмеження вихідного трафіку на аплайєнсах площини управління — це той контроль стримування, який міг би послабити цю кампанію. Якщо ваш vCenter може досягти відкритого інтернету, виправте це цього кварталу.

Часті запитання

Q: Що таке CVE-2026-59310 і чому вона така небезпечна?

Це критична вразливість обходу директорій у VMware vCenter з оцінкою CVSS 9.8, розкрита Broadcom 29 липня 2026 року. Атакуючий з мережевим доступом до екземпляра vCenter може віддалено виконати довільний код, фактично отримавши контроль над площиною управління всім віртуалізованим середовищем.

Q: Чи повністю усуває загрозу патч CVE-2026-59310?

Ні. За даними QUIRSO, загрозливий актор встановлює persistence за допомогою reverse_ssh, що створює вихідний канал управління, який переживає оновлення vCenter до виправленої версії. Організації потребують форензик-розслідування потенційно постраждалих систем, а не лише оновлення версії.

Q: Як захисники можуть виявити persistence через reverse_ssh, що використовується в цій кампанії?

QUIRSO опублікувала YARA-правило для ідентифікації збірок reverse_ssh та закликала організації перевіряти екземпляри vCenter на ознаки компрометації. Захисники також повинні шукати несподівані вихідні сесії від vCenter і суміжних аплайєнсів управління до незнайомих адресатів та обмежити вихідний трафік із площини управління.

AD
Alex Drover
RiverCore Analyst · Dublin, Ireland
ПОДІЛИТИСЯ
// СХОЖІ СТАТТІ
ГоловнаРішенняПроєктиПро насКонтакт
Новини06
Дублін, Ірландія · ЄСGMT+1
LinkedIn
🇺🇦UK