Статья Sigma правила детекции Cisco SD-WAN: пишем детекты на CVE-2026-20127 и lateral movement через NETCONF

Февраль 2026 - CISA выпускает Emergency Directive 26-03, Cisco Talos публикует разбор деятельности группировки UAT-8616, а Австралийский центр кибербезопасности (ASD-ACSC) выкладывает полноценный Hunt Guide по SD-WAN. Цепочка эксплуатации CVE-2026-20127 (CVSS 10.0, активно эксплуатируется - внесена в CISA KEV Catalog 25 февраля 2026 с due date 27 февраля 2026 - 48 часов вместо стандартных 14–21 дней по BOD 22-01, что само по себе говорит о масштабе паники) в связке с CVE-2022-20775 (CVSS 7.8, тоже в CISA KEV) давала атакующим root на контроллерах Cisco Catalyst SD-WAN. И они сидели там незамеченными как минимум с 2023 года. Публичные Sigma-правила из SigmaHQ заточены под endpoint-телеметрию и этот attack chain не покрывают вообще. Разберём, как написать детекты под каждую фазу атаки, адаптировать их под реальные логи vManage и vSmart и развернуть в SIEM так, чтобы не утонуть в ложных срабатываниях.

Почему endpoint-детекты бесполезны на SD-WAN-инфраструктуре​

Подавляющее большинство Sigma-правил в репозитории SigmaHQ написаны под Windows: Sysmon, Security Event Log, PowerShell ScriptBlock. Когда задача detection engineering смещается на сетевую инфраструктуру, все эти наработки можно отложить в сторону. Вот почему.

Нет EDR - нет телеметрии процессов. На контроллерах vManage и vSmart нельзя поставить агент CrowdStrike, Sysmon или что угодно другое. Единственный источник - syslog, который по умолчанию пишется локально. Получил root - зачистил файлы - и всё, как будто ничего не было. Если syslog не форвардится в SIEM в реальном времени - visibility равен нулю. Буквально.

Нет стандартного Sigma-logsource для SD-WAN. В таксономии SigmaHQ есть firewall, webserver, dns, продукт cisco с сервисами типа asa - но service: sdwan отсутствует. Pipeline-конфигурации sigma-cli понятия не имеют, как маппить поля логов VDAEMON на Sigma fieldnames. Каждое правило требует кастомного pipeline или ручной конвертации.

Атакующий живёт за счёт инфраструктуры. UAT-8616, по данным Cisco Talos и ASD-ACSC, не загружал на устройства никакого вредоносного ПО. Весь attack chain построен на легитимных протоколах: NETCONF (TCP/830) для манипуляции конфигурациями, SSH для удалённого доступа, встроенные механизмы software update для понижения версии (даунгрейда) прошивки. Living off the land на сетевой инфраструктуре в чистом виде - каждый отдельный шаг неотличим от штатной работы админа. Детектировать нужно не события по одному, а аномальные комбинации и контекст.

Этот набор ограничений и делает обнаружение атак на SD-WAN задачей, которая не решается загрузкой готовых правил с GitHub. Тут нужна ручная работа: маппинг полей, осмысленная фильтрация false positives, корреляция разнородных источников. Я потратил приличное время на то, чтобы собрать рабочий pipeline - и ниже покажу, к чему пришёл.

Анатомия атаки UAT-8616 на Cisco SD-WAN​

Прежде чем писать Sigma-правила, нужно точно понять, какие события генерирует каждый шаг атаки. По данным Cisco Talos, ASD-ACSC Hunt Guide и CISA ED 26-03, группировка UAT-8616 работала по следующей цепочке.

Шаг 1 - Initial Access. Crafted-запросы к management-интерфейсу SD-WAN Controller или Manager. Эксплуатируется CVE-2026-20127 - обход аутентификации в механизме peering (CWE-287, CVSS 10.0). По данным NVD - обход аутентификации и получение административных привилегий. Cisco Talos и ASD-ACSC указывают, что эксплуатация предположительно связана с сервисным аккаунтом vmanage-admin, используемым для межкомпонентного peering, - а это административный контроль над control plane. Workaround отсутствует. Только обновление до версий 20.9.8.2, 20.12.6.1, 20.12.5.3, 20.15.4.2 или 20.18.2.1.

Шаг 2 - Rogue peer injection. Через NETCONF (TCP/830) атакующий добавляет подконтрольный rogue-пир в control plane SD-WAN-фабрики. Это даёт возможность манипулировать конфигурациями, маршрутизацией и политиками на всех устройствах фабрики. В логах vSmart всплывает запись control-connection-state-change new-state:up peer-type:vmanage с нехарактерным peer-system-ip. Вот эта строчка - первый звоночек.

Шаг 3 - Software downgrade. Через легитимные механизмы обновления атакующий откатывает версию ПО на содержащую CVE-2022-20775 - уязвимость повышения привилегий в CLI (CWE-25, CWE-22, CVSS 7.8; root cause по NVD - improper access controls на CLI-команды, классификация CISA KEV - path traversal vulnerability). Имея authenticated-доступ как vmanage-admin (со Шага 1), эксплуатирует уязвимость через CLI (AV:L/PR:L) для эскалации до root. Потом восстанавливает оригинальную версию - следы даунгрейда стёрты.

Шаг 4 - Persistence. Создание локальных аккаунтов, имитирующих легитимные. SSH-ключи в /home/root/.ssh/authorized_keys и /home/vmanage-admin/.ssh/authorized_keys/. Модификация startup-скриптов SD-WAN для автозапуска. Включение PermitRootLogin yes в /etc/ssh/sshd_config. Классика закрепления, но на нетипичной для SOC платформе.

Шаг 5 - Anti-forensics. Последовательное удаление syslog, wtmp, lastlog, cli-history, bash_history и содержимого /var/log/. Цель - стереть все следы до момента анализа. Именно поэтому пересылка syslog в SIEM - не рекомендация, а необходимое условие.

Шаг 6 - Lateral movement. Через SSH и NETCONF атакующий перемещается между компонентами SD-WAN-фабрики. По данным ASD-ACSC, зафиксировано перемещение и за пределы SD-WAN-окружения - в корпоративную сеть.

MITRE ATT&CK маппинг цепочки эксплуатации​

Каждая фаза атаки UAT-8616 маппится на конкретные техники MITRE ATT&CK. Этот маппинг определяет, какие детекты писать и что именно искать в логах.

Фаза	Техника MITRE ATT&CK	ID	Индикатор в логах SD-WAN
Initial Access	Exploit Public-Facing Application	T1190	SSH publickey auth для vmanage-admin от неизвестного IP
Persistence	Create Account	T1136	Создание нового локального пользователя
Persistence / Priv Esc	Valid Accounts	T1078	Повторное использование vmanage-admin без change request
Privilege Escalation	Exploitation for Privilege Escalation	T1068	Аномальные CLI-команды от vmanage-admin (path traversal - один из векторов)
Defense Evasion	Indicator Removal	T1070	Очистка/truncate файлов логов (Atomic Red Team тесты для T1070 - только под Windows; на Linux нужны кастомные)
Lateral Movement	Remote Services	T1021	SSH/NETCONF-сессии между нодами фабрики
Command and Control	Application Layer Protocol	T1071	Нехарактерные NETCONF-сессии на TCP/830 (Atomic Red Team тесты - только под Windows)

Покрыть все семь техник одними Sigma-правилами не получится: T1071 требует анализа трафика через Zeek или ntopng, а не парсинга логов. Но пять из семи детектируются по syslog-записям - ими и займёмся.

Требования к окружению перед написанием правил​

Прежде чем открывать редактор YAML, нужна базовая инфраструктура для сбора и обработки логов. Без неё Sigma-правила - теоретическое упражнение, которое никого не защитит.

