Основные результаты расследования
17 октября 2026 года мы обнаружили компрометацию платформы управления виртуализацией VMmanager 6, разработанной ISPsystem. Злоумышленник получил административный доступ к панели и использовал её штатные функции для запуска сборщика данных на узлах виртуализации. Сборщик подключал диски клиентских виртуальных машин в режиме только для чтения и копировал выбранные файлы, включая пароли, ключи, токены и конфигурации. Он работал на гипервизорах и не требовал запуска программы внутри клиентских ВМ.
Мы приносим извинения за последствия инцидента, ограничения в управлении услугами и необходимость срочной смены учётных данных. В этом отчёте изложены установленные обстоятельства, оценка последствий, выполненные меры и дальнейшие действия.
Редакция от 27 октября 2026 года. Время событий — московское (UTC+3). Расследование ведёт аналитическая группа на базе Отдела эксплуатации FirstVDS.
Действия для затронутых клиентов
18 октября мы начали направлять персональные уведомления по электронной почте и через личный кабинет, указывая затронутые серверы и необходимые действия. По результатам дополнительной проверки уведомления дополнялись. Если вы получили такое сообщение, считайте данные на указанных серверах скомпрометированными и выполните следующие действия. Скопированные пароли и ключи сохраняют силу до их смены или отзыва.
Смените пароли root и других пользователей сервера, а также пароли баз данных, панелей управления и приложений.
Перевыпустите SSH-ключи, API-ключи и токены облачных сервисов, репозиториев, платёжных систем и ботов. Отзовите прежние ключи и токены: одного создания новых недостаточно.
Проверьте файлы конфигурации, включая .env и строки подключения к базам данных. Замените содержащиеся в них пароли и другие секреты, в том числе используемые для доступа к внешним системам.
Если на сервере хранились приватные ключи или seed-фразы криптокошельков, перенесите средства на новые кошельки, созданные на доверенном устройстве.
Исследованный сборщик читал диски без изменения их содержимого. Сам этот способ сбора не требует обязательной переустановки каждой ВМ. Однако похищенные учётные данные могут использоваться для последующего входа, поэтому проверьте журналы авторизации, пользователей, authorized_keys, задания cron и службы systemd. При обнаружении постороннего доступа или невозможности подтвердить целостность системы восстановите её из доверенного источника. Переустановка не отзывает ключи и токены внешних сервисов — их необходимо заменить отдельно.
Проверка гостевой системы и смена учётных данных решают разные задачи. Отсутствие следов постороннего входа не исключает чтения файлов со стороны гипервизора, а смена одного пароля не отзывает остальные секреты, которые могли храниться на сервере.
Если уведомление не поступило, проверьте сообщения в личном кабинете. По результатам проведённой проверки мы уведомили владельцев серверов, отнесённых к затронутым. При выявлении дополнительных обстоятельств мы направим отдельные сообщения.
Хронология событий
14–15 октября. ISPsystem выпустил обновления безопасности VMmanager. Мы обратились в поддержку за их установкой; обновлением занимались специалисты вендора. По сообщению поддержки, к вечеру 15 октября все панели были обновлены. На запрос о характере ошибки мы получили ответ о наличии уязвимости безопасности без раскрытия технических подробностей.
17 октября, 00:44. Самая ранняя метка создания найденного архива сборщика. В течение дня зафиксированы несколько волн сбора данных и соединений с сервером злоумышленника. В первых уведомлениях клиентам было указано окно 12:27–22:34. Последующая проверка узлов выявила более ранние архивы и расширила установленный период сбора.
17 октября, около 23:00. После предупреждения представителя ISPsystem об активности злоумышленника мы обнаружили посторонние скрипты. Дежурная команда отдела эксплуатации остановила панели VMmanager и применила сетевую изоляцию.
18 октября, 04:00. ISPsystem выпустил экстренное обновление. Оно намеренно ограничивало часть функций панели, в том числе запуск скриптов внутри платформы, чтобы злоумышленник не мог ими пользоваться. Первопричина на тот момент ещё не была найдена.
18 октября. Начали персональное уведомление затронутых клиентов по электронной почте и через личный кабинет. В сообщениях приводились перечни серверов и инструкции по смене учётных данных.
18 октября, 18:00. Вендор выпустил обновление, которое закрывало дополнительные возможные пути перемещения внутри панели.
19–20 октября. Из-за экстренного обновления 18 октября перестал работать модуль выдачи IP-адресов, и новые виртуальные серверы не создавались. Работу восстановили после обновления 21 октября.
19–21 октября. 19 октября ISPsystem выпустил исправление уязвимости HTTP Request Smuggling. Первая версия сильно урезала функции панели. Наши панели с 17 октября были закрыты от внешней сети, поэтому вендор решил её не ставить и дождаться доработанной версии. Она вышла утром 20 октября. С 20 по 21 октября вендор вместе с нашей командой обновлял панели по очереди, кластер за кластером, и параллельно возвращал функции, отключённые экстренными обновлениями.
21–22 октября. При дополнительной проверке управляющих серверов обнаружены инструменты сохранения удалённого доступа. Для поиска вредоносных компонентов команда использовала собственный анализ и Kaspersky Virus Removal Tool (KVRT) с обновлёнными детектами.
23 октября. ISPsystem выпустил очередные обновления безопасности VMmanager. К этой дате мы сменили пароли всех учётных записей VMmanager — от пользовательских до административных.
Файловые метки указывают, что сбор данных начался примерно за 22 часа до обнаружения инцидента. Точное время первоначального проникновения не установлено. В ходе нашей проверки следов присутствия злоумышленника до 17 октября не обнаружено.
Механизм получения административного доступа
По техническому пояснению ISPsystem, злоумышленник использовал HTTP Request Smuggling — контрабанду HTTP-запросов. По описанному поведению мы сопоставили этот механизм с вариантом CL.0, при котором прокси учитывает тело запроса, а внутренний сервис фактически обрабатывает его как отсутствующее. CL.0 здесь является нашей технической интерпретацией описания вендора.
Атакующий отправлял запрос на установку WebSocket-соединения и помещал в его тело дополнительный HTTP-запрос. Nginx передавал тело внутреннему сервису как часть исходного запроса. Сервис отклонял запрос на соединение, но не вычитывал его тело и сохранял соединение открытым. Оставшиеся данные затем разбирались как следующий самостоятельный запрос.
Во вложенном запросе находился заголовок, которым внутренние службы обозначали доверенные обращения. Обычно nginx не пропускал такой заголовок от внешнего клиента. В данном случае он находился внутри тела первого запроса и не проходил обычную обработку заголовков. Внутренний сервис принимал его как признак доверенного обращения и выполнял запрос с административными полномочиями.
По последующему пояснению ISPsystem, обновление 14–15 октября закрывало другую уязвимость. Уязвимость HTTP Request Smuggling вендор нашёл и закрыл 19–20 октября, у нас исправление установлено 20–21 октября (подробнее в хронологии). После обновления мы продолжили проверку инфраструктуры на ранее оставленные средства доступа.
Получив административный доступ, атакующий использовал штатный механизм запуска задач на узлах. Сборщик читал диски со стороны гипервизора, без входа по SSH в каждую виртуальную машину. Поэтому отсутствие посторонних входов в гостевую систему не исключает доступа к её файлам.
Другие провайдеры, включая Senko Digital и ProfitServer, сообщали о создании посторонних административных учётных записей и других способах сохранения доступа в панелях. В наших панелях признаков такого способа закрепления не обнаружено; этот результат проверки также подтвердил вендор.
Затронутые системы и данные
Команда располагает бинарным файлом стиллера и исследовала его в доступном объёме. Анализ образца и параметров запуска из плейбуков управляющего сервера платформы позволил установить маски имён и расширения файлов, отбиравшихся для включения в дампы. В изученной команде запуска категории сбора и ограничение размера файлов не переопределялись; дополнительные маски отбора не задавались. По справке программы, набор категорий по умолчанию включает секреты и учётные данные, данные криптокошельков, пользовательские файлы и каталоги, системные настройки, данные Tor и историю команд. Исследованный стиллер выборочно копировал файлы с дисков клиентских ВМ, не создавая полных образов дисков. Дампы оперативной памяти ВМ этим инструментом не создавались.
Действие, заданное после завершения сборщика, отправляло уже сформированный архив на сервер злоумышленника; команд дополнительного сбора данных оно не содержало. На каждом обследованном узле найдено не более одного дампа стилера. По исследованным плейбукам и обнаруженным артефактам признаков дополнительного извлечения данных из клиентских ВМ за пределами установленного сценария сбора не выявлено. При этом количество сохранившихся дампов само по себе не исключает других операций с данными.
Найденные архивы сохранились, но зашифрованы ключом злоумышленника. Ключа расшифровки у нас нет. Анализ бинарного файла и известные параметры запуска позволяют установить правила отбора, однако проверить точный перечень фактически скопированных файлов по каждой ВМ по содержимому архивов невозможно; для архивов доступны размеры и файловые временные метки.
Архивы сборщика обнаружены на 457 узлах виртуализации — физических серверах, размещающих клиентские ВМ. Это количество узлов, а не клиентов или виртуальных машин: на одном физическом сервере работают ВМ разных заказчиков.
Суммарный размер найденных архивов составляет 117,24 ГиБ, или около 126 ГБ. Это объём файлов, обнаруженных на узлах. Он не устанавливает объём данных, фактически полученных злоумышленником.
По результатам антивирусной проверки исследованные образцы отнесены к семействам Grabber — средству кражи учётных данных — и Bpfit — бэкдору для удалённого доступа. Дополнительно выявлен инструмент Gsnetcat. Эти компоненты обнаружены на управляющих серверах и узлах VMmanager 6. Доступ снаружи мы перекрыли ещё 17 октября. Выявленные вредоносные объекты были сохранены для анализа, затем удалены.
На одном из управляющих серверов VMmanager также обнаружен архив базы панели управления. Он учитывается отдельно от зашифрованных архивов сборщика на узлах. База панели управления содержит данные учётных записей и сведения, связанные с доступом к виртуальным серверам; соответствующие пароли, ключи и токены рассматриваются как скомпрометированные. Персональных данных клиентов в базе VMmanager не было.
Биллинг, личный кабинет, платёжные данные, инфраструктура резервного копирования и другие системы, где хранятся персональные данные клиентов и сведения об их услугах, не управляются через VMmanager и инцидентом не затронуты.
Оценка передачи данных
Журналы прокси подтверждают соединения с сервером злоумышленника. Однако используемый формат журналов прокси-сервера учитывал размер ответа клиенту и не содержал достаточных данных для расчёта объёма отправленных данных. При семплировании объём трафика в NetFlow рассчитывается на основе выборочного учёта пакетов с последующей экстраполяцией на весь поток. Поэтому полученные значения являются статистической оценкой и могут отличаться от фактического объёма переданных данных. Подтвердить или опровергнуть полную передачу всех подготовленных архивов невозможно.
Для оценки последствий мы исходим из передачи данных всех виртуальных машин, которые в период сбора находились на узлах с обнаруженными архивами, кешами или индексами. Это основание для уведомления клиентов и смены учётных данных. Такая оценка не означает доказанного копирования всех файлов или полного диска каждой ВМ.
Для узлов, на которых не обнаружены ни каталоги дампов, ни связанные вредоносные процессы, мы принимаем рабочую оценку отсутствия передачи данных. Отсутствие этих признаков само по себе не подтверждает отсутствие иных последствий компрометации.
Выполненные меры и состояние восстановления
Команда ограничила сетевой доступ к панелям управления и узлам VMmanager. На пограничных маршрутизаторах заблокированы сети автономной системы, использовавшейся атакующим, чтобы затруднить обход блокировки сменой адреса у того же провайдера. Мы проверяли процессы и автозапуск, сопоставляли сетевые и файловые следы, сохраняли образцы и заменяли скомпрометированные учётные данные.
По информации ISPsystem, Лаборатория Касперского подготовила по материалам провайдеров эвристические детекты и включила их в базы KVRT 21 октября. Дополнительное сканирование помогло выявить оставшиеся вредоносные компоненты. Их копии сохранены для дальнейшего анализа, после чего обнаруженные объекты удалены.
По состоянию на 23 октября в VMmanager сменены пароли всех учётных записей, включая пользовательские и административные. Эта мера относится к платформе управления. Пароли и секреты внутри клиентских ВМ и во внешних сервисах необходимо менять отдельно.
Экстренные обновления вендора ограничивали часть функций панели. Одно из них, от 18 октября, нарушило выдачу IP-адресов, и 19–20 октября новые виртуальные серверы не создавались. Работа восстановлена 21 октября. Полная статистика доступности клиентских ВМ ещё не сведена; утверждать, что инцидент не повлиял на работу всех сервисов, было бы некорректно.
Рост числа обращений увеличил сроки ответа поддержки. Мы обрабатываем накопившиеся запросы и приносим извинения за задержки. Обращения, связанные с признаками компрометации и восстановлением доступа, просим описывать с указанием конкретного сервера и обнаруженных признаков.
Мы установили выпущенные ISPsystem обновления безопасности. В журнале изменений за 23 октября указаны сборки VMmanager 2026.09.1-8 и 2026.05.2-12. Параллельно мы отдельно проверяли управляющие серверы и узлы: исправление уязвимости не подтверждает удаления всех ранее внедрённых инструментов злоумышленника.
По сообщению ISPsystem, 23–25 октября вендор проверял исправления на ряде доступных из интернета тестовых стендов, имитирующих инфраструктуру провайдера: с исправлениями и без них. На стенды поступило более 10 000 запросов с перебором способов атаки и вызовов API. Вендор сообщил о воспроизведении атаки на контрольных стендах и отсутствии компрометации стендов с исправлениями. По его наблюдениям, новых случаев компрометации инфраструктур, установивших исправления от 19–20 октября, не зафиксировано. Исправления подтвердили эффективность в условиях реальной атаки. При этом ISPsystem продолжает изучать, какие векторы злоумышленник пробовал использовать: эти данные будут учтены в следующих патчах. Эти сведения приводятся как результаты проверки ISPsystem.
На момент подготовки отчёта командой FirstVDS выполнены следующие изменения:
в VMmanager заменены пароли, ключи и токены;
для панелей и узлов VMmanager, а также DNSmanager действуют сетевые ограничения;
внедрён новый прокси-сервер с расширенным журналированием и ограничениями исходящих соединений.
Инцидент не считается закрытым. Завершение восстановления связано с проверкой установленного исправления, устранением выявленных способов сохранения доступа, отзывом скомпрометированных учётных данных и контрольным обследованием систем.
Дальнейшие изменения защиты
Продолжаются следующие работы:
проверка всего управляющего контура и поиск оставшихся способов сохранения доступа;
замена секретов смежных систем и проверка интеграций;
восстановление части узлов средствами дистрибутива с проверкой целостности; для узлов, целостность которых подтвердить не удастся, предусмотрена пересборка из доверенной операционной системы;
разделение прокси по сервисам и зонам, введение дополнительных правил исходящей фильтрации;
централизованное длительное хранение журналов и настройка аварийных оповещений дежурной смене.
Мы изменяем порядок реагирования: сообщение об активной эксплуатации уязвимости становится основанием для немедленного ограничения доступа к затронутым системам, параллельно с проверкой и установкой исправлений. После остановки панели проверке подлежат все узлы, которыми она управляла.
Прямой публичный доступ клиентов к VMmanager восстанавливать не планируем. Управление серверами будет предоставляться через личный кабинет. О сроках и доступных функциях сообщим отдельно.
Компенсации
После публикации данного отчёта мы начнём рассмотрение вопросов компенсации. Порядок обращения и условия рассмотрения будут опубликованы отдельно.
Материалы расследования и источники
Материалы аналитической группы FirstVDS: инвентаризация архивов и узлов, анализ образцов, журналы прокси-сервера и сетевые данные, результаты антивирусных проверок, переписка с поддержкой и внутренний технический постмортем.
Технические пояснения ISPsystem и материалы вендора, использованные при подготовке отчёта. Описание первопричины и результаты испытаний на тестовых стендах приведены со ссылкой на сведения ISPsystem.
ISPsystem, сообщение об инциденте от 20 октября: ispsystem.ru/news/vulnerability-incident
ISPsystem, журнал изменений VMmanager: ispsystem.com/vm-changelog
Senko Digital, собственный постмортем инцидента: https://senkostatus.com/history/inci_EhaD8uWavIoVCE
ProfitServer, сообщение об инциденте с VMmanager 6: https://profitserver.net/knowledge-base/vmmanager-6-october-2026/
HTTP request smuggling, вариант CL.0, описание класса: https://portswigger.net/web-security/request-smuggling/browser/cl-0
Публичный разбор инцидента ISPsystem: https://www.ispsystem.ru/news/post-mortem
