В начале июля 2026 года Volexity описала атаку на устройства SonicWall Secure Mobile Access серии SMA 1000. Исследователи связывают инцидент с группой UTA0533: она использовала две ранее не раскрытые уязвимости, получила root-доступ к шлюзам и установила вредоносные компоненты для закрепления в сети.

По данным компании, атакующие успели не только выполнить команды на устройствах, но и перехватывали LDAP-учётные данные. Речь идёт о сценарии, где компрометация одного пограничного устройства открывает путь к внутренним сервисам и чужим паролям.

1) История инцидента

Volexity обнаружила атаку после расследования инцидента у одного из клиентов. Под удар попали два устройства SonicWall SMA 1000, но имя пострадавшей организации не раскрывают.

Сначала злоумышленники применили CVE-2026-15409 и CVE-2026-15410. Первая уязвимость давала возможность добраться до локальных сервисов через /wsproxy, вторая — поднимала привилегии до root и позволяла запускать команды от имени администратора.

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

На одном из устройств атакующие развернули самодельный набор с файлами ROOTRUN, KNUCKLEBALL и двумя JAR-архивами, которые встраивались в легитимный процесс SonicWall. На втором — создали скрипт, который запускал tcpdump и снимал незашифрованный LDAP-трафик с логинами и паролями.

2) Что пошло не так в защите

Главная проблема — уязвимый пограничный сервис, который оказался доступен для цепочки атак без начальной аутентификации. В таких случаях одно слабое звено превращается в входную дверь для целой сети.

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

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

Похожий класс проблем мы уже разбирали в материале о кражe сертификатов DigiCert: когда злоумышленник добирается до доверенного слоя инфраструктуры, последствия выходят далеко за пределы одного сервера.

3) Уроки для читателя

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

Вторая мысль касается паролей и токенов. Когда система хранит или выводит секреты из легко доступных параметров, защита держится на иллюзии. Любой такой секрет надо считать скомпрометированным, если он хоть где-то читается без жёсткого контроля доступа.

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

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

Если у вас в компании есть удалённые сотрудники или подрядчики, отдельное внимание стоит уделить тому, откуда они подключаются. В поездках и командировках полезно заранее продумать защиту приватности на открытых сетях — например, через инструмент для защищённой связи в дороге, а не через импровизацию в аэропорту или кафе.

4) Практические выводы и чек-лист

Ниже — короткий список, который можно использовать без глубоких технических знаний.

  • Проверьте, какие пограничные устройства стоят у вас в компании и кто за них отвечает.
  • Убедитесь, что на шлюзах и контроллерах стоят последние патчи от производителя.
  • Отключите лишние сервисы и закройте доступ к локальным интерфейсам, если они не нужны извне.
  • Проверьте, не читаются ли служебные файлы и идентификаторы без прав администратора.
  • Пересмотрите хранение паролей, ключей и служебных секретов: они не должны выводиться из открытых параметров.
  • Настройте журналирование на пограничных устройствах и сохранение логов вне самой машины.
  • Ищите в логах нетипичные запросы к /wsproxy, массовое создание файлов в /tmp и подозрительные изменения конфигурации.
  • Если устройство работало в открытой сети или в поездке, проверьте, не перехватывались ли внутренние учётные данные.
  • Для сотрудников, которые часто подключаются из кафе, аэропортов и гостиниц, используйте отдельный защищённый канал связи.
  • После инцидента меняйте не только пароли, но и связанные с ними сервисные учётные записи, токены и сертификаты.

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

Поделиться: