пятница, 17 июля 2026 г.

Сети с ViPNet под атакой HelloNet: инженерный разбор и чек-лист защиты от EDR до SOC

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

Давайте разберём инцидент так, как его стоит разбирать инженеру, а не пресс-службе. Кампанию назвали HelloNet, за ней стоят группы кибершпионажа TA428 и BlueTraveller, а вскрыли её Kaspersky GReAT и Positive Technologies ESC. Причем никаких эксплойтов нулевого дня здесь нет. Атакующие взяли штатный транспорт MFTP, абсолютно легальный конвейер доставки обновлений, и заставили его разносить бэкдоры по сети, по аналогии как в Москве сделали выделенную полосу для спецтранспорта.

Главный вывод вынесу в первую строку, чтобы дальше только обосновать его.

Слово «защищённый» на сертифицированной коробке не отменяет законов многоэшелонированной защищенной архитектуры, а «доверенный» узел внутри СЗИ это не «безопасный» узел. Это просто узел, за которым вы перестали следить. И тут выяснилось что принцип, доверяй но проверяй - вечно жив. 

Что именно произошло

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

В 2021 году специалисты Solar JSOC CERT впервые зафиксировали атаку через инфраструктуру ViPNet. Схему они описали - она была изящной. Злоумышленники слали пакет, имитирующий обновление, внутри лежали легитимный Lha.exe и подменённая библиотека Unlha32.dll. ViPNet честно проверял подпись запускаемого EXE, но не проверял всю цепочку, которую этот EXE тянул за собой. Подписанный процесс загружал чужую DLL через технику DLL Hijacking, и дальше код исполнялся уже от имени доверенного компонента.

В апреле 2025 года Лаборатория Касперского описала новый бэкдор, который снова маскировался под обновление ПО ViPNet и распространялся через тот же MFTP. Другие артефакты, та же идея.

В мае 2026 года началась кампания, которую сегодня знают как HelloNet. По данным Positive Technologies, активность держалась минимум с 1 июня по 14 июля и затронула не менее восьми организаций, а Kaspersky фиксирует её среди предприятий госсектора, промышленности, энергетики, транспорта, логистики и образования

Механика 2026 года выглядит так. По протоколу MFTP между узлами уходит специально сформированный конверт с расширением .ctl. Внутри лежит вредоносная библиотека wtsapi32.dll. Её подхватывает исполняемый файл Itcsrvup64.exe, штатный компонент службы обновления ViPNet, через всё тот же DLL Hijacking. А кладётся эта библиотека в системный каталог обновления через уязвимость обработки относительных путей, то есть через Path Traversal:

C:\ProgramData\InfoTeCS<9-значный_ID_устройства>\...\...\...\program files (x86)\infotecs\vipnet update system\wtsapi32.dll

Раньше Path Traversal был не нужен: вредонос уже лежал внутри подготовленного пакета. Теперь конверт умеет записать файл прямо в чужую доверенную папку, а доверенный компонент ViPNet сам его и запускает. Это и есть новое поколение той же атаки.

На заражённых узлах нашли загрузчик Donnect и бэкдор ShadowRelay (файл Diagnosis.exe). Последний маскируется под службу с описанием OneDrive client application. Вдумайтесь в этот троллинг от хакеров. Внутри самого импортозамещённого, самого сертифицированного стека страны имплант носит костюм Microsoft OneDrive и стучится на внешний командный сервер. Отдельный компонент из майского эпизода, SetupCheck.dll с напарником SetupChk.exe, изучал систему и подчищал журналы, готовя следующий конверт для распространения.

Атрибуция здесь важнее любой технической детали. TA428 и BlueTraveller это не шифровальщики за биткоины, а группы кибершпионажа, которые целятся на страны СНГ с 2021 года. И в теории и тем более в практике построения защиты мы постоянно должны контролировать риск, что в ядре защищённых сетей российского госсектора живёт APT группировка и ходит по доверенным туннелям как у себя дома. 

И сразу оговорю то, что я не бросаю камень в ИнфоТеКС. Злоупотребление доверенным механизмом обновления и DLL Hijacking это целый класс атак, на котором горели все, от SolarWinds до 3CX. Проблема отраслевая, а не про «плохого вендора». К чести коллег, уязвимость закрыли быстро, выпустили фикс-версии и YARA-правила. Пресс-релиз тут. Явно архитектурная тонкость появилась не намеренно. Такие были, есть и будут в ИТ инфраструктуре у любого вендора.

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

Почему это вообще стало возможно

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

Подпись проверяет происхождение, а не поведение

Сравните два эпизода. В 2021 году подписанный Lha.exe тянул подменённую Unlha32.dll. В 2026 году подписанный Itcsrvup64.exe тянет подменённую wtsapi32.dll. Пять лет, одна и та же ошибка оценки уровня доверия: проверяется подпись основного осполняемого файла, но не всей цепочки исполнения в виде подгружаемых динамических библиотек. Неполная проверка подписи у исполняемого кода - это имитация бурной деятельности в кибербезопасности. Она успокаивает аудитора и не мешает атакующему. Это как проверка бейджиков на мероприятиях: да беджик верный, но следующий этап, что бейджик именно ваш - почему-то пропускается.

