Несколько российских хостинг-провайдеров столкнулись с масштабной кибератакой, направленной на инфраструктуру управления виртуальными серверами. Злоумышленники использовали уязвимость в платформе VMmanager 6, разработанной компанией ISPsystem, которая входит в «Группу Астра». Получив доступ к системам виртуализации, атакующие смогли запустить вредоносное программное обеспечение, предназначенное для извлечения конфиденциальной информации с клиентских VPS и VDS. Под угрозой оказались пароли, SSH-ключи, токены авторизации, конфигурационные файлы и другие данные, хранящиеся на виртуальных машинах.

Об инцидентах сообщили представители FirstVDS и других российских провайдеров. По имеющимся сведениям, подготовка атаки продолжалась с 11 по 16 октября 2026 года, а наиболее активные действия злоумышленников пришлись на ночь с 16 на 17 октября. В отдельных случаях вредоносная программа получала доступ к дискам виртуальных серверов на протяжении нескольких часов. Разработчик VMmanager подтвердил проведение расследования и сообщил о выпуске исправлений безопасности. При этом точное количество пострадавших компаний и масштаб возможной утечки информации пока не установлены.

Как злоумышленники получили доступ к виртуальным серверам

Целью атаки стала VMmanager 6 — специализированная платформа для создания, настройки и администрирования виртуальных машин.

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

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

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

После проникновения в инфраструктуру они развернули специальную программу, предназначенную для поиска и копирования информации с клиентских серверов.

Точный технический механизм первоначального проникновения публично не раскрывается. Разработчик объясняет ограничение подробностей необходимостью защитить инфраструктуры заказчиков, которые ещё не завершили установку обновлений.

Вредоносная программа подключала диски клиентов и копировала файлы

Особенностью атаки стал способ получения информации с виртуальных машин.

Вместо непосредственного подключения к каждому серверу злоумышленники использовали возможности инфраструктуры виртуализации.

Вредоносное программное обеспечение подключало диски клиентских VPS/VDS в режиме только для чтения. После этого атакующие могли просматривать файловые системы и извлекать интересующие сведения.

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

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

Среди потенциально скомпрометированной информации оказались:

• Пароли пользователей и администраторов серверов.

• Приватные SSH-ключи, используемые для удалённого подключения.

• Токены авторизации в облачных платформах и сторонних сервисах.

• Конфигурационные файлы приложений и системных служб.

• История команд, выполнявшихся в терминале.

• Документы и другие пользовательские файлы.

• Данные криптовалютных кошельков, если они хранились на серверах.

Отдельную опасность представляют секреты доступа к внешним системам.

Например, похищенный SSH-ключ или действующий API-токен может позволить злоумышленникам продолжить атаку уже за пределами первоначально скомпрометированной инфраструктуры.

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

Фактический объём утечки ещё предстоит установить.

Атака развивалась несколько дней

По результатам анализа, проведённого облачным провайдером ForestsNet Cloud, компрометация управляющих панелей VMmanager происходила в период с 11 по 16 октября.

Наиболее активная фаза вредоносной деятельности была зафиксирована в ночь с 16 на 17 октября.

В одном из известных эпизодов доступ к клиентским данным осуществлялся 17 октября с 12:27 до 22:34 по московскому времени.

Таким образом, потенциально опасная активность продолжалась более десяти часов.

Специалисты ForestsNet Cloud также сообщили, что злоумышленники располагали значительным объёмом служебной информации об инфраструктуре.

В их распоряжении находились сведения о серверах и IP-адресах, электронные адреса клиентов, административные пароли и данные для подключения к удалённым консолям VNC.

Наличие такой информации могло существенно облегчить дальнейшие действия атакующих.

При этом представители ForestsNet Cloud не обнаружили на собственных узлах подтверждённых следов хищения файлов. Однако полностью исключить несанкционированный доступ компания не смогла.

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

«Группа Астра» подтвердила инцидент и выпуск исправлений

