Настройка сбора данных о событиях Windows Configure Windows Event collection

Функции обнаружения Microsoft Defender для удостоверений Microsoft Defender for Identity анализируют определенные записи журнала событий Windows для расширения своих возможностей и предоставления дополнительных сведений о том, кто именно выполняет определенные действия, например вход через NTLM, изменение групп безопасности и действия при аналогичных событиях. Microsoft Defender для удостоверений Microsoft Defender for Identity detection relies on specific Windows Event log entries to enhance some detections and provide additional information on who performed specific actions such as NTLM logons, security group modifications, and similar events. Чтобы проводить аудит и включать в журнал событий Windows нужные события, контроллерам домена требуются точные параметры расширенной политики аудита. For the correct events to be audited and included in the Windows Event Log, your domain controllers require accurate Advanced Audit Policy settings. Неверные параметры расширенной политики аудита могут привести к тому, что требуемые события не будут записываться в журнал и охват Defender для удостоверений Defender for Identity будет неполным. Incorrect Advanced Audit Policy settings can lead to the required events not being recorded in the Event Log and result in incomplete Defender для удостоверений Defender for Identity coverage.

Чтобы расширить возможности обнаружения угроз, необходимо настроить следующие события Windows и обеспечить их сбор в Defender для удостоверений Defender for Identity : To enhance threat detection capabilities, Defender для удостоверений Defender for Identity needs the following Windows Events to be configured and collected by Defender для удостоверений Defender for Identity :

Для событий служб федерации Active Directory (AD FS) For Active Directory Federation Services (AD FS) events

• 1202 — служба федерации проверила новые учетные данные. 1202 — The Federation Service validated a new credential
• 1203 — службе федерации не удалось проверить новые учетные данные. 1203 — The Federation Service failed to validate a new credential
• 4624 — учетная запись успешно использована для входа в систему. 4624 — An account was successfully logged on
• 4625 — учетную запись не удалось использовать для входа в систему. 4625 — An account failed to log on

Для прочих событий For Other events

• 4726 — удаление учетной записи пользователя 4726 — User Account Deleted
• 4728 — добавление участника в глобальную группу безопасности 4728 — Member Added to Global Security Group
• 4729 — удаление участника из глобальной группы безопасности 4729 — Member Removed from Global Security Group
• 4730 — удаление глобальной группы безопасности 4730 — Global Security Group Deleted
• 4732 — добавление участника в локальную группу безопасности 4732 — Member Added to Local Security Group
• 4733 — удаление участника из локальной группы безопасности 4733 — Member Removed from Local Security Group
• 4741 — добавление учетной записи компьютера 4741 — Computer Account Added
• 4743 — удаление учетной записи компьютера 4743 — Computer Account Deleted
• 4753 — удаление глобальной группы рассылки 4753 — Global Distribution Group Deleted
• 4756 — добавление участника в универсальную группу безопасности 4756 — Member Added to Universal Security Group
• 4757 — удаление участника из универсальной группы безопасности 4757 — Member Removed from Universal Security Group
• 4758 — удаление универсальной группы безопасности 4758 — Universal Security Group Deleted
• 4763 — удаление универсальной группы рассылки 4763 — Universal Distribution Group Deleted
• 4776 — попытка проверки данных учетной записи контроллером домена (NTLM) 4776 — Domain Controller Attempted to Validate Credentials for an Account (NTLM)
• 7045 — установка новой службы 7045 — New Service Installed
• 8004 — проверка подлинности NTLM 8004 — NTLM Authentication

Настройка политик аудита Configure audit policies

Чтобы изменить расширенные политики аудита контроллера домена, выполните следующие инструкции. Modify the Advanced Audit Policies of your domain controller using the following instructions:

Войдите на сервер с правами администратора домена. Log in to the Server as Domain Administrator.

Загрузите редактор управления групповыми политиками из соответствующего раздела, последовательно выбрав Диспетчер сервера > Средства > Управление групповой политикой. Load the Group Policy Management Editor from Server Manager > Tools > Group Policy Management.

