CISA внесла в каталог KEV ещё две уязвимости Ivanti Connect Secure, CVE-2026-111357 и CVE-2026-118527. Вместе с обходом аутентификации CVE-2026-104935 они дают root на VPN-шлюзе без пароля. Взлом Ivanti Connect Secure в этой кампании закончился не веб-шеллом, а кражей учётных данных, метаданных Active Directory и поиском ключей BitLocker.

Коротко

• В пятницу, 30 октября, CISA добавила в KEV две уязвимости Ivanti Connect Secure: CVE-2026-111357 (CVSS 8,8) и CVE-2026-118527 (CVSS 4,3).
• Обе входят в цепочку, которую Volexity описала в октябре. Вместе с обходом аутентификации CVE-2026-104935 (CVSS 8,6, в KEV с 13 октября) они дают выполнение кода с правами root без учётных данных.
• Атаки Volexity приписывает ранее неизвестной группе UTA0576. Веб-шеллы группа не ставила. Она забирала учётные данные и метаданные AD, а также искала пароли администраторов и ключи восстановления BitLocker.
• Всю цепочку закрывают сборки 25.1.1.3 и 22.8R2.6. Патча только на CVE-2026-104935 или июльского релиза 25.1.3.0 недостаточно, чтобы считать шлюз защищённым.
• Федеральным ведомствам США дали срок до 2 ноября для CVE-2026-111357 и до 13 ноября для CVE-2026-118527.

Почему root на VPN-шлюзе уже инцидент в домене?

Шлюз удалённого доступа не просто пропускает трафик. Через него проходят логины сотрудников, он обращается в Active Directory для проверки учёток и держит сессии. Кто получил на нём root, видит всё, что видит шлюз, и может вынести это наружу.

Ivanti Connect Secure стоит на периметре и доступен из интернета. Цепочке, которую описала Volexity, пароль не нужен: атакующему достаточно сетевого доступа к шлюзу. В итоге его код выполняется с правами root на устройстве.

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

Из каких трёх CVE складывается путь без пароля?

Цепочка состоит из обхода аутентификации, записи файла и повышения привилегий, и каждое звено снимает барьер, который оставило предыдущее. Volexity описывает итог так: обход аутентификации, удалённое выполнение кода и повышение привилегий вместе дают «выполнение кода с правами root без аутентификации».

CVE	CVSS	Класс ошибки	Роль в цепочке
CVE-2026-104935	8,6	Обход аутентификации	Вход без учётных данных; в KEV с 13 октября
CVE-2026-118527	4,3	Предсказуемые числа и идентификаторы	Атакующий записывает файл с контролируемым содержимым в известное место на диске; это даёт выполнение кода
CVE-2026-111357	8,8	Нет аутентификации для критической функции	Локальное повышение привилегий до root

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

Отсюда главный урок про CVSS: оценки звеньев не складываются и ничего не говорят об опасности цепочки целиком. CVE-2026-118527 с оценкой 4,3 во многих процессах патч-менеджмента ушла бы в конец очереди. На деле именно она превращает обход входа в выполнение кода. Фильтр обновлений по порогу «7,0 и выше» её бы пропустил.

Что UTA0576 забирал после взлома Ivanti Connect Secure?

Root на шлюзе UTA0576 использовал не для закрепления, а для сбора секретов. Группа выгружала учётные данные и ограниченный набор метаданных Active Directory, изучала хост, искала пароли администраторов и ключи восстановления BitLocker. Название группе дала Volexity, раньше публичных отчётов о ней не было.

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

Метаданные AD служат картой домена: какие есть учётки и группы, где сидят администраторы. Учётные данные со шлюза дают доступ к этой карте. Дальше атакующему удобнее работать через обычный VPN-вход под чужим именем, а такую активность трудно отличить от работы сотрудника.

С ключами BitLocker отдельная история. Active Directory умеет хранить ключи восстановления в объектах msFVE-RecoveryInformation, привязанных к учёткам компьютеров. Без доступа к диску ключ бесполезен, но с украденным ноутбуком, образом диска или доступом к виртуальной машине он снимает шифрование. Похоже, группу интересовал не только сам шлюз, но и данные на устройствах компании, хотя ключи могли собирать и про запас.

Сколько шагов отделяет учётку, украденную на периметре, от администратора домена, показывает пентест Active Directory.

Хватит ли июльского 25.1.3.0 и патча на обход входа?

Не хватит. Ориентируйтесь на сборки, которые Ivanti называет закрывающими цепочку: 25.1.1.3 для ветки 25.1.1.x и 22.8R2.6 для ветки 22.8R2.x. Уязвимы версии 25.1.1.2 и ниже, а также 22.8R2.5 и ниже.

Путаница возникла из-за порядка раскрытия. Когда Ivanti узнала об эксплуатации, исправление CVE-2026-104935 уже проходило QA для поддерживаемых версий. Повышение привилегий обнаружили позже, и компания решила не задерживать патч, закрывающий основной путь эксплуатации. Поэтому 13 октября в KEV попал только обход аутентификации, а два других звена добавили через 17 дней.

Решение разумное: исправление обхода входа обрывает цепочку на первом шаге для внешнего атакующего без учётки. Но команды, которые закрыли октябрьскую запись KEV, могли счесть вопрос решённым, хотя запись файла и повышение привилегий оставались открыты. Любой, у кого уже была сессия (украденный пароль, скомпрометированный сотрудник), мог пройти остаток пути до root.

Июльский релиз 25.1.3.0 добавляет путаницы. Номер у него выше, чем у октябрьской 25.1.1.3, но это отдельная линейка релизов, а не продолжение ветки 25.1.1.x. По словам Ivanti, часть уязвимости компания нашла сама, через собственную программу безопасности продукта, и закрыла её в 25.1.3.0. Бэкпорт исправления на другие поддерживаемые ветки ещё шёл, когда начались атаки.

