Sysmon v6 на 500 рабочих станциях: DNS-логирование сразу показало подозрительные хосты

Sysinternals выпустили Sysmon v6, и в этот раз список изменений заставил нас остановиться. DNS query logging - событие типа 22, которое пишет каждый DNS-запрос с хоста: имя домена, результат, процесс, который запросил. Для детектирования это совсем другой уровень видимости по сравнению с тем, что было.

Решили развернуть на одном из крупных проектов в управляемом сервисе - около 500 рабочих станций, Active Directory, события уже шли в ELK, но Sysmon раньше не стоял централизованно. Развернули через GPO, настроили конфиг и начали смотреть.

Что нового в v6

Три вещи, которые меняют картину мониторинга.

Первое - DNS query logging (Event ID 22). Раньше DNS-запросы с хостов не видел никто, кроме самого DNS-сервера, если там включено логирование. Теперь Sysmon пишет каждый запрос прямо на хосте: имя процесса, PID, запрашиваемое имя, тип запроса, результат. Это значит, что DGA-домены (те, что генерируются алгоритмически и используются C2-инфраструктурой) видно не в трафике, который ещё надо захватить на шлюзе, а прямо в логах хоста.

Второе - улучшенный WMI event monitoring. Sysmon теперь пишет создание WMI-подписок (Event ID 19, 20, 21) с более подробным контекстом. WMI-persistence - один из любимых механизмов атакующих именно потому, что он не оставляет явных следов вроде сервиса или записи в реестре запуска. Теперь подписка на WMI-событие пишется в лог с именем потребителя, фильтром и пространством имён.

Третье - именованные каналы (pipe events, Event ID 17/18). Подключение к именованному каналу - характерный признак ряда инструментов lateral movement. PsExec создаёт \pipe\PSEXESVC, Cobalt Strike Beacon по умолчанию использует \pipe\msagent_*. Теперь это событие в логах.

Как разворачивали

Sysmon v6 устанавливается как сервис через стандартный MSI. Разворачивали в два этапа: сначала тихая установка через GPO Computer Startup Script, потом отдельная политика для конфигурационного XML через реестр.

Конфиг делали на базе открытой конфигурации SwiftOnSecurity - там уже отфильтровано много шума от системных процессов, иначе DNS-события с 500 машин это поток, который легко перегружает Logstash. Основные решения:

• Фильтруем DNS-запросы к внутренним DNS-суффиксам (домен AD, внутренние зоны) - они не интересны для детектирования, только добавляют объём.
• Pipe events включаем полностью - там и так не очень много событий, фильтровать нечего.
• WMI-события включаем без фильтрации - в нормальной среде их немного, и любое подозрительное стоит видеть.

Передача событий в ELK - через Winlogbeat. Канал Windows Event Log, Sysmon пишет в Microsoft-Windows-Sysmon/Operational, Winlogbeat его читает и отправляет в Elasticsearch. Отдельный индекс для Sysmon-событий с разбивкой по Event ID.

Что показало DNS-логирование за первые дни

Вот здесь стало интересно. На третий день после развёртывания запрос к Kibana на DNS-события с нестандартными характеристиками вернул несколько хостов с обращениями к доменам, которые очень похоже на DGA-генерацию: длинные строки из случайных символов в зоне .tk и .pw, запросы шли пачками, результат - NXDOMAIN почти везде.

DGA-домены при активном C2 обычно недоступны: командный центр регистрирует только один-два из тысячи сгенерированных, остальные возвращают NXDOMAIN. Сам паттерн NXDOMAIN-запросов к доменам с высокой энтропией в имени - это довольно характерный сигнал.

На двух хостах нашли малварь, которую антивирус не детектировал. На одном - дропнутый файл, на другом - запись в планировщике задач, которая его периодически запускала. Как попало - пока выясняем, но судя по всему стандартный фишинг с документом.

Антивирус молчал. Sysmon за три дня показал.

Про объём и нагрузку

500 машин с DNS-логированием - это заметная нагрузка на ELK. У нас суммарно около 8-10 тысяч DNS-событий в минуту в пиковые часы. Elasticsearch справляется, но нужно правильно считать шардирование индекса и retention-политику: держать все DNS-события год - это уже разговор о терабайтах.

Пока оставили 90 дней для Sysmon-индекса. Для forensics этого должно хватить - если инцидент не заметили за три месяца, скорее всего дата компрометации ещё глубже и DNS-логи всё равно не помогут.

Что дальше

Детектирование по DNS - это только первый слой. Нужно строить правила: корреляция процесса, который делает запрос, с его обычным поведением; энтропия имени домена как признак DGA; редкие домены, которые никогда раньше не запрашивались из сети. Всё это требует правил в Elasticsearch или отдельного слоя аналитики.

Pipe events пока смотрим руками - правила для Cobalt Strike-паттернов ещё пишем. WMI-события тоже пока на ручном мониторинге: за две недели два реальных срабатывания, оба оказались легитимными корпоративными инструментами, которые используют WMI-подписки. Их занесли в whitelist.

Итого: Sysmon v6 - инструмент, который реально меняет видимость на Windows-хостах. DNS-логирование в нашем случае за три дня вернуло результат, который обосновывает всё развёртывание. Остальное - дело правил и терпения.