Цепочка из трёх уязвимостей нулевого дня в Ivanti Connect Secure обошла защиту VPN

В начале октября 2026 года исследователи компании Volexity обнаружили атаку на корпоративные VPN-шлюзы Ivanti Connect Secure, в которой злоумышленники использовали не одну, а сразу три ранее неизвестные уязвимости, связанные в единую цепочку. Комбинация дала атакующим возможность выполнять произвольный код с правами root на полностью пропатченных устройствах — то есть обходя все выпущенные ранее исправления. 13 октября Ivanti закрыла две из трёх дыр, а CISA (Агентство кибербезопасности и защиты инфраструктуры США) включило уязвимость в каталог активно эксплуатируемых угроз (KEV), установив федеральным ведомствам срок на патч до 16 октября. История показательна тем, что демонстрирует, насколько изощрённее стали атаки на периметровые устройства за последние пару лет — и насколько недостаточно разового патча, когда в цепочке остаётся непочиненное звено.

Как устроена цепочка из трёх уязвимостей

По данным Volexity, атака строится на трёх отдельных дефектах. Первый — обход аутентификации в скрипте welcome.cgi, второй — уязвимость произвольной записи файлов в wu.cgi; вместе они отслеживаются под идентификатором CVE-2026-104935 и позволяют выполнять код от имени служебного пользователя cgi-server, под которым работает веб-интерфейс устройства. Третий компонент цепочки — уязвимость повышения привилегий, связанная с тем, как служебный процесс dsinvoked доверяет данным конфигурации DSCache: именно она поднимает права с уровня cgi-server до root. Ivanti уже выпустила исправления для первых двух звеньев в версиях 25.1.1.2, 25.1.3.0, 25.1.3.1 и 22.8R2.5, а патч для уязвимости повышения привилегий, по данным Volexity, всё ещё готовится — то есть формально цепочку нельзя считать полностью закрытой даже после обновления. Под угрозой находились версии Connect Secure 22.8R2.4 и более ранние, 25.1.2.2 и более ранние, а также 25.1.1.1 и более ранние.

Кто стоит за атакой и когда она началась

Активность связывают с группой, которую Volexity отслеживает под обозначением UTA0576. Сами исследователи оценивают атакующих как, вероятно, финансово мотивированную группировку, а не государственного актора, хотя и с невысокой степенью уверенности в этой оценке. Источники расходятся в датировке начала эксплуатации: Volexity указывает на 3 октября, тогда как независимая группа мониторинга Defused сообщила о первых признаках использования CVE-2026-104935 уже с 1 октября. Ни Ivanti, ни Volexity не раскрыли точное число пострадавших организаций: Volexity подтвердила как минимум одну жертву, а сама Ivanti охарактеризовала масштаб эксплуатации как «ограниченное число клиентов», не уточняя цифры.

Почему атаку было так сложно заметить

Отдельного внимания заслуживает то, как атакующие заметали следы. UTA0576 не устанавливала постоянный вредоносный код или веб-шелл на взломанных устройствах — вместо этого при каждой необходимости выполнить команду группа заново прогоняла всю трёхзвенную цепочку эксплойтов. По данным Volexity, атакующие также подменяли библиотечный код Ivanti прямо в оперативной памяти устройства и затем восстанавливали исходные данные конфигурации, из-за чего штатный инструмент проверки целостности системы Ivanti — Integrity Checker Tool — не фиксировал никаких модификаций. Это существенно отличает инцидент от более ранних атак на тот же класс устройств, где защитники обычно могли опираться на сам факт обнаружения изменений файловой системы как индикатор компрометации.

Что атакующие делали после проникновения

Получив root-доступ, UTA0576 переходила к сбору учётных данных внутри сети жертвы. Volexity обнаружила у атакующих самописный инструмент на Python, использующий протокол LDAP: он аутентифицировался на внутреннем контроллере домена под служебной учётной записью, которая принадлежит самому VPN-устройству, и затем искал в Active Directory пароли локальных администраторов, хранящиеся через механизм LAPS, ключи восстановления BitLocker и атрибуты с паролями в открытом виде. То есть захват VPN-шлюза рассматривался атакующими не как конечная цель, а как плацдарм для горизонтального перемещения и массового сбора секретов внутри корпоративной сети — классическая логика атак через периметровые устройства, которая в данном случае была реализована заметно аккуратнее обычного.

Что это значит для администраторов

Для организаций, использующих Ivanti Connect Secure, ситуация требует двух шагов, а не одного. Установка октябрьских патчей закрывает возможность первоначального проникновения через welcome.cgi и wu.cgi, но поскольку уязвимость повышения привилегий в dsinvoked на момент публикации патча ещё не устранена, сам факт обновления не гарантирует, что устройство нельзя скомпрометировать полностью. Учитывая, что атакующие умеют маскировать изменения от штатного Integrity Checker Tool, разумной мерой для организаций с признаками компрометации выглядит не только обновление, но и смена учётных данных, которые использовались сервисным аккаунтом устройства для подключения к домену, а также проверка журналов LDAP-запросов на предмет аномальной активности. История с Ivanti в очередной раз подтверждает тенденцию последних лет: периметровые VPN- и SSL-шлюзы остаются одной из самых привлекательных целей для атакующих именно потому, что они по определению доступны из интернета и при этом обладают высокими привилегиями внутри внутренней сети.