KeyDrift: Cisco SD-WAN взламывали ради ключей филиалов

Безопасность

KeyDrift: Cisco SD-WAN взламывали ради ключей филиалов

KeyDrift Cisco SD-WAN: цепочка conf_sshd → rsshd → PolyFlame в процессе vdaemon и модуль LittleFilch, копирующий AES-ключи через CVE-2026-20127

Cisco Talos 28 октября описала вредонос KeyDrift: Cisco SD-WAN он атакует через закрытую в феврале уязвимость CVE-2026-20127 и копирует AES-ключи, которыми шифруется трафик между площадками. Фильтрация портов такой модуль не удаляет, а Cisco предупреждает, что установленные до обновления средства эксплуатации могут остаться и после патча.

Коротко

  • Cisco Talos 28 октября описала KeyDrift: через CVE-2026-20127 (CVSS 10.0) он копирует AES-ключи межплощадочного трафика Cisco SD-WAN.
  • LittleFilch читает расшифрованные сообщения vdaemon на контроллере, PolyFlame работает в памяти, а запуск обеспечивают изменённые сценарии runit.
  • Talos приписывает атаки UAT-11473 и связывает его с Volt Typhoon только через пересечение с сетью Silent Train.
  • Исправленные релизы: 20.9.8.2, 20.12.5.3, 20.12.6.1, 20.15.4.2, 20.18.2.1. Обходного пути нет.
  • Закрытие портов 22 и 830 уже установленный модуль не удаляет, а Cisco предупреждает, что средства эксплуатации могут пережить и обновление. До перезагрузки соберите admin-tech и проверьте auth.log.

Коротко

  • Cisco Talos описала вредонос KeyDrift. Его устанавливали на компоненты Cisco Catalyst SD-WAN через CVE-2026-20127 (CVSS 10.0), которую Cisco закрыла ещё в феврале.
  • Компонент LittleFilch читает управляющие сообщения процесса vdaemon после расшифровки и извлекает 32-байтовый материал ключей AES-256 для заданных маршрутизаторов.
  • Активность приписывают кластеру UAT-11473. Его инфраструктура сильно пересекается с сетью Silent Train, через которую маскировался Volt Typhoon, но Talos не называет их одной группой.
  • Обходного пути нет, исправленные релизы вышли для веток от 20.9 до 20.18. Закрытие портов 22 и 830 уже установленный модуль не удаляет.
  • Прямого ответа, снимает ли обновление KeyDrift и нужно ли менять ключи, ни Cisco, ни Talos пока не дали.

Что известно о KeyDrift: Cisco SD-WAN под прицелом

Talos впервые описала KeyDrift, вредонос для компонентов управления Cisco Catalyst SD-WAN. Он копирует ключи, которыми шифруется трафик между площадками, и хранит их для дальнейшего использования. Атаки Talos называет историческими, но когда именно они шли, не уточняет.

Вход открывала CVE-2026-20127. Уязвимость с максимальной оценкой CVSS 10.0 позволяет удалённому злоумышленнику без учётных данных обойти аутентификацию и получить административные права на системах управления SD-WAN. Cisco раскрыла и закрыла её в феврале. Тогда Talos отслеживала эксплуатацию как кластер UAT-8616, активный минимум с 2023 года.

На Controller успешная атака даёт не root, а внутреннюю учётную запись с высокими привилегиями. Для KeyDrift этого хватило. Это не шифровальщик и не шумная атака: модуль тихо копирует ключи. Отправляли ли их наружу, Talos не утверждает.

Где в схеме обмена ключами встраивается LittleFilch

LittleFilch встраивается в ту точку, через которую проходят ключи площадок и где они уже расшифрованы. В штатной схеме Cisco SD-WAN каждый маршрутизатор периодически генерирует AES-ключ для своего трафика и отправляет его на Catalyst SD-WAN Controller (бывший vSmart). Контроллер раздаёт ключи остальным маршрутизаторам. Зашифрованные управляющие соединения, по которым всё это ходит, держит процесс vdaemon.