ОС и инструменты: Linux-хост с sigma-cli (pip install sigma-cli) или доступ к Uncoder.IO. SIEM: Splunk, Elastic SIEM или Microsoft Sentinel с настроенным приёмом syslog на выделенный порт.

Syslog-форвардинг c SD-WAN-устройств. На каждом vManage и vSmart должна быть настроена отправка логов на удалённый syslog-сервер. Канадский центр кибербезопасности (CCCS) в рекомендациях по hardening'у Cisco Catalyst SD-WAN прямо указывает: логирование должно направляться на remote syslog server. Это условие номер один. Атакующий получает root, зачищает локальные логи - а записи, уже ушедшие в SIEM, нетронуты.

Два типа логов - две стратегии маппинга. vManage генерирует записи двух принципиально разных форматов. Первый - стандартный Linux syslog из /var/log/auth.log, формируемый sshd. Для него в Sigma подходит logsource product: linux, service: auth. Второй - записи VDAEMON контрольного плана: %Viptela-vSmart-VDAEMON_0-5-NTCE-1000001: control-connection-state-change new-state:up peer-type:vmanage peer-system-ip:1.1.1.10 public-ip:192.168.3.20. Для них стандартного Sigma-logsource нет - определяем кастомный product: cisco, service: sdwan и создаём pipeline-файл для sigma-cli с маппингом на конкретный sourcetype в SIEM.

Белый список легитимных IP. Для фильтрации false positives нужен актуальный перечень System IP всех SD-WAN-компонентов. Берётся из веб-интерфейса SD-WAN Manager: раздел Devices, столбец System IP. Этот список станет основой для блока filter в каждом правиле. Без него - утонете в алертах от штатных подключений.

Sigma-правила детекции Cisco SD-WAN exploitation​

Ниже - два ключевых детекта, покрывающих наиболее критические фазы цепочки UAT-8616. Каждый блок содержит минимальный рабочий набор полей: title, logsource, detection, level. Метаданные (id, status, tags, references, author, date, falsepositives) добавляйте по стандарту SigmaHQ.

Обнаружение обхода аутентификации (T1190, Initial Access)​

Ключевой индикатор компрометации по CVE-2026-20127 - SSH-аутентификация аккаунта vmanage-admin с IP-адреса, не входящего в перечень легитимных System IP. Cisco Security Advisory прямо указывает: запись Accepted publickey for vmanage-admin from <IP> в auth.log - primary indicator of compromise. Адрес источника сопоставляйте со списком из WebUI SD-WAN Manager.

title: Cisco SD-WAN Unauthorized vmanage-admin SSH Login
logsource:
    product: linux
    service: auth
    definition: 'auth.log с SD-WAN appliances через syslog. ТРЕБУЕТСЯ ingest-pipeline с grok-экстракцией поля src_ip из sshd-сообщений (паттерн: Accepted publickey for %{USER} from %{IP:src_ip}). Без этого фильтр filter_known неработоспособен.'
detection:
    selection:
        message|contains: 'Accepted publickey for vmanage-admin'
    filter_known:
        # ОБЯЗАТЕЛЬНО: ingest-pipeline с grok-экстракцией src_ip.
        # Без этого правило НЕРАБОТОСПОСОБНО и ОПАСНО:
        # - Splunk: NOT по несуществующему полю = true → фильтр пропускает ВСЁ
        # - Elastic: missing field = no match → фильтр блокирует ВСЁ
        # Grok: Accepted publickey for %{USER} from %{IP:src_ip}
        # Перед деплоем: убедитесь что поле src_ip не null на тестовых событиях.
        src_ip|cidr: '10.0.1.0/24'  # ваш management-диапазон
    condition: selection and not filter_known
level: critical

