На последней конференции ZeroNights, в ходе неформального общения со своими коллегами по цеху — инженерами систем мониторинга, нам был задан простой на первый взгляд вопрос — распространено мнение, что для полноценного мониторинга эндпоинта с ОС Windows необходимо использовать Sysmon, а так ли это? И если да, то по каким конкретным причинам (привет Сереже!)? Однозначного комплексного ответа в своём багаже знаний или соответствующего сравнения на просторах интернета нам найти не удалось, поэтому прежде всего для себя, но и не в последнюю очередь для того, чтобы в последующем такой источник у сообщества всё-таки был, мы решили исследовать эту тему и сравнить события Windows и Sysmon на очной ставке. Как говорится, “1… 2… 3… Fight!”.

Введение

Любой специалист в области информационной безопасности вынужден работать в определенных рамках. Например, в рамках ограниченного бюджета — безопасность, за редким исключением, не является основным способом организации получить прибыль или выполнить иные функции в рамках основной деятельности. Поэтому в условиях лимитированных ресурсов, которыми обладает организация, сфере безопасности часто отводится лишь небольшая их часть с целью поддержания этого направления на минимально достаточном уровне (в соответствии с теми или иными требованиями). Даже при наличии неограниченных ресурсов всегда будут существовать иные ограничения, не позволяющие довести уровень безопасности до абсолюта. Это и пресловутые уязвимости нулевого или обычного дня (endless patch management), и постоянная гонка вооружений хакеров и безопасников, и динамичность развития ИТ-инфраструктуры, и многое-многое другое.

В этом свете как никогда актуален вопрос приоритезации средств и методов защиты, в том числе в направлении мониторинга. В этой области согласно статистике, приведённой на основе данных матрицы MITRE ATT&CK, про которую мы уже писали в прошлый раз, приоритеты расставляются следующим образом: безоговорочное первое место занимает такой источник событий безопасности, как эндпойнты.


Данный источник лидирует по количеству техник матрицы, которые можно выявить на основе регистрируемых на нем событий. Самой распространенной ОС для эндпоинтов остаётся Microsoft Windows. Сбор именно её логов в большинстве корпоративных инфраструктур даст наилучший результат по соотношению всех видов затрат к охвату устройств сети и покрытию техник злоумышленников. Это подтверждает статистика тех же авторов. Места 1-3, 5, 7, 8, 10 и частично 4 занимают как раз эти, так называемые базовые события.


Но, как в известном анекдоте, есть один нюанс. В последние годы широкое распространение получило мнение, что логи Windows нужно дополнить, если не заменить, событиями Sysmon — дескать они полнее, лучше, приспособленнее в качестве инструмента мониторинга с точки зрения ИБ.

Кроме того, такой подход в некотором роде отвечает концепции минимализма. Каждый программный продукт, который вы пытаетесь занести в свой или добровольно выданный вам заказчиком энтерпрайз — это увеличение площади атаки, затрат на администрирование и обновление, точек отказа. А часто — и просто времени до внедрения вашей системы мониторинга, пока ваш подход проходит согласование.

Sysmon же разработан специалистами Microsoft, а недавно и поглощен этой корпорацией, что даёт определённый уровень доверия со стороны ИТ. Кроме того, логи пишутся в виде .evtx журнала, что позволяет собирать и обрабатывать их теми же средствами и методами, что и обычные логи Windows.

Сразу оговоримся, что статья получилась большая, хоть мы и старались минимально дублировать и сжимать материал. Читатель, конечно, может сказать, отсылая нас к тому анекдоту про Ленина: “А мог бы и полоснуть...”. Или что “публикацию можно было разделить на две или три части для большей читаемости”. Но нам показалось, что не смотря на объем подготовленного материала, мы должны предоставить полноценный ответ на вопрос коллег по цеху, да и поиск так будет удобнее. Таким образом, чтобы не потерять ничего, рекомендуем ознакомиться со статьей 1 раз полностью, возможно, сделать для себя пометки и уже потом возвращаться к конкретным группам событий и копаться в них детально.

Для удобства добавим оглавление:
Введение
Оглавление
Формат сравнения
Создание процесса
Сетевые соединения
Завершение процесса
Загрузка драйвера
Доступ к процессу
Создание файла
Действия с реестром
Конфигурация WMI
Запросы DNS
Уникальные событий Sysmon
Фильтрация событий
Иные бесплатные поставщики базовых событий
Общий вывод

Формат сравнения

Зачем и что сравнивали, вроде бы понятно. А как это делалось и почему именно так?