LittleFilch (библиотека libcommon.so) перехватывает работу vdaemon и читает управляющие сообщения после расшифровки. Для заранее заданного списка пограничных маршрутизаторов он извлекает IP-адрес и 32-байтовое поле, которое Talos оценивает как материал ключа AES-256. Защита транспортного канала здесь не помогает: процесс сам расшифровал данные, чтобы с ними работать.

Поэтому компрометация контроллера опаснее компрометации одного маршрутизатора. Controller принимает ключи от маршрутизаторов и передаёт их дальше. Тот, кто сидит внутри vdaemon, видит ключи, которые площадки доверили центру.

KeyDrift шифрует похищенные данные открытым ключом RSA, сохраняет их на диск и может отправить по UDP. Адрес получателя лежал в файле настроек, который удалили сразу после чтения. Восстановить его Talos не смогла.

UDP не устанавливает сеанс, поэтому в журналах останется разве что короткий односторонний поток датаграмм. Искать его стоит в NetFlow, журналах межсетевых экранов и записях трафика, а не в списках TCP-соединений.

Как KeyDrift закрепляется на Controller и Validator

KeyDrift стартует в основном через изменённые сценарии runit, которыми устройства Cisco SD-WAN запускают свои службы. В одном варианте сценарий /etc/sv/sshd/run запускал загрузчик conf_sshd раньше настоящего SSH-сервера, так что вредонос поднимался вместе со службой SSH.

Дальше цепочка из двух шагов. conf_sshd записывает идентификаторы процессов vdaemon в файл /tmp/system-vdaemon. Инжектор rsshd проходит по списку и внедряет в каждый процесс основной модуль PolyFlame.

PolyFlame (libdssl.so) живёт только в памяти vdaemon и работает в одном из двух режимов. Первый: бэкдор в духе TinyShell с выполнением команд, чтением и записью файлов. Второй: ретранслятор, который передаёт команды между своим командным сервером и другими машинами.

Команды PolyFlame принимает внутри управляющего трафика SD-WAN, поэтому на уровне сети они смешиваются с легитимным обменом. Жёстко прошитого адреса сервера в изученных образцах не нашли.

На Validator (бывший vBond) схема другая. Там операторы создали поддельную службу aaamgr: в каталоге /etc/sv/aaamgr/ запускается упакованный загрузчик aaamgrd, который расшифровывает и стартует PolyFlame. Настоящий aaamgr у Cisco представлен пакетом на Python и скомпилированной службой не работает, так что любой бинарный файл в этом каталоге стоит разобрать.

Следы операторы маскировали подменой времени (timestomping): копировали метки времени и права существующих файлов на свои. Поиск по дате изменения файлов их не покажет.

Кто стоит за KeyDrift и связан ли он с Volt Typhoon?

Talos приписывает KeyDrift кластеру UAT-11473 и связывает его с Volt Typhoon только через общую инфраструктуру. Цели UAT-11473: космические и спутниковые сервисы, оборонные и аэрокосмические технологии, аналитические центры и политологические исследования.

По оценке Talos, сделанной с высокой уверенностью, инфраструктура кластера сильно пересекается с Silent Train. Так Lumen Black Lotus Labs называет сеть взломанных SOHO-роутеров, IoT и бизнес-устройств, через которую, по данным Lumen, маскировался Volt Typhoon. В 2024 году CISA, NSA и FBI назвали Volt Typhoon группой, которую поддерживает Китай. К UAT-11473 Talos эту атрибуцию не применяет.

Пересказы тут легко склеивают три ярлыка в один. Talos не утверждает, что за UAT-11473 и Volt Typhoon стоит одна группа. Не объясняет она и связь UAT-11473 с UAT-8616, февральским кластером эксплуатации той же уязвимости.

Отдельно Lumen в тот же день сообщила, что Volt Typhoon эксплуатировал CVE-2026-20127 уже к концу 2025 года и продолжил после февральского раскрытия. С KeyDrift эту активность Lumen не связывает. Cisco называет эксплуатацию ограниченной.