Разверните узел Подразделения контроллеров домена, щелкните правой кнопкой мыши элемент Политика контроллеров домена по умолчанию и выберите Изменить. Expand the Domain Controllers Organizational Units, right-click on Default Domain Controllers Policy, and then select Edit.

Для задания этих политик можно использовать политику контроллеров домена по умолчанию или выделенный объект групповой политики (GPO). You can use the Default Domain Controllers Policy or a dedicated GPO to set these policies.

В открывшемся окне последовательно выберите Конфигурация компьютера > Политики > Параметры Windows > Параметры безопасности и в зависимости от включаемой политики выполните следующие действия. From the window that opens, go to Computer Configuration > Policies > Windows Settings > Security Settings and depending on the policy you want to enable, do the following:

Для конфигурации расширенной политики аудита For Advanced Audit Policy Configuration

Перейдите в раздел Конфигурация расширенной политики аудита > Политики аудита. Go to Advanced Audit Policy Configuration > Audit Policies.

В разделе Политики аудита измените каждую из следующих политик и выберите Настроить следующие события аудита как для выполненных событий, так и для событий со сбоем. Under Audit Policies, edit each of the following policies and select Configure the following audit events for both Success and Failure events.

Политика аудита Audit policy	Подкатегория Subcategory	ИД активируемых событий Triggers event IDs
Вход учетной записи Account Logon	Аудит проверки учетных данных Audit Credential Validation	4776 4776
Управление учетными записями Account Management	Аудит управления учетными записями компьютеров Audit Computer Account Management	4741, 4743 4741, 4743
Управление учетными записями Account Management	Аудит управления группами распространения Audit Distribution Group Management	4753, 4763 4753, 4763
Управление учетными записями Account Management	Аудит управления группами безопасности Audit Security Group Management	4728, 4729, 4730, 4732, 4733, 4756, 4757, 4758 4728, 4729, 4730, 4732, 4733, 4756, 4757, 4758
Управление учетными записями Account Management	Аудит управления учетными записями пользователей Audit User Account Management	4726 4726
Система System	Аудит расширения системы безопасности Audit Security System Extension	7045 7045

Например, чтобы настроить Аудит управления группами безопасности, в разделе Управление учетными записями дважды щелкните Аудит управления группами безопасности и выберите Настроить следующие события аудита как для выполненных событий, так и для событий со сбоем. For example, to configure Audit Security Group Management, under Account Management, double-click Audit Security Group Management, and then select Configure the following audit events for both Success and Failure events.

Для локальных политик (ИД события: 8004) For Local Policies (Event ID: 8004)

• Групповые политики домена для получения событий 8004 в Windows должны применяться только к контроллерам домена. Domain group policies to collect Windows Event 8004 should only be applied to domain controllers.
• Когда датчик Defender для удостоверений Defender for Identity анализирует события Windows 8004, действия аутентификации NTLM Defender для удостоверений Defender for Identity обогащаются данными, к которым получает доступ сервер. When Windows Event 8004 is parsed by Defender для удостоверений Defender for Identity Sensor, Defender для удостоверений Defender for Identity NTLM authentications activities are enriched with the server accessed data.

Перейдите в раздел Локальные политики > Параметры безопасности. Go to Local Policies > Security Options.

В разделе Параметры безопасности настройте указанные политики безопасности следующим образом. Under Security Options, configure the specified security policies, as follows

Параметр политики безопасности Security policy setting	Значение Value
Сетевая безопасность: ограничения NTLM — исходящий трафик NTLM к удаленным серверам Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers	Аудит всего Audit all
Сетевая безопасность: ограничения NTLM — аудит проверки подлинности NTLM на этом домене Network security: Restrict NTLM: Audit NTLM authentication in this domain	Включить все Enable all
Сетевая безопасность: Ограничение NTLM: Аудит входящего трафика NTLM Network security: Restrict NTLM: Audit Incoming NTLM Traffic	Включить аудит для всех учетных записей Enable auditing for all accounts

