Microsoft Windows Event Logs

Overview

Table name: universal_wel

Windows Event Logs (WEL) refer to the different types of events that can be recorded on Windows machines. These logs contain information on operating system-related operations that take place on the machine. By logging WEL on relevant machines in your organization, you can gain visibility into internal actions that occur on the machine, such as user activity, process creation, network activity, and domain actions.

This data source can be used extensively for Enterprise threat detection for both Windows endpoints and servers. The Hunters platform supports the ingestion of these logs to a dedicated schema and leverages the logs for automated detection and investigation.

About log collection

There are various agents and methods available to collect Windows Event Logs. Commonly used products for collection include NXLog, Winlogbeat, and the Fluentd WEL plugin.

Collection can be done on each device separately or in a centralized location by forwarding the logs to the centralized location using native Windows Event Forwarding or remote WMI collection which is offered by products like NXLog and Splunk.

Finally, the data needs to be uploaded to an S3 bucket to be shared with Hunters. This can be achieved using data collectors like Fluentd and LogStash.

Recommended Auditing Policy

Minimum policy

To ensure that the proper events are logged in your Windows environment, it is strongly advised to follow Microsoft's Audit Policy Recommendation while at least adhering to the "Baseline Category." Detailed information on this recommendation can be found here.

It's important to note that there are different recommendations for a standard host versus a Domain Controller (denoted as DC).

Enhanced policy

It’s recommended to enhance auditing by taking the following steps:

Enable audit policy categories

Category	Sub-category	Type
Account Logon	Kerberos Authentication Service	Success and Failure
Account Logon	Kerberos Service Ticket Operations	Success and Failure
Logon and Logoff	Other Logon and Logoff Events	Success and Failure
Object Access	Other Object Access Events	Success

Extend PowerShell Auditing

Extend PowerShell Auditing to include Script Block Logging (event code 4104).

By default, only commands that are categorized as ‘Warning’ are being logged. Configuring Script Block Logging ensures all PowerShell commands are being captured.

Script Block Logging can be configured through the GPO: Computer Configuration => Policies => Administrative Templates => Windows Components/Windows PowerShell => Turn on PowerShell Script Block Logging.

The option of Log script block invocation start/stop events should remain Disabled.

Enable command line auditing (optional)

By default, the security event “A new process has been created” (event code 4688) does not present details of the full command line attached to the new process.

Enabling command line auditing provides better context around the new process. In general, it provides the organization with an extra level of process data visibility, that is independent on 3rd party products.

Furthermore, it can be useful for Hunters detectors and enrichments. For example, detectors and enrichments that are based on EDR process data would also cover machines that don’t have EDR agent installed or machines whose EDR agent was tampered with.

Enabling command line auditing may expose the organization to a risk of a credential leak in case clear text passwords are being used in CLI or batch scripts. For this reason, the configuration is marked as Optional.

See Microsoft’s documentation: Command line process auditing

Supported Providers

Each Windows Event Logs provider has its own data structure, and Hunters supports the following providers:

Security Auditing: Microsoft-Windows-Security-Auditing
PowerShell event logs: Microsoft-Windows-Powershell, Powershell
DNS client logs: Microsoft-Windows-Dns-Client

Supported Windows event IDs

The list below specifies the Windows event IDs required for Hunters detectors:

System Health Events

1, 3, 4, 4608, 4609, 4610, 4611, 4612

Application Errors

1000, 1001, 1002, 4621, 4622, 4626, 4627

Directory Service Events

1013, 5136

Windows Defender Security Events

1116, 1117, 1121, 1124, 1128, 4646, 4647, 4648, 4649, 4650, 4651, 4652, 4653

System Warning Events

1150, 1151, 4654, 4655, 4656, 4657, 4658, 4659

Application Failure Errors

2000, 2001, 2002, 4660, 4661, 4663, 4664, 4665

System Operation Issues

2010, 4666, 4667, 4668

Dangerous Script Load

2050

Network Connectivity Issues

5004, 5007, 4689, 4690, 4691, 4692, 4693, 4694, 4695, 5156

Security Breach Events

5857, 5859, 5860, 4696, 4697, 4699, 4700, 4701, 4702

Successful and Failed Logins

Successful Logon: 4624
Failed Logon: 4625
Account Lockout: 4740