Какие версии Catalyst SD-WAN закрывают CVE-2026-20127 и чего патч не делает?

Обходного пути Cisco не даёт, уязвимость закрывает только обновление. Под ударом Controller (vSmart), Manager (vManage) и Validator (vBond) в любой конфигурации: локальные установки и облачные развёртывания Cisco, включая среды Cisco Managed и FedRAMP. Validator добавили в бюллетень 16 июня.

Ваша ветка релизовПервый исправленный релиз
до 20.9миграция на исправленную ветку
20.920.9.8.2
20.1120.12.6.1 (переход на ветку 20.12)
20.1220.12.5.3 или 20.12.6.1
20.13, 20.14, 20.1520.15.4.2
20.16, 20.1820.18.2.1

Строка 20.11 не опечатка: релизы до 20.9 и ветки 20.11, 20.13, 20.14 и 20.16 вышли из сопровождения, и исправление для них лежит в следующей ветке. Если вы на них, обновление превращается в переход на другую ветку с полноценным тестированием.

Временная мера для локальных установок: пустить на порты 22 и 830 только известные адреса контроллеров и других своих систем. Cisco проверила её в тестовой среде и просит заказчиков проверить у себя. В облаке Cisco такие ограничения уже действуют.

Про порты Cisco пишет прямо: их блокировка не удаляет вредонос, который уже стоит на устройстве. Про обновление сказано осторожнее. Февральское руководство Cisco по устранению этой уязвимости предупреждает, что средства эксплуатации, установленные до обновления, могут остаться на месте. Удаляет ли патч именно KeyDrift и нужно ли менять ключи, ни Cisco, ни Talos не уточнили.

Федеральные гражданские ведомства США подчиняются чрезвычайной директиве CISA от 25 февраля. При обнаружении компрометации учётной записи root она требует сообщить в CISA, развернуть новые Manager, Controller и Validator из исправленных образов и перевести на них пограничные маршрутизаторы. Остальным это хороший ориентир: при подтверждённом заражении перестроить надёжнее, чем чистить.

Как проверить контроллеры на следы KeyDrift?

Начинайте со сбора данных, а не с перезагрузки и не с обновления: PolyFlame живёт в памяти, и часть следов пропадёт при перезапуске. Порядок, который выбрали бы мы сами:

  1. Изолировать управляющие интерфейсы и выполнить request admin-tech на каждом Manager, Controller и Validator. Cisco просит сделать это до обращения в TAC, а собранные файлы повторно проверить функцией Check Bug Applicability на странице ошибки CSCws52722 в Bug Search Tool.
  2. Найти в /var/log/auth.log строки «Accepted publickey for vmanage-admin» и сопоставить источники с известными адресами. Незнакомый IP указывает на возможную эксплуатацию.
  3. Сверить /etc/sv/sshd/run с эталоном, проверить содержимое /etc/sv/aaamgr/ и наличие /tmp/system-vdaemon, /var/tmp/vdaemon.bin и /var/tmp/vdaemon.conf. Сам путь оценивайте вместе с процессами и содержимым файлов.
  4. Для процессов vdaemon посмотреть список загруженных библиотек: посторонних libdssl.so или libcommon.so там быть не должно.
  5. Выгрузить данные NetFlow и журналы межсетевых экранов за длительный период и искать исходящие UDP-потоки с компонентов управления на внешние адреса.

Для сети Talos выпустила правила Snort против командного канала KeyDrift: 67387-67416 для Snort 2 и 7:44-7:73 для Snort 3. Правила для Snort 2 по умолчанию отключены, подписчикам платного набора Snort Subscriber их нужно включить. Правила для Snort 3 вышли без состояния по умолчанию, поэтому проверьте в консоли, что они действительно активны. Саму уязвимость покрывают более ранние правила 65938 и 65958.

Хешей, IP-адресов и доменов в отчёте Talos нет. Опирайтесь на пути файлов, поведение процессов и сетевые правила.