Сравнение решили произвести в виде таблицы для каждой из групп событий, отражающих определённую активность в системе. Например, события с ID (Event ID, EID) 12, 13 и 14 в Sysmon, отражающие активность с реестром, даже не фильтруются по отдельности, хотя и говорят про разные атомарные действия. По подобной логике произведена и остальная группировка.

В такие группы включали только аналогичные события. Например, аналог события Sysmon EID 6 — событие Windows EID 6. При этом о загрузке драйверов есть ещё как минимум события 219 и 7036 Windows. Но они возникают в случае неуспеха. Т.е. не несут ту же смысловую нагрузку и, при необходимости, могут дополнять события Sysmon или Windows, в зависимости от того, что мы решили собирать.

Для групп событий, отражаемых в таблице, в виде строк представлены информативные (которые используются нами для целей мониторинга) поля, содержащиеся в событиях. Для каждого такого поля указано его наименование. Для Windows возможно 2 варианта, для xml и журнального представлений (кто бы мог подумать, что они будут совпадать?), если они отличаются больше, чем на пробелы. Это сделано, т.к. название поля, которое попадет в систему мониторинга, может зависеть от метода сбора. Также строки содержат данные события (для того, чтобы понять их формат) и комментарий (если по нашему мнению такой требуется).

Одинаковые по смысловой нагрузке поля для обоих источников объединены в одной строке. При отсутствии поля с аналогичной смысловой нагрузкой для одного из источников в полях, соответствующих ему, указаны прочерки ("-").

Строки, содержащие информацию о конкретной сущности, например, субъекте, совершающем действие, объединены в одну смысловую группу.

Сравнение производилось для версий Windows Kernel 6.3 (Windows 2012R2) и 10.0 (Windows 10, 2016, 2019). Более ранние версии не рассматривались, так как хотя ещё и распространены широко, но постепенно уходят. Если события для разных версий ядра не различались, колонки объединялись в одну для уменьшения дублирования.

Поскольку ставка очная, то колонки расположены в следующем порядке от центра к краям: данные, наименование поля, комментарий. Это делает сравнение более наглядным. Для визуального разделения колонок по источникам, к которым они относятся, используются цвета.

Уникальные для Sysmon EID (так как он в данном случае является дополняющим инструментом, запись логов ОС входит в базовый функционал ОС) приведены в отдельном разделе.

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

Создание процесса

Начать, как это ни парадоксально, решили с начала. А далее были так же не оригинальны и шли по порядку — по возрастанию EID Sysmon.

Включается логирование данных события в Windows следующим образом:

• Computer Configuration – Policies – Windows Settings – Security Settings – Advanced Audit Policy Configuration – Audit Policies – Detailed Tracking – Audit Process Creation – Success включает логирование самого события;

• Computer Configuration – Policies – Administrative Templates – System – Audit Process Creation – Include command line in process creation events — добавляет в событие командную строку запускаемого процесса, что часто позволяет отличить легитимный запуск от нелегитимного.

Сравнение в описанном выше формате представлено в следующей таблице.

Здесь и далее все таблицы представлены картинками и кликабельны. Так как, во-первых, мы не нашли хорошего способа перенести таблицы в Markdown или HTML с сохранением ширины столбцов или расстановкой переносов по существующему варианту в Excel. А во-вторых, их содержимое не слишком ценно для индексирования, разве что комментарии. Гораздо ценнее в таблицах — состав полей, обсуждаемый в этой статье, и формат данных, с которым вам придется работать, если будут использованы эти источнии событий.

Рассмотрим её по порядку, но не построчно — такой подробный анализ каждый для себя сделает сам. В этом разделе и далее будем останавливаться только на информации, встречаемой впервые. Сразу же начнем с примера такого поведения. Поля раздела System присутствуют в каждом событии, попадающем в журнал, вне зависимости от источника — Sysmon или Windows. Они включают в себя общую информацию:

• Название поставщика событий.
• EID.
• Время, когда событие попало в журнал.
• Название журнала, откуда мы это событие выцепили.
• Хост, на котором событие произошло.

Название поставщика и журнала после подключения обычно не используются аналитиком. Но они позволяют понять, куда и кто логи пишет, что немаловажно, если процесс сбора ещё не начался. Время, хост и EID — основные маяки, по которым производится первичная фильтрация событий.