Account and Group Modifications

User Account Created: 4720
User Account Deleted: 4726
Global Group Activities: 4727, 4728, 4729, 4730, 4737
Local Group Activities: 4731, 4732, 4733, 4734, 4735
Universal Group Activities: 4754, 4755, 4756, 4757, 4758

Process Creation & Modification

New Process Created: 4688
Scheduled Task Created: 4698
Process Changes: 4703, 4704, 4705, 4706, 4707, 4709, 4710, 4711, 4712, 4713, 4714, 4715, 4716, 4717, 4718, 4719

Kerberos Authentication Events

TGT Request: 4768
TGS Request: 4769
Service Ticket Renewed: 4770

DNS-Related Events

3006, 3007, 3008, 3009, 3010, 3011, 3012, 3013, 3014, 3016, 3018, 3019, 3020

Access Control & Security Policy Changes

User Access to an AD Object: 4662
Object Modifications: 4719, 4722, 4723, 4724, 4725

Additional Security & System Events

Advanced Logging & System Modifications:
4771, 4772, 4773, 4774, 4775, 4776, 4777, 4778, 4779, 4780, 4781, 4782, 4783, 4784, 4785, 4786, 4787, 4788, 4789, 4790, 4791, 4792, 4793, 4794
System Integrity & Object Auditing:
4797, 4798, 4799, 4800, 4801, 4802, 4803, 4816, 4817, 4818, 4819, 4820, 4821, 4822, 4823, 4824, 4825, 4826

Additional System and Security Warnings

Advanced System Operations:
4864, 4865, 4866, 4867, 4868, 4869, 4870, 4871, 4872, 4873, 4874, 4875, 4876, 4877, 4878, 4879, 4880, 4881, 4882, 4883, 4884, 4885, 4886, 4887, 4888, 4889, 4890, 4891, 4892, 4893, 4894, 4895, 4896, 4897, 4898, 4899, 4900

Setup Guide - Windows Event Log Shippers

Fluent Bit Windows Event Log Plugin

Fluent Bit is a super fast, lightweight, and highly scalable logging and metrics processor and forwarder. It is the preferred choice for cloud and containerized environments.

Prerequisites

Fluent Bit uses very low CPU and memory consumption, it's compatible with most of x86, x86_64, arm32v7 and arm64v8 based platforms.

Installations

Installation packages

Process creation

🚧 NOTE

Below assumes the installation path is C:\PROGRA~1\FLUENT~1\
Use "dir /x" command to verify the Fluent Bit installation path and change it accordingly (8.3 file format is recommended)

sc.exe stop Fluent-Bit
sc.exe delete Fluent-Bit
sc.exe create Fluent-Bit binpath= "C:\PROGRA~1\FLUENT~1\bin\FLUENT~1.EXE -c C:\PROGRA~1\FLUENT~1\CONF\FLUENT~1.CON -l C:\PROGRA~1\FLUENT~1\flunetbit.log"
sc.exe description Fluent-Bit "Fluent Bit Enables You To Collect Logs And Metrics From Multiple Sources, Enrich Them With Filters, And Distribute Them To Any Defined Destination."
sc.exe config Fluent-Bit start=auto
sc.exe start Fluent-Bit
sc.exe query Fluent-Bit
sc.exe failure Fluent-Bit reset= 30 actions= restart/5000

Recommended configuration

Clear text:

[INPUT]
    Name         winlog
    Tag          winlog
    Channels     Security
    Interval_Sec 1
    DB           winlog.sqlite


[OUTPUT]
    Name Forward
    Match *
    Host <Fluentd IP>
    Port <Fluentd TCP port)

TLS:

[INPUT]
    Name         winlog
    Channels     Security
    Interval_Sec 1
    DB           winlog.sqlite

[OUTPUT]
    Name          forward
    Match         *
    Host          <Fluentd IP>
    Port          <Fluentd TCP Port>
    
    tls           on
    tls.verify    off

Fluentd Windows Event Log Plugin

Prerequisites

The Fluentd agent works on most modern Windows versions, on 64-bit versions only. For earlier versions, a different solution (such as the native Windows Event Forwarding) will need to be configured.
Make sure all reporting hosts have NTP set up, for the logs to have accurate timestamps.