Механизм обновления любого СЗИ это легальный канал удалённого выполнения кода

Служба доставки обновлений по своей природе представляет собой конвейер, который приносит на узел произвольный код и запускает его с правами SYSTEM. Годами рынок убеждали, что канал безопасен за счёт цифровой подписи. Как только атакующий получает контроль над узлом управления, то конвейер мгновенно превращается в оружие поражения всей сети, и ему не нужны уязвимости нулевого дня на клиентах. Один захваченный узел ViPNet Administrator или других систем управления это кнопка автоматического заражения всех, кто ему доверяет.

Государственная криптография умеет работать против защитника

Мы привыкли считать шифрование по ГОСТ внутри сети абсолютной гарантией. Да, но у каждой медали есть обратная сторона. Зашифрованный туннель идеально прячет и перемещение вредоносных библиотек, и трафик командного сервера от внешних сенсоров обнаружения вторжений. Ваши дорогие NGFW и IPS на периметре видят лишь зашифрованный трафик и вынуждены его пропускать. Инспекцию нужно ставить внутри защищенного контура, там, где уже расшифровали поток данных.

Трансграничное доверие убивает изоляцию периметра

Можно потратить сотни миллионов на круглосуточный SOC и межсетевые экраны нового поколения, и всё это рухнет из-за одного "доверенного" стыка по СМЭВ с региональной поликлиникой или постоянным подрядчиком. Легальный межсетевой туннель открывает прямую дорогу вредоносному конверту из слабой чужой инфраструктуры в ваше защищённое ядро. Вашу сеть взломают через самого невнимательного администратора на стороне самого слабого партнёра. Сам ИнфоТеКС фактически подтверждает эту модель, когда советует проверять заражение даже тем, кто отвечает за свою сеть, но не может гарантировать безопасность связанных сетей.

Что делать: инженерный чек-лист

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

Шаг 1. Вывести СЗИ из слепой зоны EDR, и сделать это законно

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

Сначала юридическая часть, без неё в госсекторе никак. В аттестованной ГИС нельзя менять конфигурацию СЗИ в обход регламента, это нарушение, а не смелость. Правильный путь это пересмотр формальной модели угроз. Зафиксируйте в документе, что служба доставки обновлений представляет собой высокопривилегированный вектор удалённого выполнения кода с правами SYSTEM, а значит мониторинг самого СЗИ обязан входить в контур аттестации. Это даёт законное основание перестроить политики, не ломая нормативку. Интегратор, который отвечает «нельзя, аттестат» и ставит на этом точку, просто не хочет оформлять переаттестацию. Спрашивайте с него не за отказ, а за бездействие.

Дальше техника.

  • Сузьте белые списки. Уберите слепое доверие к каталогу \ViPNet Update System\ и к процессам обновления. Вместо полного исключения настройте контроль цепочки вызовов процесса Itcsrvup64.exe.
  • Заблокируйте DLL Sideloading. Фокус на подгрузке библиотек. Любая попытка доверенного сервиса подтянуть DLL без валидной подписи вендора должна рвать поток и изолировать узел. В этой кампании маркером была wtsapi32.dll, поднимавшая бэкдор ShadowRelay.
  • Поставьте поведенческие триггеры. Штатная служба обновления не должна порождать интерпретаторы командной строки или сторонние диагностические утилиты. Подписанный процесс, внезапно запускающий cmd или powershell, это не обновление, это инцидент.
  • Логируйте централизованно. Каждая рассылка обновления и каждый порождённый службой дочерний процесс должны уходить в SIEM. Тишина в этой точке это не признак спокойствия, а признак того, что вы её отключили.

Шаг 2. Запереть ViPNet Administrator в технологический изолятор

Атака всегда начинается с управляющего узла, потому что он и есть тот самый пульт от телевизора у хакеров. У меня есть гипотеза, что в типовом ведомстве на этой машине админ одновременно читает почту, сидит в мессенджере и правит документы. Если это это верно, то ТАК нельзя. 

  • Архитектура Jump-Host. Вынесите узел с ViPNet Administrator в глухой выделенный VLAN. Полностью закройте с него прямой выход в интернет, корпоративную почту, мессенджеры и веб.
  • Жёсткое управление сессиями. Доступ инженера только через терминальный шлюз с PAM, обязательной двухфакторной аутентификацией и записью сессии.
  • Иммунитет хоста. На управляющей станции ничего лишнего: чистая ОС, консоль управления СЗИ, агенты телеметрии. Захватить такую машину фишингом становится несоизмеримо труднее.
  • Разнесите роли. Администратор ViPNet это не локальный администратор ОС узла. Максимально лишите людей совмещённых прав, чтобы компрометация одной учётки не превращалась в контроль над всем контуром управления.
  • Применение диодов данных - отличная практика реальной безопасности в госсекторе. Вы когда-нибудь слышали про них?

Шаг 3. Резать плоские сети и ставить инспекцию за туннелем