Например, чтобы настроить Исходящий трафик NTLM к удаленным серверам, в разделе Параметры безопасности дважды щелкните Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам и выберите Аудит всего. For example, to configure Outgoing NTLM traffic to remote servers, under Security Options, double-click Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers, and then select Audit all.

Если вместо групповой политики выбрана локальная политика безопасности, добавьте в нее журналы аудита Вход учетной записи, Управление учетными записями и Параметры безопасности. If you choose to use a local security policy instead of using a group policy, make sure to add the Account Logon, Account Management, and Security Options audit logs in your local policy. При настройке расширенной политики аудита следует принудительно применить подкатегорию политики аудита. If you are configuring the advanced audit policy, make sure to force the audit policy subcategory.

Новые события, примененные с помощью объекта групповой политики, отображаются в журналах событий Windows. After applying via GPO, the new events are visible under your Windows Event logs.

Настройка сбора данных о событиях Configure event collection

В датчике Defender для удостоверений Defender for Identity сбор этих данных может происходить автоматически. Если датчик Defender для удостоверений Defender for Identity не развернут, события могут перенаправляться автономному датчику Defender для удостоверений Defender for Identity одним из следующих способов: These events can be collected automatically by the Defender для удостоверений Defender for Identity sensor or, if the Defender для удостоверений Defender for Identity sensor is not deployed, they can be forwarded to the Defender для удостоверений Defender for Identity standalone sensor in one of the following ways:

• Автономные датчики Defender для удостоверений Defender for Identity не поддерживают сбор записей журнала трассировки событий Windows (ETW), которые предоставляют данные для нескольких обнаружений. Defender для удостоверений Defender for Identity standalone sensors do not support the collection of Event Tracing for Windows (ETW) log entries that provide the data for multiple detections. Для полного охвата среды рекомендуется развернуть датчик Defender для удостоверений Defender for Identity . For full coverage of your environment, we recommend deploying the Defender для удостоверений Defender for Identity sensor.
• Важно просмотреть и проверить политики аудита перед включением сбора данных о событиях, чтобы убедиться, что контроллеры доменов настроены правильно для записи необходимых событий. It is important to review and verify your audit policies before enabling event collection to ensure that the domain controllers are properly configured to record the necessary events.

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows

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

Для выявления атаки на самой ранней стадии в ОС Windows есть три полезных событийных источника: журнал событий безопасности, журнал системного мониторинга и журналы Power Shell.

Журнал событий безопасности (Security Log)

Это главное место хранения системных логов безопасности. Сюда складываются события входа/выхода пользователей, доступа к объектам, изменения политик и других активностей, связанных с безопасностью. Разумеется, если настроена соответствующая политика.

Перебор пользователей и групп (события 4798 и 4799). Вредоносное ПО в самом начале атаки часто перебирает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих тёмных делишек. Эти события помогут обнаружить вредоносный код раньше, чем он двинется дальше и, используя собранные данные, распространится на другие системы.

Создание локальной учётной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377). Атака может также начинаться, например, с добавления нового пользователя в группу локальных администраторов.

Попытки входа с локальной учётной записью (событие 4624). Добропорядочные пользователи заходят с доменной учётной записью и выявление входа под локальной учётной записью может означать начало атаки. Событие 4624 включает также входы под доменной учетной записью, поэтому при обработке событий нужно зафильтровать события, в которых домен отличается от имени рабочей станции.

Попытка входа с заданной учётной записью (событие 4648). Такое бывает, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем такого не должно быть, поэтому такие события должны находиться под контролем.

Блокировка/разблокировка рабочей станции (события 4800-4803). К категории подозрительных событий можно отнести любые действия, которые происходили на заблокированной рабочей станции.

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

Подключение устройств Plug’n’play (событие 6416 и только для WIndows 10). За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, а тут вдруг раз — и подключили.

Windows включает в себя 9 категорий аудита и 50 субкатегорий для тонкой настройки. Минимальный набор субкатегорий, который стоит включить в настройках:

• Logon;
• Logoff;
• Account Lockout;
• Other Logon/Logoff Events.

Account Management

