Практика ИБ. Политики аудита безопасности Windows

Практика ИБ. Политики аудита безопасности Windows

Руслан Рахметов, Security Vision


В предыдущей статье мы описали принципы централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему. Логично, что чем больше данных мы собираем, храним и обрабатываем, тем проще нам будет обрабатывать инциденты ИБ и расследовать обстоятельства произошедших атак для поиска причин их возникновения (так называемый Root Cause Analysis, т.е. анализ корневых причин инцидентов информационной безопасности).

Проведение аудита безопасности также невозможно качественно осуществить без наличия системных журналов аудита ИБ. Однако, большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, логами, уведомлениями. Необходимо выбрать самые значимые с точки зрения ИБ события, обогатить их данными от сторонних средств защиты, скоррелировать между собой и эффективно осуществлять по ним поиск. Поэтому в настоящей статье мы сконцентрируемся на наиболее полезных и эффективных (с нашей точки зрения) политиках аудита безопасности и типах событий безопасности на примере ОС Windows, а также рассмотрим использование утилиты Sysmon для обогащения данных журналов аудита безопасности. Начнем!

Как мы уже писали в предыдущей части, начиная с Microsoft Windows Server 2008 и Vista в Windows используются политики расширенного аудита информационной безопасности, которые позволяют следить практически за всеми значимыми событиями безопасности. Пройдем последовательно по настройкам, эффективным для решения задач аудита ИБ и выработки целостной политики аудита безопасности.

Категория аудита

Подкатегория аудита

События аудита

EventID

Комментарии

Вход учетной записи

Аудит проверки учетных данных

Успех, Отказ

4776

Целесообразно контролировать на домен-контроллерах при использовании NTLM-аутентификации.

Аудит службы проверки подлинности Kerberos

Успех, Отказ

4771

Неуспешная аутентификация учетной записи на контроллере домена с использованием Kerberos-аутентификации.

4768

Запрос билета Kerberos, при этом следует анализировать коды ответа сервера.

Примечание:

Данный тип аудита следует включать на контроллерах домена, при этом для детального изучения попыток подключения и получения IP-адреса подключающегося устройства на контроллере домена следует выполнить команду nltest /dbflag:2080ffff и проводить аудит текстового лог-файла %windir%\debug\​netlogon.log

Управление учетными записями

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

Успех

4741

Заведение устройства в домен Active Directory. Может использоваться злоумышленниками, поскольку любой пользователь домена по умолчанию имеет возможность завести в домен 10 устройств с установленным на них не контролируемым компанией ПО, в том числе вредоносным.

Аудит управления группами безопасности

Успех, Отказ

4728

Добавление члена глобальной группы.

4732

Добавление члена локальной группы.

4756

Добавление члена универсальной группы.

Аудит управления учетными записями пользователей

Успех, Отказ

4720

Создание учетной записи.

4725

Отключение учетной записи.

4740

Блокировка учетной записи.

4723

Смена пароля.

4724

Сброс пароля.

Подробное отслеживание

Аудит создания процессов

Успех

4688

При создании процесса.

4689

При завершении процесса.

Примечание:

Для того чтобы для командного интерпретатора велась запись введенных команд, следует включить политику «Конфигурация компьютера - Конфигурация Windows - Административные шаблоны - Система - Аудит создания процессов -> Включать командную строку в события создания процессов».

Примечание:

Для того, чтобы велась запись выполняемых PowerShell-команд и загруженных PowerShell-модулей, следует включить в каталоге  «Конфигурация компьютера - Конфигурация Windows - Административные шаблоны - Компоненты Windows - Windows PowerShell» политики  «Включить ведение журнала модулей» (в настройках политики указать все модули символом  «*») и  «Включить регистрацию блоков сценариев PowerShell» (в настройках политики отметить check-box  «Регистрация начала или остановки вызова блоков сценариев»). Работа PowerShell-скриптов регистрируется с EventID=4104,4105,4106 в журнале Microsoft-Windows-PowerShell/Operational, а загрузка PowerShell-модулей регистрируется с EventID=800 в журнале Windows PowerShell.

Вход/выход

Аудит выхода из системы

Успех

4634

Для неинтерактивных сессий.

4647

Для интерактивных сессий и RDP-подключений.

Примечание:

При этом следует обращать внимание на код Logon Type, который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.).

Аудит входа в систему

Успех, Отказ

4624

При успешной попытке аутентификации. Создается на локальном ПК и на домен-контроллере при использовании NTLM и Kerberos-аутентификации.

4625

При неуспешной попытке аутентификации. Создается на локальном ПК и на домен-контроллере при использовании NTLM аутентификации; при Kerberos-аутентификации на контроллере домена создается EventID=4771.

4648

При попытке входа с явным указанием учетных данных, например, при выполнении команды runas, а также при работе «хакерской» утилиты mimikatz.

Примечание:

При этом следует обращать внимание на код входа (Logon Type), который показывает тип подключения (интерактивное, сетевое, с закэшированными учетными данными, с предоставлением учетных данных в открытом виде и т.д.). Целесообразно также обращать внимание на код ошибки (Status/SubStatus), который также сохраняется в событии аудита и характеризует причину неуспешного входа - несуществующее имя учетной записи, недействительный пароль, попытка входа с заблокированной учетной записью и т.д.

Аудит других событий входа и выхода

Успех, Отказ

4778

RDP-подключение было установлено.

4779

RDP-подключение было разорвано.

Аудит специального входа

Успех

4672

При входе с административными полномочиями.

Доступ к объектам

Аудит сведений об общем файловом ресурсе

Успех, Отказ

5145

При доступе к системных сетевым ресурсам, таким как \\C$\.

Данное событие будет создаваться при работе ransomware, нацеленного на горизонтальное перемещение по сети.

Аудит других событий доступа к объектам

Успех, Отказ

4698

При создании задания в «Планировщике задач», что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе.

Изменение политики

Аудит изменения политики аудита

Успех

4719

Изменение политики аудита.

4906

Изменение настройки CrashOnAuditFail.

Примечание:

Изменить реакцию ОС на невозможность вести журнал аудита безопасности (настройка CrashOnAuditFail) можно в каталоге  «Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры безопасности» в политике  «Аудит: немедленное отключение системы, если невозможно внести в журнал записи об аудите безопасности».

Система

Аудит расширения системы безопасности

Успех

4610

4614

4622

При появлении в системе новых пакетов аутентификации, что не должно происходить несанкционированно.

4697

При создании нового сервиса, что часто используется злоумышленниками как метод закрепления и скрытия активности в атакованной системе.

 

Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.

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

Не лишним также будет обратиться к таким документам, как Microsoft Security Compliance Toolkit и CIS Microsoft Windows Benchmarks, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита.

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита позволяет проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:\folder\sysmon64.exe -accepteula -i C:\folder\sysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe  –  файл-установщик.

Поддерживается запуск установки с сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational, размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется. Sysmon работает в виде сервиса, его исполняемый файл находится в C:\Windows\sysmon64.exe. По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

Интересные публикации