Далее, среди полей, которые бы хотелось отметить особо — GUID как для сессии пользователя, так и для дочерних и родительских процессов существует только в логах Sysmon. И в эту же копилку, из странностей — ID процесса (нового и родительского) в событиях Windows записан в шестнадцатеричном виде, хотя в том же Task Manager он отображается в десятичном представлении. Как говорится, счастливой отладки ("-Want to improve? -Github")…

Командная строка при запуске процесса в событиях Windows имеет различный формат в зависимости от утилиты, использовавшейся для запуска. А вот в Sysmon авторы захотели и смогли — формат не зависит от прочих вводных. О причинах судить не возьмусь, но создатели контента для SIEM благодарности в Microsoft по этому поводу писать не будут, это уж точно.

Основной отличительной особенностью Sysmon как для этого, так и других событий, которые содержат данное поле, я бы назвал хэш исполняемого файла. Формат хэша выбирается в конфигурации Sysmon.

Опять же из дополнительных интересных бонусов Sysmon — поле Rule Name. Это, фактически, тег, которым удобно отмечать определенные фильтры в конфиг файле, а далее использовать его при анализе событий. Например, можно сказать, что запуск процесса X относится к тактике Y или технике Z. Такой подход интересен как с точки зрения аналитика, так и с точки зрения разработчика контента SIEM или Sysmon — позволяет понять причину, почему мы решили собирать данное событие.

Вывод

Для фиксации данной группы событий Sysmon подходит куда лучше:

• Уникальные GUID позволяют отслеживать только старт сессий и процессов, в то время как в большой инфраструктуре не мала вероятность, что, даже отфильтровав события конкретного хоста, вы можете обнаружить не уникальный ID процессов и вынуждены будете искать события их окончания (завершение процесса или сеанса пользователя). Забегая вперёд, скажу, что именно по этой причине вообще рассматривалась группа событий завершения процессов. Обычно необходимость в этих событиях не так и очевидна. Подход с использованием ID создает дополнительную работу для аналитика или нагрузку на используемый инструмент анализа, например, SIEM, который будет строить списки сессий и процессов в фоне. Наличие GUID, соответственно — большой плюс.
• Хэш процесса — на название образа запускаемого процесса или дополнительные текстовые сведения о нём мы бы сильно не ориентировались — кто знает, кем прикинулся зловред и не получилось ли у авторов подписать его сертификатом, который ещё не отозван. Жирный минус здесь — в Sysmon недоступна фильтрация по хэшу, её придётся организовывать на стороне SIEM (при необходимости). А если какой-то процесс запускается часто — это надо зафиксировать, создав дополнительную нагрузку на диск хоста и сеть. Самым неприятным местом будет, если ваш SIEM считает лицензионную квоту до фильтрации. Раньше так было, например, в IBM QRadar. Может, где-то есть и до сих пор. Но это замечание, скорее, не в рамках сравнения — в Windows не то, что фильтра такого нет, сам хэш не снимается.
• Про удобство Rule Name подробно уже сказали выше.
• Применимость остальных уникальных полей, что в событиях Windows, что в событиях Sysmon, играет роль, как говорится на англицком, case by case. Поэтому и принимать решение о выборе того или иного лога, или вообще их совмещения, тоже нужно case by case.

Сетевые соединения

Запись этих событий в Windows: Computer Configuration – Policies – Windows Settings – Security Settings – Advanced Audit Policy Configuration – Audit Policies – Object Access – Audit Filtering Platform Connection

Почему решили остановиться именно на событиях Windows Filtering Platform (WFP), а не Windows Firewall? Ответ прост. Исходя из нашей практики, на хостах так или иначе уже стоят эндпойнты в виде антивирусов. Они хоть и не предназначены для мониторинга базовых событий системы (по причине чего не подходят для наших целей), но тем не менее, в современных реалиях всегда имеют в своем составе хостовый межсетевой экран. По этой причине для исключения дублирования Windows Firewall обычно просто погашен. Соответственно, полковнику никто не пишет… WFP же, хотя и может осуществлять фильтрацию трафика, нами используется только для мониторинга. Поэтому дублирование отсутствует.

Из таблицы видно, что если мы попытаемся опереться на виндовые события, то УЗ пользователя и FQDN взаимодействующих хостов придётся восстанавливать обогащением событий. Хотя, если задуматься, для нас важнее знать какой процесс установил соединение, а не какой пользователь. Например, зловред идёт к своему C&C центру. Мы всё равно захотим узнать, кто запускал процесс или создать инцидент на основе понимания, что notepad в интернет сам не ходит (т.е. на основе имеющейся в событии информации).