Какую именно часть закрыл июльский релиз, Ivanti не уточнила. Зато, по словам компании, последний выпуск закрывает все уязвимости, которые злоумышленники связали в цепочку и использовали в атаках. Сверяйте номер сборки со свежим бюллетенем, а не с датой последнего обновления.

Почему VPN-шлюзы раз за разом становятся точкой входа?

Для атакующего это почти идеальная цель. Устройство открыто в интернет, домен ему доверяет, EDR на нём обычно нет, а обновляют его редко в день выхода патча. У Ivanti Connect Secure уже был похожий случай: в конце 2023 и начале 2024 года исследователи, включая Volexity, описали связку CVE-2023-46805 (обход аутентификации) и CVE-2024-21887 (внедрение команд), которая тоже позволяла выполнять команды без входа.

Тогда CISA выпустила экстренную директиву ED 24-01, а позже потребовала от федеральных ведомств временно отключить уязвимые продукты Ivanti. Урок той истории простой: когда пограничный шлюз атакуют, патч закрывает дверь, но не доказывает, что внутрь никто не заходил. Похожую картину мы разбирали на примере Citrix NetScaler, где уязвимость эксплуатировали и после патча.

Из практики. На внешних пентестах периметра мы раз за разом видим у VPN-шлюзов три одинаковые проблемы. Первая: шлюз ходит в AD под сервисной учёткой с правами шире, чем нужно для проверки пароля. Вторая: журналы лежат только на самом устройстве и перезаписываются за несколько дней, так что к началу расследования их уже нет.

Третья: шлюз числится сетевым оборудованием, и обновляет его не та команда, которая читает бюллетени безопасности. Чтобы увидеть свой периметр глазами атакующего, начните с внешнего пентеста сети.

Что спросить у админов до 2 ноября?

Ведомства FCEB должны закрыть CVE-2026-111357 до 2 ноября, через три дня после внесения в KEV, а CVE-2026-118527 до 13 ноября. Эти даты юридически не касаются компаний вне США. Но CISA вносит в каталог только уязвимости, которые уже применяют в атаках, так что KEV помогает отличить по-настоящему срочное среди тысяч CVE с похожими оценками.

Вот вопросы, которые стоит задать администраторам:

1. Какая сборка стоит прямо сейчас? Сверьте точный build в консоли с бюллетенем Ivanti: нужны 25.1.1.3 или 22.8R2.6 и новее. Обновление не завершено, пока устройство не перезагрузилось на целевую версию.
2. Сохранены ли журналы? До обновления выгрузите журналы User Access, Admin Access и System, а также конфигурацию. Обновление и перезагрузка могут стереть то, что понадобится для расследования.
3. Был ли шлюз доступен из интернета в октябре на уязвимой сборке? Если да, исходите из того, что могли утечь учётные данные, прошедшие через шлюз, пароли администраторов и ключи BitLocker, доступные его сервисной учётке.
4. Что искать в журналах? Не только файлы. Следы такой кампании скорее найдутся в аутентификации: входы администраторов в необычное время, обращения шлюза к AD сверх обычного объёма, VPN-учётки, которые после октября начали входить с новых адресов.
5. Как менять секреты? Меняйте пароли с заведомо чистого устройства. Начните с сервисной учётки шлюза и администраторов, завершите активные VPN-сессии и сессии администраторов, проверьте, не появились ли новые участники в привилегированных группах. Перезагрузка шлюза сама ничего не отзывает.
6. Где взять индикаторы? В публикациях, на которых основан этот материал, IOC нет. Берите их из рекомендаций Ivanti и Volexity и запустите штатную проверку целостности устройства. Если одна проверка ничего не нашла, взлом от этого не исключён.

Чего пока не знаем

Неизвестно, сколько шлюзов взломали, в каких странах и отраслях находятся пострадавшие и кто стоит за UTA0576: привязки группы к стране в открытом разборе нет. Нет и данных о том, когда именно начались атаки и пользовалась ли группа украденными учётками, чтобы продвигаться дальше по сети.

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

Частые вопросы

Какие версии Ivanti Connect Secure закрывают цепочку UTA0576?

Ivanti называет закрывающими цепочку сборки 25.1.1.3 (вместо 25.1.1.2 и ниже) и 22.8R2.6 (вместо 22.8R2.5 и ниже). По словам компании, последний релиз закрывает все звенья, которые использовали в атаках.

Можно ли считать шлюз безопасным, если стоит только патч CVE-2026-104935?

Нет. Этот патч закрывает вход без пароля, но запись файла и повышение привилегий остаются доступны тому, у кого уже есть сессия, например по украденной учётке.

Нужно ли компаниям в РФ и СНГ ориентироваться на дедлайны CISA?

Юридически нет: сроки 2 и 13 ноября обязательны только для федеральных гражданских ведомств США. Но они показывают, насколько срочным CISA считает исправление уязвимостей, которые уже используют в атаках.

Стоит ли менять пароли, если вредоносных программ на шлюзе не нашли?

Да, если шлюз был доступен из интернета на уязвимой сборке. UTA0576 как раз не оставляла вредоносных программ, а забирала учётные данные, поэтому чистое устройство не доказывает, что секреты не утекли.

Есть ли публичные IOC и число взломанных шлюзов Ivanti?

В открытых публикациях нет ни индикаторов, ни числа пострадавших, ни страновой атрибуции. Индикаторы берите из рекомендаций Ivanti и Volexity.

Если ваш VPN-шлюз давно никто не проверял глазами атакующего, команда HirexTech проведёт симуляцию целевой атаки от периметра до домена и покажет, на каком шаге цепочка оборвётся, а где пройдёт насквозь.