Инцидент безопасности VMmanager 6: что произошло и что делать

В октябре 2026 года злоумышленники атаковали сразу несколько российских хостинг-провайдеров через критическую уязвимость в VMmanager 6 — панели управления виртуализацией от компании ISPsystem (входит в «Группу Астра»). На этой панели работают VPS у нас и у многих других провайдеров. Мы тоже пострадали.

Ваши серверы продолжают работать. Ниже — что произошло, почему, что мы уже сделали и что нужно сделать вам.

Причина: уязвимость в продукте разработчика

Атака стала возможной из-за критической уязвимости в самом программном обеспечении VMmanager 6. Это не ошибка настройки у отдельного провайдера: одна и та же уязвимость была использована одновременно против многих хостинговых компаний.

О взломе через VMmanager 6 публично сообщили FirstVDS, ForestsNet Cloud, MHost, HSH Network и YaColo. Сам разработчик подтвердил инцидент: по словам представителя «Группы Астра», уязвимость была в одной из сборок VMmanager.

Чего до сих пор не сообщил разработчик

На момент публикации ISPsystem не предоставила провайдерам информации, достаточной для уверенного устранения уязвимости и проверки инфраструктуры. Не опубликованы:

• описание уязвимости и способ первоначального проникновения;
• идентификатор CVE и список затронутых версий;
• индикаторы компрометации (IoC): адреса серверов злоумышленников, имена файлов и процессов, признаки закрепления;
• подтверждение, что выпущенные исправления закрывают уязвимость полностью.

Первое исправление вышло в ночь на 18 октября, затем последовали ещё несколько. По данным других пострадавших провайдеров, разработчик сам не рекомендовал открывать доступ к панели до выхода следующих патчей. Без технических деталей каждый провайдер вынужден восстанавливать картину атаки самостоятельно, по собственным журналам и в общении с коллегами.

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

Что могло утечь

Злоумышленники получили доступ к базе данных панели. В ней хранились:

• список серверов и их IP-адреса;
• адреса электронной почты учётных записей панели;
• root-пароли, заданные через панель при заказе, переустановке или смене пароля;
• пароли VNC-консоли.

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

• SSH-ключи, authorized_keys, хеши паролей, менеджеры паролей, ключи GnuPG;
• учётные данные облаков и DevOps: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, токены GitHub, GitLab и npm;
• файлы .env, docker-compose.yml, конфигурации приложений и баз данных;
• криптокошельки, seed-фразы, ключи API бирж;
• пароли и cookies браузеров, история командной оболочки;
• API-ключи сервисов ИИ, пароли резервных копий restic и Borg.

Программа работала на уровне инфраструктуры и не запускалась внутри серверов. Поэтому на самом сервере следов её работы нет, даже если данные были скопированы.

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

Что мы сделали

Не дожидаясь полной информации от разработчика, мы провели собственную проверку и закрыли известные нам пути доступа:

1. Закрыли публичный доступ к панели управления сразу после обнаружения атаки.
2. Нашли и заблокировали в обеих наших панелях посторонние учётные записи с правами администратора, созданные злоумышленниками для закрепления. Данные о них сохранены для расследования и переданы разработчику.
3. Установили все исправления, выпущенные ISPsystem.
4. Сменили всё, что хранилось на сервере панели: ключи доступа к узлам, служебные пароли интеграций с биллингом и поддержкой, ключи DNS и резервного копирования.
5. Проверили узлы с клиентскими серверами: файлы, службы, процессы и журналы.

Какие данные не пострадали

По результатам нашего расследования, инцидент не затронул:

• резервные серверы;
• персональные данные в биллинге;
• платёжные реквизиты;
• любые сервисы, кроме пострадавшей платформы управления виртуализацией.

Здесь сыграло роль разделение этих систем: доступ к части среды управления виртуализацией не открывал доступа к данным о выставлении счетов, учётным записям клиентов и инфраструктуре резервного копирования.

Что нужно сделать вам

Главный риск — что злоумышленники воспользуются украденными паролями и ключами. Сделайте это как можно скорее, даже если на сервере всё выглядит нормально.

1. Криптокошельки — в первую очередь. Если на сервере хранились кошельки или seed-фразы, переведите средства на новые кошельки, созданные на другом, чистом устройстве.
2. Смените root-пароль, если задавали его через панель и с тех пор не меняли.
3. Перейдите на вход по SSH-ключу и отключите вход по паролю.
4. Смените все секреты, хранившиеся на сервере: пароли пользователей и баз данных, SSH-ключи, API-ключи и токены, доступы к облакам, CI/CD, почте, платёжным системам и сервисам ИИ.
5. Отзовите старые ключи, а не просто создайте новые: в облачных консолях, GitHub, GitLab, у платёжных провайдеров.
6. Проверьте сервер: незнакомые пользователи, ключи в ~/.ssh/authorized_keys, задания cron, незнакомые процессы и службы systemd.
7. Проверьте журналы входов на сервере и в сервисах, ключи от которых на нём лежали: нет ли входов с незнакомых адресов после 11 октября.
8. Если на сервере были персональные данные ваших клиентов, проконсультируйтесь с юристом об обязанности уведомить Роскомнадзор.

Если у вас есть серверы у других провайдеров, которые работают на VMmanager 6, выполните те же действия и там.

Если нужна помощь

Нашли на сервере что-то постороннее или не уверены? Напишите в поддержку — поможем разобраться и при необходимости переустановим сервер.

Приносим извинения за неудобства, включая время без доступа к панели. Мы будем обновлять эту статью по мере появления информации от разработчика и опубликуем подробный разбор после завершения расследования.