А с FQDN всё ещё проще — все современные системы в качестве базового или дополнительного функционала включают компонент CMDB. А если и нет — точно стоит запастись сторонним решением. Знание своей инфраструктуры — основа ИБ в целом. Так что информация доступна либо через обогащение, либо через карточку актива, что позволит использовать её и в корреляции. Главное — по возможности, не забыть подключить логи DHCP, чтобы информация была актуальной.

Все другие уникальные поля не так существенны, например:

• Известные порты. Мы бы не полагались на это поле — не зря существуют средства выявления аномалий в трафике, когда, например, по 80 порту идёт не HTTP, а ssh туннель.
• Направление трафика. Зная идентификатор хоста (IP или FQDN) и источника\цели соединения, можно легко вычислить направление.

Вывод

И в этом случае Sysmon выигрывает, но уже менее значительно — GUID, FQDN, User дают удобство, которое вполне реально достичь с помощью SIEM или сторонних решений. Тем не менее, малые усилия — не значит нулевые.

Завершение процесса

В целом, событие, как уже писалось выше, не особо часто используется, но…

Если уж оно понадобится, то тут явный выигрыш на стороне Windows. Добавим только, как включить логирование, и перейдём сразу к выводам.

Computer Configuration – Policies – Windows Settings – Security Settings – Advanced Audit Policy Configuration – Audit Policies – Detailed Tracking – Audit Process Termination – Success

Вывод

В этом случае преимущество родного логирования ОС достигается за счёт:

• Отображения пользователя, завершившего процесс.
• Наличия Exit Code, который может говорить как о штатном завершении процесса, так и об ошибках.

Загрузка драйвера

Данное событие Windows, в отличие от остальных, включено по умолчанию и попадает в журнал System. Информативных полей в данных событиях не много.

И снова сразу к выводам.

Вывод

В этой группе события Sysmon дают аналитику гораздо больше полезной информации. Например, по событиям Windows даже непонятно, какой именно файл драйвера использовался. Поэтому в данной группе Windows в явных аутсайдерах.

Доступ к процессу

Эту группу событий мы бы не отнесли к базовым, скорее чуть продвинутый уровень. С точки зрения безопасности, событие может представлять большой интерес. Существует множество способов, как злонамеренный процесс может сделать ваш легитимный чуточку «лучше». Разумеется, не альтруизма ради, а злонамеренных действий для. И рассматриваемые события как раз помогут нам обнаружить многие варианты подобного творчества. Включаются эти логи в Computer Configuration — Policies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Audit Kernel Object — Success

У Windows тут два преимущества. Во-первых, отображение пользователя, от которого работает процесс-источник вмешательства. Как мы уже отмечали выше, преимущество обычно незначительное. А, во-вторых, HandleID и права доступа.

Если интерес к правам доступа понятен, то HandleID пригодится только для поиска смежных событий. Он необходим для организации взаимодействия пользователя через процессы с объектами ОС — такими же процессами (их потоками), файлами и т.д. Соответственно, дополнительные события могут показать, как, в результате чего и кому был выдан и когда был отозван требуемый handle для доступа.

Касаясь в первый раз темы объектов и handle, а также логирования действий с ними, важно отметить две вещи.

Во-первых, для логирования вышеуказанных дополнительных действий важно включить дополнительные настройки политик аудита, в частности Computer Configuration — Polcies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Audit Handle Manipulation — Success. При этом стоит помнить, что объём данных событий может быть очень велик. Handle выдается при поступившем запросе, соответственно, отражает истребованные права. Но почему мы можем не ждать такого же объёма событий непосредственно от аудита доступа к объектам?

Всё потому, что, во-вторых, необходимо включить SACL на объекте, который планируется контролировать. Фактически это перечень, аналогичный перечню прав доступа DACL, который определяет, получит субъект или объект, созданный с его токеном, успех или отказ при попытке доступа к объекту. Но SACL определяет в примерно той же форме не права по взаимодействию с объектом, а будут ли созданы события безопасности при запросе и реализации тех или иных прав. Эти события будут включать уже не запрошенные, а реально использованные права на доступ.

В итоге мы получаем фильтр, позволяющий логировать только доступ к объектам, которые для нас критичны и только те виды доступа, которые для нас важны. Но взамен мы должны на каждый такой объект навесить SACL напрямую или указать, что SACL наследуется от родительского объекта. Конечно, это можно автоматизировать различными методами. Но поддерживать конфигурацию таких средств автоматизации вряд ли будет удобно. В отличие от простого списка Sysmon, который также может включать в себя wildcards, пусть и своеобразные. О фильтрации в Sysmon мы поговорим в отдельном разделе.

