FirstVDS повідомив, що 17 жовтня зловмисники скопіювали файли з дисків клієнтських віртуальних серверів, не запускаючи програму-викрадач усередині цих серверів. Сайт міг працювати, поки з нього забирали паролі, приватні ключі та інші дані. У повідомленні від 18 жовтня хостинг-провайдер закликав сповіщених клієнтів вважати дані скопійованими й терміново замінити секрети, що зберігалися на сервері.
Вирішальне значення має місце доступу: частина інфраструктури віртуалізації провайдера, куди нападники потрапили через вразливість VMmanager 6. Це не просто шкідливий процес, який клієнт міг знайти та завершити у власній операційній системі. Якщо ви отримали сповіщення, перевірте перелік серверів в особистому кабінеті FirstVDS і почніть відкликати розкриті облікові дані з надійного пристрою.
Програма читала диски ззовні гостьової ОС
За поясненням FirstVDS, зловмисники розмістили програму для викрадення даних на частині інфраструктурних серверів. Вона підключала диски клієнтських віртуальних машин у режимі лише читання, переглядала їхній вміст і надсилала зібране на сервер нападників. Провайдер називає паролі, SSH- та API-ключі, доступи до хмарних сервісів, токени, конфігураційні файли, історію команд, криптогаманці й користувацькі файли серед скопійованих даних.
Режим лише читання — ключова деталь. Він описує спосіб доступу до диска, а не безпечність такого доступу. Програма могла забирати інформацію, нічого не змінюючи у файлах клієнта. FirstVDS стверджує, що вона не виконувалася всередині постраждалих віртуальних машин: тому гостьовий сервер міг виглядати звично й не мати слідів саме цієї активності на хості.
Операційна система віртуальної машини керує процесами всередині неї. Хост провайдера керує сховищем, на якому лежать її диски. У цьому випадку описаний шлях до файлів проходив через зовнішній рівень. Самого списку процесів або перевірки доступності сайту недостатньо, щоб встановити, чи залишилися секрети приватними.
Атака охопила частину вузлів віртуалізації, а не всю інфраструктуру FirstVDS. Провайдер повідомляє, що надіслав клієнтам листи та сповіщення в кабінет із переліком серверів. О 15:25 за московським часом 18 жовтня він доповнив повідомлення: додаткові сповіщення отримали власники серверів на вузлах з ознаками можливої компрометації. Кількість постраждалих клієнтів публічно не вказана.
Закрита панель не скасовує викрадені ключі
FirstVDS заявив, що після виявлення атаки закрив зовнішній доступ до системи керування віртуалізацією та заблокував у своїй мережі адресу сервера-одержувача. За повідомленням провайдера, виробник надав проміжний патч і працює над остаточним виправленням; доступ до системи залишатиметься обмеженим до повного усунення вразливості. Це заявлені заходи стримування, а не незалежно підтверджена безпека всіх інсталяцій VMmanager.
На перевіреній 18 жовтня статус-сторінці окремо зазначалася недоступність авторизації в кількох панелях VMmanager. Це підтверджує наявність обмежень доступу, але індикатор доступності не показує, які файли скопіювали та чи скористався хтось токеном в іншому сервісі.
Отже, є два різні завдання. Провайдер має закрити шлях до інфраструктури. Постраждалі клієнти — позбавити чинності доступи, які вже могли опинитися за її межами. Відновлення панелі чи зміна одного пароля сервера не вимикає старий API-токен у сервісі, що його видав. Новий ключ також не замінює відкликання попереднього.
Перевірте, куди ведуть секрети із сервера
Для сповіщених клієнтів FirstVDS насамперед радить переказати кошти на нові криптогаманці, створені на іншому, чистому пристрої. Далі потрібно замінити паролі, приватні SSH-ключі, API-ключі й токени, що зберігалися на постраждалому сервері. Йдеться не лише про root: серед прикладів провайдер називає бази даних, панелі сайтів, пошту, хмарні сервіси, CI/CD та платіжні системи.
Відкличте старі облікові дані там, де ними можна скористатися. Саме створення нового ключа може залишити скопійований чинним. Якщо на сервері лежав приватний SSH-ключ, перевірте інші машини, де відповідний публічний ключ надає доступ. Зміна root-пароля орендованого сервера не скасовує цієї довіри. Важливість окремого відкликання токенів показує й випадок із викраденням секретів через npm-пакети Keyv.
Перегляньте входи починаючи із 17 жовтня — і на самому сервері, і в сервісах, ключі яких на ньому зберігалися. Якщо нападник міг увійти до заміни доступів, провайдер радить перевірити ~/.ssh/authorized_keys, невідомих користувачів, завдання cron і служби systemd. Це пошук можливого подальшого проникнення, окремий від початкового копіювання дисків. Збережіть потрібні журнали для розслідування.
У історії з перехопленням пароля sudo крадіжка відбувалася всередині Linux. Тут описано інший рівень доступу: перевстановлення гостьового сервера не поверне вже скопійований секрет, а відсутність шкідливого процесу всередині не виправдовує зовнішнє сховище.
Якщо сповіщення немає, FirstVDS каже, що поки не знайшов слідів атаки на ваших вузлах; розслідування триває. Перевіряйте кабінет безпосередньо. Мовчання, доступний сайт чи відсутність антивірусного попередження не є остаточним висновком щодо витоку. Провайдер обіцяє докладний розбір після закриття інциденту та завершення розслідування.
Джерела
- FirstVDS/CLO. Повідомлення про інцидент безпеки. Офіційний канал провайдера, на який посилається firstvds.ru; 18 жовтня 2026 року, з доповненням о 15:25 за московським часом. Переглянуто 18 жовтня 2026 року.
- FirstVDS. Статус сервісів. Поточна доступність панелей VMmanager; переглянуто 18 жовтня 2026 року.