Step 1 - Install the Fluentd agent on all devices

Download the newest Fluentd Windows agent (td-agent v4) from here.
Install the agent as a local administrator on all hosts where Windows Event Logs collection is planned.
Running the .msi installer should automatically register and start Fluentd as a Windows service. If not, follow the instructions here.

Step 2 - Configure the Windows Event Log Input Plugin

The Fluentd configuration file is found in `C:\opt\td-agent\etc\td-agent\td-agent.conf`.
Full documentation of the Windows Event Log input plugin can be found here.

Recommended Configuration:

 <source>
  @type windows_eventlog2
  @id windows_eventlog2
  channels security
  read_existing_events false
  read_interval 2
  tag winevt.raw
  <storage>
    @type local             # @type local is the default.
    persistent true         # default is true. Set to false to use in-memory storage.
    path C:\opt\td-agent\tmp\storage.json
  </storage>
</source>

Step 3 - Forward the logs to the desired destination

After configuring the WEL collection, you can now forward the logs to the desired destination. One option is forwarding the logs directly to an S3 bucket, as detailed in the below section. Another option is to forward the logs to a centralized location using other output plugins such as out http or out_forward, and from there forward the logs to the S3 bucket.

Winlogbeat

💡Learn more
Winlogbeat documentation

Please make sure the log format follows the guidelines outlined in the below section Supported Formats.

In order to keep the Message field in a raw text format, use the following configuration (more details here):

winlogbeat.event_logs:
  - name: ForwardedEvents
    api: wineventlog-experimental

For additional questions, please refer to the Hunters support team.

NXLog

💡Learn more
NXLog documentation

Please make sure the log format follows the guidelines outlined in the below section Supported Formats.

For additional questions, please refer to the Hunters support team.

NXLog Example Configuration

Please find below a working configuration for NXLog agent to use for the purpose of forwarding Windows Event Logs to Fluentd or Logstash.

# Windows Event Logs

define ROOT C:\Program Files\nxlog
define CERTDIR %ROOT%\cert
define CONFDIR %ROOT%\conf
define LOGDIR %ROOT%\data
define LOGFILE '%LOGDIR%/nxlog.log'

# Defining Output Host & Port
define WEL_OUTPUT_DESTINATION_ADDRESS <destination_host>
define WEL_DNS_OUTPUT_DESTINATION_PORT <destination_port>

Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log

<Extension syslog>
    Module xm_syslog
</Extension>

<Extension json>
    Module xm_json
</Extension>

<Input in_wel>
    Module	im_msvistalog
    ReadFromLast TRUE
</Input>

<Output out_wel>
    Module  om_tcp
    Host    %WEL_OUTPUT_DESTINATION_ADDRESS%
    Port    %WEL_OUTPUT_DESTINATION_PORT%
    Exec $SyslogFacilityValue = 22;to_syslog_snare();
</Output>

<Route wel_to_aws_nlb>
    Path        in_wel => out_wel
</Route>

# Panic SOFT will cause an exception to be thrown at the place of the panic/assertion.
Panic Soft

# END OF FILE

Windows Event Collector (WEC)

Windows offers the Windows Event Forwarding solution for centralized Windows event logging. This solution includes configuring WEF (Windows Event Forwarding) on all wanted devices, that will ship their Windows event logs to WEC (Windows Event Collector) servers.

A common logging architecture consists of WEF clients sending their logs to WEC servers, that have a log shipper installed (such as Fluentd or Winlogbeat) that ships the Windows event logs to a cloud storage solution such as AWS S3.

Note that there are many different tweaks and configurations available for WEF that should be taken into account in the logging pipeline. For example, the forwarded events can be written to several different locations and channels on the WEC server, as described in this blog post by Elastic. This will require configuring your log shipper to subscribe to the correct channel.

In addition, the event message might require configuration changes to be parsed correctly. Some log shippers require the WEF ContentFormat to be RenderedText (the default) while others might require changing it to Events, as described in this thread in the Microsoft forums.

Fluentd S3 Plugin

Step 1 - Set up an S3 bucket

Configure an IAM role attached to a policy that will allow the Fluentd agents to write the logs. The policy needs to allow List, Read and Write operations on the bucket.

Step 2 - Configure the S3 Output Plugin