К счастью, для объектов типа процесс SACL по умолчанию уже существует для ядра версии 6.3 и выше. Если кто-то может указать способ, как этот SACL получить (рекомендации из этой статьи нам выполнить не удалось), будет интересно услышать/обсудить.

На стороне Sysmon у нас кроме уже рассмотренных GUID-ов и Rule Name-ов есть ещё несколько интересных полей. Во-первых, PID процесса-цели. Он позволит отслеживать последующую активность инфицированного объекта, ведь инстансов из одного исполняемого файла может быть запущено несколько. Во-вторых, поле CallTrace, которое фиксирует действия источника событий в цели. Посмотришь на такое и поймёшь, что «ловкость рук и никакого мошенничества» — не просто слова. С другой стороны, такой подробный анализ — это уже удел форензики. А кто имеет выделенного форензика, тот скорее всего уже не в начале пути по построению системы мониторинга.

Вывод

В этой группе события различаются на довольно большое количество полей. Но если в событиях Windows эта информация скорее даёт удобство первичного анализа, то Sysmon фиксирует уникальные данные, которые сложно получить каким-либо другим способом. Поэтому преимущество остается за Sysmon.

Создание файла

Включается данная категория в Windows следующим образом: Computer Configuration — Polcies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Audit File System — Success

Как можно видеть из таблицы, все плюсы и минусы данной группы аналогичны уже описанным выше. В том числе плюсы и минусы SACL (для файлов и папок для всех (Everyone) пользователей включается Properties — Security — Advanced — Auditing — Add — Everyone — Success — Write (для файлов) или Modify (для директории)).

Также SACL на файлы можно задать глобально, определив его в Computer Configuration — Policies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Global Object Access Auditing — File System. Но количество событий, особенно с файлами типа временных, возрастёт пропорционально объёму операций. Не сказал бы, что это действенный подход, возможно только для маленькой части операций.

Хотелось бы отметить начинающиеся здесь странности логирования. Для этой группы не фиксируется событие Windows при создании файла через Powershell, например, New-Item C:\ForTest\test.t. При этом то же действие отображается в логах Sysmon на отлично.

Вывод

Данную группу событий лучше регистрировать с использованием Sysmon.

Действия с реестром

До сих пор, говоря о группе, мы включали в неё только одно событие. Здесь эта тенденция изменится.

Логирование этих событий настраивается так: Computer Configuration — Polcies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Audit Registry — Success.

SACL для всех (Everyone) пользователей задаётся следующим образом: regedit.exe — ветка реестра — Permissions — Advanced — Auditing — Everyone — Success — Advanced Permissions — Full Control или Set Value, Create Subkey, Create Link, Delete, Write DAC.

Также SACL на файлы можно задать глобально, определив его в Computer Configuration — Policies — Windows Settings — Security Settings — Advanced Audit Policy Configuration — Audit Policies — Object Access — Global Object Access Auditing — Registry. Минусы подхода аналогичны таким же операциям с файлами.

Сразу остановим внимание на ограничениях. Для Sysmon все операции (создание, изменение, удаление) с value или key порождают события (кроме переименования value). Для Windows:

• Все операции с value порождают события.
• Создание key не порождает события.
• Переименование key порождает только событие Access, новое имя ключа не отображается; запрашиваемые права, указанные в событии, не обладают интуитивно однозначным соответствием с операцией. Таким образом, операция переименования может быть определена только методом исключения — отсутствует событие удаления 4660 с данным HandleID.
• Удаление key порождает событие 4663 с последующим 4660.

Кроме рассмотренных в предыдущих разделах полей, важно отметить, что события Windows содержат старые и новые данные имён и значений key и value, что при расследовании может помочь понять мотив злоумышленника. Особенно, если начальные значения не являются стандартными или типовыми, а конфигурация, включающая данные реестра исследуемой машины, не сохраняется где-либо вне хоста.

Вывод

Как мы видим, на логирование Windows наложены более жёсткие ограничения. А для фиксирования некоторых фактов и вовсе нужна «корреляция», пусть и простейшая. Однако оно способно предоставить больший объём действительно полезной информации. Для этой группы событий предпочтение одному из участников отдать сложно.

Конфигурация WMI

