В середине октября инфраструктура нескольких десятков хостинг-провайдеров, использующих в своей ИТ-инфраструктуре VMmanager 6 Hosting, столкнулась со скоординированной многоэтапной атакой. Злоумышленники использовали уязвимости, которые с поправкой на специфику технических и бизнес-процессов хостинг-провайдеров увеличили поверхность атаки и привели к компрометации данных конфигурации, секретов и пользовательских файлов у ряда клиентов.
При взаимодействии с заказчиками и партнерами команда разработки ISPsystem в кратчайшие сроки начала расследование и устранение инцидента безопасности. В частности, было установлено, что атака на VMmanager 6 велась с помощью специализированных ИИ-инструментов. Уязвимости, которые эксплуатировались в ходе атаки, закрыты. Работа по изучению инцидента продолжается, чтобы исключить другие возможные векторы и установить все обстоятельства произошедшего.
Что произошло
14.10.2026 в 00:40 (МСК) в службу технической поддержки поступило обращение от одного из хостинг-провайдеров — в его инфраструктуре была обнаружена подозрительная активность на серверах под управлением VMmanager 6 Hosting.
Сразу после этого команда ISPsystem оперативно инициировала совместное с хостинг-провайдерами расследование инцидента, однако на момент начала реагирования не было достоверно установлено, что именно является точкой входа — платформа VMmanager 6 Hosting или инфраструктура провайдера. В дальнейшем анализ ситуации показал, что первые следы проникновения были зафиксированы у некоторых клиентов 12.10.2026. Также об этом свидетельствуют обсуждения пользователей в профильных сообществах социальных сетей.
По информации от провайдеров было выдвинуто предположение, что злоумышленник проник в инфраструктуру через уязвимость в ISO-образе, верифицированную в рамках программы Bug Bounty 09.10.2026. Иными словами, подобная ошибка предполагает наличие первичного пользовательского доступа, который можно получить, фактически просто купив виртуальную машину у хостинг-провайдера. Команда работала над ее исправлением. Усиление безопасности требовало определенных архитектурных доработок, поэтому релиз новой версии платформы был запланирован на 15.10.2026.
14.10.2026 в 19:00 (МСК) для экстренного закрытия уязвимостей вместо запланированного патча были выпущены хотфиксы 2026.05.2-5 и 2026.09.1-1, основанные на исправлениях, запланированных в новой версии. Чтобы ускорить выпуск, мы не стали включать в этот хотфикс ряд превентивных архитектурных доработок, которые планировали к релизу 15 октября: они вошли в следующие хотфиксы. Также команда ISPsystem оперативно уведомила заказчиков через техническую поддержку о необходимости установки таковых и дала актуальные на тот момент рекомендации по защите инфраструктур, в том числе закрыть возможность загрузки пользователями своих ISO для уже скомпрометированных инфраструктур. Поскольку VMmanager и DCImanager имеют ряд общих сервисов, схожий патч 2026.09.1-1 был собран и применён для DCImanager 15.10.2026.
В отличие от Enterprise-сегмента, где инфраструктуру можно полностью изолировать внутри закрытого корпоративного периметра, бизнес-модель хостинг-провайдеров требует максимальной публичной доступности. По этой причине хостинг-провайдеры, как правило, эксплуатируют платформу в открытом контуре. Здесь важно уточнить: для хостинг-провайдера «открытый контур» — это не просто наличие доступа в интернет, а публично доступные сервисы на белых IP-адресах. Именно белые IP-адреса и выставленные наружу сервисы кратно увеличивают поверхность атаки, которая включает не только саму платформу, но и окружающую инфраструктуру. У инфраструктурных клиентов «открытый контур» обычно означает лишь доступ в интернет. Поэтому модели угроз для этих двух сценариев принципиально различаются.
Утром 17.10.2026 (МСК) началась новая волна атак, подтвержденная обращениями в поддержку ISPsystem. Их количество увеличивалось по нарастающей в течение дня, и к вечеру 17.10.2026 суммарно составило порядка 20. В ходе изучения журналов систем, подвергшихся новому этапу атаки, мы выяснили, что выпущенный ранее хотфикс решил поставленную перед ним задачу, однако злоумышленник начал дополнительно эксплуатировать другую уязвимость. Одновременно с этим предприняли еще ряд мер защиты — закрыли возможность выдачи SSH-доступа в платформе, запретили администраторам запускать скрипты для узлов и ВМ, дали провайдерам рекомендации по «закрытию» их инфраструктуры, которые позволили ограничить злоумышленнику пространство для маневра и помешать ему закрепиться в системе, и собирали хотфиксы.
18.10.2026 в 4:00 (МСК) были выпущены хотфиксы 2026.05.2-6 и 2026.09.1-2. Мы намеренно ограничили часть функционала, в том числе запуск и выполнение скриптов внутри платформы. Это позволяло «парализовать» злоумышленника, однако мы понимали, что первопричина инцидента пока не найдена, и продолжали вести расследование.
18.10.2026 в 18:00 (МСК) были выпущены хотфиксы 2026.05.2-7 и 2026.09.1-3 с закрытием дополнительных потенциально возможных путей перемещения внутри продукта.
19.10.2026 были выпущены обновления безопасности для DCImanager 6 — 2026.09.1-3 и 2026.09.1-4: как уже упоминали, платформа имеет схожую архитектуру с VMmanager 6, и мы защищали и ее в рамках реагирования на инцидент.
19.10.2026 в 16:00 (МСК) в ходе расследования мы установили, что злоумышленник проникал на серверы с использованием контрабанды HTTP-запросов (HTTP Request Smuggling). Для этого использовалась ранее неизвестная 0-day уязвимость в нашем сервисе, а особенность nginx пропускать такие запросы делала ее эксплуатацию возможной. В систему отправлялся HTTP-запрос на установку websocket-соединения с телом. По RFC такое поведение со стороны клиента не рекомендуется, nginx пропускает подобные запросы, и это открыло возможность использования контрабанды HTTP-запросов.
В NGINX, начиная с версии 1.31.5 от 2 сентября 2026 года, появилась директива client_body_early_read, позволяющая легко и удобно настраивать блокировку подобных запросов как для HTTP/1.1, так и для HTTP/2 (к счастью, HTTP/3 мы не используем). К сожалению, в stable-версии nginx на текущий момент (1.30.6) эта директива еще не поддерживается. Безусловно, найденная особенность работы nginx не снимает с нас ответственности за возникновение инцидента, однако мы крайне рекомендуем учитывать ее, если вы используете это решение в своей инфраструктуре.
Это привело к тому, что сервис, к которому обращается злоумышленник, запрос отвергает, но при этом не вычитывает его тело, а поскольку запрос содержит keep-alive, читает полученное тело как новый запрос. Для обычных запросов при передаче их из nginx в сервис (proxy_pass) мы со своей стороны использовали дополнительные Connection: close, что не позволяет обманывать систему подобным образом, но для websocket этого делать нельзя.
Это и позволило злоумышленнику выполнить запрос внутри системы с административными привилегиями. Внутри сети docker наши службы помечают внутренние запросы специальным HTTP-заголовком, который снаружи не принимается (nginx, используемый как frontend, этот заголовок не пропускает). Но из-за того, что nginx второй запрос воспринимал как тело первого, он никак не анализировал и не менял его.
19.10.2026 в 21:00 (МСК) были выпущены хотфиксы 2026.05.2-8 и 2026.09.1-4 с исправлением обнаруженной контрабанды HTTP-запросов (HTTP Request Smuggling), при этом блокировка части функционала сохранялась, поскольку злоумышленник все еще оставался внутри платформы.
20.10.2026 в 4:00 (МСК) были выпущены хотфиксы 2026.05.2-9 и 2026.09.1-5: возвращены веб-сокеты, которые ранее ограничил хотфикс против HTTP Request Smuggling, а также выпущен более аккуратный фикс основной уязвимости, не затрагивавший основную функциональность платформы.
Параллельно мы занимались зачисткой инфраструктур: искали вредоносные файлы, бэкдоры и закрепления и значительную часть из них находили и удаляли сами. «Лаборатория Касперского» предложила свою помощь в поиске и устранении следов атакующих и индикаторов компрометации, и мы приняли это предложение: коллеги усилили начатую нами работу по чистке. С согласия тех клиентов, чьи инфраструктуры проверялись, мы провели аудит их систем с помощью утилиты «Лаборатории Касперского» и передали партнеру результаты анализа их инфраструктур, а также скрипты, которые написали сами для поиска следов.
Также «Лаборатория Касперского» оперативно обновила детектирующие правила для обнаружения ВПО атакующих с помощью собственных решений. Правила обновлялись далее по мере получения новых данных в ходе расследования инцидента.
20.10.2026 в 21:30 (МСК) выпущены хотфиксы 2026.05.2-10 и 2026.09.1-6 с доработкой архитектуры и возвратом ещё части намеренно заблокированного функционала. Добавлена автоматическая блокировка известных «закладок» злоумышленника. Также был выпущен фикс для DCImanager — 2026.09.1-5.
21.10.2026 в 19:00 (МСК) на основе анализа данных хостинг-провайдеров «Лаборатория Касперского» предоставила бесплатный инструмент Kaspersky Virus Removal Tool (KVRT). Он помогал выявлять оставшиеся вредоносные объекты — например, бинарные файлы и другие следы атакующих. Инструмент был передан ряду провайдеров для дополнительного сканирования. Он показал эффективность, после чего ISPsystem предложила его всем, кого затронул инцидент.
22.10.2026 в 21:30 (МСК) мы выпустили фиксы 2026.05.2-11 и 2026.09.1-7 с дополнительными механизмами защиты платформы от потенциальных атак и стабилизационными улучшениями уже выпущенных хотфиксов. Параллельно мы продолжили анализировать скомпрометированные инфраструктуры, искать бэкдоры и аномалии.
23.10.2026 выпущены обновления безопасности для всех продуктов экосистемы: VMmanager 6 — stable v2026.05.2-12, regular v2026.09.1-8; DCImanager 6 — stable v2026.09.2-2, regular v2026.09.1-6; BILLmanager 6 — stable v6.154.5, regular v6.157.3; DNSmanager 6 — v6.5.2. Подчеркнем: эти обновления представляют собой дополнительные меры защиты, внедренные по результатам анализа методов атаки, и направлены на усиление безопасности экосистемы в целом — в том числе от векторов, которые в ходе инцидента не применялись. Также включают обновление компонентов nginx с устранением известных уязвимостей CVE-2026-15176, CVE-2026-97205, CVE-2026-93479.
После установки патча от 19.10.2026 случаев компрометации инфраструктур, применивших обновление, не зафиксировано.
23.10.2026 совместно с «Лабораторией Касперского» и клиентами хостинг-провайдеров мы продолжили работу по изучению скомпрометированных инфраструктур. По ее завершении мы дополнительно проинформируем о рекомендациях, которые необходимо выполнить для полной зачистки инфраструктуры.
В ходе расследования, чтобы проверить эффективность исправлений в условиях реальной атаки, ISPsystem развернула ряд стендов в открытом контуре, имитирующих инфраструктуру хостинг-провайдеров (honeypot): часть с актуальными патчами безопасности, другая без них. Стенды без исправлений были намеренно оставлены уязвимыми и подтвердили воспроизводимость атак. Стенды с исправлениями скомпрометировать не удалось.
Злоумышленник обнаружил стенды в короткие сроки и в течение нескольких дней предпринимал попытки взлома: в общей сложности более 10 000 запросов только на одну установку с перебором различных векторов и вызовов. Все попытки против защищенных стендов были отражены: исправления подтвердили эффективность в условиях реальной атаки. При этом мы изучаем, какие векторы злоумышленник пробовал использовать: эти данные будут учтены в следующих патчах.
На данный момент в ходе совместного с провайдерами расследования инцидента было установлено, что атака повлекла за собой угрозу безопасности пользовательских данных, включая потенциальную утечку SSH-ключей, паролей доступа, токенов доступа к облачным сервисам, конфигурационных файлов, истории вводимых команд, криптокошельков и пользовательских документов. Для части конечных клиентов инцидент обернулся временной недоступностью сервисов, вызванной необходимостью проведения экстренных технических работ и принудительной изоляции скомпрометированных нод. В результате анализа инцидента на узлах было обнаружено специализированное вредоносное ПО, занимающееся сбором данных. Вместе с тем мы не можем ни подтвердить, ни опровергнуть объем и сам факт передачи данных. Поэтому ряд провайдеров оценивает ситуацию консервативно и считает де-факто данные скомпрометированными. Мы считаем данный подход обоснованным.
На сегодняшний день закрыты уязвимости, которые эксплуатировались в ходе атаки. На инфраструктурах заказчиков развернуты необходимые исправления безопасности. При этом расследование продолжается: совместно с заказчиками и партнерами мы изучаем скомпрометированные инфраструктуры, анализируем поведение атакующего, а также ищем заложенные ранее не выявленные злоумышленником бэкдоры.
Меры реагирования и недопущения подобных ситуаций:
- В рамках реагирования было организовано тесное взаимодействие с рядом хостинг-провайдеров — их обратная связь, содействие в проверке инсталляций и готовность участвовать в диагностике использовались для локализации инцидента и проверки эффективности принятых мер.
- Мы информировали клиентов по закрытым каналам: рассылки, личный кабинет, баннеры в продукте. Публичных заявлений не делали, пока злоумышленник оставался активен: преждевременное раскрытие деталей могло увеличить число пострадавших. Приоритетом было снижение риска для клиентов, а не скорость публичной коммуникации. Дополнительно мы убирали с официального сайта предыдущие версии патчей безопасности, чтобы у клиентов не возникало путаницы при установке актуальной версии. Убедительно просим обращать внимание на сообщения вендора и не откладывать установку обновлений безопасности.
- На стороне продукта внесены изменения во внутренний framework, используемый всеми сервисами системы — усилен контроль над обработкой HTTP-запросов и введены дополнительные проверки для внутренних запросов, чтобы снизить риск их подделки при проникновении злоумышленника во внутреннюю сеть.
- Усилены механизмы защиты платформы от потенциальных атак — изменения уже вошли в последний релиз. Работа по повышению защищенности платформы продолжается — в ближайшее время выпустим и другие дополнительные обновления. Пожалуйста, устанавливайте актуальные версии и следите за рекомендациями. Использование старых версий продукта значительно усложняет или вовсе исключает проведение расследования в случае возникновения инцидента, а также делает возможным использование уязвимостей для проникновения и взлома, уже устраненных вендором в актуальных версиях платформы.
- Мы уже трансформировали внутренний процесс управления жизненным циклом уязвимостей. Это позволит усилить их поиск, контроль и обработку, а также перейти к модели сквозного превентивного и экспресс-реагирования на инциденты безопасности. Данный подход уже применялся при итеративной доставке последних хотфиксов. Почему это важно? Когда атакующие работают с автоматизированными инструментами, между находкой уязвимости и её эксплуатацией проходят часы.
- Еще одно направление работы — автоматизированный непрерывный ИИ-пентест. Эта практика применялась и ранее, но в рамках реагирования на инцидент была усилена: выросла частота проверок и расширился их охват. Это позволяет выявлять скрытые цепочки уязвимостей более оперативно.
- Сотрудничество с «Лабораторией Касперского» будет продолжено с целью аудита скомпрометированных инфраструктур и проведения полноценного расследования для восстановления всей картины инцидента, включая поиск закрепов акторов, новых IoC и зачистку инфраструктур.
- Важная информация для пользователей, которые закрыли контур в связи с инцидентом: просим держать контур закрытым еще некоторое время: мы завершаем анализ действий злоумышленника и планируем выпустить еще несколько патчей с усилением безопасности. Мы сообщим о возможности открытия контура и возобновлении работы в штатном режиме. Дополнительно всем пользователям рекомендуем использовать надежные средства защиты от киберугроз. Решения «Лаборатории Касперского» обнаруживают ВПО, применяемое в данной атаке. Вы также можете проверить инфраструктуру с помощью бесплатного инструмента Лаборатории под названием Kaspersky Virus Removal Tool (KVRT).
Важная информация для пользователей лицензий VMmanager Infrastructure и VMmanager Infrastructure (версия ФСТЭК): мы подготовили дополнительные меры усиления безопасности платформы на основании данных анализа инцидента и рекомендуем произвести установку выпускаемых патчей по мере их выхода.
Вывод
Мы столкнулись с беспрецедентной по своим масштабам атакой и на наши продукты, и на хостинг-провайдеров одновременно. На сегодняшний день было установлено, что она велась с помощью специализированных инструментов на базе ИИ. В частности, на это указывает наличие характерных специфических ИИ-паттернов, оставленных комментариев в скриптах злоумышленника, количество атак, а также тот факт, что в разных инфраструктурах одновременно шел параллельный процесс подбора методов атаки с динамическим изменением поведения злоумышленника в зависимости от настроек инфраструктуры конкретного провайдера, и ряд других наблюдений, сделанных нами в процессе изучения инцидента.
Сегодня инструменты на базе ИИ все активнее применяются при поиске уязвимостей, в том числе в широко распространенных компонентах — PHP, ядре Linux, nginx, Postgres. За последние недели атакам подверглись как фундаментальные компоненты, так и прикладные платформы. Использование таких инструментов существенно меняет требования к скорости реакции разработчиков программного обеспечения на подобные угрозы. Безусловно, безопасность — это не свойство когда-то написанного кода, а непрерывный процесс. ИИ не отменяет этот процесс, но задает ему более высокий темп.
Безопасность требует постоянной работы; для недопущения подобных ситуаций мы продолжим выпускать обновления с усиленными механизмами защиты и анализировать инфраструктуры. Расследование инцидента не завершится до тех пор, пока мы не будем уверены, что в пораженных средах не осталось каких-либо закреплений или бэкдоров злоумышленника.
Мы понимаем, что этот инцидент потребовал от наших клиентов и партнеров дополнительных усилий, приносим свои извинения и благодарим всех, кто помогает в диагностике и проверке исправлений.
