Атаки на Citrix NetScaler націлені на пристрої ADC і Gateway

Резюме

Зловмисники активно експлуатують дві вразливості нульового дня в пристроях Citrix NetScaler, щоб отримати доступ на рівні root. Кампанія включає розгортання нестандартних PHP веб-шелів, таких як WHIPSHOT, і інструмента для тунелювання на базі Python, відомого як SLAPSHOT. Ці утиліти дозволяють зловмисникам виконувати внутрішню розвідку та красти облікові дані, проксіруя трафік у захищені мережеві середовища.

Розслідування

Mandiant і Google Threat Intelligence Group виявили експлуатацію CVE-2026-88772 та CVE-2026-88771 наприкінці вересня 2026 року. Дослідники виявили, що зловмисники використовують неправильні заголовки запису DTLS, щоб викликати переповнення пам’яті купи в обробнику пакетів NetScaler. Форензичні докази також показали змінені файли httpd.conf, що використовуються для забезпечення стійкості, і права SUID, застосовані до /bin/sh для збереження привілеїв root.

Зменшення ризиків

Організації повинні пріоритетно встановлювати останні збірки Citrix для підтримуваних треків випуску NetScaler 14.1 та 13.1. Якщо негайне виправлення неможливе, захисники повинні відключити DTLS, де це можливо, і обмежити вхідний UDP/443 трафік на рівні периферії. Також настійно рекомендується суворе фільтрування вихідного трафіку та ротація всіх облікових даних, збережених на порушених пристроях.

Відповідь

Коли підозрюється компрометація, організації повинні ізолювати постраждалі вузли NetScaler і призупинити синхронізацію High Availability (HA), щоб запобігти реплікації зловмисних змін конфігурації. Реагуючі повинні відкликати активні адміністративні та VPN-сеанси та змінити секрети пристрою, включаючи ключі SSH і сертифікати TLS. Облікові дані, які використовуються інтегрованими службами, такими як LDAP і RADIUS, також повинні бути комплексно змінені.

## Виконання симуляції

• Сценарій атаки та команди: Супротивник намагається встановити довготривалу стійкість і прихований канал C2 на пристрої Citrix NetScaler. Спочатку вони модифікують конфігурацію веб-сервера для того, щоб обробляти .deb файли як PHP-скрипти, дозволяючи завантажувати та виконувати веб-шели, замасковані під файли пакетів Linux. По-друге, вони використовують AliasMatch для маскування зловмисного скрипту як нешкідливий .ico файл іконки. Нарешті, щоб уникнути виявлення традиційними NIDS, вони спілкуються зі своїм C2 сервером, використовуючи спеціальні заголовки HTTP (HTTP_X_UX and HTTP_NSC_LDAP) вбудовані в стандартні веб-запити.

• Сценарій регресійного тесту: Цей сценарій імітує генерування логів, які виявне правило очікує бачити. Оскільки ми тестуємо правило виявлення, ми імітуємо записи журналів так, ніби вони згенеровані пристроєм.

  #!/bin/bash
  # Імітаційний сценарій для генерування журналів, що відповідають логіці виявлення
  
  # 1. Імітація зміни конфігурації: додавання обробника для .deb файлів
  echo "$(date) NetScaler-Config: AddHandler application/x-httpd-php .deb" >> /var/log/netscaler_config.log
  
  # 2. Імітація зміни конфігурації: AliasMatch для маскування
  echo "$(date) NetScaler-Config: AliasMatch ^/vpn/media/(.+).ico$ /var/netscaler/gui/vpn/scripts/linux/$1.sig" >> /var/log/netscaler_config.log
  
  # 3. Імітація трафіку C2: впровадження заголовків HTTP (використовуючи curl для імітації веб-трафіку)
  # Ми використовуємо -H, щоб впровадити конкретні заголовки, визначені в правилі
  curl -H "HTTP_X_UX: true" -H "HTTP_NSC_LDAP: active" http://localhost/index.php
  
  # 4. Імітація трафіку C2: числовий заголовок UX
  curl -H "HTTP_X_UX_99: payload" http://localhost/index.php

• Команди очищення:

  # Видалення записів журналу (якщо вони були записані у локальний файл для тестування)
  sed -i '/AddHandler application/x-httpd-php .deb/d' /var/log/netscaler_config.log
  sed -i '/AliasMatch ^/vpn/media/(.+).ico$/d' /var/log/netscaler_config.log