Eventlog что это за служба windows 10

What is the Windows Event Log (EventLog) service?

The EventLog service manages event logs — repositories of events generated by services, scheduled tasks and applications working closely with the Windows operating system.

The service’s display name is Windows Event Log and it runs inside the service host process, svchost.exe. By default, the service is set to start automatically when your computer boots:

You can use the Windows Event Viewer to browse the event logs managed by the service. For example, here are some of the records captured in the Windows Security event log:

What happens if I stop EventLog?

You may find it virtually impossible to stop the Windows Event Log service.

That’s because the service supports several important system services. You can see that list on the service’s Dependencies tab:

And because of those dependency relationships, attempting to stop EventLog triggers a “cascade” that causes all dependent services to stop too. Here you can see Windows alerting us of that situation:

But after we clicked “Yes”, Windows failed to stop EventLog and the dependent services! A peculiar error was returned:

We tracked the issue to “Network List Service” (netprofm). That service refused every attempt to stop it, consistently failing with the error above. And since we could not stop “Network List Service”, we could not stop EventLog either.

Is it OK to disable the Windows Event Log service?

No — it’s not safe to disable the Windows Event Log service.

Indeed, in the very description of the service, Microsoft warns:

That advice makes sense because EventLog provides essential support for Windows Services, scheduled tasks, and other background programs. Those components typically run “headless”, without a user interface, and rely on the event logs to record important events.

If the EventLog service stops, those background components will have no way to chronicle their activities. There would be an ominous gap in the operating system’s low-level records.

With that in mind, it’s easy to see why the EventLog service is an alluring target for attackers looking to compromise a system. Once the service has been crippled, vital forensics records may not be captured and intruders could operate with impunity.

Questions? Problems?

If you would like to know more about the Windows Event Log service, or you have a specific problem, please feel free to get in touch. We will do our best to help you!

This service manages events and event logs. It supports logging events, querying events, subscribing to events, archiving event logs, and managing event metadata. It can display events in both XML and plain text format. Stopping this service may compromise security and reliability of the system.

This service also exists in Windows 7, 8, Vista and XP.

Startup Type

Windows 10 version	Home	Pro	Education	Enterprise
1507	Automatic	Automatic	Automatic	Automatic
1511	Automatic	Automatic	Automatic	Automatic
1607	Automatic	Automatic	Automatic	Automatic
1703	Automatic	Automatic	Automatic	Automatic
1709	Automatic	Automatic	Automatic	Automatic
1803	Automatic	Automatic	Automatic	Automatic
1809	Automatic	Automatic	Automatic	Automatic
1903	Automatic	Automatic	Automatic	Automatic
1909	Automatic	Automatic	Automatic	Automatic
2004	Automatic	Automatic	Automatic	Automatic
20H2	Automatic	Automatic	Automatic	Automatic
21H1	Automatic	Automatic	Automatic	Automatic
21H2	Automatic	Automatic	Automatic	Automatic
22H2	Automatic	Automatic	Automatic	Automatic

Default Properties

Display name:	Windows Event Log
Service name:	EventLog
Type:	share
Path:	%WinDir%\System32\svchost.exe -k LocalServiceNetworkRestricted -p
File:	%WinDir%\System32\wevtsvc.dll
Error control:	normal
Group:	Event Log
Object:	NT AUTHORITY\LocalService
Privileges:	SeChangeNotifyPrivilege SeImpersonatePrivilege SeAuditPrivilege

Default Behavior

The Windows Event Log service is running as NT AUTHORITY\LocalService in a shared process of svchost.exe. Other services might run in the same process. If Windows Event Log fails to start, the error is logged. Windows 10 startup proceeds, but a message box is displayed informing you that the EventLog service has failed to start.

Dependencies

If Windows Event Log is stopped, the following services cannot start:

• Network Location Awareness
• Windows Event Collector

Restore Default Startup Type of Windows Event Log

Automated Restore

1. Select your Windows 10 edition and release, and then click on the Download button below.

2. Save the RestoreWindowsEventLogWindows10.bat file to any folder on your hard drive.

3. Right-click the downloaded batch file and select Run as administrator.

4. Restart the computer to save changes.