The Fluentd configuration file is found in `C:\opt\td-agent\etc\td-agent\td-agent.conf.`

If you're using Fluentd to perform the WEL collection and the S3 forwarding on the same host, you only need to append an output configuration to the same configuration file in which you added the windows_eventlog2 source (as explained here under Step 2 - Configure the Windows Event Log Input Plugin). Below is a simple configuration example. For more complex use cases like AssumeRole credentials, refer to the S3 plugin documentation.

    <match winevt.raw>
  @type s3

  aws_key_id YOUR_AWS_KEY_ID
  aws_sec_key YOUR_AWS_SECRET_KEY
  s3_bucket YOUR_S3_BUCKET_NAME
  s3_region YOUR_S3_BUCKET_REGION
  path "winevtlogs/#{hostname}/%Y/%m/%d/"
  <format>
    @type json
  </format>
  <buffer tag,time>
    @type file
    path C:\opt\td-agent\s3.log
    timekey 300 # 5 minutes partition
    timekey_wait 1m
    timekey_use_utc true # use utc
    chunk_limit_size 256m
  </buffer>
</match>

If you plan to forward Windows Event Logs to a centralized location using Fluentd, and then perform the S3 upload in the centralized location, you will need to add additional outputs on the collecting devices and matching inputs on the centralized forwarder.

Step 3 - Restart the Fluentd service

After editing the configuration file, restart the service (go to Control Panel > System and Security > Administrative Tools > Services, right-click on Fluentd Windows Service, and click Restart).

Step 4 - Verify files written to S3

Browse to the destination S3 bucket.
5-10 minutes after the Fluentd service was restarted, .gz files should already be written to the bucket.
Download the latest file and open it.
Make sure it is in the nd-json format.

Step 5 - Set up read permissions for the S3 bucket

Configure a role and policy that lets Hunters download objects from the S3 bucket, as described in the Access to Cloud Storage chapter.

Step 6 - Contact Hunters representative

Contact your account manager to start ingesting this data into the Hunters platform.

LogStash

Please refer to the LogStash S3 Plugin Documentation.
Make sure that the log format stays intact and is written to the bucket as nd-json.

Supported Formats

The Hunters platform reads the event logs from an S3 Bucket. The supported formats are ndjson and xml. The following considerations should be applied to the logs shared:

Hunters currently supports the following providers:
- Security Auditing: Microsoft-Windows-Security-Auditing
- PowerShell event logs: Microsoft-Windows-Powershell, Powershell
- DNS client logs: Microsoft-Windows-Dns-Client
Logs Format: the logs should be stored in the bucket in nd-json or xml formats, with the following specifications (and see sample examples below):
- xml format as exported directly from the Windows Event Log console. Each xml log should be on a separate line in the file, without any new lines within it.
- ndjson format that should suffice:
  - Each event should have a timestamp field under the EventTime key, in the format %Y-%m-%dT%H:%M:%S.%f%z.
    - Make sure that your log collector logs timestamps with timezones, so it will be possible to get the UTC timestamp of the events.
  - The Message field should be kept intact, as it appears in the raw text format, and not parsed or manipulated - field delimiters being \t\t, group delimiters being \r\n\r\n, etc.
  - For servers in different languages, make sure that your log collector saves the messages in en-US encoding.

Note:

If your operating system delivers json logs in a language other than English, it's recommended to use xml.

Sample NDJSON Event

