WEC configuration¶

Input specification: input:WEC:

listen:  # Where to expose the server, "5985" for HTTP with Kerberos authentication or "5986 ssl" for HTTPS certificate authentication
output:  # Which output to send the incoming events to

queries:  # The Windows Event queries separated by new lines, which determine which Windows Events should be loaded in subscriptions
read_existing_events:  # (optional) Notifies Windows machines if they should send existing events (true/false, default: false)

last_value_storage:  # Persistent storage for the current last value (default: ./var/last_value_storage)
connection_retries:  # (optional) How many retries in a row is acceptable from Windows machines (default: 60)
connection_retries_wait:  # (optional) How long in seconds to wait for connection retry (default: 10.0)
heartbeat:  # (optional) How often in seconds the heart beat should be called upon subscriptions (default: 60)

backlog:  # (optional) Specify the number of pending connections the queue will hold (default: 128)
servertokens:  # (optional) Controls whether 'Server' response header field is included ('full') or faked 'prod' (default: full)
cors: # (optional) Specify CORS attributes (default: none)

cert:  # Specify path to the WEC server certificate
key:  # Specify path to the WEC server private key 
issuer_thumbprints:  # Specify issuer (CA) certificate SHA1 thumbprints separated by space (f. e. d6986fef2104f21ab0c7ccb279217abe29c0808a)
password:  # (optional) Specify a private key file password (default: none)
cafile:  # (optional) Specify a file to verify the peer (default: none)
capath:  # (optional) Specify a path to verify the peer (default: none)
ciphers:  # (optional) Specify custom SSL ciphers (default: none)
dh_params:  # (optional) Diffie–Hellman (D-H) key exchange (TLS) parameters (default: none)
verify_mode:  # (optional) Empty or one of CERT_NONE, CERT_OPTIONAL or CERT_REQUIRED

Queries¶

The queries setting with Windows Event queries may look as follows (query name followed by its definition):

input:WEC:WECInput:
  ...
  queries:
    Application: "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    System: "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    Security: "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    Setup: "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    Microsoft-Windows-Sysmon/Operational: "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    Microsoft-Windows-Windows Defender/Operational: "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    Microsoft-Windows-GroupPolicy/Operational: "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    Microsoft-Windows-TaskScheduler/Operational: "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    Microsoft-Windows-Windows Firewall With Advanced Security/Firewall: "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"

The queries can be specified for every Window Event log type, including:

Application for application logs
System for system logs
Security for security logs
Setup for logs related to the installations or updates

Log levels¶

In Windows Event Logging, the Level field indicates the severity of the event, ranging from critical errors to detailed informational messages.

Level 0 (Always) is reserved and typically unused.

Level 1 (Critical) signals a serious problem, such as a system component failure that requires immediate attention.

Level 2 (Error) denotes significant problems, such as failed services or drivers, that may impact functionality.

Level 3 (Warning) highlights potential issues that aren't immediately harmful but could lead to future problems if not addressed.

Level 4 (Information) records successful operations or routine events, like service startups or user logins, useful for tracking activity.

Level 5 (Verbose) provides detailed debugging or diagnostic information, mainly used during development or advanced troubleshooting. Filtering events with these levels allows for focused monitoring of system behavior based on severity.

Inclusion & exclusion¶

The queries can be limited for certain source IP addresses or machine IDs using YAML list of the identificators at the end of the query. The machine ID is unique to each Windows machine and it is based on the domain hostname.

  queries:
    System:
      "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"

    Security:
      "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    ...
    Application:
      "*[System[(Level=1 or Level=2 or Level=3 or Level=4 or Level=0 or Level=5)]]":
        - 192.168.111.128
        - 192.168.111.128
        - "APP.example.com"
    ...

In this way, only Windows machines with IPs 192.168.111.128, 192.168.111.128 and with machine ID APP.example.com will send application logs (their subscription will contain the application query).

This notation is analogic to specifying include section:

  queries:
    System:
      "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"

    Security:
      "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    ...
    Application:
      "*[System[(Level=1 or Level=2 or Level=3 or Level=4 or Level=0 or Level=5)]]":
        include:
          - 192.168.111.128
          - 192.168.111.128
          - "APP.example.com"
    ...

In order to exclude certain IP addresses / servers, there should be exclude section specified:

  queries:
    System:
      "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"

    Security:
      "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]"
    ...
    Application:
      "*[System[(Level=0 or Level=1 or Level=2 or Level=3 or Level=4 or Level=5)]]":
        exclude:
          - 192.168.111.129
    ...

Hence all machines except 192.168.111.129 will be queried for application logs.

Filtering¶

Filtering allows you to fine-tune which events are forwarded from Windows machines to the collector. This is achieved by modifying the XPath query syntax in the queries section.

You can filter events based on:

EventID
Level (Severity)
Provider Name
TimeCreated
Combinations of the above

Filter by EventID (Exclude Specific Events)¶

To exclude specific event IDs (e.g., event 5156 from Security logs), use a negated filter:

queries:
  Security:
    "*[System[(EventID!=5156)]]"

Filter by Multiple EventIDs (Exclude or Include)¶

You can exclude multiple event IDs using logical and, or, and not operators:

queries:
  Security:
    "*[System[not(EventID=5156 or EventID=4688 or EventID=4624)]]"

To include only specific event IDs:

queries:
  Security:
    "*[System[(EventID=4624 or EventID=4625)]]"

Filter by Level (Severity)¶

Event severity levels are defined as:

Level	Name
0	LogAlways
1	Critical
2	Error
3	Warning
4	Information
5	Verbose

Example: include only critical and error events:

queries:
  Application:
    "*[System[(Level=1 or Level=2)]]"

Filter by Provider Name¶

To filter only events generated by a specific provider, use:

queries:
  Security:
    "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and EventID=4624]]"

Filter by TimeCreated (Time Range)¶

You can restrict events to only those created after a specific time. The timestamp must be in ISO 8601 UTC format:

queries:
  System:
    "*[System[TimeCreated[@SystemTime>'2025-07-10T00:00:00.000Z']]]"

Note

Time-based filters apply only to existing events (read_existing_events: true) and may be ignored for live streams.

Combined Filters¶

You can combine multiple conditions for precise filtering:

queries:
  Security:
    "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and Level=0 and not(EventID=5156 or EventID=4688)]]"

This example includes only LogAlways events from the specified provider, excluding events 5156 and 4688.