Note. Make sure that the wevtsvc.dll file exists in the %WinDir%\System32 folder. If this file is missing you can try to restore it from your Windows 10 installation media.

Yea, though I walk through the valley of the shadow of death, I will fear no evil: for thou art with me; thy rod and thy staff they comfort me.

Windows Event Log is a built-in feature of the Microsoft Windows operating system that records and stores various system, security, and application events that occur on a computer.

These events can include errors, warnings, and information messages. Using this event log,  administrators can troubleshoot problems, monitor system health, and track user activity.

The Windows Event Log is organized into three main categories:

System, Application, and Security.

The Application log contains events related to applications and services, whereas the System log includes events associated with system components and drivers. Logon sessions, unsuccessful login attempts,  and other security-related incidents are documented in the Security log.

This windows event log entries include detailed information such as the date and time the event occurred, the source of the event,  and any relevant error codes.

Windows Event Log Importance

The role of event log monitoring is crucial for system and network engineers because it enables them to stay informed about any problems, illegal activity, network breakdowns, and other key issues that might be arising inside a computer.

It provides complete details about each event, including its origin, username, sensitivity level, and other information. This information can be very helpful in identifying and resolving structural failures, as well as in forecasting upcoming challenges based on data patterns.

Network administrators can effectively discover and handle issues before they become serious by keeping an eye on event logs. This might possibly save a lot of time and effort when investigating and fixing the issue. This can help to guarantee that systems continue to be safe, dependable, and performing at their best.

How to Access Windows Event Log?

#1. Using GUI

Step 1 – Open the Start menu and search for “Event Viewer”.

Step 2 – Click on the Event Viewer application to open it.

Step 3 – In the leftmost panel, you will see a list of event logs. Choose the Windows Logs option and then click the desired log to view.

Step 4 – In the middle panel,  you can see a list of events for the selected log. You can use the filter options at the right-hand side of the screen to narrow down the events you are interested in.

Step 5 – To view the details of an event, double-click on it. This will open the Event Properties dialog box, which contains detailed information about the event ID, source, severity level, date and time, user name, computer name,  and description.

Step 6 – You can use the menu options and toolbar at the top of the screen to perform various actions such as saving and clearing logs, creating custom views,  and filtering events.

#2. Using Command Prompt

You can access the Windows Event Log using the Command Prompt or PowerShell by using the “wevtutil” command. Here are some examples.

• To display all events in the System log

wevtutil qe System

• To display the events in the Application log

wevtutil qe Application

The output may look like this.

• To display all events in the Security log

wevtutil qe Security

• To display events from a specific source in the System log.

wevtutil qe System /f:text /c:1 /rd:true /q:"*[System[Provider[@Name='source_name']]]" 

Here you need to replace “source_name” with the name of the event source you want to view.

• To export events from a log to a file

wevtutil epl System C:\Logs\SystemLog.evtx

Replace “System” with the name of the log you want to export, and “C:\Logs\SystemLog.evtx” with the path and filename where you want to save the exported log.

#3. Using Run

You can also access the Windows Event Log using the Run dialog box in Windows. Here’s how:

Step 1 – Press the “Windows key + R” on your keyboard to open the Run dialog box.

Step 2 – Type “eventvwr.msc” in the Run dialog box and press Enter.

Step 3 – The Event Viewer utility will open and display the main console window.

Step 4 – In the left-hand side console window, you can expand the “Windows Logs” folder to see the System, Application, Security, Setup,  and other logs.

Step 5 – Click on the log you want to view its contents in the right panel. You can filter and sort the events as well as create custom views & save them for future use.

When to use these Event Logs?

Generally, You can use the Windows Event Log whenever you need to monitor, troubleshoot,  or audit events on a Windows system. Here are some specific situations where you might use it.

Monitoring system health

The Windows Event Log can provide valuable information about system errors, warnings,  and performance issues which allows you to proactively monitor and maintain the health of your system.

Troubleshooting problems

When you encounter a problem on a Windows system, the Event Log can provide an indication of the cause and help you diagnose the issue. By analyzing event logs, you can easily identify the root cause of a problem and take steps to resolve it.

Auditing and tracking user activity