{
    "EventTime": "2021-11-16T06:14:35.129481-05:00",
    "Hostname": "MyHost",
    "Keywords": "923929806109516800",
    "EventType": "AUDIT_SUCCESS",
    "SeverityValue": 2,
    "Severity": "INFO",
    "EventID": 4799,
    "SourceName": "Microsoft-Windows-Security-Auditing",
    "ProviderGuid": "{5434235-54478-4992344-A5BA-3E3B03a2323330D}",
    "Version": 0,
    "TaskValue": 13826,
    "OpcodeValue": 0,
    "RecordNumber": 71245,
    "ActivityID": "{B5B00A214-D0A2-0372-7E7A-B195E9983401}",
    "action": "Logon"
    "ExecutionProcessID": 618,
    "ExecutionThreadID": 3228,
    "Channel": "Security",
    "Message": "A security-enabled local group membership was enumerated.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-5-18\r\n\tAccount Name:\t\tHost123$\r\n\tAccount Domain:\t\tWORKGROUP\r\n\tLogon ID:\t\t0x3E7\r\n\r\nGroup:\r\n\tSecurity ID:\t\tS-1-5-32-327\r\n\tGroup Name:\t\tAdministrators\r\n\tGroup Domain:\t\tBuiltin\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x1ab0\r\n\tProcess Name:\t\tC:\\Windows\\System32\\svchost.exe",
    "Category": "Security Group Management",
    "Opcode": "Info",
    "TargetUserName": "Administrators",
    "TargetDomainName": "Builtin",
    "TargetSid": "S-1-5-32-327",
    "SubjectUserSid": "S-1-5-18",
    "SubjectUserName": "Host123",
    "SubjectDomainName": "WORKGROUP",
    "SubjectLogonId": "0x3e7",
    "CallerProcessId": "0x1ab0",
    "CallerProcessName": "C:\\Windows\\System32\\svchost.exe",
    "EventReceivedTime": "2021-11-16T06:14:36.079168-05:00",
    "SourceModuleName": "eventlog",
    "SourceModuleType": "im_msvistalog",
    "event_details": {"SubjectDomainName": "Domain", "SubjectLogonId": "123", "SubjectUserName": "username"}
}

Sample XML Event

In this format, the file should contain XMLs separated by a new line.

<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{GUID}' /><EventID>4656</EventID><Version>1</Version><Level>Information</Level><Task>Kernel Object</Task><Opcode>Info</Opcode><Keywords>Audit Success</Keywords><TimeCreated SystemTime='2022-01-01T00:00:00.000000000Z' /><EventRecordID>123456789</EventRecordID><Correlation /><Execution ProcessID='123' ThreadID='123' /><Channel>Security</Channel><Computer>mydomain.corporate.name</Computer><Security /></System><EventData><Data Name='SubjectUserSid'>NT AUTHORITY\SYSTEM</Data><Data Name='SubjectUserName'>AA0ASDFGHJ000$</Data><Data Name='SubjectDomainName'>AA</Data><Data Name='SubjectLogonId'>0x111</Data><Data Name='ObjectServer'>Security</Data><Data Name='ObjectType'>Process</Data><Data Name='ObjectName'>\Device\HarddiskVolume2\Windows\System32\lsass.exe</Data><Data Name='HandleId'>0x1234</Data><Data Name='TransactionId'>{00000000-0000-0000-0000-000000000000}</Data><Data Name='AccessList'>%%1234      %%5678</Data><Data Name='AccessReason'>-</Data><Data Name='AccessMask'>0x123456</Data><Data Name='PrivilegeList'>-</Data><Data Name='RestrictedSidCount'>0</Data><Data Name='ProcessId'>0x123</Data><Data Name='ProcessName'>C:\Program Files\Log\System Monitor\asdf.exe</Data><Data Name='ResourceAttributes'>-</Data></EventData></Event>
<Event xmlns='http://schemas.microsoft.com/win/2004/09/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{GUID}' /><EventID>4689</EventID><Version>1</Version><Level>Information</Level><Task>Kernel Object</Task><Opcode>Info</Opcode><Keywords>Audit Success</Keywords><TimeCreated SystemTime='2022-01-02T00:00:00.000000000Z' /><EventRecordID>987654321</EventRecordID><Correlation /><Execution ProcessID='123' ThreadID='456' /><Channel>Security</Channel><Computer>mydomain.corporate.name</Computer><Security /></System><EventData><Data Name='SubjectUserSid'>NT AUTHORITY\SYSTEM</Data><Data Name='SubjectUserName'>AA0ASDFGHJ000$</Data><Data Name='SubjectDomainName'>AA</Data><Data Name='SubjectLogonId'>0x111</Data><Data Name='ObjectServer'>Security</Data><Data Name='ObjectType'>Process</Data><Data Name='ObjectName'>\Device\HarddiskVolume2\Windows\System32\lsass.exe</Data><Data Name='HandleId'>0x1234</Data><Data Name='TransactionId'>{00000000-0000-0000-0000-000000000000}</Data><Data Name='AccessList'>%%1234      %%5678</Data><Data Name='AccessReason'>-</Data><Data Name='AccessMask'>0x123456</Data><Data Name='PrivilegeList'>-</Data><Data Name='RestrictedSidCount'>0</Data><Data Name='ProcessId'>0x123</Data><Data Name='ProcessName'>C:\Program Files\Log\System Monitor\asdf.exe</Data><Data Name='ResourceAttributes'>-</Data></EventData></Event>
<Event xmlns='http://schemas.microsoft.com/win/2004/10/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{GUID}' /><EventID>4656</EventID><Version>1</Version><Level>Information</Level><Task>Kernel Object</Task><Opcode>Info</Opcode><Keywords>Audit Success</Keywords><TimeCreated SystemTime='2022-01-03T00:00:00.000000000Z' /><EventRecordID>741852963</EventRecordID><Correlation /><Execution ProcessID='123' ThreadID='789' /><Channel>Security</Channel><Computer>mydomain.corporate.name</Computer><Security /></System><EventData><Data Name='SubjectUserSid'>NT AUTHORITY\SYSTEM</Data><Data Name='SubjectUserName'>AA0ASDFGHJ000$</Data><Data Name='SubjectDomainName'>AA</Data><Data Name='SubjectLogonId'>0x111</Data><Data Name='ObjectServer'>Security</Data><Data Name='ObjectType'>Process</Data><Data Name='ObjectName'>\Device\HarddiskVolume2\Windows\System32\lsass.exe</Data><Data Name='HandleId'>0x1234</Data><Data Name='TransactionId'>{00000000-0000-0000-0000-000000000000}</Data><Data Name='AccessList'>%%1234      %%5678</Data><Data Name='AccessReason'>-</Data><Data Name='AccessMask'>0x123456</Data><Data Name='PrivilegeList'>-</Data><Data Name='RestrictedSidCount'>0</Data><Data Name='ProcessId'>0x123</Data><Data Name='ProcessName'>C:\Program Files\Log\System Monitor\asdf.exe</Data><Data Name='ResourceAttributes'>-</Data></EventData></Event>

