Вы когда-нибудь слышали о NetScaler ADC или Gateway? Если вы работали в крупных организациях, то почти наверняка — да.

Это «железная коробка», а позднее уже и «виртуальная коробка» (так называемый Appliance, т. е. развертываемый образ виртуальной машины, который требует для старта минимальной конфигурации на стороне клиента), которая предназначена для «доставки» веб-приложений пользователям (Application Delivery Controller, или сокращенно ADC), защиты веб-приложений (Web Application Firewall, WAF), балансировки нагрузки (Load Balancer, LB), а также может использоваться как инструмент для добавления аутентификации, авторизации и аудита в существующие веб-приложения (Authentication, Authorization, and Accounting, или просто AAA) и даже как шлюз доступа в корпоративную сеть (Gateway, используется для организации виртуальных рабочих столов через широко известный стек продуктов под названием Citrix Virtual Desktop Infrastructure, или просто Citrix VDI).

Хотя есть много свободных альтернатив для доставки веб-приложений и балансировки нагрузки, NetScaler продолжает пользоваться популярностью в корпоративном сегменте. Добавить доменную (на базе Active Directory) аутентификацию в веб-приложение без правки кода? Пожалуйста, это несколько настроек. Обеспечить умную балансировку, когда один и тот же клиент (речь про клиент протокола HTTP, т. е. браузер) всегда попадает на один и тот же бэкенд (веб-сервер)? Одна галочка в настройках, и больше не надо синхронизировать состояние между бэкендами (и пользователя больше не «выкидывает» из какого-нибудь личного кабинета, если вдруг второй бэкенд еще не знает, что аутентификация и авторизация пройдены на первом бэкенде).

В качестве продукта для организации удаленного доступа работников это хорошая альтернатива для решений корпорации Microsoft: Remote Desktop Protocol (RDP) и Remote Desktop Gateway (RDG) — пользователи могут использовать одноразовые и многоразовые виртуальные машины (в зависимости от настроек и прав), а также «запускать» лишь одно рабочее приложение (например, почтовый клиент или браузер с доступом к интранету, без необходимости работы в полноценной терминальной сессии: пользователь получает окно с нужным приложением и ничего лишнего).

