Критическая уязвимость CVE-2026-88771 затрагивает Citrix NetScaler ADC и NetScaler Gateway. Оба продукта компании Citrix стоят на границе корпоративной сети. Через них сотрудники подключаются к внутренним ресурсам, а сторонние пользователи попадают в опубликованные приложения. Уязвимость открывает путь к внедрению команд (передаче устройству управляющих инструкций вместо обычных данных) ещё до прохождения аутентификации. Ни логин, ни пароль атакующему для этого не нужны. NetScaler давно входит в список приоритетных целей: через него проходит трафик сотен и тысяч пользователей. Устройства этого класса нередко доступны из интернета, поэтому попытки эксплуатации стоит ждать круглосуточно. Подобные ошибки ставят под удар не одно устройство, а внутреннюю сеть организации целиком.
Описание
Производитель и независимые исследователи уже описали и саму уязвимость, и общий механизм её эксплуатации. Практический интерес представляет другое: что происходит с устройством после успешной попытки. Наблюдения за несколькими клиентскими средами показали, что атакующие редко останавливаются на проверке работоспособности ошибки. Часть попыток ограничивалась простым тестом: злоумышленник выяснял, под какой учётной записью работает устройство, и на этом прекращал действия. Другие шли дальше и почти сразу переходили к загрузке стороннего кода. Чем дольше устройство остаётся без исправления, тем выше шансы, что проверка перерастёт в полноценную атаку. В журналах аутентификации такие события выглядят необычно: вместо имени пользователя в них передаются управляющие инструкции.
По данным группы THOR компании LevelBlue, цепочка атаки развивалась последовательно. Сначала злоумышленники убеждались, что команды действительно исполняются. Затем загружали с внешних серверов дополнительные программы и запускали их напрямую, не сохраняя на диске. Далее собирали и подготавливали к отправке конфигурацию NetScaler. Завершали последовательность развёртывание обратной оболочки, закрепление в системе, установка веб-оболочки и попытка выгрузить конфигурационные данные наружу. Обратная оболочка даёт атакующему интерактивный доступ к устройству, поскольку соединение инициирует сама жертва и не попадает под входящие фильтры.
Два образца полезной нагрузки разобрали подробнее. Первый, написанный на языке Python, подменял служебный компонент устройства собственным кодом. После подмены компонент открывал соединение с внешним сервером и передавал туда всё, что вводит и выводит командная оболочка. Дополнительно скрипт завершал процессы, связанные с прежней версией этого компонента. Так подмена держалась дольше, а следы оставались менее заметными. Соединение с внешним узлом и интерактивная работа оболочки указывают, что эксплуатация зашла дальше первого шага. Любое неожиданное изменение или запуск этого компонента заслуживает отдельного разбора.
Второй образец, написанный на Perl, действовал шире. Он правил конфигурацию устройства и создавал локальную учётную запись с правами суперпользователя. Скрипт упаковывал каталог с настройками в архив и отправлял его на внешний узел, откуда пришла команда. Следом он менял права доступа к командной оболочке и ставил веб-оболочку (серверный скрипт для удалённого выполнения команд) в каталоге веб-интерфейса. Он же разрешал исполнение PHP и связывал вредоносный файл с адресами, похожими на обычные ресурсы оформления NetScaler. Веб-оболочка маскировалась под файлы стилей, которые загружает страница входа. Через неё атакующий выполнял команды, скачивал и загружал файлы. Под конец скрипт удалял архив и стирал самого себя.
Отсутствие этих файлов на диске не говорит о том, что атака провалилась. Полезная нагрузка убирает следы сразу после выполнения. Неудачная попытка входа сама по себе тоже ничего не доказывает. Сетевые журналы стоит просмотреть на предмет соединений с внешними узлами вскоре после попытки эксплуатации. Такие связи иногда остаются единственным свидетельством того, что команды всё-таки исполнились. Полезно сверить список локальных учётных записей с тем, что было раньше. Проверять нужно и события, которые предшествовали установке обновлений.
Конфигурация NetScaler описывает внутреннюю сеть: адреса серверов, правила доступа, параметры подключения к каталогам пользователей. Для атакующего это полный набор сведений об инфраструктуре. Локальная учётная запись с максимальными правами даёт постоянный доступ, даже если уязвимость закроют обновлением. Веб-оболочка оставляет возможность удалённого управления через обычный браузер. Созданные файлы лежат в открытом наружу каталоге, и заметить их непросто. Отдельная сложность в том, что они находятся рядом со штатными файлами и почти не отличаются от них по названию. Для организаций, публикующих приложения через NetScaler, это риск простоя, утечки учётных данных и дальнейшего продвижения по внутренней сети.
Первое, что нужно сделать, - установить исправления Citrix и проверить, какие версии работают на границе сети. Отдельного внимания заслуживает история событий: эксплуатация могла произойти задолго до обновления. Доступ к панели управления устройством из интернета стоит ограничить, а для администраторов включить двухфакторную аутентификацию. Мониторинг полезно настроить не только на неудачные входы, но и на записи, где в полях аутентификации появляются команды. Изменения в конфигурации, новые локальные учётные записи и неожиданные исходящие соединения с самого NetScaler - те сигналы, по которым атаку видно на ранней стадии. Если признаки компрометации найдены, устройство лучше переустановить и сменить все связанные с ним учётные данные и ключи. Инфраструктура и имена файлов у разных групп меняются быстро, а поведение остаётся узнаваемым.
