- Introduction
- Deployment
- Configuration
- OS Support
- Integration
- Troubleshooting
- Enterprise Edition Reference Manual
- 127. Man Pages
- 128. Configuration
- 129. Language
- 130. Extension Modules
- 131. Input Modules
- 131.1. Process Accounting (im_acct)
- 131.2. AIX Auditing (im_aixaudit)
- 131.3. Azure (im_azure)
- 131.4. Batched Compression (im_batchcompress)
- 131.5. Basic Security Module Auditing (im_bsm)
- 131.6. Check Point OPSEC LEA (im_checkpoint)
- 131.7. DBI (im_dbi)
- 131.8. Event Tracing for Windows (im_etw)
- 131.9. External Programs (im_exec)
- 131.10. Files (im_file)
- 131.11. File Integrity Monitoring (im_fim)
- 131.12. Go (im_go)
- 131.13. HTTP(s) (im_http)
- 131.14. Internal (im_internal)
- 131.15. Java (im_java)
- 131.16. Kafka (im_kafka)
- 131.17. Kernel (im_kernel)
- 131.18. Linux Audit System (im_linuxaudit)
- 131.19. macOS ULS (im_maculs)
- 131.20. Mark (im_mark)
- 131.21. EventLog for Windows XP/2000/2003 (im_mseventlog)
- 131.22. EventLog for Windows 2008/Vista and Later (im_msvistalog)
- 131.23. Null (im_null)
- 131.24. ODBC (im_odbc)
- 131.25. Packet Capture (im_pcap)
- 131.26. Perl (im_perl)
- 131.27. Named Pipes (im_pipe)
- 131.28. Python (im_python)
- 131.29. Redis (im_redis)
- 131.30. Windows Registry Monitoring (im_regmon)
- 131.31. Ruby (im_ruby)
- 131.32. TLS/SSL (im_ssl)
- 131.33. Systemd (im_systemd)
- 131.34. TCP (im_tcp)
- 131.35. Test Generator (im_testgen)
- 131.36. UDP (im_udp)
- 131.37. Unix Domain Sockets (im_uds)
- 131.38. Windows Performance Counters (im_winperfcount)
- 131.39. Windows Event Collector (im_wseventing)
- 131.40. ZeroMQ (im_zmq)
- 132. Processor Modules
- 133. Output Modules
- NXLog Manager
- NXLog Add-Ons
131.22. EventLog for Windows 2008/Vista and Later (im_msvistalog)
This module can be used to collect EventLog messages on Microsoft Windows platforms which support the newer EventLog API (also known as the Crimson EventLog subsystem), namely Windows 2008/Vista and later. See the official Microsoft documentation about Event Logs. The module supports reading all System, Application, and Custom events. It looks up the available channels and monitors events in each unless the Query and Channel directives are explicitly defined. Event logs can be collected from remote servers over MSRPC.
Note
|
To examine the supported platforms, see the list of installer packages in the Available Modules chapter. |
Note
|
For Windows 2003 and earlier, use the im_mseventlog module because the new Windows Event Log API is only available in Windows Vista, Windows 2008, and later. |
Note
|
Use the im_etw module to collect Analytic and Debug logs as the Windows Event Log subsystem, which im_msvistalog uses, does not support subscriptions to Debug or Analytic channels. |
Note
|
Unlike nxlog4 NXLog can alter fields content regarding CR and LF characters according to W3C recommendations. Any CR LF and any CR that is not followed by an LF will be translated to a single LF. |
In addition to the standard set of fields which are listed under the System section, event providers can define their own additional schema which enables logging additional data under the EventData section. The Security log makes use of this new feature and such additional fields can be seen as in the following XML snippet:
<EventData>
<Data Name="SubjectUserSid">S-1-5-18</Data>
<Data Name="SubjectUserName">WIN-OUNNPISDHIG$</Data>
<Data Name="SubjectDomainName">WORKGROUP</Data>
<Data Name="SubjectLogonId">0x3e7</Data>
<Data Name="TargetUserSid">S-1-5-18</Data>
<Data Name="TargetUserName">SYSTEM</Data>
<Data Name="TargetDomainName">NT AUTHORITY</Data>
<Data Name="TargetLogonId">0x3e7</Data>
<Data Name="LogonType">5</Data>
<Data Name="LogonProcessName">Advapi</Data>
<Data Name="AuthenticationPackageName">Negotiate</Data>
<Data Name="WorkstationName" />
<Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
<Data Name="TransmittedServices">-</Data>
<Data Name="LmPackageName">-</Data>
<Data Name="KeyLength">0</Data>
<Data Name="ProcessId">0x1dc</Data>
<Data Name="ProcessName">C:\Windows\System32\services.exe</Data>
<Data Name="IpAddress">-</Data>
<Data Name="IpPort">-</Data>
</EventData>
NXLog can extract this data when fields are logged using this schema. The values will be available in the fields of the internal NXLog log structure. This is especially useful because there is no need to write pattern matching rules to extract this data from the message. These fields can be used in filtering rules, be written into SQL tables, or be used to trigger actions. The Exec directive can be used for filtering:
1
2
3
4
5
<Input in>
Module im_msvistalog
Exec if ($TargetUserName == 'SYSTEM') OR \
($EventType == 'VERBOSE') drop();
</Input>
131.22.1. Configuration
The im_msvistalog module accepts the following directives in addition to the common module directives.
- AddPrefix
-
If this boolean directive is set to TRUE, names of fields parsed from the
<EventData>
portion of the event XML will be prefixed withEventData.
. For example,$EventData.SubjectUserName
will be added to the event record instead of$SubjectUserName
. The same applies to<UserData>
. This directive defaults to FALSE: field names will not be prefixed.
- ReadBatchSize
-
This optional directive can be used to specify the number of event records the EventLog API will pass to the module for processing. Larger sizes may increase throughput. Note that there is a known issue in the Windows EventLog subsystem: when this value is higher than 31 it may fail to retrieve some events on busy systems, returning the error "EvtNext failed with error 1734: The array bounds are invalid." For this reason, increasing this value is not recommended. The default is
31
.
- CaptureEventXML
-
This boolean directive defines whether the module should store raw XML-formatted event data. If set to TRUE, the module stores raw XML data in the $EventXML field. By default, the value is set to FALSE, and the
$EventXML
field is not added to the record.
- Channel
-
The name of the Channel to query. If not specified, the module will read from all sources defined in the registry. See the MSDN documentation about Event Selection.
- File
-
This optional directive can be used to specify a full path to a log file. Log file types that can be used have the
.evt
and.evtx
extensions. The path of the file must not be quoted (as opposed to im_file and om_file). If the File directive is specified, the SavePos directive will be overridden to TRUE.NoteThe File directive can also be used for reading
.etl
files with the limitation that the _im_msvistalog module can not seek in.etl
files. It can only read these files from start to end.The File directive can be specified multiple times to read from multiple files. This module finds files only when the module instance is started; any files added later will not be read until it is restarted. If the log file specified by this directive is updated with new event records while NXLog is running (the file size or modification date attribute changes), the module detects the newly appended records on the fly without requiring the module instance to be restarted. Reading an EventLog file directly is mostly useful for forensics purposes. The System log would be read directly with the following:
File C:\Windows\System32\winevt\Logs\System.evtx
You can use wildcards to specify file names and directories. Wildcards are not regular expressions, but are patterns commonly used by Unix shells to expand filenames (also known as "globbing").
- ?
-
Matches any single character.
- *
-
Matches any string, including the empty string.
- \*
-
Matches the asterisk (
*
) character. - \?
-
Matches the question mark (
?
) character. - […]
-
Matches one character specified within the brackets. The brackets should contain a single character (for example,
[a]
) or a range of characters ([a-z]
). If the first character in the brackets is^
or!
, it reverses the wildcard matching logic (the wildcard matches any character not in the brackets). The backslash (\
) characters are ignored and should be used to escape]
and-
characters as well as^
and!
at the beginning of the pathname.
- Language
-
This optional directive specifies a language to use for rendering the events. The language should be given as a hyphen-separated language/region code (for example,
fr-FR
for French). Note that the required language support must be installed on the system. If this directive is not given, the system’s default locale is used.
- PollInterval
-
This directive specifies how frequently the module will check for new events, in seconds. If this directive is not specified, the default is 1 second. Fractional seconds may be specified (
PollInterval 0.5
will check twice every second).
- Query
-
This directive specifies the query for pulling only specific EventLog sources. See the MSDN documentation about Event Selection. Note that this directive requires a single-line parameter, so multi-line query XML should be specified using line continuation:
1 2 3 4 5
Query <QueryList> \ <Query Id='1'> \ <Select Path='Security'>*[System/Level=4]</Select> \ </Query> \ </QueryList>
- QueryXML
-
This directive is the same as the Query directive above, except it can be used as a block. Multi-line XML queries can be used without line continuation, and the XML Query can be copied directly from Event Viewer.
1 2 3 4 5 6 7 8 9 10 11
<QueryXML> <QueryList> <!-- XML-style comments can span multiple lines in QueryXML blocks like this. --> <Query Id='1'> <Select Path='Security'>*[System/Level=4]</Select> </Query> </QueryList> </QueryXML>
Caution
|
Commenting with the # mark does not work within multi-line Query
directives or QueryXML blocks.
In this case, use XML-style comments <!-- --> as shown in the
example above. Failure to follow this syntax for comments within
queries will render the module instance useless. Since NXLog
does not parse the content of QueryXML blocks, this behavior is
expected.
|
- ReadFromLast
-
This optional boolean directive instructs the module to only read logs which arrived after NXLog was started if the saved position could not be read (for example on first start). When SavePos is TRUE and a previously saved position value could be read, the module will resume reading from this saved position. If ReadFromLast is FALSE, the module will read all logs from the EventLog. This can result in quite a lot of messages, and is usually not the expected behavior. If this directive is not specified, it defaults to TRUE.
- RemoteAuthMethod
-
This optional directive specifies the authentication method to use. Available values are
Default
,Negotiate
,Kerberos
, andNTLM
. When the directive is not specified,Default
is used, which is actuallyNegotiate
.
- RemoteDomain
-
Domain of the user used for authentication when logging on the remote server to collect event logs.
- RemotePassword
-
Password of the user used for authentication when logging on the remote server to collect event logs.
- RemoteServer
-
This optional directive specifies the name of the remote server to collect event logs from. If not specified, the module will collect locally.
- RemoteUser
-
Name of the user used for authentication when logging on the remote server to collect event logs.
- ResolveGUID
-
This optional boolean directive specifies that GUID values should be resolved to their object names in the
$Message
field. If ResolveGUID is set to TRUE, it produces two output fields. One that retains the non-resolved form of the GUID, and another which resolves to the above mentioned object name. To differentiate the two output fields, the resolved field name will have the DN suffix added to it. If the field already exists with the same name the resolved field will not be added and the original is preserved. The default setting is FALSE; the module will not resolve GUID values. Windows Event Viewer shows the Message with the GUID values resolved, and this must be enabled to get the same output with NXLog.
- ResolveSID
-
This optional boolean directive specifies that SID values should be resolved to user names in the
$Message
field. If ResolveSID is set to TRUE, it produces two output fields. One that retains the non-resolved form of the SID, and another which resolves to the above mentioned user name. To differentiate the two output fields, the resolved field name will have the Name suffix added to it. If the field already exists with the same name the resolved field will not be added and the original is preserved. The default setting is FALSE; the module will not resolve SID values. Windows Event Viewer shows the Message with the SID values resolved, and this must be enabled to get the same output with NXLog.
- SavePos
-
This boolean directive specifies that the file position should be saved when NXLog exits. The file position will be read from the cache file upon startup. The default is TRUE: the file position is saved if this directive is not specified. Even if SavePos is enabled, it can be explicitly turned off with the global NoCache directive.
- TolerateQueryErrors
-
This boolean directive specifies that im_msvistalog should ignore any invalid sources in the query. The default is FALSE: im_msvistalog will fail to start if any source is invalid.
131.22.2. Fields
The following fields are used by im_msvistalog.
$raw_event
(type: string)-
A list of event fields in key-value pairs.
$AccountName
(type: string)-
The username associated with the event.
$AccountType
(type: string)-
The type of the account. Possible values are:
User
,Group
,Domain
,Alias
,Well Known Group
,Deleted Account
,Invalid
,Unknown
, andComputer
.
$ActivityID
(type: string)-
A globally unique identifier for the current activity, as stored in EvtSystemActivityID.
$Category
(type: string)-
The category name resolved from Task.
$Channel
(type: string)-
The Channel of the event source (for example,
Security
orApplication
).
$Domain
(type: string)-
The domain name of the user.
$ERROR_EVT_UNRESOLVED
(type: boolean)-
This field is set to TRUE if the event message cannot be resolved and the insertion strings are not present.
$EventID
(type: integer)-
The event ID (specific to the event source) from the EvtSystemEventID field.
$EventTime
(type: datetime)-
The EvtSystemTimeCreated field.
$EventType
(type: string)-
The type of the event, which is a string describing the severity. This is translated to its string representation from EvtSystemLevel. Possible values are:
CRITICAL
,ERROR
,AUDIT_FAILURE
,AUDIT_SUCCESS
,INFO
,WARNING
, andVERBOSE
.
$EventXML
(type: string)-
The raw event data in XML format. This field is available if the module’s CaptureEventXML directive is set to TRUE.
$ExecutionProcessID
(type: integer)-
The process identifier of the event producer as in EvtSystemProcessID.
$Hostname
(type: string)-
The EvtSystemComputer field.
$Keywords
(type: string)-
The value of the Keywords field from EvtSystemKeywords.
$Message
(type: string)-
The message from the event.
$Opcode
(type: string)-
The Opcode string resolved from OpcodeValue.
$OpcodeValue
(type: integer)-
The Opcode number of the event as in EvtSystemOpcode.
$ProviderGuid
(type: string)-
The globally unique identifier of the event’s provider as stored in EvtSystemProviderGuid. This corresponds to the name of the provider in the $SourceName field.
$RecordNumber
(type: integer)-
The number of the event record.
$RelatedActivityID
(type: string)-
The RelatedActivityID as stored in EvtSystemRelatedActivityID.
$Severity
(type: string)-
The normalized severity name of the event. See $SeverityValue.
$SeverityValue
(type: integer)-
The normalized severity number of the event, mapped as follows.
Event Log Severity Normalized Severity 0/Audit Success
2/INFO
0/Audit Failure
4/ERROR
1/Critical
5/CRITICAL
2/Error
4/ERROR
3/Warning
3/WARNING
4/Information
2/INFO
5/Verbose
1/DEBUG
$SourceName
(type: string)-
The event source which produced the event, from the EvtSystemProviderName field.
$TaskValue
(type: integer)-
The task number from the EvtSystemTask field.
$ThreadID
(type: integer)-
The thread identifier of the event producer as in EvtSystemThreadID.
$UserID
(type: string)-
The Security Identifier (SID) which resolves to $AccountName, stored in EvtSystemUserID.
$Version
(type: integer)-
The Version number of the event as in EvtSystemVersion.
131.22.3. Examples
Note
|
Due to a bug or limitation of the Windows Event Log API, 23 or more
clauses in a query will result in a failure with the following error message:
ERROR failed to subscribe to msvistalog events, the Query is invalid: This
operator is unsupported by this implementation of the filter.;
[error code: 15001]
|
This configuration collects Windows EventLog with the specified query. BSD Syslog headers are added and the messages are forwarded to a remote host via TCP.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<Extension syslog>
Module xm_syslog
</Extension>
<Input eventlog>
Module im_msvistalog
<QueryXML>
<QueryList>
<Query Id='0'>
<Select Path='Application'>*</Select>
<Select Path='Security'>*[System/Level<4]</Select>
<Select Path='System'>*</Select>
</Query>
</QueryList>
</QueryXML>
</Input>
<Output tcp>
Module om_tcp
Host 192.168.1.1:514
Exec to_syslog_bsd();
</Output>
<Route eventlog_to_tcp>
Path eventlog => tcp
</Route>