The Security log in the Event Log can be used to track user logins, logoff, failed logon attempts,  and other security-related events, which can help you identify potential security threats and take appropriate action.

Compliance reporting

Many regulatory frameworks such as HIPAA, PCI-DSS,  and GDPR require organizations to maintain event logs and provide regular reports. The Windows Event Log can be used to meet these compliance requirements.

How to Read these Event Logs?

It can be a little difficult to read the Windows Event Log at first, but with enough practice and familiarity, it gets simpler to understand the data it provides. Here are some general steps to follow when reading the Windows Event Log.

#1. Open the Event log

The first step is to open the event log. You can access it by using any of the above-mentioned methods.

#2. Navigate to the appropriate log

There are several logs in the Event Viewer, including the Application, System, Security,  and Setup logs. Each log contains different types of events. Select the log that contains the events you want to view.

#3. Filter event

You can filter events by severity level, event source, date range, and other criteria. This can help you narrow down the events you are interested in.

#4. View event details

Examine each event carefully to view its details, including the event ID, source, severity level, date & time, user name, computer name, and description. This information can help you identify the cause of the event and take appropriate action.

#5. Use event properties

Many events have additional properties that provide more information about the event.

For example, a security event might have properties such as logon type, logon process,  and authentication package. These properties can help you understand the context of the event and its significance.

#5. Analyze patterns

Always try to look for patterns in the events to identify recurring issues or trends. For example, if you see a series of disk errors, it could indicate a problem with the disk hardware or configuration.

Windows Event Severity Levels

The Windows Event Log uses severity levels to categorize events based on their importance or impact on the system. There are five severity levels in the Windows Event Log, listed below from highest to lowest severity:

• Critical: This severity level is reserved for events that indicate a critical system or application failure that requires immediate attention. Examples include system crashes, major hardware failures,  and critical application errors.
• Error: It is used for events that indicate a serious problem that requires attention but not necessarily immediate action. Some common examples are application crashes, network connectivity failures,  and disk errors.
• Warning: It indicates a potential issue that system administrators should keep an eye on, including low disk space warnings and security policy violations.
• Verbose: It is used for events that provide detailed information about system or application activity,  typically for troubleshooting or debugging purposes.
• Information: It shows that everything went smoothly. Almost all logs include information events.

These severity levels allow administrators & system analysts to quickly identify critical issues that require attention and prioritize their response accordingly.

Conclusion ✍️

I hope you found this article helpful in learning about the windows event log and its importance. You may also be interested in learning about the various ways to recover deleted data in Windows 11.

This service manages events and event logs. It supports logging events, querying events, subscribing to events, archiving event logs, and managing event metadata. It can display events in both XML and plain text format. Stopping this service may compromise security and reliability of the system.

Default Settings

Startup type:	Automatic
Display name:	Windows Event Log
Service name:	EventLog
Service type:	share
Error control:	normal
Group:	Event Log
Object:	NT AUTHORITY\LocalService
Path:	%SystemRoot%\System32\svchost.exe -k LocalServiceNetworkRestricted -p
File:	%SystemRoot%\System32\wevtsvc.dll
Registry key:	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog
Privileges:	SeChangeNotifyPrivilege SeImpersonatePrivilege SeAuditPrivilege

Default Behavior

Windows Event Log is a Win32 service. In Windows 10 it is starting automatically when the operating system starts. Then the Windows Event Log service is running as NT AUTHORITY\LocalService in a shared process of svchost.exe along with other services. If Windows Event Log fails to start, the failure details are being recorded into Event Log. Then Windows 10 will start up and notify the user that the EventLog service has failed to start due to the error.

Dependencies

While Windows Event Log is stopped, disabled or working incorrectly, the following services do not start:

• Network Location Awareness
• Windows Event Collector

Restore Default Startup Configuration of Windows Event Log

1. Run the Command Prompt as an administrator.

2. Copy the commands below, paste them into the command window and press ENTER:

sc config EventLog start= auto

sc start EventLog

3. Close the command window and restart the computer.

The EventLog service is using the wevtsvc.dll file that is located in the C:\Windows\System32 directory. If the file is removed or corrupted, read this article to restore its original version from Windows 10 installation media.

Время на прочтение
17 мин

Количество просмотров 61K

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса 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=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.