Разработчик платформы VMmanager — компания ISPsystem, входящая в структуру «Группы Астра», — подтвердил осведомлённость о произошедшем.

Представители компании сообщили о проведении внутренней проверки и взаимодействии с заказчиками, использующими программный продукт.

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

Также были подготовлены и выпущены исправления безопасности.

Владельцам инфраструктуры рекомендовано как можно быстрее установить доступные обновления.

При этом компания пока не раскрывает:

• Точное количество затронутых хостинг-провайдеров.

• Полный перечень скомпрометированных инфраструктур.

• Подробности эксплуатации уязвимости.

• Окончательные результаты расследования.

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

На момент появления сообщений об атаке ни одна известная хакерская группировка публично не заявила об ответственности за произошедшее.

Почему взлом системы виртуализации особенно опасен

Обычный виртуальный сервер представляет собой изолированную программную среду, работающую на физическом оборудовании провайдера.

На одном физическом узле могут одновременно размещаться десятки и даже сотни клиентских виртуальных машин.

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

Именно поэтому компрометация управляющего уровня создаёт серьёзные риски.

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

В подобных условиях атакующий потенциально способен обращаться к виртуальным дискам в обход стандартных механизмов авторизации гостевой системы.

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

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

Поэтому последствия подобных атак способны выходить далеко за пределы одного хостинг-провайдера.

Уязвимость затронула направление для хостинг-провайдеров

VMmanager первоначально создавался как инструмент для компаний, предоставляющих услуги виртуального хостинга и аренды серверов.

В дальнейшем платформа получила распространение и в корпоративном секторе, где применяется для управления собственной виртуальной инфраструктурой.

При этом сценарии эксплуатации продукта в этих двух сегментах различаются.

Согласно имеющейся информации, обнаруженная уязвимость находилась в функциональности, связанной именно с работой хостинг-провайдеров.

По этой причине сообщения о компрометации поступили прежде всего от компаний, предоставляющих VPS/VDS частным и корпоративным клиентам.

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

Кто использует VMmanager в России

Программная платформа ISPsystem применяется не только коммерческими хостинг-компаниями.

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

В частности, в опубликованных материалах фигурируют медицинские учреждения системы Минздрава, МИАЦ Томской области, Уральский федеральный университет, Алеф-банк и «Электросети Кубани».

Однако сам факт использования VMmanager не означает, что перечисленные организации пострадали от кибератаки.

Подтверждённых сведений об их компрометации в рассматриваемом инциденте нет.

Стоит также учитывать историю самого продукта.

Компания ISPsystem занималась разработкой VMmanager задолго до её включения в структуру «Группы Астра». Приобретение состоялось в 2022 году, поэтому платформа не является первоначальной разработкой группы.

Что рекомендуется сделать владельцам VPS и VDS

В условиях возможной компрометации управляющей инфраструктуры клиентам затронутых хостинг-провайдеров важно оценить риски не только для самих серверов, но и для всех связанных с ними систем.

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

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

1. Заменить потенциально скомпрометированные пароли.

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

2. Перевыпустить SSH-ключи.

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

3. Отозвать токены и ключи API.

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

4. Проверить журналы безопасности.

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

5. Оценить необходимость восстановления серверов.

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

Важно понимать, что установка обновления VMmanager на стороне провайдера устраняет известную уязвимость, но сама по себе не делает ранее похищенные пароли или токены безопасными.

Если секреты могли попасть к злоумышленникам, их необходимо заменить независимо от того, устранена ли первоначальная причина проникновения.

Последствия атаки пока остаются неясными

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

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

На данный момент известно о проведении расследования, выпуске исправлений и предупреждениях со стороны ряда российских хостинг-провайдеров.

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

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

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

Дальнейшие результаты расследования должны прояснить, насколько широко использовалась уязвимость и удалось ли атакующим получить доступ к дополнительным инфраструктурам.