Vates опубликовала индикаторы эксплуатации VSA-2026-062 в Xen Orchestra. Уязвимость позволяет обойти аутентификацию и выполнять действия с правами администратора; вендор уже фиксировал реальные атаки. Ниже собраны адреса, имена и артефакты, по которым можно проверить инфраструктуру.
Описание
По данным Vates, атакующие использовали IP 91.211.251.112 и Tor-сервис. На скомпрометированных узлах появлялись VM с именем pivot2 и необычный параметр hvm_serial: file. В логах XenServer искали строки -serial file:, а в файловой системе - следы cron-задач и подмену динамического загрузчика.
Отдельно стоит проверить HTTP-запросы. Индикатор выглядит как cookie authenticationToken с пустым JSON-объектом: authenticationToken=j:%7B%7D или authenticationToken=j:{}. Если такой запрос пришёл на Xen Orchestra из интернета, это повод считать управляющую консоль потенциально скомпрометированной.
Список ниже не заменяет обновление. Vates подчёркивает: если XO или XOA была открыта в интернет, одного патча недостаточно. Нужно сменить пароли и секреты VMS, отозвать сессии и API-токены, проверить узлы XCP-ng. При подтверждённом взломе вендор советует полную переустановку, а не удаление найденных файлов.
Если Xen Orchestra обслуживает сторонний провайдер, письменно подтвердите, что его XO/XOA не была открыта в интернет, какая версия установлена и когда применён фикс. Проверьте также, не осталось ли активных сессий и токенов. Ирония в том, что самый заметный индикатор здесь - пустой объект в cookie, который выглядит как безобидная ошибка.
Почему это важно. Xen Orchestra управляет гипервизорами XCP-ng, поэтому административный доступ к ней почти равен доступу к инфраструктуре. Злоумышленник может создать VM, добраться до хранилищ и закрепиться на узлах. В отчёте Vates описан именно такой сценарий: после обхода аутентификации атакующий получал токены и действовал как администратор.
Индикаторы стоит проверять в двух местах. Сетевые признаки показывают, пытались ли войти через уязвимую cookie. Файловые и системные признаки показывают, успел ли атакующий закрепиться: VM pivot2, параметр hvm_serial: file, задания cron с именем zz-ustar и файлы.ustar. Подмена /etc/ld.so.preload особенно неприятна: она позволяет загружать чужой код в процессы без правки самих бинарников.
Не стоит ограничиваться поиском одного артефакта. Если найден хотя бы один индикатор, проверьте соседние узлы, историю задач, сетевые соединения и активные сессии. Vates прямо говорит: после подтверждённого взлома нужна переустановка. Удаление cron-файла или строки из ld.so.preload не гарантирует, что в системе не осталось другого закрепа.
Для SOC полезно завести отдельные правила на authenticationToken с пустым объектом и на сочетание pivot2 + hvm_serial: file. Для администраторов Xen Orchestra - обновить XO/XOA и проверить, не была ли консоль доступна из интернета. Это тот случай, когда список индикаторов помогает не найти виноватого, а быстро понять масштаб.
Индикаторы компрометации
