Learn how to set up a Windows Event Collector and let your servers or clients send events to it with this Windows event collector tutorial.
Checking the events for one system is pretty easy. But checking events on just a few servers is not much fun. Fortunately Microsoft added a feature called Windows Event Collector, which allows us to centrally collect events from multiple servers and clients.
Table of Contents
Preparation
This tutorial will show you how to set up a collector server and how to let your servers send certain events.
I assume that the collector server is already installed and patched completely. The requirements are not different to any other server. Of course the logs will take up disk space, so ensure that sufficient space is available.
For the installation, you will need console or remote desktop access to the collector server and either console/remote desktop or PowerShell remoting access to a source server (I will use the term “source server” through this tutorial, but clients will work as well).
If you want to configure multiple server, I will show you how to configure them with group policies. A basic understanding of group policies is therefore required.
Collector server
Enable PS Remoting
Event collection with source computer initiated subscription (which we are going to use) requires PSRemoting to be enabled.
Run this powershell to enabled it:
Enable-PSRemoting
Start the collector service
The first step is to start the collector service. The easiest way is to access the Event Viewer on the collector server and click on Subscriptions. This will trigger the server to ask if you want to start the service:
Start collector service
Alternatively, you can use PowerShell to start the service:
Start-Service Wecsvc
Change permissions for Server 2016 and 2019
In earlier Windows server versions, the Windows event collector and Windows remote management use the same process. With Server 2016 and 2019 this behavior can be changed or changes automatically (When using more than 3.GB RAM on Server 2019) so that they are using different processes.
Therefore you have to adjust the permissions for the http endpoint.
Click here for more information from Microsoft.
Open an elevated prompt or PowerShell prompt and enter:
netsh http delete urlacl url=http://+:5985/wsman/
netsh http add urlacl url=http://+:5985/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)
netsh http delete urlacl url=https://+:5986/wsman/
netsh http add urlacl url=https://+:5986/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)
Create subscription
The next step is to create a subscription. A subscription defines which source servers will send which events to the collector.
Open the Event Viewer, right click on Subscriptions and select Create Subscriptions…
Create subscription
The subscription we are going to build will collect events indicating the usage of SMB version 1. So the subscription name is SMBv1 usage.
You can add a description, but this is not required.
The destination log specifies where the collected events will be stored in. Forwarded Events is the default value and this is what we are going with. If you are collecting multiple subscriptions, you can later define views to list your logs separately.
The subscription type defines which party initiates the communication. We will use Source computer initiated. I prefer this over collector initiated subscription as it does not require us to open inbound ports on the source server as the communication is triggered from the source servers. Plus we don’t have to handled user name and passwords or managed service accounts.
Click on Select Computer Groups… to add computers from which we want to receive events.
Add computer groups
The dialog title is computer groups, but you can add single computers too. Click Add Domain Computers… to select your servers, clients or group(s) and then OK to close this dialog.
Now you have to select which events are to be collected. Click on Select Events…
Select events
Here you can select from a large range of filters to get only the needed events. After defining your filters, click OK to close the dialog.
For advanced settings, click Advanced….
Advanced settings
This dialog allows you to tweak how the delivery of events is optimized. If you have requirements for bandwidth or latency (e.g. because you send events over WAN), choose one of the options.
For this tutorial I will use HTTP as the protocol. If you are using certificates already, change the protocol. Keep in mind that you have to change the URL for the subscription later.
Click OK to close the advanced settings and again OK to create your subscription.
Subscription added
Source server
Set target subscription manager
The first setting is which collector(s) the computer has to contact. As we are using source computer initiated subscriptions, the source computer has to contact the collector and therefore we have to tell him the URL of the collection service.
The easiest way is to the create a group policy.
The path is Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding > Configure target subscription manager
Enable the policy and add the entry
Server=http://FQDNofTheCollector:5985/wsman/SubscriptionManager/WEC,Refresh=60
If you want to use a different interval, change the refresh value accordingly or delete everything after the comma.
Have you set your collector to use HTTPS, change the protocol and use the port 5986 instead of 5985.
Define subscription manager
Alternatively you can use an elevated PowerShell prompt to add the required registry value:
New-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager" -Name "1" -Value "Server=http://FQDNofTheCollector:5985/wsman/SubscriptionManager/WEC,Refresh=60" -PropertyType REG_SZ -Force
With the subscription manager set, your source system fetches events to send from the collector.
Allow NT AUTHORITY\NETWORK SERVICE to read event logs
The event log service is executed as network service. This service by default does not have permission to read event logs. You have to add the account to the Event Log Readers group.
Add network service to Event Log Readers group
Add permissions for applications and services logs
The NT AUTHORITY\NETWORK SERVICE is now in the Event Log Readers group. This allows it to read the Windows logs “Application” und “System”.
If you want to forward events from other logs, you need to give the network service permissions for the logs.
To add permissions to logs, you need to know the internal name of that log. Open the event viewer and browse for you log. Right click on it and select Properties.
Copy the entry Full Name.
Event log properties
The permissions can be added either by command line:
wevtutil set-log EventLogFullName /ca:O:BAG:SYD:(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
For our example log, the command would be:
wevtutil set-log Microsoft-Windows-SMBServer/Audit /ca:O:BAG:SYD:(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
This command gives the local administrators full access and the network service (SID: S-1-5-32-573) read permissions.
Alternatively you can add the permission via a registry key. This also allows you to distribute the permissions with group policies.
Event log permissions distributed via group policies
The key is:
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\EventLogFullName
Value name: ChannelAccess
Value type: REG_SZ
Value: O:BAG:SYD:(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)
Restart the event log service after changing the registry.
Verify collection
At this point, your source servers should send you their events to the collector and the collector should list the events in “Forwarded events”.
To validate that all your source systems are forwarding, you can either check the source computer count in the event viewer. Open the Subscription folder and check the value in the column Source Computers.
Source computers count
If you like to have to have more information about your source server, open a command prompt and enter this command:
wecutil gr SubscriptionName
This will list all sources, their current status and the last time they contacted the collector.
Check source computer
Conclussion
Setting up an event collector is pretty easy. The only nasty thing is the permissions for the network service. If you set up your collector and added it to all your servers or clients, you have an easy-to-administrate infrastructure as any new log or event, you want to collect, just has to be added in the collector.
Настройка сбора событий с устройств Windows при помощи Агента KUMA (WEC).
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/248413.htm
Схема работы сбора с WEC (Windows Event Collector)
Рекомендации для сервера WEC
- Рекомендациям Microsoft по мощностям WEC сервера (4-8 CPU 16 GB) — https://docs.microsoft.com/en-us/troubleshoot/windows-server/admin-development/configure-eventlog-forwarding-performance
- Рекомендация использовать до 1500 станций на один сервер (максимум по указанным выше мощностям 4000 машин)
- на котроллеры домена не надо ставить ничего лишнего
- события с контроллеров домена необходимо собирать с использованием механизмов, рекомендуемых MS. В данном случае это будут серверы WEC
Отказоустойчивый сбор событий с WEC
- на котроллеры домена не надо ставить ничего лишнего
- события с контроллеров домена необходимо собирать с использованием механизмов, рекомендуемых MS. В данном случае это будут серверы WEC
В одной инсталляции, события на контроллерах домена хранятся очень мало – ротация примерно через 3-5 минут. Поэтому чтобы гарантировать доставку, если по какой-то причине WEС не доступен, предлагается следующая схема:
- использовать 2 WEC сервера
- все DC отправляют события не на один, а на 2 WEC сервера (события обоих WEC дублируются)
- на каждом WEC сервере установлены KUMA Agent
- оба KUMA Agent отправляют события в ОДИН и тот же коллектор Windows (это важный момент)
- на коллекторе Windows настраивается агрегация события, чтобы дубли событий с обоих WEC серверов были агрегированы в одно событий
С этим одним событием, прошедшее через такую сложную цепочку и работает KUMA. Это позволит выполнять обслуживание, перезагружать WEC коллекторы (но не одновременно), без потери потока данных с контролеров
Описание схемы работы с Windows Event Collector
Компоненты схемы:
- Источники событий (рабочие станции/серверы).
- Windows Event Collector сервер или WEC-сервер (сервер, с запущенной службой «Сборщик событий Windows». Данный сервер на основании создаваемых подписок на события получает события от источников и обеспечивает их локальное хранение. Взаимодействие между WEC-сервером и источниками событий осуществляется с использованием протокола удаленного управления Windows (WS-Management protocol). Для настройки доступно два типа подписок:
- Source—initiated subscriptions (Push) — события отправляются источником. Источники настраиваются на отправку событий на WEC-сервер с помощью GPO.
- Collector—initiated subscriptions (Pull) — события собираются WEC-сервером самостоятельно. WEC-сервер подключается к рабочим станциям/серверам и забирает события из локальных журналов.
- Агент KUMA (компонент KUMA, устанавливаемый на WEC-сервер для отправки собранных событий с источников в коллектор KUMA).
- Коллектор KUMA (компонент KUMA, обеспечивающий прием/нормализацию/агрегацию/фильтрацию событий, полученных от агента KUMA, и их дальнейшую отправку в коррелятор и/или хранилище KUMA).
В данном примере мы рассмотрим вариант Source-initiated subscriptions (режим Push) ввиду того, что этот режим более предпочтителен из-за отсутствия необходимости настройки «прослушивания» входящих соединений службой WinRM на источниках событий.
Также о Windows Event Collector можно почитать здесь: https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector.
Настройка политики аудита
По умолчанию на устройствах Windows аудит событий не осуществляется.
Настройка политики аудита на отдельной рабочей станции/сервере
Запустите оснастку Локальная политика безопасности (нажмите кнопку Win -> введите secpol.msc и запустите Локальная политика безопасности от имени администратора).
Перейдите в политику аудита (Локальные политики -> Политика аудита).
Настройте параметры аудита согласно скриншоту (при необходимости включите аудит оставшихся политик).
Примеры рекомендованных политик можно найти тут
Настройка политики аудита для группы рабочих станций/серверов средствами GPO
При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов настройки.
Создайте группу компьютеров средствами «Active Directory – пользователи и компьютеры». Добавьте в данную группу рабочие станции/серверы, с которых предполагается сбор событий.
Для того, чтобы изменения вступили в силу (в данном случае членство в новой группе), необходимо выполнить перезагрузку устройства. Альтернативным вариантом может быть перевыпуск Kerberos-тикетов для устройства с помощью klist.exe.
Если предполагается сбор событий с контроллера домена, в таком случае, контроллер домена можно не добавлять в созданную группу компьютеров, добавив отдельно в Фильтр безопасности при настройке GPO
На контроллере домена запустите оснастку Управление групповой политикой (нажмите Win + R -> gpmc.msc).
Выберите существующий объект групповой политики или создайте новый. В данном примере создается новый объект групповой политики Audit Policy for KUMA (правой кнопкой мыши Объекты групповой политики -> Создать -> введите в имени Audit Policy for KUMA).
Далее выберите созданный объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Политики аудита и настройте параметры аудита согласно скриншоту (при необходимости включите аудит оставшихся политик).
Далее вернитесь в Управление групповой политикой -> выберите объект групповой политики Audit Policy for KUMA -> в окне справа Фильтры безопасности удалите группу Прошедшие проверку и добавьте группу KUMA WEC.
Нажмите правой кнопкой мыши на домен и выберите Связать существующий объект групповой политики -> выберите Audit Policy for KUMA и нажмите ОК.
Итоговый вид политики должен выглядеть следующим образом (см. скриншот).
В целом, групповые политики Active Directory можно назначать на OU, сайт или весь домен.
Для того, чтобы новые параметры аудита, заданные в GPO, были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:
- перезагрузка устройства и вход пользователя
- автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени)
- вручную с помощью команды gpupdate (на рабочей станции/сервере)
- вручную из консоли Group Policy Management Console (на контроллере домена, только для OU)
- вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена)
Для проверки успешного применения GPO запустите оснастку Локальная политика безопасности на одной из рабочих станций/сервере (нажмите WIN + R -> введите secpol.msc и запустите Локальная политика безопасности от имени администратора) -> перейдите в политику аудита (Локальные политики > Политика аудита) -> убедитесь, что параметры аудита соответствуют скриншоту.
Примеры рекомендованных политик аудита можно найти тут
Настройка WEC-сервера
Настройка службы Windows Event Collector (WEC)
Проверьте наличие запущенной службы WinRM на WEC-сервере с помощью следующей команды в PowerShell:
Test-WSMan
Вывод в случае если служба WinRM запущена:
Если появилось сообщение, что «Клиенту не удается подключиться к узлу назначения, указанному в запросе. Убедитесь, что служба на узле назначения работает и принимает запросы», запустите на WEC-сервере службу WinRM с помощью следующей команды в PowerShell:
winrm qc
При применении команды согласиться с выполнением изменений. После включения службы WinRM WEC-сервер начнет «прослушивать» соединения на порт TCP/5985 от источников событий.
Команда winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно следующей командой:
winrm set winrm/config/Winrs ‘@{AllowRemoteShellAccess = "false"}’
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’ # проверка, что WinRS отключен
Включите на WEC-сервере службу сборщика событий Windows («Сборщик событий Windows») с помощью следующей команды в PowerShell:
wecutil qc
При включении службы сборщика событий Windows в Windows Firewall автоматически создается разрешающее правило для входящих соединений по TCP/5985.
Настройка подписки на WEC-сервере
Нажмите кнопку Win, введите eventvwr.msc и запустите Просмотр событий от имени администратора. Выберите Подписки -> правой кнопкой мыши Создать подписку -> Укажите имя подписки, например, KUMA WEC и тип подписки Инициировано исходным компьютером.
Выберите группы компьютеров, события которых требуется собирать. В нашем примере – это KUMA WEC (Выбрать группы компьютеров -> Добавить доменный компьютер -> в поле Введите имена выбираемых объектов укажите ранее созданную группу компьютеров и нажмите ОК).
В качестве альтернативы вместо группы компьютеров можно добавить необходимые рабочие станции/серверы по отдельности.
Если предполагается сбор событий с контроллера домена, в таком случае, контроллер домена можно добавить как отдельный доменный компьютер
Задайте собираемые события (Выбрать события -> Настройте параметры, как на скриншоте ниже). В данном примере с источников собираются следующие события (Рекомендованные ID события можно найти тут): 4624,4625,4662,4719,4720,4722,4724,4725,4726,4728,4729,4739,4740,4767,4768,4769,4771,5136.
Нажмите ОК.
Далее перейдите в Дополнительно и для параметра Оптимизация доставки событий укажите Уменьшенная задержка. Нажмите ОК.
В одну подписку можно добавить не более 22 уникальных Event ID (кодов событий). Если указать больше, то на стороне источников событий (Журналы приложений и служб/Microsoft/Windows/Eventlog-ForwardingPlugin/Operational) появится ошибка «Не удается создать подписку <Наименование подписки>. Код ошибки: 5004.», при этом события от источников перестанут поступать на WEC-сервер.Поэтому, если стоит задача собирать большое количество разных типов событий, в таком случае создайте несколько подписок, в каждой из которых будет свой уникальный набор Event ID.
Если в подписке не задан фильтр по Event ID, то есть используется значение по умолчанию «<Все коды событий>», ограничение в 22 уникальных Event ID отсутствует и выполняется сбор всех журналируемых событий.
При наличии одинаковых Event ID в разных подписках, события будут дублироваться, как на WEC-сервере, так и в KUMA. Поэтому при создании нескольких подписок проверьте наличие дубликатов Event ID.
Настройка WinRM и подписки на источниках событий
Для отдельной рабочей станции/сервера
Настройка службы WinRM
Проверьте наличие запущенной службы WinRM на рабочей станции/сервере с помощью следующей команды в PowerShell:
Test-WSMan
Вывод в случае, если служба WinRM запущена:
Если появилось сообщение, что «Клиенту не удается подключиться к узлу назначения, указанному в запросе. Убедитесь, что служба на узле назначения работает и принимает запросы», запустите на рабочей станции/сервере службу WinRM с помощью следующей команды в PowerShell:
winrm qc
При применении команды согласиться с выполнением изменений, кроме «Служба WinRM не настроена на разрешение удаленного управления компьютером. Разрешите исключение брандмауэра WinRM».
После включения службы WinRM рабочая станция/сервер начнет «прослушивать» соединения на порт TCP/5985. Для отключения данного listener’а (т.к. рабочая станция/сервер инициирует соединение к WEC-серверу, выступая в качестве клиента) выполните следующую команду в PowerShell:
Remove-WSManInstance winrm/config/Listener -SelectorSet @{Address="*";Transport="http"}
Команда winrm qc
одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно следующей командой:
winrm set winrm/config/Winrs ‘@{AllowRemoteShellAccess = "false"}’
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’ # проверка, что WinRS отключен
На источнике событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers («Читатели журнала событий»).
Для этого нажмите кнопку Win -> введите lusrmgr.msc и запустите Локальные пользователи и группы от имени администратора. В появившемся окне выберите перейдите в Группы -> выберите группу Читатели журнала событий -> правой кнопкой мыши Свойства -> Добавить -> в Размещение выберите имя рабочей станции -> в поле Введите имена выбираемых объектов укажите NETWORK SERVICE -> Проверить имена -> как только УЗ будет найдена нажмите ОК.
Для сбора событий журнала Security с контроллера домена необходимо предоставить доступ к журналу встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20), из-под которой запускается сервис WinRM.
Для этого на контроллере домена в PowerShell выполните следующую команду:
wevtutil sl security /ca:’O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)’
Настройка подписки
Нажмите кнопку Win -> введите Политики и запустите Изменение групповой политики от имени администратора. В появившемся окне перейдите в Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Пересылка событий -> Настроить конечный диспетчер подписки. Выберите Включено и нажмите Показать. В появившемся окне введите параметры WEC-сервера:
Server=http://<обязательно FQDN (не IP !!!) WEC-сервера>:5985/wsman/SubscriptionManager/WEC,Refresh=60
где 60 – частота обращения (в секундах) источников событий к WEC-серверу за новыми инструкциями по пересылке журналов.
Источники событий должны иметь возможность «резолвить» FQDN WEC-сервера для отправки событий. Для этого создайте A-запись на DNS-сервере или создайте запись локально в файле hosts
После применения данной настройки перезапустите службу WinRM c помощью PowerShell-команды:
Restart-Service -Name WinRM
Для группы рабочих станций/серверов средствами GPO
Настройка службы WinRM
При наличии опыта администрирования Windows инфраструктуры вы можете использовать наиболее привычный для Вас способ настройки. Ниже описан один из вариантов.
На контроллере домена запустите оснастку Управление групповой политикой (нажмите Win + R -> gpmc.msc).
Выберите ранее использовавшийся объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Системные службы -> в списке служб найдите «Служба удаленного управления Windows (WS—Management)» -> Свойства -> укажите параметры согласно скриншоту ниже. Нажмите Применить и ОК.
Далее перейдите в Конфигурация компьютера -> Настройка -> Параметры панели управления -> Службы -> справа в окне нажмите Создать -> Службы -> укажите параметры согласно скриншоту ниже.
Перейдите во вкладку Восстановление и укажите параметры согласно скриншоту ниже. Нажмите Применить и ОК.
Перейдите в Конфигурация компьютера -> Политики -> Административные шаблоны -> Компоненты Windows -> Удаленное управление Windows -> Служба удаленного управления Windows -> выберите Разрешить удаленное администрирование сервера средствами WinRM и укажите параметры согласно скриншоту ниже.
Перейдите в Конфигурация компьютера -> Политики -> Административные шаблоны -> Компоненты Windows -> Удаленное оболочка Windows -> выберите Разрешить доступ к удаленной оболочке и укажите параметры согласно скриншоту ниже.
Также на источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers («Читатели журнала событий»).
Для этого выберите ранее использовавшийся объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера -> Настройка -> Параметры панели управления -> нажмите правой кнопкой мыши на Локальные пользователи и группы -> Создать -> Локальная группа. В появившемся окне укажите параметры согласно скриншоту ниже. Нажмите Применить и ОК.
При добавлении члена локальной группы введите NETWORK SERVICE и нажмите ОК.
Для того, чтобы новые параметры групповой политики Audit Policy for KUMA были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:
- перезагрузка устройства и вход пользователя
- автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени)
- вручную с помощью команды gpupdate (на рабочей станции/сервере)
- вручную из консоли Group Policy Management Console (на контроллере домена, только для GPO)
- вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена)
Проверьте наличие запущенной службы WinRM на одной из рабочих станций/сервере с помощью следующей команды в PowerShell:
Test-WSMan
Вывод в случае, если служба WinRM запущена:
Убедитесь, что WinRS отключен с помощью следующей команды:
winrm get winrm/config | findstr ‘AllowRemoteShellAccess’
Убедитесь, что порт TCP/5985 не «прослушивается» (т.к. рабочая станция/сервер инициирует соединение к WEC-серверу, выступая в качестве клиента):
netstat -aon -p TCP # выполнить в cmd
Для сбора событий журнала Security с контроллера домена необходимо предоставить доступ к журналу встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20), из-под которой запускается сервис WinRM.
Для этого на контроллере домена в PowerShell выполните следующую команду:
wevtutil sl security /ca:’O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)’
Настройка подписки
Выберите ранее использовавшийся объект групповой политики Audit Policy for KUMA и нажмите Изменить.
В открывшемся Редакторе управления групповыми политиками перейдите в Конфигурация компьютера -> Политики -> Административные шаблоны -> Компоненты Windows -> Пересылка событий -> Настроить конечный диспетчер подписки. Выберите Включено и нажмите Показать. В появившемся окне введите параметры WEC-сервера:
Server=http://<обязательно
FQDN сервера-коллектора>:5985/wsman/SubscriptionManager/WEC,Refresh=60
где 60 – частота обращения (в секундах) источников событий к серверу за новыми инструкциями по пересылке журналов.
Источники событий должны иметь возможность «резолвить» FQDN WEC-сервера для отправки событий. Для этого создайте A-запись на DNS-сервере или создайте запись локально в файле hosts
Для того, чтобы новые параметры групповой политики Audit Policy for KUMA были применены на рабочих станциях/серверах Windows необходимо выполнить обновление групповых политик. Настройки групповых политик обновляются в следующих случаях:
- перезагрузка устройства и вход пользователя
- автоматически в фоновом режиме раз в 90 минут (+ случайное смещение времени)
- вручную с помощью команды gpupdate (на рабочей станции/сервере)
- вручную из консоли Group Policy Management Console (на контроллере домена, только для OU)
- вручную с помощью командлета Invoke-GPUpdate Powershell (на контроллере домена)
Проверка поступления событий
Убедитесь, что на WEC-сервер поступают события с рабочих станций/серверов. Для этого нажмите кнопку Win, введите eventvwr.msc и запустите Просмотр событий от имени администратора. Перейдите в Журналы Windows -> Перенаправленные события. Если в появившемся окне Перенаправленные события отображаются события с источников, значит подписка работает корректно.
Для MS Server 2016 и 2019 в случае если события не пересылаются, выполнить шаги по этой инструкции. При добавлении разрешения для URL-адреса с помощью netsh http add urlacl добавьте кавычки «…» в параметре SDDL:netsh http delete urlacl url=http://+:5985/wsman/
netsh http add urlacl url=http://+:5985/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"
netsh http delete urlacl url=https://+:5986/wsman/
netsh http add urlacl url=https://+:5986/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"
В случае если определенный лог не отправляется от источника проверьте на нем в журнале Microsoft/windows/event_forwardingPlugin/Operational
события с кодом 5004 (ошибка отправки логов в wec сервер), если там есть такие события, то выполните рекомендации по этой статье: https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/system-management-components/security-event-log-forwarding-fails-error-0x138c-5004
Настройка коллектора и агента KUMA
Создание коллектора KUMA
Для создания коллектора в веб-интерфейсе KUMA перейдите на вкладку Ресурсы -> Коллекторы и нажмите на кнопку Добавить коллектор. Также можно на вкладке Ресурсы нажать на кнопку Подключить источник событий.
После выполнения вышеуказанных действий откроется мастер настройки. На первом шаге выберите Имя коллектора и Тенант, к которому будет принадлежать создаваемый коллектор.
На втором шаге мастера укажите транспорт. В данном случае рекомендуется использовать http. В поле URL задайте FQDN/порт (выбирается любой из незанятых), на котором коллектор будет ожидать соединение от агента. В качестве разделителя укажите \0.
*можно указать только порт при инсталляции All-in-one.
На вкладке Дополнительные параметры для шифрованной передачи данных между агентом и коллектором выберите Режим TLS — С верификацией.
На третьем шаге мастера укажите нормализатор. В данном случае рекомендуется использовать предустановленный расширенный нормализатор для событий Windows актуальный для версии 3.2 — [OOTB] Microsoft Products for KUMA 3.
Шаги мастера настройки с четвертого по шестой можно пропустить и вернуться к их настройке позднее.
На седьмом шаге мастера задайте точки назначения. Для хранения событий добавьте точку назначения типа Хранилище. В случае если предполагается также корреляция по событиям добавьте точку назначения типа Коррелятор.
На завершающем шаге мастера нажмите на кнопку Создать и сохранить сервис. После чего появится строка установки сервиса, которую необходимо скопировать для дальнейшей установки.
Также после выполнения вышеуказанных действий на вкладке Ресурсы -> Активные сервисы появится созданный сервис коллектора.
Установка коллектора KUMA
Выполните подключение к CLI KUMA (установка коллектора выполняется с правами root).
Для установки сервиса коллектора в командной строке выполните команду, скопированную на прошлом шаге.
При необходимости добавьте порт коллектора в исключения фаервола и обновите параметры службы.
firewall-cmd --add-port=<порт, выбранный для коллектора>/tcp –permanent
firewall-cmd --reload
После успешной установки сервиса его в статус в веб-консоли KUMA изменится на зеленый.
Создание агента KUMA
Для создания агента в веб-интерфейсе KUMA перейдите на вкладку Ресурсы -> Агенты и нажмите на кнопку Добавить агент.
В открывшейся вкладке Общие параметры укажите Имя агента и Тенант, к которому он будет принадлежать.
На вкладке Подключение 1 в параметрах коннектора задайте имя коннектора, тип wec и выберите из выпадающего списка журналы Windows типа ForwardedEvents. Также можно в ручном режиме задать дополнительные журналы Windows.
В секции Точки назначения укажите имя точки назначения, тип http (должен совпадать с настройками коллектора). Задайте URL в формате fqdn:port (FQDN коллектора и порт, должны совпадать с настройками коллектора).
В дополнительных параметрах укажите Режим TLS С верификацией, если требуется шифровать соединение между коллектором и агентом (настройка должна совпадать с соответствующей на стороне коллектора). Укажите разделитель \0 (должен совпадать с настройками коллектора). Также на изображении ниже приведены дополнительные параметры и их рекомендуемые значения.
После настройки дополнительных параметров сохраните созданный ресурс агента.
Публикация агента KUMA
В разделе Ресурсы -> Активные сервисы опубликуйте созданную конфигурацию KUMA Windows Agent. Для этого нажмите Создать сервис -> выберите созданный сервис агента Windows WEC Agent и нажмите Создать сервис.
После публикации сервиса скопируйте id данного сервиса для последующей установки на WEC-сервере.
Установка агента KUMA
Создание сервисной учетной записи
Для функционирования агента KUMA необходимо создать доменную сервисную учетную запись, с помощью которой будет выполняться запуск агента KUMA и обеспечиваться доступ к журналам событий, полученных от источников (рабочих станций/серверов).
Добавление сервисной учетной записи в группу «Читатели журнала событий»
На WEC-сервере добавьте созданную сервисную учетную запись в локальную группу Читатели журнала событий. Для этого нажмите кнопку Win, введите lusrmgr.msc и запустите Локальные пользователи и группы от имени администратора. В появившемся окне выберите перейдите в Группы -> выберите группу Читатели журнала событий -> правой кнопкой мыши Свойства -> Добавить -> в поле Введите имена выбираемых объектов укажите <имя сервисной учетной записи> -> Проверить имена -> как только УЗ будет найдена нажмите ОК.
Назначение прав входа в качестве службы
На WEC-сервере разрешите сервисной учетной записи вход в качестве службы. Для этого нажмите кнопку Win, введите secpol.msc и запустите Локальная политика безопасности от имени администратора. В появившемся окне выберите перейдите в Локальные политики -> Назначение прав пользователя -> Выберите политику Вход в качестве службы -> правой кнопкой мыши Свойства -> Добавить пользователя или группу -> в поле Введите имена выбираемых объектов укажите <имя сервисной учетной записи> -> Проверить имена -> как только УЗ будет найдена нажмите ОК.
Дополнительно убедитесь, что соответствующая сервисная учетная запись отсутствует в свойствах политики Отказать во входе в качестве службы.
Установка агента KUMA
Выполняется на WEC-сервере, который обеспечивает прием событий от источников (рабочих станций/серверов). Предварительно FQDN Core KUMA должен быть добавлен в файл hosts на WEC-сервере, либо добавлен на DNS-сервере.
На WEC-сервере рекомендуется создать папку C:\Users\<имя пользователя>\Desktop\KUMA.
Далее скопируйте в данную папку исполняемый файл kuma.exe.
Файл kuma.exe находится в архиве пакетов установки KUMA.
Для установки агента KUMA запустите командную строку с правами администратора.
Примите лицензионное соглашение: C:\Users\<имя пользователя>\Desktop\KUMA\kuma.exe license
Перейдите в папку C:\Users\<имя пользователя>\Desktop\KUMA
Запустите установку агента командой:
C:\Users\<имя пользователя>\Desktop\KUMA>kuma.exe agent --core https://<DOMAIN-NAME-KUMA-CORE-Server>:7210 --id <Windows Agent ID> –-user <Имя сервисной доменной УЗ> --install
Если агент устанавливается из-под доменной учетной записи пользователь указывается в формате <домен>\<имя учетной записи>, например, demo\user
Во время установки сервиса система запросит пароль. Введите пароль сервисной доменной учетной записи.
В результате, на WEC-сервере будет установлен сервис KUMA Windows Agent <Windows Agent ID>.
Если статус агента в веб-интерфейсе KUMA красный, необходимо удостовериться в доступности портов 7210 и порта коллектора Windows по направлению от агента к KUMA Collector.
Для удаления сервиса агента KUMA по окончанию тестирования продукта выполните следующую команду:
C:\Users\<имя пользователя>\Desktop\KUMA>kuma.exe agent --id <Windows Agent ID> --uninstall
Проверка поступления событий Windows в KUMA
Для проверки, что сбор событий с устройств Windows успешно настроен перейдите в Ресурсы -> Активные сервисы -> выберите ранее созданный коллектор для Windows и нажмите Перейти к событиям.
В открывшемся окне События убедитесь, что присутствуют события с Windows-устройств.
Время на прочтение17 мин
Количество просмотров100K
Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!
Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.
Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).
Политики аудита 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 весьма гибка и позволяет настроить аудит произвольных папок и веток реестра — следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.
Настройка Windows Event Forwarding, интеграция с IBM QRadar
Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.
Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.
Для включения сервиса сбора логов следует выполнить нижеописанные шаги:
1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»false»}
2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.
3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).
4. Проверить состояние службы WinRM на сервере-колекторе можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management).
5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY\NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN\Event Log Readers («Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).
6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера…» (Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address…) и указать адрес сервера-коллектора в следующем формате:
Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60
где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.
7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*</Select>
</Query>
</QueryList>
8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.
9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.
Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.
10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).
После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM-системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.
Утилита Sysmon
Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания 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 Мб ОЗУ.
XPath-запросы
Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box «Отобразить аналитический и отладочный журналы».
Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.
Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку «Подробности», а там выбрать radio-button «Режим XML», в котором в формате «ключ-значение» будут представлены данные события безопасности.
Приведем несколько полезных XPath запросов с комментариями.
1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>
2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:
<QueryList>
<Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
<Select Path="Microsoft-Windows-Sysmon/Operational">*[EventData[Data[@Name='DestinationPort'] = '443']]</Select>
</Query>
</QueryList>
3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]]
and
*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>
4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]]
and
*[EventData[Data[@Name='TargetUserName']='Username']]
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
</Query>
</QueryList>
5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=4624)]]</Select>
<Suppress Path="Security">*[EventData[(Data[@Name='TargetUserSid'] and (Data='S-1-5-18' or Data='S-1-5-19' or Data='S-1-5-20') and Data[@Name='LogonType'] and (Data='4' or Data='5'))]]
or
*[EventData[(Data[@Name='LogonProcessName'] and (Data='Advapi') and Data[@Name='AuthenticationPackageName'] and (Data='Negotiate' or Data='NTLM'))]]
</Suppress>
</Query>
</QueryList>
IRP-система штатными средствами Windows
Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.
Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант «При событии», а в открывшейся форме отображения установить radio-button «Настраиваемое». После этих действий появится кнопка «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.
Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]]
and
*[EventData[Data[@Name='TargetUserName']='Username']]
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
</Query>
</QueryList>
Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:
<QueryList>
<Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
<Select Path="Microsoft-Windows-Sysmon/Operational">
*[System[(EventID=10)]]
and
*[EventData[Data[@Name='TargetImage']='C:\Windows\System32\lsass.exe']]
and
*[EventData[(Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038'))]]
</Select>
</Query>
</QueryList>
Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.
Event log management is a critical skill to learn in all Windows environments. Activity is being recorded to Windows event logs every second and it acts as not only a security tool but also as a vital troubleshooting aid. With a feature called Windows Event Forwarding (WEF), Windows can send events to the Windows event collector from remote machines.
Not a reader? Watch this related video tutorial!
Not seeing the video? Make sure your ad blocker is disabled.
Windows Event Log Forwarding Overview
WEF is a service that allows you to forward events from multiple Windows servers and collect them in one spot. The service has two main components; a forwarder and a collector. A collector is a service running on a Windows server that collects all events sent to it from an event log forwarder.
The “link” between the forwarding server and a collector is known as a subscription.
Collectors serve as subscription managers that accept events and allow you to specify which event log alerts to collect from endpoints.
WEF Project Overview
This is a Project article where we cover how to build a project or implement a solution. Each section hereafter will be cumulative steps that build upon the previous.
For this project, you’re going to learn how to set up a basic WEF implementation. You’ll learn how to set up both a collector and how to forward events to a collector with a subscription.
You’ll learn how to:
- Set up and configure an event log collector on a Windows Server instance. This will be the Windows Server that all of the event log forwarders will send events.
- Create a GPO that, when applied, will point applicable Windows Server instances to the collector to send events to.
- Configuring the types of events to send to the collector.
You will learn how to work through each step in the remainder of this article.
Environment and Knowledge Requirements
Before you get too far, let’s first ensure my environment is the same as yours. Please be sure you have the following items in place before starting:
- (2) Windows Server instances – You can use any Windows Server instance of 2012 R2 or higher. In this article, I’ll be using Windows Server 2016.
- Active Directory
- GPO – A familiarity with Group Policy Objects will be required.
- WinRM- WinRM needs to be running on all clients. Not configured just running.
Configuring the Windows Event Collector
The first task to perform is configuring one of your Windows Server instances as the collector. Recall that the collector is the one that receives incoming event logs from the forwarder.
Enabling WinRM on the Windows Event Collector
Windows Server instances that forward events to the collector do so over PowerShell Remoting or WinRM. You’ll first have to ensure WinRM is available on your collector. If the collector is running Windows Server 2012 R2 and above, WinRM is enabled by default, but the Windows Firewall may be interfering.
Run the the Enable-PSRemoting
PowerShell cmdlet with no parameters on the collector. Even if PowerShell Remoting is already enabled, it will skip the necessary steps.
To be sure, you can also run Invoke-Command -ComputerName <COLLECTORHOSTNAME> -ScriptBlock {1}
from a remote computer. If you don’t receive an error, PowerShell Remoting is working.
Starting the Subscription Collector Service
Now that PowerShell Remoting is enabled and listening, start the subscription collector service. The subscription collector service needs to also start up automatically when Windows Server boots up.
On the collector, open Event Viewer click on Subscriptions. The first time you open the Subscriptions option, Windows will ask if you want to start the Windows Event Log Collector Service and configured to start automatically. Click Yes to accept.
You can see an example of the message below.
Congratulations! You now have a collector configured. It’s now time set up a GPO which will instruct Windows Server instances to forward events to the collector.
Setting up the Forwarders’ GPO
The next step is to configure one or more Windows servers to begin forwarding event logs to the collector. The easiest way to do so is by creating a GPO. This GPO can then be applied to one or more OUs which contain the servers to send events from.
You’ll learn the basics of setting up the necessary settings in a GPO in this Project article. But if you’d like to a complete rundown with all the available options, check out the Microsoft documentation.
Allowing the Network Service to Read Event Logs
WEF uses the Network Service account to read and send events from a forwarder to a collector. By default, the Network Service account does not have access to do this. You’ll first need to set this ACL to allow it.
Note: Many of the event logs in Windows Server already provide the Network Service account access to the common event logs like Application and System. But the account is not given access to the Security event log and other custom event logs.
To allow the Network Service account to read event logs on event log forwarders, use a GPO. In this article, you’ll learn how to allow the Network Service account access to the Security event log. Other event logs will follow the same process.
1. Begin by opening up a command prompt and running wevtutil gl security
. This will provide various information about the Security event log. But the piece to pay attention to is the channelAccess SDDL.
You can see below an example of the SDDL you’ll need for the Security event log. The channelAccess line represents the permissions set on the event log. Copy the SDDL highlighted below and save it somewhere for later to add to a GPO.
2. Create a GPO via the Group Policy Management Console. Inside of the GPO, navigate to Computer Configuration → Policies → Administrative Templates → Windows Components → Event Forwarding → Configure target subscription manager.
3. Set the value for the target subscription manager to the WinRM endpoint on the collector. You will set the Server to be in the format:
Server=http://<FQDN of the collector>:5985/wsman/SubscriptionManager/WEC,Refresh=60
Note the Refresh interval at the end of the collector endpoint. The Refresh interval indicates how often clients should check in to see if new subscriptions are available.
4. Next, find the SDDL you copied earlier from running wevtutil gl security
and paste it into the setting Computer Configuration → Policies → Administrative Templates → Windows Components → Event Log Service → Security → Configure log access.
Note that this SDDL will take precedence over all other permissions that have been configured for the event log.
You can see an example of what your GPO will look like below for the Security event log.
5. Once the GPO is created, you’ll then either link this GPO to an existing OU containing the Windows servers to send event logs from or create a new OU and link the GPO. Any AD computer account you add to this OU will now set up a subscription to the collector.
Setting up a Subscription
While configuring WEF to collect all events for all Windows servers in an Active Directory domain may seem like a good idea, it’s not. You must be selective and only forward events that are important to you. Filtering out the noise from what matters is where WEF demonstrates its true value.
Let’s work through setting up a subscription for the Security Event log.
Since you’ve already created the GPO and linked it to an Active Directory OU containing the Windows servers you’d like to send events from, the event sources are already set up
- On the collector, open the Windows Event Viewer and right-click on Subscriptions, then create subscription.
2. As shown below, select the Source computer initiated option and then click Select Computer Groups. This is where you will select which computers you’d like to forward events from.
Pro Tip: Selecting AD Groups. Ex: “Domain Controllers” will auto-populate any computers within the group. No need to select individual computers every time you add a new server.
3. Next select the events to forward. Opening up the query filter as you can see below, select Security to forward events to the collector from the Security event log.
4. Once the Security log is selected, you can filter down even more by entering the event ID, keywords, users and computers as shown below.
5. Click OK to exit from the Query Filter.
6. Click Advanced in the Subscription Properties window. Now select Minimize Latency. This setting will ensure the collector will receive events as soon as possible and also to help it catch up if it gets behind.
Verifying the WEF Configuration
Once WEF is set up, you should now check to see if the forwarders actually checked in by checking the Source Computers column on the main Subscriptions page.
You can also check the Event Forwarding Plugin Operational log under Applications and Services on the client to make sure everything is working. This is where you’ll see descriptive errors if something has gone awry with Kerberos or firewalls.
All that is left to to is find a low-value client, clear the Security log and see if you get an alert.
Your Takeaways
In this Project, you learned how to set up a basic WEF subscription. You:
- Set up an event collector
- Created a GPO to create a subscription on various Windows Server forwarders
- Configured a WEF subscription to only send specific events
- Ensured the WEF subscription sent events as fast as possible
WEF is a bit tricky to configure initially, but once up and running, you should have little problems and minimal maintenance headaches.
Set up the Windows Event Log Collector to retrieve logs natively from your Windows server. The Windows Event Log Collector is a set of Site Collector flows, pre-built processors, groups, custom processors, other components, and integrations that pull logs in XML, Event Viewer format (called as Friendly View in Windows Journal), or both from your Windows server and push the logs to New-Scale Security Operations Platform. The collector provides flexible template configuration capabilities to collect Windows events.
Tip
If you configure a Windows Event Log Collector instance for a Site Collector instance which was created using a hostname, you may get a ‘Request timed out‘ error while establishing communication with the host VM from a Windows VM. To avoid the ‘Request timed out’ error and ‘Setup error’, ensure that you complete the following steps on your Windows VM.
Type ping hostnname_of_site_collector in your Windows command prompt. If this command succeeds, proceed with installing a Windows Event Log Collector for this Site Collector instance. If you get a ‘Request timed out’, or ‘Cannot resolve host’ or ‘Unknown host’ error, use the following steps.
-
Open the hosts file that maintains mapping between hostname and IP_address, located at: C:\Windows\System32\drivers\etc\hosts, using Notepad.
-
Add a new entry with your hostname and IP address at the end of the file for example, hostnname_of_site_collector ip_address
-
Save the hosts file.
-
Proceed to install a Windows Event Log Collector instance for this Site Collector instance.
To set up a Windows Event Log Collector:
-
Log in to the New-Scale Security Operations Platform with your registered credentials.
-
Navigate to Collectors > Site Collectors.
-
Ensure that Site Collector is installed and in running state.
-
On the Site Collector page, click the Collectors Library tab, then click Windows.
-
In the Definition section, enter the required information as follows.
-
Collector Name – Site Collector generates a name for the Windows Event Log collector based on your hostname.
-
Site Collector Instance – Select the site collector instance for which you want to set up the Windows Event Log Collector.
-
Log Ingestion Start Date – Select the date from which you want the Windows Event Log Collector to collect events.
-
Now (Default) – Retain the default option Now if you want the collector to pull all the logs registered immediately after collector installation time.
-
1 Week Ago – Select this option if you want the collector to start pulling logs one week before the time of collector installation. For example, if you installed the collector instance on September 27, the collector instance starts pulling logs from September 20, 00:00 UTC, irrespective of the installation time.
-
2 Weeks Ago – Select this option if you want the collector to start pulling logs two weeks before the time of collector installation.
-
3 Weeks Ago – Select this option if you want the collector to start pulling logs three weeks before the time of collector installation.
-
4 Weeks Ago – Select this option if you want the collector to start pulling logs four weeks before the time of collector installation.
-
All Time – Select All Time if you want the collector to collect all the data that is available on the Windows server.
-
-
-
Click Next.
-
In the Data section, set up the Windows template while configuring the collector. After you create a template, you can reuse the template for other collector instances or create a new template each time you set up a new Windows Event Log Collector.
-
Windows Template – Select preconfigured templates to filter logs, or, create a new template. Templates enable you to filter logs by attribute values.
You can select one or up to five preconfigured templates. If you select templates with conflicting conditions, the collector instance may pull duplicate data. To avoid data duplication, it is recommended to create templates with different conditions. For example:
-
Log Conditions for Template 1
-
Log Conditions for Template 2
-
Log Conditions for Template 3
By clicking +New Windows Template, you can create and apply up to five templates.
To create a new Windows template:
-
In the Templates list, click New Windows Template.
-
In the Template Name field, specify a name for the new Windows template.
-
In the Windows Event Format section, select the format: XML, Event Viewer format (called as Friendly View in Windows Journal), or both, in which you want the Collector to pull logs.
-
In the Windows Log Category section, for filtering logs, enable the log fields that you want to use and select the appropriate option: All, Range, and Exclude.
-
All – Click All to include all types of logs irrespective of the value. The collector collects all events for the specified Windows Log name.
-
Range – Click Range and specify a range in the box that appears next. The collector collects security events based on the defined range.
-
Exclude – Click Exclude and specify a value for the events to be rejected while log collection in the box that appears next. The collector collects all the security events from the specified Windows Log name excluding the events listed in this section.
-
-
Click Create.
-
-
-
In the Installation section, copy the scripts and download certificates as follows.
-
Certificate – Click Default Certificate to download the certificates. After you download the certificates, ensure that you save the certificates in the same directory from where you execute the installation command.
Note
After the security certificate expires, the collector may continue to deliver data for several hours because the collector maintains active connections that were created and authenticated before the certificate expiration.
-
Install Script – Copy the Install script. Paste the script in the PowerShell or CMD command line interface as an administrator and run the copied command to install the Windows collector.
Note
You can use one install script for installing Windows Event Log Collector on multiple Windows machines.
-
Uninstall Script – To uninstall the Windows collector, copy and run the script using PowerShell or CMD interface as an administrator. You must execute the script on the windows server.
For a Windows collector instance you want to uninstall or delete, it is recommended to first use the Delete option on the Overview page. If the delete action fails, copy and run the uninstallation script in Windows Server PowerShell as an administrator. Then, delete the Windows collector instance again from the Overview page to complete the cleanup.
-
Support Package – Copy and run the support package command using PowerShell to share the support package with the support team for troubleshooting and remediation of issues if any.
-
-
Verify that the Collector installed. After you run the Install script on your Windows server, you get a confirmation message about successful collector installation and the Collector instance is listed in the Overview section on the user interface.
The Windows Event Log Collector is set up and is ready to pull Windows events from your Windows server.
After the Windows collector is set up, Site Collector Core starts pulling logs periodically based on your template configuration and uploads logs to New-Scale Security Operations Platform. If the Windows server is not available, Site Collector core resumes pulling logs from the place where it stopped.
In case of installation failure, the collector is disabled, and the configuration is saved. You can check the status of the collector on the user interface or by using the support package.
Note
-
The supported versions of Windows operating system are Windows 10, Windows 11, Windows Server 2016, Windows Server 2016 core, Windows Sever 2019, Windows Server 2019 core, Windows Server 2022, Windows Server 2022 core, Windows Server 2025, and Windows Server 2025 core.
-
CrowdStrike may interfere with the operation of Windows Agent collectors. To avoid disruptions, ensure that you:
-
Whitelist the collector and management services. For example, for WELC, Exabeam Windows Collector service and Exabeam WELC Management service.
-
Provide read/write access to the installation folder of the agent collector and C:\Windows\Temp.
-
-