Переходим к предпоследней группе событий. Это события WMI. Злоумышленник может создать фильтр (filter), получающий какие-либо события об изменении состояний системы, в нашем примере — изменение состояния сервиса. И выполнять на основании получаемых от этого фильтра событий определённые действия, создав потребителя (consumer). В нашем случае это запись в лог-файл. Далее он должен соединить выход фильтра с входом потребителя, создав связку (binding) между фильтром и потребителем. Получится система, срабатывающая при заданных условиях. Часто используется для тактики Persistence. Как раз в описанном порядке и фиксируются события 19-21 Sysmon.

Важно понимать, что само по себе создание фильтра или потребителя не несёт угрозы, но, безусловно, может являться частью атаки. При этом для злонамеренной активности могут использоваться уже существующий фильтр, потребитель или оба. Тут как с ножом, или, ближе к теме ресурса, с шифрованными мессенджерами. Вопрос не в инструменте, а в его использовании.

Детальнее разберёмся, глядя на таблицу.

Важный момент, который стоит отметить в первую очередь — событие 5861 генерируется в указанном журнале только на факт создания или последующей модификации (в том числе в части фильтра и потребителя) связки. Это, с одной стороны, упрощает отслеживание предположительно вредоносной активности (не нужна корреляция между двумя-тремя событиями), если в рамках неё создаётся не только связка. А с другой стороны, мы упускаем время начала этой активности, если фильтр или потребитель созданы именно в рамках неё и загодя.

Критично ли это? Case by case. Если мы начинаем разматывать последовательность инцидента и видим, что нетиповой и предположительно злонамеренный фильтр или потребитель были созданы два года назад, то мы сразу понимаем, что злоумышленники сидят у нас как дома уже два с лишним года. И следы атаки надо искать минимум на эту глубину. Часто ли такое бывает? Это основной вопрос.

Зато если изменения вносятся в фильтр или потребителя существующей связки, мы увидим полную картину целиком в одном событии. В то время, как Sysmon отразит только те изменения (тот объект), которые были произведены.

Среди других различий: в событиях Sysmon данные отражены в более структурированном виде и в более удобном формате. Например, вместо SID в нетипичном формате, сразу представлен логин пользователя. Но данных при этом немного меньше. Возможно, это критично именно для вашего кейса.

Завершим ограничениями. Во-первых, несмотря на то, что данный журнал присутствует с версии Windows 2012 (ядро 6.2), нам не удалось получить эти события даже для ядра 6.3 (2012R2), исследуемого в статье. Возможно, это связано с отсутствием каких-то патчей.

Во-вторых, если верить автору этой статьи, фильтр для событий по таймеру не фиксируется Sysmon. Можно было бы не верить на слово, а проверить. Тем более, что версия Sysmon указана старая. Но тут важен прецедент — типов фильтров и потребителей WMI не мало. Из такого исследования, дополненного деталями, можно было бы сделать отдельную статью. Просто тестируйте целевые типы, чтобы точно понимать, что они будут зарегистрированы.

Вывод

В этом случае мы склоняемся к тому, что использовать события Windows практичнее. Как с точки зрения удобства: большее количество данных, нет необходимости первичной корреляции. Так и с точки зрения целеполагания — фиксирует создание механизма (на основе новых, модифицируемых или существующих частей), а не его отдельных кусков.

Запросы DNS

Итак, мы переходим к заключительной сравниваемой группе, но ещё далеко не к заключению нашей статьи. Этот тип и соответствующее ему множество событий последние не только по появлению в нашей статье, но и по добавлению в инструментарий Sysmon.

За несколько предыдущих лет тема использования DNS не по назначению, например, для получения команд от C&C или хищения информации через этот канал, стала популярной. Скорее всего не сама по себе — рассказы о таком использовании каналов ICMP и DNS мы бы отнесли ещё к нулевым. В то время знакомые студенты изощрялись в инкапсулировании трафика игрушек с целью добраться по единственным разрешённым каналам до заветных игровых серверов из сети института (привет, Женя!). Это позволяло хоть как-то скоротать время на скучных или быстро освоенных ими лабах. И вряд ли это была их идея.

Но не так давно к этому каналу утечки добавилась такая концепция, как DoH, что усложнило обнаружение подозрительного DNS трафика на уровне сети.

А возможно, это был просто маркетинговый ход — продать новое, которое одновременно и хорошо забытое старое. Или начало широкого распространения таких каналов в обнаруживаемой злонамеренной активности. Глубоко в этом вопросе мы не копали, приготовились собирать крупицы — вдруг кто-то из читателей решит обронить немного мудрости в комментариях.

