SIEM после WannaCry: корреляционные правила для EternalBlue, SMB-сканирования и lateral movement

После эпидемии WannaCry что-то сдвинулось в голове у безопасников и их руководства. Вопрос «а есть ли у вас SIEM» перестал вызывать скучающий взгляд. Вопрос «а что у вас в SIEM настроено» - другое дело. Большинство ответов на него в мае выглядели примерно так: «есть правила по умолчанию из коробки». Это значит - ничего полезного по теме.

Вендоры отреагировали быстро: в течение двух-трёх недель после 12 мая ArcSight, QRadar, Splunk и несколько игроков поменьше выкатили либо готовые пакеты правил, либо подробные write-up с сигнатурами, которые можно имплементировать самостоятельно. Мы прошлись по этим правилам, поставили их в тестовой среде и прогнали по логам нескольких клиентов. Делимся наблюдениями.

Что за правила и что они ловят

Сигнатуры делятся на три класса - по этапам атаки WannaCry.

Детектирование SMB-сканирования. Логика простая: один хост генерирует SYN-пакеты на порт 445 к большому числу адресов за короткий промежуток времени. WannaCry сканирует и случайные подсети из интернета, и локальную сеть параллельно, поэтому всплески характерные. Типовой порог в опубликованных правилах - более 20-30 уникальных dst-IP за 60 секунд с одного src. Значение варьируется, потому что вендоры настраивали его на разных выборках трафика.

Детектирование попыток эксплуатации SMBv1. Здесь нужны сетевые сигнатуры уровня IDS/NIDS или разбор SMB-заголовков. EternalBlue имеет характерный паттерн TransactNamedPipe-запросов с нестандартными TID/FID-значениями. Snort/Suricata-правила для этого были опубликованы ещё в апреле после дампа Shadow Brokers - сейчас вендоры SIEM предлагают агрегировать алерты с IDS в корреляционные правила, чтобы не тонуть в сырых событиях.

Детектирование аномального трафика по 445 между сегментами. Это правило работает только если у вас уже есть сегментация сети и базовый профиль того, какой трафик по 445 является нормой. Основная идея: если хост из сегмента A ранее никогда не ходил на 445 к хостам из сегмента B, а теперь пошёл - это событие для расследования. Без baseline правило бесполезно.

Сколько ложняков ждать

Честный ответ: зависит от сети. Мы смотрели на это по нескольким клиентам с разной топологией.

Правило на SMB-сканирование. В сетях с Windows-доменом и стандартным уровнем административной активности даже порог в 30 dst-IP/60с даёт неприятное количество ложных срабатываний. Источники: легитимные скрипты инвентаризации, WSUS-серверы опрашивающие клиентов, антивирусные агенты с сетевой активностью. В одной из сред порог пришлось поднять до 50, и это уже давало терпимую картину - единичные алерты в день, а не непрерывный шум.

Правило на попытки эксплуатации SMBv1. Здесь ложняков мало, если IDS-сигнатуры подобраны аккуратно. Основная проблема не в количестве, а в отсутствии IDS как такового - без него корреляция нечего агрегировать.

Правило на аномальный трафик по 445. Без нормального baseline - просто шторм. Первые сутки после включения у одного клиента правило выдало несколько сотен событий, потому что «аномальным» считалось практически всё: профиля не было вообще. На построение адекватного baseline ушло около недели пассивного мониторинга.

Это один из системных уроков WannaCry для SIEM: большинство инсталляций работали без профилей нормального поведения, только с сигнатурными правилами. Сигнатурные правила ловят известное - они не заметили бы нулевой день.

Что мы сделали для managed-клиентов

В рамках мониторинга управляемой инфраструктуры мы прогнали следующее:

• Импортировали опубликованные пакеты правил и адаптировали пороги под трафик конкретного клиента. Не взяли дефолтные значения - потому что они откалиброваны на «среднюю» среду, которой не существует.
• Включили пассивный сбор baseline по 445 на две недели перед активацией правил на аномальный трафик.
• Добавили корреляцию алертов: если сработал триггер на сканирование и одновременно видна попытка SMBv1-соединения с того же src - это комбинированный алерт с высоким приоритетом. Одиночные срабатывания - средний.
• Для клиентов без IDS выставили NetFlow-правила на порту 445 как промежуточное решение.

Результат пока скромный по данным - правила работают меньше месяца. Ни одного реального инцидента не поймали, зато поймали несколько администраторов с несогласованными скриптами сканирования. Это тоже полезно.

Оговорка, которую важно держать в голове

Correlation rules после конкретного инцидента - это детектор прошлой атаки. WannaCry использовал EternalBlue, поэтому правила заточены под EternalBlue. Следующий инструмент из арсенала Shadow Brokers с другим паттерном или другим портом эти правила не заметят. Это не аргумент против корреляционных правил - это аргумент против иллюзии, что «настроили SIEM» означает «защищены».

Работа по SIEM - итерационная. Правила появляются, уточняются, устаревают. Полезная часть - обвязка: процессы реагирования, ответственные за алерты, базовые профили нормального поведения. Без этого самые красивые correlation rules просто добавляют шум в очередь.