Рис. 1: Интерфейс входа в виртуальные рабочие столы у одной российской компании (доменное имя, логотипы и цвет удалены, чтобы никого не обидеть, но знайте, что таких точек входа много, т. к. средние и
Рис. 1: Интерфейс входа в виртуальные рабочие столы у одной российской компании (доменное имя, логотипы и цвет удалены, чтобы никого не обидеть, но знайте, что таких точек входа много, т. к. средние и крупные бизнесы любят Citrix VDI)

Если просканировать Рунет на наличие NetScaler, такие устройства часто встречаются в следующих сегментах: операторы связи, банки, «нефтегаз» и даже «госы».

Вайб нулевых

NetScaler как продукт появился в конце 90-х, потом его купила компания Citrix, а сейчас, после слияния, вендор называется Cloud Software Group.

При изучении вопросов кибербезопасности, нередко возникающих уже после внедрения NetScaler, возникает ощущение, что код продукта пришел к нам прямо из какого-нибудь 2004 года. Ну или около того.

Простая иллюстрация: NetScaler является частым гостем в каталоге Known Exploited Vulnerabilities (KEV) [1]. По состоянию на первую половину июня 2026 года в каталоге есть (за все время) 12 уязвимостей, эксплуатация которых была зафиксирована «в дикой природе», из них 3 использовались для распространения шифровальщиков. В действительности уязвимостей гораздо больше, просто не все фиксируются в реальных атаках (не все эксплуатируются в реальных атаках и не все реальные атаки «берут на карандаш»).

Так, одна из трендовых уязвимостей (из тех, что использовались в атаках шифровальщиков), CitrixBleed 2 (CVE-2025-5777) — это банальная запись неинициализированного содержимого байтов из стека в ответ на специально сформированный запрос от клиента [2], что позволяет прочитать то, что должно быть скрыто от чужих глаз (содержимое чужой куки, идентификаторы сессий и т. п.). Это именно то, что с некоторой долей иронии именуют C mistake (ошибка, которой не было бы, если бы код был не на языке Си).

Ко всему этому нужно добавить, что NetScaler в исполнениях VPX («виртуальная коробка») и MPX («железная коробка») функционируют на базе старой версии операционной системы FreeBSD (11.4), где нет ряда митигаций — например, Address Space Layout Randomization (ASLR).

Эксплуатация «бинарных» уязвимостей здесь — это подлинный вайб нулевых (к слову, в более ранних версиях NetScaler все было еще хуже: the stack was executable, address space was not randomised, there were no stack canaries [3] — но сейчас, в ветке NetScaler 14.1, защита стека все же присутствует).

Для сравнения: в решении Cisco ASA (другой класс, но природа та же: закрытая от посторонних глаз «коробка») ASLR присутствует уже много лет. Наличие большого количества потенциальных C mistakes и отсутствие современных митигаций превращают NetScaler в очень слабое звено.

Проникновение NetScaler в облако ситуацию не улучшило: облачные провайдеры (например, Google Cloud Platform) предлагают по умолчанию такую настройку NetScaler, где управляющий интерфейс (а это отдельная поверхность атаки!) доступен напрямую из Интернета (в корпоративных сетях этот интерфейс выносят в отдельную сеть, куда доступ сильно ограничен). Почему я акцентирую на этом внимание? Для аутентификации по протоколу SSH и из физической консоли в NetScaler используется собственная библиотека аутентификации pam_nsauth.so! Зачем? Если вдруг операционная система NetScaler не загрузится, то эта библиотека позволит войти в шелл (bash) с помощью логина nsrecover и пароля nsroot, но вход возможен только с физической консоли (не удаленно). Такая функция уже требует отдельной библиотеки аутентификации…

Когда я «скормил» эту библиотеку искусственному интеллекту (Claude Opus 4.6), почти сразу была найдена ошибка класса use-after-free (использование полученных от неаутентифицированного клиента протокола SSH данных после их высвобождения). Ошибку невозможно эксплуатировать (т. к. сервер протокола SSH использует в этом участке кода один поток и данные после их высвобождения ничем не меняются), но осадочек остался — аудит кодовой базы как будто не осуществляется (такая ошибка может быть замечена любым современным анализатором кода).

Но кто же проводил такой аудит в нулевых? Вот-вот, прошло почти четверть века, а у кого-то воз и ныне там.

Классификация уязвимостей

На практике уязвимости в NetScaler попадают в одну из двух категорий:

1. «Пролом» веб-приложения через уязвимость в NetScaler (например, «кража» сессии Citrix VDI позволяет зайти под чужой учетной записью в корпоративную сеть — атакующий просто получает доступ к виртуальной машине, обслуживающей чужой сеанс доступа, см. [2]).

2. Взлом самого устройства (например, атакующий загружает веб-шелл и через него исполняет код в операционной системе NetScaler, см. [3]).

Подходы к мониторингу и расследованию

Важно различать подходы к мониторингу и началу расследования: «пролом» веб-приложения через уязвимость в NetScaler требует, в первую очередь, исследования логов этого веб-приложения. В общем случае в логах следует искать признаки «угона» сессии (куки): например, внезапную смену IP-адреса источника подключения для старой сессии: был, скажем, легитимный доступ из мобильной сети в РФ, а затем IP-адрес источника подключения стал относиться к провайдеру хостинга в другой стране; другим признаком будет наличие множества сессий на одном IP-адресе источника подключения (т. е. речь идет про «угон» сразу большого числа сессий).

Понятно, что «угон» сессии тяжело отличить от ситуации, когда пользователь меняет способ подключения к Интернету: была домашняя сеть, стала мобильная, затем пользователь включил обход блокировок и получил иностранный IP-адрес, но при этом это все один и тот же пользователь (а не злоумышленник). Сложность представляют и ситуации, когда много пользователей работают с одного IP-адреса (например, из одного офиса или коворкинга).

На этих принципах строится и мониторинг «угона» сессий Citrix VDI [4][5]. Нужно заметить, что NetScaler, работающий в связке с Citrix VDI или в режиме AAA (не путать с применением в режимах WAF и LB), ведет очень подробные журналы действий на уровне приложения в директориях /var/log/ и /var/nslog/ (глубина этих логов — от нескольких часов до нескольких дней, размер — гигабайты).

Листинг 1. Строка из журнала (/var/log/ns.log*), содержащая сведения о сессии Citrix VDI (часть информации удалена)

С другой стороны, взлом самого NetScaler приводит к сложной с точки зрения расследования задаче — изучению текущего состояния устройства. Операционная система этой «коробки» базируется на FreeBSD в урезанном варианте (например, в ней отсутствует утилита stat, что усложняет сбор временных меток из файловой системы). Кроме того, содержимое части директорий существует только в оперативной памяти, а потому значительная часть действий должна фокусироваться на исследовании работающего устройства.

Один из популярных способов удаленного исполнения кода атакующего — загрузка веб-шелла в виде скрипта с расширением .php [3]. Это дает защитникам quick win, заключающийся в выявлении файлов веб-шеллов по ключевым словам в их содержимом (довольно типовая задача для тех, кто регулярно имеет дело со взломом веб-приложений) — веб-шеллы часто загружают в директории внутри /var/vpn/ и /var/netscaler/.

Примечательно, что вендор сейчас поставляет в составе NetScaler скрипт для проверки целостности файлов в директории, где может размещаться бэкдор для перехвата паролей (в виде скрипта на языке JS), — /netscaler/portal_core_checksum_check.pl. Этот скрипт не упоминается в документации, поэтому возможно, что он существует для глаз сотрудников официальной технической поддержки. Защитникам это на руку — это готовый скрипт для быстрой проверки одной гипотезы (компрометация портала LogonPoint путем установки JS-бэкдора).

Злоумышленник также может перейти к запуску собственных скомпилированных исполняемых файлов, для чего вендор предусмотрел еще одну защитную меру — проверку хешей у исполняемых файлов, портированную из операционной системы NetBSD (подсистема veriexec).

Эта проверка активна в режиме «только предупреждение» (запуск неподписанных исполняемых файлов разрешен). Утилита для проверки целостности исполняемых файлов запускается так: /netscaler/sigchk check. Разумеется, аргумент check в документации не упоминается.

Листинг 2. Пример вывода команды /netscaler/sigchk check

Другой способ найти подозрительные исполняемые файлы: поискать строку MAC/veriexec: no fingerprint или MAC/veriexec: fingerprint does not match loaded value в файлах /var/log/messages*. Правда, иногда в эти строки попадают и легитимные файлы, поэтому не надо относиться к обнаружению пары таких строк как к критическому событию (вместо этого нужно спокойно изучить каждое срабатывание).

Листинг 3. Пример записи в файле /var/log/messages

Сами манифесты, содержащие эталонные хеши, размещены в файлах по путям: /netscaler/.signedexe.manifest, /var/python/.signedexe.manifest и /var/perl5/.signedexe.manifest.

Вас удивляет такое количество незадокументированных фич, направленных на обнаружение успешного взлома устройства? Меня тоже.

Важно также забрать для дальнейшего исследования креш-дампы из директории /var/core/. Поскольку значительная часть уязвимостей NetScaler «бинарные», то неудачные попытки их эксплуатации будут оставлять за собой креш-дампы. Основное уязвимое место — движок обработки пакетов (NetScaler Packet Processing Engine, NSPPE), его исполняемый файл — /netscaler/nsppe.

Если вы рассматриваете постановку NetScaler на мониторинг событий кибербезопасности, то было бы полезно также забирать вывод команды nscli -U %%:.:. show system session. Эта команда показывает список сессий, активных в управляющем интерфейсе устройства.

Следует заметить, что NetScaler позволяет создавать административные учетные записи с разными правами доступа — вплоть до запрета выполнять в шелле (т. е. в интерфейсе nscli, не путать с шеллом операционной системы — bash) некоторые команды (это ограничение реализуется по регулярным выражениям, т. е. можно, например, запретить сетевому администратору удалять конфигурации веб-серверов, но разрешить создавать новые).

При этом особый интерес представляет встроенная учетная запись #nsinternal# (да, у нее именно такое имя). С помощью этой учетной записи один NetScaler заходит на другой NetScaler (например, это происходит в режиме High Availability, когда поступающие запросы обрабатывает пара «коробок», запросы идут на основное устройство, а запасное устройство только пингует основное несколько раз в секунду; если основное устройство перестает отвечать, запасное переводит трафик на себя и продолжает обработку). Эта учетная запись имеет права суперпользователя, а пароль к ней меняют редко (наверное, только один раз после первоначальной настройки или вообще никогда).

Если NetScaler был скомпрометирован, то злоумышленник сможет вернуться по протоколу SSH с помощью учетной записи #nsinternal#, если пароль на нее не менялся (в конфигурационном файле NetScaler ns.conf эту учетную запись обзывают как rpcNode; а деобфускатор паролей из конфигурационного файла уже давно публично доступен [6]).

Будьте особо внимательны, если вы заменяете (переустанавливаете) только один скомпрометированный NetScaler из пары High Availability. Нужно убедиться, что после замены на обоих устройствах установлен новый пароль для учетной записи #nsinternal# (этот пароль будет одинаковым на обоих устройствах).

Если вам нужно быстро собрать данные с NetScaler в связи с подозрением на компрометацию, воспользуйтесь скриптом easy_triage_fbsd.sh [7]. Не используйте другие скрипты, т. к. в них не учитываются многие внутренности работы NetScaler.

Выводы

Если вы используете NetScaler, держитесь последней версии в последней ветке. Устанавливайте обновления сразу (не позднее недели с момента выхода), следите за KEV.

Помните, что не все устраняемые уязвимости получают идентификаторы CVE (да, у компании Cloud Software Group есть такая практика). Не забывайте, что не все уязвимости описываются в уведомлениях от вендора. Не думайте, что вендор портирует исправления всех уязвимостей на предыдущие поддерживаемые ветки (например, с 14.1 на 13.1) — это не так.

Ссылки

  1. https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search=netscaler&field_date_added_wrapper=all&field_cve=&sort_by=field_date_added&items_per_page=All&url=
  2. https://labs.watchtowr.com/how-much-more-must-we-bleed-citrix-netscaler-memory-disclosure-citrixbleed-2-cve-2025-5777/
  3. https://www.assetnote.io/resources/research/finding-and-exploiting-citrix-netscaler-buffer-overflow-cve-2023-3519-part-3
  4. https://cloud.google.com/blog/topics/threat-intelligence/session-hijacking-citrix-cve-2023-4966/
  5. https://www.netscaler.com/blog/news/evaluating-netscaler-logs-for-indicators-of-attempted-exploitation-of-cve-2025-5777/
  6. https://github.com/rapid7/metasploit-framework/blob/master//modules/auxiliary/admin/citrix/citrix_netscaler_config_decrypt.rb
  7. https://github.com/msuhanov/easy_triage/blob/main/easy_triage_fbsd.sh