Итак, ближе к делу. Включаем Event Viewer — Application and Services Logs — Microsoft — Windows — DNS Client Events — Operational — Контекстное меню — Enable Log.

Всё то же, что уже обсуждали. Что касается информации о субъекте, обратим внимание на явное указание образа исполняемого файла, выполнившего запрос в событии Sysmon.

Если говорить об объекте — в логах Windows информации значительно больше. Но есть несколько важных «но». Во-первых, информация распределена по нескольким событиям со всеми вытекающими.

Во-вторых, информация представлена в неинтуитивном виде. Для расшифровки большей части требуются знания, о том как формируются поля пакета, и умение преобразовать эти данные обратно в факты, которые способствуют принятию аналитиком решения. Можно сказать, что, вообще-то аналитик не зря зарплату получает и почему бы ему не сесть и не разобраться. Да, всё так. Но напоминаю, мы говорим о маленькой команде без узкопрофильных специалистов, перед которой непочатый край задач по ИБ. И если по каждому событию, анализируемому SIEM, на него ляжет такая задача, он не нагонит их и за несколько лет.

Вывод

Для этой группы победителя определить сложно. Sysmon предлагает лаконичный вариант, из которого запросто можно выжать неплохую порцию полезной информации. Windows предлагает вариант для продвинутых. Его осталось «сшить», разобраться с наполнением и спросить себя, а не пора ли было внедрить NTA?

Уникальные событий Sysmon

К уникальным событиям Sysmon мы отнесли следующие:

• EID 4, 16. Хотя и можно отследить через журналы Windows, но они говорят нам только о событиях самого Sysmon. Соответственно, при его отсутствии смысла не имеют.
• EID 2 — в качестве аналога можно было бы считать EID 4663. Но даже с учётом предоставляемых в нём списков прав доступа, событие не является таким гранулярным, как EID2, и не обогащается до такого состояния иными событиями Windows.
• EID 7-9, 17 — не найдены аналоги. Можно попробовать получить их через ETW. О том, что это такое, поговорим в одном из следующих разделов.
• EID 15 — не найдены аналоги, отсутствуют аналоги в ETW. Это мы уже можем утверждать с уверенностью, так как используется дополнительный функционал — хэш.
• EID 18 — сетевое взаимодействие по именованным каналам (named pipes) можно отлавливать с помощью мониторинга сетевых соединений. Но, во-первых, это частный случай. А во-вторых, так как это иной уровень абстракции, то и информация о таком взаимодействии будет иная. Локальные пайпы должны фиксироваться тем же ETW.

Фильтрация событий

Существует три возможности фильтрации событий на стороне источников.

Первый доступен только для событий Windows и только для мониторинга доступа и операций с объектами. Осуществляется с помощью SACL. Среди минусов такого подхода — сложность гранулярной настройки (например, нельзя следить только за существующими или создаваемыми файлами с расширением .exe). Среди плюсов — возможность ограничить перечень пользователей, для которых фиксируются операции с объектом.

Второй доступен и для событий Windows, и для событий Sysmon: использование Xpath с учётом ограничений, налагаемых великим Microsoft. Так как метод доступен для обоих источников, описание вынесем за рамки данной статьи.

И третий — конфиг Sysmon. Тут есть множество вариантов:

• Эмуляция wildcard — contains (any|all), excludes (any|all), end with, begin with. С помощью contains|exludes all позволяют эмулировать выражения типа «C:\Windows\*.exe».
• Точные совпадение — is, is not, image.
• Арифметические — less than, more than.

Необходимо отметить, что такая фильтрация доступна не для всех полей. Например, нельзя составить белый список хэшей стандартного ПО, создание процессов которого нам не интересно. Пример из нашего опыта — легитимный процесс git.exe создавал десятки тысяч событий старта за сутки на хостах наших разработчиков. Возможно, конкретно в этом случае его поведение можно было подтюнить, уменьшив тем самым этот вал событий. Но исключать исполняемые файлы по имени образа — не самая хорошая идея. Ну, может быть, только антивирус со включённой самозащитой.

Также Sysmon пока только находится на пути к сложной фильтрации с помощью комбинирования условий из различных полей. Можно создать только одну группу правил для каждого EID, объединённых отношениями И, и только одну с отношениями ИЛИ. Соответственно, условия вида (A and B) or (C and D) уже не напишешь. В зависимости от фильтруемого потока, этот факт может как не давать никакого существенного преимущества, так и дать ощутимый результат.

Иные бесплатные поставщики базовых событий

