Средняя
В июле 2026 года специалисты по информационной безопасности сообщили о целевой кампании, в которой злоумышленники использовали механизмы обновления ViPNet для закрепления на компьютерах российских организаций и доставки вредоносных модулей.
ИнфоТеКС подтвердил наличие нового вектора атаки с использованием транспортного протокола MFTP в составе ViPNet Client 4. Важное условие атаки — злоумышленник должен предварительно получить контроль над узлом с установленным ViPNet Administrator внутри доверенной сети. После этого скомпрометированный управляющий узел может отправить специально сформированный файл-конверт, имитирующий легитимное обновление и содержащий произвольную вредоносную нагрузку.
Эта деталь принципиальна. Речь идёт не о том, что атакующий обязательно взломал центральную инфраструктуру производителя и подменил официальный дистрибутив для всех пользователей. В описанном сценарии сначала компрометируется конкретный управляющий узел организации, а затем доверенный механизм взаимодействия внутри сети используется для дальнейшего распространения атаки.
Содержание
Когда доверенный узел становится источником угрозы?
Управляющим системам обычно предоставляют широкие сетевые полномочия. Им необходимо подключаться к подконтрольным узлам, передавать настройки, распространять обновления и получать служебную информацию.
Такая связность оправданна, пока управляющий сервер действует легитимно. Но после его компрометации те же разрешения становятся потенциальными маршрутами распространения атаки.
Упрощённо сценарий можно представить так:
Компрометация ViPNet Administrator
→ отправка поддельного обновления
→ выполнение кода на доступных узлах
→ разведка внутренней сети
→ дальнейшее перемещение
Исследователи кампании HelloNet обнаружили на заражённых системах загрузчик HelloInjector, прокси и загрузчик дополнительных модулей HelloProxy, средство исполнения команд HelloExecutor и модуль очистки журналов HelloCleaner. Злоумышленники собирали данные о сетевых настройках, пользователях, группах и установленных компонентах ViPNet, а также создавали туннели к внешней управляющей инфраструктуре.
Это означает, что после первоначального заражения атакующий получает не только возможность выполнять код на одном компьютере. Он может исследовать окружение, использовать заражённый узел как прокси и искать пути к другим системам.
В этот момент инцидент перестаёт быть только проблемой уязвимой версии программного обеспечения. Он становится задачей анализа всей сетевой связности вокруг потенциально скомпрометированного узла.
Главный вопрос — не только «какие узлы заражены?»
Поиск вредоносных файлов, анализ журналов и подтверждение компрометации относятся к задачам антивирусов, EDR, SIEM и команды расследования.
Но после обнаружения потенциально скомпрометированного узла возникает другой вопрос:
До каких критичных активов злоумышленник может добраться из этой точки?
Ответ не всегда очевиден.
Путь может проходить через несколько маршрутизаторов и межсетевых экранов. Адреса могут изменяться с помощью NAT. На разных участках могут использоваться виртуальные контексты, VRF и политики разных производителей.
Прямого доступа к критичной системе может не быть, но атакующий способен сначала перейти на промежуточный сервер, использовать известную уязвимость и уже оттуда продолжить движение.
Поэтому оценивать последствия компрометации только по расположению заражённого компьютера недостаточно. Необходимо учитывать действующую топологию, правила МЭ, доступные сервисы и уязвимости других активов.
Что можно проверить с помощью Netopia?
Netopia не определяет наличие вредоносного файла и не подтверждает факт реализации атаки. Её задача в таком сценарии — показать возможный сетевой радиус компрометации.
Анализ можно разделить на три последовательных этапа.
1. Проверить достижимость критичных активов
Предполагаемые скомпрометированные узлы ViPNet можно использовать как источники при проверке сетевого доступа.
В качестве назначений выбираются критичные активы организации:
- контроллеры домена;
- серверы виртуализации;
- системы резервного копирования;
- средства защиты информации;
- административные сегменты;
- системы управления сетевым оборудованием;
- значимые бизнес-системы;
- сегменты АСУ ТП.
Netopia анализирует топологию, таблицы маршрутизации, политики межсетевых экранов и NAT и определяет, существует ли сетевой путь между источником и выбранным активом.
Результат отвечает на базовый вопрос:
Может ли атакующий установить прямое сетевое соединение с критичной системой из уже скомпрометированной точки?
При этом речь идёт именно о разрешённой конфигурациями достижимости. Наличие пути не доказывает, что злоумышленник его использовал, но показывает техническую возможность такого действия.
2. Построить возможные векторы атак
Прямая связность — не единственный сценарий распространения.
Между скомпрометированным узлом и критичным активом могут находиться другие доступные системы с известными уязвимостями. После их эксплуатации атакующий получает новую точку присутствия и продолжает движение.
Такой путь может выглядеть следующим образом:
Скомпрометированный узел ViPNet
→ доступный прикладной сервер
→ известная уязвимость
→ административный сегмент
→ критичный актив
Netopia позволяет построить векторы атак с учётом сетевой доступности, используемых портов и известных уязвимостей активов.
Это помогает обнаружить многошаговые сценарии, которые не видны при обычной проверке соединения между двумя адресами.
Результат анализа отвечает на второй вопрос:
Существуют ли промежуточные уязвимые узлы, через которые атакующий потенциально может приблизиться к критичному активу?
Расчёт вектора атаки также не подтверждает, что описанная цепочка уже реализована. Он показывает возможный сценарий на основании известных системе данных.
3. Определить разрешающие правила
После обнаружения прямого пути или многошагового вектора необходимо понять, за счёт каких настроек сети он существует.
Для каждого участка Netopia позволяет определить:
- через какие устройства проходит трафик;
- какие правила межсетевых экранов его разрешают;
- какие источники, назначения и сервисы указаны в правилах;
- какие группы сетевых объектов используются;
- существуют ли альтернативные маршруты к тому же активу.
Например, анализ может показать, что путь от управляющего узла к серверному сегменту обеспечивается правилом с широким источником:
VIPNET_MANAGEMENT_NET
→ SERVER_NETWORKS
→ ANY
→ ALLOW
Само наличие такого правила ещё не означает ошибку. Доступ может быть необходим для штатной работы инфраструктуры. Но теперь специалисты ИБ, сетевые инженеры и владельцы систем видят связь между потенциальным сценарием атаки и конкретной конфигурацией МЭ.
Netopia показывает путь, но не принимает решение
На основании анализа Netopia не должна автоматически рекомендовать удалить или изменить конкретное правило.
Сетевой доступ может быть связан с критичным бизнес-процессом, системой управления или обязательным взаимодействием между компонентами ViPNet. Автоматическое закрытие такого соединения способно вызвать собственный инцидент.
Задача системы — предоставить проверяемые данные для принятия решения:
- Какие узлы считаются потенциально скомпрометированными?
- Какие критичные активы доступны из этих точек напрямую?
- Какие многошаговые векторы возможны с учётом известных уязвимостей?
- Какие правила МЭ обеспечивают найденные пути?
- Какие системы и бизнес-процессы могут быть затронуты при изменении доступа?
После этого владельцы инфраструктуры могут определить, какие взаимодействия действительно необходимы, какие следует дополнительно контролировать, а какие допустимо временно ограничить.
После внесения изменений расчёт можно выполнить повторно и проверить, исчез ли нежелательный путь.
Общий подход к реагированию
Для подобных инцидентов можно сформулировать следующий порядок действий:
- Средствами EDR, SIEM и расследования определить подтверждённые или предполагаемые точки компрометации.
- Выделить перечень критичных активов организации.
- Проверить прямую сетевую достижимость от скомпрометированных узлов.
- Построить возможные векторы атак с учётом известных уязвимостей.
- Определить правила межсетевых экранов, обеспечивающие найденные пути.
- Передать результаты сетевым инженерам, специалистам ИБ и владельцам систем.
- Принять решение о сохранении, дополнительном контроле или временном ограничении доступов.
- После изменения конфигурации повторить анализ.
Параллельно необходимо выполнить рекомендации производителя: обновить ViPNet Client и ViPNet Administrator до исправленных версий, проверить остальные узлы сети на использование устаревшего ПО и искать признаки заражения. ИнфоТеКС также рекомендует обращать внимание на подозрительную сетевую активность от узлов ViPNet в сторону координаторов и других элементов инфраструктуры.
Что показывает этот инцидент?
Кампания вокруг ViPNet демонстрирует общий принцип: доверенность системы не должна означать неограниченную сетевую достижимость.
Управляющий узел, сервер обновлений или средство защиты может быть необходимым и легитимным компонентом инфраструктуры. Но после его компрометации разрешённые ему соединения становятся частью потенциального пути атаки.
Поэтому реагирование не должно заканчиваться поиском заражённых файлов и установкой исправлений. Необходимо также определить, что доступно атакующему из захваченной точки и какие настройки сети создают эту возможность.
В таком сценарии Netopia отвечает на три конкретных вопроса:
До каких критичных активов существует сетевой доступ?
Какие векторы атак возможны с учётом известных уязвимостей?
Какие правила межсетевых экранов обеспечивают эти пути?
Это позволяет перейти от общей оценки угрозы к анализу конкретной инфраструктуры — без автоматических решений за заказчика, но с данными, необходимыми для быстрого и обоснованного реагирования.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