Обратите внимание на logsource: product: linux, не cisco. Это не ошибка - auth.log на vManage генерируется стандартным демоном sshd, и стандартный Sigma pipeline для Linux auth-логов корректно обработает поля. Поле src_ip в блоке filter_known требует предварительного извлечения из неструктурированного sshd-сообщения - через grok-паттерн Accepted publickey for %{USER} from %{IP:src_ip} в ingest pipeline вашего SIEM. Без этого field extraction фильтр не сработает, и дальше зависит от SIEM: Splunk пропустит всё, Elastic заблокирует всё (подробности - в комментариях в YAML).

Блок filter_known критически важен: без белого списка management-адресов правило будет орать на каждое штатное SSH-подключение администратора. Замените 10.0.1.0/24 на реальный CIDR вашей management-сети. Несколько подсетей - YAML-список значений.

Уровень critical обоснован CVSS 10.0 для CVE-2026-20127. Рекомендую дополнить правило вторым selection, детектирующим строку PermitRootLogin в потоке syslog - атакующий модифицирует /etc/ssh/sshd_config для включения root-логина.

Детекция rogue-пиров и lateral movement через SD-WAN (T1021)​

Вторая критическая точка - появление неожиданных control-connection peering-событий в логах VDAEMON. UAT-8616 создаёт rogue-пир типа vmanage в control plane, что генерирует характерную запись. Cisco Security Advisory явно указывает: все peering-события требуют ручной валидации с фокусом на peer-type vmanage.

title: Cisco SD-WAN Unexpected Control Peer Connection
logsource:
    product: cisco
    service: sdwan
    definition: 'VDAEMON syslog с vSmart/vManage'
detection:
    selection:
        message|contains|all:
            - 'control-connection-state-change'
            - 'new-state:up'
            - 'peer-type:vmanage'
    condition: selection
level: high

Этот logsource кастомный - product: cisco, service: sdwan - стандартные pipeline-конфигурации sigma-cli его не обработают. Нужен файл пайплайна с маппингом на ваш sourcetype. Уровень high, а не critical: событие control-connection-state-change возникает и при штатных операциях - перезагрузке, failover, плановом добавлении нод. Задача правила - не блокировать, а дать алерт для ручной валидации по чеклисту из Cisco Advisory: совпадает ли peer-system-ip с ожидаемой схемой, валиден ли public-ip как источник peering, есть ли соответствующий change request.

Для полноценного SD-WAN threat hunting этот детект - отправная точка. Каждое срабатывание триггерит проверку domain-id, site-id и временной корреляции с журналом изменений.

Обнаружение anti-forensics и зачистки логов (T1070)​

Третья детектируемая фаза - уничтожение следов. UAT-8616 целенаправленно удаляет syslog, wtmp, lastlog, cli-history, bash_history и содержимое /var/log/. Если syslog не форвардится в SIEM в реальном времени, этот класс детектов бессмыслен - удалять будет нечего, потому что и алертить будет не на чем.

Два подхода к обнаружению.

Прямой: Sigma-правило с keywords, детектирующее команды truncate, rm -f, echo "" > в комбинации с путями /var/log/, bash_history, wtmp, cli-history. Аналог стандартного SigmaHQ-правила для очистки bash_history, но адаптированный под SD-WAN-специфичные пути - /var/log/confd/ и cli-history, которых на обычных Linux-хостах не бывает. Logsource: product: linux, service: auth для записей из auth.log или product: linux, service: syslog для общего потока.

Косвенный (и, на мой взгляд, более надёжный): мониторинг разрывов в потоке syslog от SD-WAN-устройств. Если vSmart-01 стабильно генерировал 100+ событий в час, а потом поток прекратился на 30+ минут без запланированного maintenance - это индикатор компрометации с high confidence. Реализуется не через Sigma, а через встроенные механизмы корреляции SIEM: | tstats в Splunk или watcher/alert rule в Elastic.

Для проверки эксплуатации CVE-2022-20775 отслеживайте аномальные CLI-команды от vmanage-admin и любые CLI-сессии, завершающиеся неожиданной эскалацией к root. CVE-2022-20775 - path traversal (CWE-22/CWE-25), эксплуатируемая через некорректный access control на CLI-команды. Детекция только по литералу /../../ даёт и ложноотрицательные, и ложноположительные срабатывания - так что тут нужна более хитрая логика.

