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

Одним прекрасным утром прилетела задача внедрить Sysmon вчера срочно. Естественно, первым, что я сделал зашел на github и нашел сборник конфигурационных файлов для sysmon. Выбрал тот, который понравился (имел больше отзывов и звезд).

После внедрения найденного конфига (естественно без предварительного анализа) обнаружил, что есть, то чего не должно быть и нет того, что ожидал увидеть.

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

1. Как можно меньше флуда без потери качества собираемых событий

2. Минимальная нагрузка на конечные устройства

3. Мониторим все, что не относится к нормальному поведению системы (создаем в основном исключения)

Что за зверь Ваш sysmon

Sysmon утилита разработанная Microsoft, которая дополняет, а в некоторых случаях помагает заменить расширенный аудит Windows, в части создания процессов, сетевой активности, доступа к файлам и (др). События генерируемые Sysmon можно посмотреть с помощью Event viewer по пути :

Applications and Services Logs/Microsoft/Windows/Sysmon/Operational

На момент написания статьи версия Sysmon 13.33, которая позволяет регистрировать 26 типов событий (+1 связанное с ошибками работы Sysmon).

Обзор синтаксиса

Конфигурационный файл sysmon представлен в формате xml. Рассмотрим несколько важных параметров, которые не относятся к фильтрации событий, но важны при использовании Sysmon.

• ArchiveDirectory. Определяет директорию в которую будут архивироваться удаляемые файлы и изменения буфера обмена, по умолчанию в директорию Sysmon логического диска, на котором установлена ОС.

• CheckRevocation. проверяет отозван ли сертификат, которым подписан исполняемый файл, по умолчанию: True.

• DnsLookup. Управляет обратным поиском DNS. значение по умолчанию: True

• DriverName. Использует указанное имя для драйвера Sysmon, по умолчанию: SysmonDrv

• HashAlgorithms. Хэш-алгоритмы, применяемые для определения хеш-суммы файлов, поддерживаемые алгоритмы: MD5, SHA1, SHA256, IMPHASH и * (все), по умолчанию: None

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

<Sysmon schemaversion="4.67">
	<HashAlgorithms>md5,sha256,IMPHASH</HashAlgorithms>
	<CheckRevocation>True</CheckRevocation>
	<DnsLookup>True</DnsLookup>
	<DriverName>CPUDrv</DriverName>
	
	<EventFiltering>

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

<FileCreateTime onmatch="exclude">
	<Image condition="image">OneDrive.exe</Image>
 </FileCreateTime>
 <ProcessCreate onmatch="exclude"></ProcessCreate>

Фильтровать события можно по всем полям которые есть в схеме того или иного события, например:

<Image condition="contains">ping.exe</Image>

Правило сработает, если в поле события Image будет содержатся ping.exe.

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

Процесс анализа и профилирования событий

Расскажу о том как я организовал процесс профилирования у себя, и с какими проблемами столкнулся при внедрении и разработки своего конфигурационного файла.

Использование конфигов с GitHub

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

Минусы

• Перед внедрением необходимо изучить конфигурационный файл, в большинстве случае это больше 1000 строк, и займет непонятно сколько времени

• Злоумышленник может изучить общедоступные конфиги при планировании атаки, чтобы использовать пути и имена файлов, которые содержатся в исключениях

Плюсы

• Если у Вас мало времени для внедрения Sysmon, использование готового конфига Вас спасет

• Правила уже смаплены на матрицу MITRE ATT&CK, для многих это важно

• Большое комьюнити, которое делится своими наработками (никто не запрещает использовать их в своем конфиге)

Профилирование

После принятия решения о разработке собственного конфигурационного файла, необходимо было решить следующие вопросы:

• Что мониторить?

• Что исключать?

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

1. На время создания основного конфига будет установлен наиболее подошедший под наши критерии общедоступный конфиг.

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

3. Параллельно siem-системе устанавливаем Elasticsearch+Kibana, для сбора событий с профилируемых машин.

4. Устанавливаем временные интервалы для анализа собираемых событий. Для этого мы сделали дашборды, которые показывают:

   • Машины по количеству собранных событий

   • Популярные процессы

   • Количество событий по EventID

5. Определить сколько времени Вы готовы выделить на профилирование, собираемых событий т.к впервое время их будет слишком много (порядка 1кк событий в сутки с машины администратора) и Ваш мониторинг будет выглядеть примерно так)

Собираем все что не относится к нормальному повидению системы

Следующий вопрос который нужно решить: Как смириться с тем, что определенные пути файлов или их имена попадут в исключения, ведь это верный вектор для defense evasion. Для себя я принял, что буду создавать правила как можно точно описывающее событие, которое добавляется в исключение.

Сила визуализации

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

1. Количество событий по EventID

2. Количество событий по источкам событий (конечные машины)

3. Количество событий по процессам

4. Heatmap количество конечных устройств/EventID

5. Heatmap количество конечных устройств/имя процесса

С помощью вышеуказанных дашбордов легко определить с какого EventID, процесса или конечного устройства начать профилирование, событий которые создают много шума.

Обзор конфига для профилирования

Для исходной точки создания конфига был выбран hunt-naked.xml. При его использовании будьте готовы, что первое время будет очень много флуда, настолько много, что в них можно будет утонуть. Но это не беда т.к. терпение и визуализация Kibana поможет нам впервые несколько часов уничтожить флудящие события.

Чтобы добавить исключения в конфиг необходимо использовать конструкцию:

<ImageLoad onmatch="exclude">
	<Image condtition="is">explorer.exe</Image>
</ImageLoad>

Или для создания связанной группы правил:

<ImageLoad onmatch="exclude">
	<Rule groupRelation="and">
    	<ParentImage condition="image">eventvwr.exe</ParentImage>
       <Image condition="is not">c:\windows\system32\mmc.exe</Image>
   </Rule>
</ImageLoad>

Остановимся на событиях, которые могут навредить конечному устройству. Если Вам не нужно записывать изменения буфера обмена и удаляемых файлов, отключаем EventID 23 и EventID 24, т.к. нагрузка на жесткий диск и уменьшение свободного места не заставит Вас долго ждать.

• EventID 23: FileDelete (File Delete archived). Файл был удален, и архиврован в директорию sysmon (по умолчанию C:\Sysmon). Если Вам не нужно архивирование удаляемых файлов, то можно использовать EventID 26. Например:

<RuleGroup groupRelation="or">
	<FileDelete onmatch="include">
		<Rule groupRelation="and">
			<TargetFilename condtion="contains">\Downloads\</TargetFilename>
			<TargetFilename condtion="contains any">exe;xlsx;xlsb;docx;docm;docxb;xlsm</TargetFilename>
		</Rule>	
	</FileDelete>
</RuleGroup>

• EventID24: ClipboardChange (New content in the clipboard) Этот тип события регистрируется когда изменяется содержимое буфера обмена.

Для отключения какого-либо правила используется конструкция вида (где FileDelete заменяется на необходимую категорию правил):

<FileDelete onmatch="exclude"></FileDelete>

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

Выводы

Потратив две недели и несколько часов в день на анализ срабатываний у Вас получится конфигурационный файл, исключающий нормальное поведение системы и включающий остальные события. Если у Вас возник вопрос: Можно ли на этом закончить? Однозначный ответ нет, необходимо продолжать работу по анализу собираемых событий, а также если у Вас есть pentest-группа привлечь их, к поиску того, что Вы пропустили или наоборот убрали лишнего. Не судите строго первый опыт написания подобного контента)