Шифрование MFTP делает внутренний трафик непроницаемым для внешних IDS, IPS, NGFW, NTA, NDR, UEBA. МСЭ видитзашифрованный поток, а внутри летит конверт .ctl с нагрузкой.

  • Инспекция расшифрованного трафика. Сенсоры сетевого анализа обязаны стоять на внутреннем контуре строго за координаторами ViPNet, где трафик уже расшифрован. Подойдут PT Network Attack Discovery, Гарда NDR или бесплатный Zeek (не путать с Zeekr) с кастомными парсерами. Разбирать нужно чистый поток, до байта.
  • Контроль аномалий транспорта. Настройте правила на резкий всплеск рассылки управляющих конвертов от одного узла, на попытки инициировать соединения с нетипичными сегментами и на передачу объёмных файлов в нерабочие часы.
  • Нулевое доверие к смежникам. Любой стык по СМЭВ или с сетью подрядчика проводите через жёсткое шлюзование. Не контролируете чужую службу ИБ, считайте её узел потенциальным источником заражения.
  • Централизуйте раздачу обновлений. Где возможно, откажитесь от peer-to-peer распространения и разрешите обновления только из одного контролируемого репозитория. Один админ-узел не должен иметь права разослать обновление за пределы заранее очерченной области.

Шаг 4. Отнять привилегии и запустить активный хантинг

Path Traversal работает беспрепятственно, пока процессы на узле имеют избыточные права.

  • Зачистка локальных админов. Заберите права администратора ОС у всех пользователей на рабочих станциях с клиентом ViPNet. Без уровня целостности High Integrity записать файл за пределами целевой папки и переписать системные ветки реестра куда сложнее.
  • Отлов зачистки логов. Атакующие подчищают следы. Настройте SIEM на событие очистки журнала безопасности Windows (Event ID 1102) и коррелируйте его с провалами в собственных логах ViPNet. В майском эпизоде за разведку и уборку отвечали SetupCheck.dll и SetupChk.exe.
  • Неизменяемые журналы. Критичные узлы ViPNet должны писать логи на централизованный write-once лог-сервер. Тогда локальная зачистка на узле не стирает историю, и ретроспективное расследование остаётся возможным.
  • Сплошной YARA-скан. Прогоните память и файловые системы всех узлов официальными правилами от Positive Technologies и Лаборатории Касперского, нацеленными на Donnect и ShadowRelay.

Быстрая охота: с чего начать сегодня

Если нужно проверить свои узлы, не дожидаясь большого проекта, начните с малого. Простая команда PowerShell ищет и подложенную библиотеку, и характерный след Path Traversal в каталоге MFTP:

Get-ChildItem -Path "C:\ProgramData\Infotecs\Mftp" -File -Recurse | Select-String -Pattern ".dll|./../../../"

Держите под рукой сетевые индикаторы. Обнаруженный экземпляр ShadowRelay стучался на 154.89.152.59 по порту 443, регистрировался как служба svcsvc с описанием OneDrive client application и шифровал канал по AES. Любой из этих признаков на узле ViPNet это повод для немедленной изоляции и обращения в TI-команду.

И обновляйтесь, но с умом. ИнфоТеКС выпустил фикс-версии: ViPNet Client 4 до сборки 65211 в сертифицированной ветке и до 24733 в релизной, ViPNet Administrator до 4.6.11.5113 и выше. Порядок действий здесь только один.

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

Диагноз

Теперь то, ради чего всё это писалось. Сертификат ФСБ подтверждает, что криптография сделана по ГОСТ и соответствует формуляру. Он никогда не проверял и не обещал проверять, устоит ли механизм обновления против целевой атаки через собственный транспорт, и тем более он ничего не говорит о том, следите ли вы за своей сетью. Это разные векторы. Ошибается не регулятор, ошибается тот, кто прочитал класс защищённости как «нас не пробьют».

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

И вот и диагноз, и он мне не нравится. Шесть недель продолжающейся кампании HelloNet вскрыли не пострадавшие, а Kaspersky GReAT, Positive Technologies ESC и Solar JSOC, то есть команды топовых экспертов. Как сделать так, чтобы хоть один SOC жертв поймал это сам и оповестил всех об угрозе? Если мы добьемся этого, то иммунная система целой отрасли сегодня это уже не текущие три-четыре сильных команды экспертов. И спасибо им: если бы они не опубликовали отчёты, вы бы прямо сейчас оставались вскрыты и не знали об этом. Уровень собственной киберустойчивости в госсекторе и КИИ, вот настоящая тема для разговора, а не конкретный баг в конкретной сборке. Ну а я лично продолжаю обучать экспертов в своем блоге и телеграм канале Топ Кибербезопасности Батранкова.

Сухой остаток

Безопасность инфраструктуры измеряется не классом в сертификате, а способностью вашей команды видеть действия каждого системного процесса, включая процессы самой системы защиты. «Доверяй, но проверяй» нужно для любого софта с правами SYSTEM, даже если на его коробке стоит гербовая печать. Как только средство защиты объявляется непогрешимым ядром, оно перестаёт быть вашей крепостью и становится главной мишенью для разведки противника.

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