Конвертация Sigma-правил в запросы SIEM​

После написания YAML-правил их надо конвертировать в запросы конкретного SIEM. Для первого правила (auth bypass) процесс прямолинеен: sigma convert -t splunk -p sysmon rules/sdwan_auth_bypass.yml с sigma-cli сгенерирует корректный SPL-запрос, поскольку logsource product: linux, service: auth имеет стандартный маппинг.

Для второго правила (rogue peer) стандартного маппинга нет. Два рабочих варианта: создать кастомный pipeline YAML-файл для sigma-cli, определяющий связку product: cisco, service: sdwan с конкретным index и sourcetype, или использовать Uncoder.IO с ручной коррекцией маппинга через веб-интерфейс.

В Splunk целевой запрос для rogue peer detection будет примерно таким: index=network sourcetype="cisco:sdwan:syslog" "control-connection-state-change" "new-state:up" "peer-type:vmanage". В Elastic - KQL-запрос к data stream с фильтрацией по полям, созданным ingest pipeline для парсинга VDAEMON-записей в структуру cisco.sdwan.*.

Дополнительный слой: Cisco выпустила Snort-правила 65938 и 65958 для обнаружения эксплуатации CVE-2026-20127 на уровне сетевого трафика. Sigma и Snort работают на разных уровнях - Sigma анализирует логи, Snort - пакеты. В связке получается многослойная Cisco SD-WAN exploitation detection: Snort ловит crafted-запросы на wire, Sigma - последствия успешной эксплуатации в журналах. Одно без другого - полудетект.

Валидация детектов без продакшн-инцидента​

Правило без тестирования - это JSON в SIEM, который генерирует ложную уверенность. Три подхода к валидации.

Replay синтетических логов. Cisco Security Advisory содержит точные форматы записей auth.log и VDAEMON. Сформируйте тестовые syslog-сообщения: SSH-аутентификацию vmanage-admin с внешнего IP и control-connection-state-change с аномальным peer-system-ip. Отправьте в dev-инстанс SIEM через logger -n <siem_ip> -P 514 -p local0.info "<сообщение>" и убедитесь, что конвертированные Sigma-правила генерируют алерты. Этот метод валидирует и правило, и pipeline, и маппинг полей одновременно - три зайца одной командой.

Лабораторная среда SD-WAN. При наличии эмулированного сегмента в Cisco CML или EVE-NG с образами vManage/vSmart можно воспроизвести отдельные фазы: SSH-подключение с нелегитимного IP, создание пользователя, модификацию sshd_config. Это ближе к реальности, но требует лицензий и ресурсов.

Ретроспективный поиск. Если ваш SIEM хранит исторические логи SD-WAN-устройств - прогоните конвертированные запросы по архиву за последние 6–12 месяцев. UAT-8616 сидели в инфраструктурах с 2023 года. Если что-то найдётся - ну, хотя бы теперь вы это видите.

Проверьте свои правила на синтетике до того, как они понадобятся на реальном инциденте. Если прямо сейчас у вас vManage не форвардит syslog в SIEM - начните с этого. Всё остальное - потом.

Вопрос к читателям​

Коллеги, кто уже разворачивал детект rogue-пиров через VDAEMON-логи в Splunk или Elastic - как вы решаете проблему field extraction для неструктурированных строк вида control-connection-state-change new-state:up peer-type:vmanage peer-system-ip:1.1.1.10 public-ip:192.168.3.20? Интересно именно: используете ли grok-паттерн на ingest-уровне (и какой именно - покажите строку паттерна) или rex на search-time в Splunk? И второй момент: как организован белый список peer-system-ip - статический lookup-файл, который обновляется вручную, или есть автоматическая синхронизация из SD-WAN Manager API? При ручном подходе какой lag между добавлением легитимного пира и обновлением фильтра - и сколько false positives это генерирует в продакшне?