• User Account Management;
• Security Group Management.

Policy Change

• Audit Policy Change;
• Authentication Policy Change;
• Authorization Policy Change.

Системный монитор (Sysmon)

Sysmon — встроенная в Windows утилита, которая умеет записывать события в системный журнал. Обычно требуется его устанавливать отдельно.

Эти же события можно в принципе найти в журнале безопасности (включив нужную политику аудита), но Sysmon даёт больше подробностей. Какие события можно забирать из Sysmon?

Создание процесса (ID события 1). Системный журнал событий безопасности тоже может сказать, когда запустился какой-нибудь *.exe и даже покажет его имя и путь запуска. Но в отличие от Sysmon не сможет показать хэш приложения. Злонамеренное ПО может называться даже безобидным notepad.exe, но именно хэш выведет его на чистую воду.

Сетевые подключения (ID события 3). Очевидно, что сетевых подключений много, и за всеми не уследить. Но важно учитывать, что Sysmon в отличие от того же Security Log умеет привязать сетевое подключение к полям ProcessID и ProcessGUID, показывает порт и IP-адреса источника и приёмника.

Изменения в системном реестре (ID события 12-14). Самый простой способ добавить себя в автозапуск — прописаться в реестре. Security Log это умеет, но Sysmon показывает, кто внёс изменения, когда, откуда, process ID и предыдущее значение ключа.

Создание файла (ID события 11). Sysmon, в отличие от Security Log, покажет не только расположение файла, но и его имя. Понятно, что за всем не уследишь, но можно же проводить аудит определённых директорий.

А теперь то, чего в политиках Security Log нет, но есть в Sysmon:

Изменение времени создания файла (ID события 2). Некоторое вредоносное ПО может подменять дату создания файла для его скрытия из отчётов с недавно созданными файлами.

Загрузка драйверов и динамических библиотек (ID событий 6-7). Отслеживание загрузки в память DLL и драйверов устройств, проверка цифровой подписи и её валидности.

Создание потока в выполняющемся процессе (ID события 8). Один из видов атаки, за которым тоже нужно следить.

События RawAccessRead (ID события 9). Операции чтения с диска при помощи “\\.\”. В абсолютном большинстве случаев такая активность должна считаться ненормальной.

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

Создание named pipe и подключения (ID события 17-18). Отслеживание вредоносного кода, который коммуницирует с другими компонентами через named pipe.

Активность по WMI (ID события 19). Регистрация событий, которые генерируются при обращении к системе по протоколу WMI.

Для защиты самого Sysmon нужно отслеживать события с ID 4 (остановка и запуск Sysmon) и ID 16 (изменение конфигурации Sysmon).

Журналы Power Shell

Power Shell — мощный инструмент управления Windows-инфраструктурой, поэтому велики шансы, что атакующий выберет именно его. Для получения данных о событиях Power Shell можно использовать два источника: Windows PowerShell log и Microsoft-WindowsPowerShell / Operational log.

Windows PowerShell log

Загружен поставщик данных (ID события 600). Поставщики PowerShell — это программы, которые служат источником данных для PowerShell для просмотра и управления ими. Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр. За появлением новых поставщиков нужно следить, чтобы вовремя выявить злонамеренную активность. Например, если видите, что среди поставщиков появился WSMan, значит был начат удаленный сеанс PowerShell.

Microsoft-WindowsPowerShell / Operational log (или MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)

Журналирование модулей (ID события 4103). В событиях хранится информация о каждой выполненной команде и параметрах, с которыми она вызывалась.

Журналирование блокировки скриптов (ID события 4104). Журналирование блокировки скриптов показывает каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning.

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

Расскажите в комментариях, какие собираете логи для аудита информационной безопасности и какие инструменты для этого используете. Одно из наших направлений — решения для аудита событий информационной безопасности. Для решения задачи сбора и анализа логов можем предложить присмотреться к Quest InTrust, который умеет сжимать хранящиеся данные с коэффициентом 20:1, а один его установленный экземпляр способен обрабатывать до 60000 событий в секунду из 10000 источников.