На практике интерфейсы управления сетевыми системами часто доступны шире, чем думает владелец. SSH и NETCONF открыли «временно для подрядчика», которого давно нет, а журналы контроллеров никто не собирает централизованно. Правила IDS и поиск по auth.log отвечают на разные вопросы, и тишина в обоих не доказывает, что устройство чистое.

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

Три решения для руководителя

Если филиалы связаны через Cisco Catalyst SD-WAN, руководителю нужно принять три решения, и патч закрывает только первое.

  • Сроки обновления. CVSS 10.0, эксплуатация с конца 2025 года по данным Lumen и отсутствие обходного пути дают приоритет выше плановых окон. Для веток вне сопровождения закладывайте время на миграцию.
  • Чистить или перестраивать. Если найдены следы компрометации, логика директивы CISA подсказывает новые экземпляры компонентов из исправленных образов. Это дольше и дороже чистки, но модуль с подделанными метками времени и закреплением через runit чистка может пропустить.
  • Ключи. Самостоятельная ротация ключей SD-WAN без согласованной процедуры опасна: неправильная последовательность разорвёт связность площадок. Задайте Cisco вопрос о компрометации ключей письменно, через TAC.

От себя добавим российский контекст, которого нет в отчётах Talos и Lumen. Если по каналам между площадками идут персональные данные, подтверждённая кража ключей превращается в вопрос о возможной утечке, а значит, и об уведомлении регулятора по 152-ФЗ.

Проверить, заметил бы ваш SOC такого гостя в управляющей плоскости, позволяет симуляция целевой атаки (Red Team).

Чего пока не знает никто

  • Ушли ли украденные ключи к злоумышленникам. Talos этого не подтверждает, адрес получателя удалён.
  • Сколько организаций пострадало. Cisco говорит лишь об ограниченной эксплуатации.
  • Как связаны UAT-11473, UAT-8616 и Volt Typhoon. Есть только пересечение инфраструктуры.
  • Удаляет ли обновление именно KeyDrift и нужна ли ротация ключей. Прямого ответа нет, есть лишь февральское предупреждение Cisco, что следы эксплуатации могут пережить обновление.

Частые вопросы

Что такое вредонос KeyDrift в Cisco SD-WAN?

Так Cisco Talos назвала вредонос для компонентов управления Cisco Catalyst SD-WAN, описанный 28 октября. Он встраивается в процесс vdaemon на контроллере и копирует AES-ключи, которыми шифруется трафик между площадками.

Какие компоненты Cisco затрагивает CVE-2026-20127?

Controller (vSmart), Manager (vManage) и Validator (vBond) в любой конфигурации: локальные установки и облачные развёртывания Cisco, включая Cisco Managed и FedRAMP. Уязвимость позволяет обойти аутентификацию без учётных данных и получить административные права.

Удаляет ли обновление уже установленный KeyDrift?

Подтверждения этому нет. Патч закрывает вход, а февральское руководство Cisco предупреждает, что установленные до обновления средства эксплуатации могут остаться на месте. Блокировка портов 22 и 830 вредонос точно не удаляет.

Как проверить vManage и контроллеры на эксплуатацию?

Ищите в /var/log/auth.log строки «Accepted publickey for vmanage-admin» с незнакомых IP-адресов. До перезагрузки выполните request admin-tech на каждом компоненте и проверьте сценарии runit в /etc/sv/.

Связан ли KeyDrift с Volt Typhoon?

Только через инфраструктуру: сеть UAT-11473 сильно пересекается с Silent Train, которую использовал Volt Typhoon. Talos не называет их одной группой, а Lumen не связывает эксплуатацию уязвимости Volt Typhoon с KeyDrift.

Нужно ли менять ключи шифрования после взлома контроллера SD-WAN?

Официального ответа пока нет. Порядок ротации согласуйте с Cisco TAC, чтобы не разорвать связность площадок.

Если нужно проверить контроллеры SD-WAN на следы компрометации или выстроить мониторинг сетевой инфраструктуры, команда HirexTech поможет: от аудита до реагирования. Подробнее о нашей информационной безопасности.

Прокрутить вверх