XML Event

This is an example of the xml format for a specific event. The new lines and tabs are only for readability and should not be part of the log(records containing a new line within it will be considered broken and will not be processed).

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
	<System>
		<Provider Name="Microsoft-Windows-Security-Auditing" Guid="{GUID}" />
		<EventID>
			4656
		</EventID>
		<Version>
			1
		</Version>
		<Level>
			Information
		</Level>
		<Task>
			Kernel Object
		</Task>
		<Opcode>
			Info
		</Opcode>
		<Keywords>
			Audit Success
		</Keywords>
		<TimeCreated SystemTime="2022-01-01T00:00:00.000000000Z" />
		<EventRecordID>
			123456789
		</EventRecordID>
		<Correlation />
		<Execution ProcessID="123" ThreadID="456" />
		<Channel>
			Security
		</Channel>
		<Computer>
			mydomain.corporate.name
		</Computer>
		<Security />
	</System>
	<EventData>
		<Data Name="SubjectUserSid">
			NT AUTHORITY\SYSTEM
		</Data>
		<Data Name="SubjectUserName">
			AA0ASDFGHJ000$
		</Data>
		<Data Name="SubjectDomainName">
			AA
		</Data>
		<Data Name="SubjectLogonId">
			0x111
		</Data>
		<Data Name="ObjectServer">
			Security
		</Data>
		<Data Name="ObjectType">
			Process
		</Data>
		<Data Name="ObjectName">
			\Device\HarddiskVolume2\Windows\System32\lsass.exe
		</Data>
		<Data Name="HandleId">
			0x1234
		</Data>
		<Data Name="TransactionId">
			{00000000-0000-0000-0000-000000000000}
		</Data>
		<Data Name="AccessList">
			%%1234      %%5678
		</Data>
		<Data Name="AccessReason">
			-
		</Data>
		<Data Name="AccessMask">
			0x123456
		</Data>
		<Data Name="PrivilegeList">
			-
		</Data>
		<Data Name="RestrictedSidCount">
			0
		</Data>
		<Data Name="ProcessId">
			0x123
		</Data>
		<Data Name="ProcessName">
			C:\Program Files\Log\System Monitor\asdf.exe
		</Data>
		<Data Name="ResourceAttributes">
			-
		</Data>
	</EventData>
</Event>