В этом разделе, прежде всего, хотелось бы сказать о механизме ETW (Event Trace for Windows). И встроенные журналы Windows, и Sysmon регистрируют события, используя этот механизм. Фактически на каждое действие в системе мы можем получить событие. Проще всего посмотреть на потенциальный объём таких событий, включив опцию Event Viewer — View — Show Analytics and Debug log. Чтобы события разом не заполонили вашу систему, каждый журнал активируется отдельно в своём контекстном меню. Глянешь на это добро и невольно задашься вопросом — зачем нам Sysmon с таким объёмом разнообразных событий?

Дело в том, что, во-первых, эти логи изначально предназначены для отладки, а не для целей безопасности. Поэтому их централизованный сбор не предусмотрен. В частности, в них вы нигде не найдете FQDN хоста, на котором они были созданы. Вопрос, конечно, может быть решён сторонними утилитами от мала до велика, от скриптов до полноценных сервисов логирования. Но нужно помнить, что это дополнительное ПО в крупном энтерпрайзе, а соответственно, и отдельная задача. Напомню, что во введении мы исходили из принципа минимализма в дополнительной активности по установке ПО.

А во-вторых, эти логи настолько подробно сообщают о каждом чихе, что и информацию из них приходится выбирать по крупицам. Записи журнала действительно атомарны и для продуктивной работы аналитика потребуют предварительной корреляции или обогащения. Ведь программист, производящий отладку своего творения с помощью этих событий, знает, как всё должно было работать. А безопасник, особенно широкого профиля, мыслит гораздо более высокими уровнями абстракции. Да в добавок ищет неизвестную нелегитимную активность. Такая постановка задачи ведёт к дополнительному программному модулю, который осуществит предварительную обработку. Это опять усложнит нашу концепцию.

Пока мы недалеко ушли от логирования средствами Windows, не забудем упомянуть WMI. Этот инструмент в основном фиксирует изменения состояний, не отображая их источник. В качестве примера исключения — загрузка dll: отображает сам модуль dll и процесс, осуществляющий загрузку. Но для целей безопасности это событие также требует обогащения, так как этим его информация и исчерпывается. В целом, на безрыбье и рак — рыба. Но инструмент может использоваться только в качестве дополнительного.

Ещё один из популярных, но не рассмотренных в статье вариантов — osquery. Две основные причины, по которым мы не стали рассматривать здесь это решение — низкая частота обновления продукта (минус как с точки зрения безопасности, так и функциональности) и увеличенное, по сравнению с другими вариантами, использование системных ресурсов (в состав входит полноценная БД). Предположительно, решение хорошо подойдёт для серверов, для которых и разрабатывалось. Но для рабочих станций, возможно с устаревшим железом — вряд ли.

В последнее время появилось ещё несколько инструментов, которые распространены не так широко, как рассмотренные. К ним можно отнести Velociraptor и SilkETW. Велосипеда они не изобретают и также работают поверх стандарта Windows — ETW. В виду объёма уже приведённого материала было решено выделить данные инструменты в отдельную публикацию (по мере наличия времени и сил, а также ощущения востребованности).

Общий вывод

В ходе сравнения было показано, что события Sysmon, имеющие аналоги, обычно превосходят по своим функциональным характеристикам события Windows. Часть событий Sysmon просто не имеет альтернатив.

Однако не стоит забывать, что, во-первых, решение надо выбирать исходя из своих задач. Если вы только строите систему мониторинга и в первый год планируете реализовать методики обнаружения семи-десяти инцидентов, как завещал Gartner, то событий Windows вам должно хватить. И возможно, гораздо больше, чем на год.

Во-вторых, система логирования событий Windows тоже постоянно дополняется, и за время написания этой статьи появились такие Windows EID, как 4798 и 4799. Возможно также, что дополняется и набор полей. Таким образом, данное сравнение хоть и является наиболее полным, исходя из той информации, которой мы обладаем, но не высечено в камне.

А в-третьих, Sysmon пока является внешним инструментом, что влечёт за собой ряд рисков. Например, у нас были случаи, когда логирование отдельных EID прекращалось без объявления причины. При этом запись остальных событий шла как обычно. Более именитые коллеги утверждают, что проблема была связана с утечками памяти в версии 10.41. Но релиз 10.42, в котором эта проблема закрыта полностью или частично (с ченджлогом у Sysmon все не так подробно), не решил наших проблем в этом направлении. Помогает только удаление-установка компонента. Всем безопасности и хорошего дня!

Выражаю благодарность zinint за помощь в подготовке публикации.