Subscriptions
While subscriptions are the cornerstone objects in Windows Event Collection (WEC), they are really just a compound specification. Subscriptions bring together all the specifications necessary to get the right event logs from the right computers (forwarders) to the right destination log on the right collector. Since subscriptions are created on individual collectors, subscriptions do NOT specify a collector since that is implicit.
Thus, subscriptions comprise specifications for
- Source computers (forwarders) defined in terms of Active Directory principals or DNS names
- Source event logs and criteria for specific events within the logs
- Destination log to receive the forwarded events
- Other settings relating to event flow
You can create a WEC subscription in Event Viewer or with Wecutil.
Each subscription has a name, which is unique among the subscriptions on that collector, and optionally a description.
Destination Log
The destination log determines which event log on the collector will receive the events forwarded by the source computers. Event Viewer defaults to the Forwarded Events log which is intended for that purpose.
However, there are important reasons why you may want to use more than one destination log for receiving forwarded events. The most common scenario is to facilitate multiple channels for log ingestion by downstream consumers, like SIEMs. Many SIEMs spool one thread per incoming log. By using multiple custom logs, you can boost the input of many SIEMs. Also, using multiple destination logs allows you more control over disk I/O and the ability to monitor EPS (events per second) for different subscriptions if they are directed to different logs. Our experience also indicates it helps avoid bottlenecks on busy collectors.
Recommending multiple destination logs leads to the question, “How do you create custom logs?”. WEC only supports custom logs which are created in a specific way which requires the creation of a manifest file, compilation involving 3 developer utilities and then registering of a DLL. We explain this process in
Creating Custom Event Logs for WEC Destinations.
Collector vs Source Initiated
Event forwarding can either be initiated
- by the collector (collector initiated) connecting to each forwarder and requesting events, or
- by each forwarder (source initiated) connecting to the collector and sending events.
Throughout this document we will focus on “source initiated” subscriptions other than a brief description of collector initiated here-in.
With collector-initiated subscriptions there is no need to configure the target
“subscription manager” on each forwarder since it’s the Collector who gets the ball rolling. However, collector-initiated subscriptions have some major requirements that are undesirable from security best practices and management:
- Windows firewall on each forwarder must allow incoming WinRM connections from each collector
- Collectors must have permissions on each forwarder to connect and request events using either the collector’s AD computer account or another AD account created for that purpose
Moreover, collector-initiated subscriptions do not scale well above a few source computers and maintenance becomes an issue, since the subscription must be kept up-to-date with each source computer for the collector to reach out to.
Source-initiated WEC subscriptions do not have these security or scalability issues. All connections are initiated from forwarder to collector. There is no need to open firewall exceptions or grant special permissions on forwarder systems. You can use AD groups or DNS wild cards to specify source computers instead of maintaining each one individually.
To specify which source event logs and which events within those logs should be forwarded, each subscription has an xpath query. Event Viewer provides a user interface that allows you to specify simple criteria such as log and event ID but in the background it’s just creating a xpath query. In fact, Event Viewer is an excellent way to test your xpath queries.
To get started building an xpath query, specify as many of the criteria as possible in the Query Filter dialog and then click the XML tab to display the generated xpath syntax. Then tailor it to your needs. Here is a simple xpath query that collects all events from the Application log and just event ID 4688 from the Security log.
<QueryList>
<Query Id="0" Path="Application">
<Select Path="Application">*</Select>
<Select Path="Security">*[System[EventID=4688]]</Select>
</Query>
</QueryList>
Xpath provides a powerful way to specify granular criteria for exactly which events are forwarded – or which are not. We recommend the latter – that is to think in terms of suppressing noise as opposed to selecting desired events. Using such negative logic is an important best practice that helps mitigate the risk of accidentally omitting important security events which you would have wanted to collect later.
Noise suppression is crucial because of the amount of valueless security events generated by Windows and the course granularity available in Windows audit policy. The earlier you discard noise events from your logging pipeline, the more you will save on network, compute and storage resources, the faster you will see and be able to analyze the important events, and this can lead to massive impacts on real dollar amounts given that most SIEMs charge based on volume. Optimizing your audit policy and implementing safe noise suppression at the WEC level has reduced SEIM expenses exponentially at organizations we have worked with.
To demonstrate the power of xpath queries here is a negative logic filter created with Supercharger’s managed filter capability:
<QueryList><Query Id="0" Path="Security"><Select Path="Security">*</Select>
<Suppress Path="Security">*[System[EventID=4688]] and *[EventData[Data[@Name='SubjectLogonId'] = '0x3e7' and (
Data[@Name='NewProcessName'] = 'C:\Windows\System32\SearchFilterHost.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\SysWOW64\SearchProtocolHost.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\SearchProtocolHost.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\backgroundTaskHost.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\conhost.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\wbem\WmiPrvSE.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\taskhost.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\taskeng.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\svchost.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\sc.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\rundll32.exe'
or Data[@Name='NewProcessName'] = 'C:\Windows\System32\taskhostex.exe'
)]]</Suppress><Suppress Path='Security'>(*[System[EventID=4769]] and *[EventData[Data[@Name='ServiceName'] = 'krbtgt']])
or (*[System[EventID=4770]])
or (*[System[EventID=4624]] and *[EventData[Data[@Name='LogonType'] = '3']])
or (*[System[EventID=4634]] and *[EventData[Data[@Name='LogonType'] = '3']])
</Suppress> </Query></QueryList>
Allowed Forwarders
Subscriptions allow you to define which computers should send events via this particular subscription, using either Active Directory or DNS names for non-domain forwarders.
AD Domain Environments
In a typical environment where all computers are part of one or more AD domains and forests, you will want to use Active Directory to specify your forwarders because you can leverage groups, and mutual authentication between forwarder and collector is handled automatically via Kerberos and the respective computer accounts. You can specify either individual computer accounts or groups. You can also indicate for each entry whether it should be included or excluded. The example below specifies all computers in the Domain Computers group of the LAB domain with the exception of SCDevWin11. Behind the scenes, Windows creates an access control list (ACL) with an ACE (access control entry) containing the SID of each computer or group specified and the allow/deny flag set to correspond to whether you selected included or excluded. Since it is SID-based, renaming groups does not affect subscriptions. In keeping with ACLs throughout Windows, deny entries override allow, meaning that exclude entries override include. In the example below SCDevWin11 won’t subscribe even though it is a member of Domain Computers. Order is not important.
If you use AD groups to specify forwarders, be aware that group membership changes for computer accounts only take effect upon reboot. That means if you add ComputerA to Group1 and assign Group1 to a subscription, ComputerA won’t subscribe until it is rebooted and sees that it is now a member of Group1. You can avoid rebooting computers by purging Kerberos tickets using the process described in
Accelerating Group Membership Changes without Rebooting Forwarders.
Using Organizational Units to specify which computers should subscribe to subscriptions on a given collector.
An alternative to using groups to scope forwarders is to rely instead on GPOs linked to OUs containing the desired forwarders. In this scenario, you specify Domain Computers as the only entry in allowed forwarders on each subscription (if you have multiple domains forwarding to this collector, include the Domain Computers group from each domain). Then create a GPO that specifies the appropriate collector as a target subscription manager. Finally link that GPO to each appropriate OU. Now each computer that receives that GPO will ask that collector for its subscriptions and subscribe since they are members of the Domain Computers group.
If you have computers that are not part of an AD domain, you can still use WEC with the help of PKI (public key infrastructure) to provide authentication. The example below shows a subscription that allows computers with DNS names ending in acme.com and a certificate signed by the lab-SCDevDC-CA certificate authority with the exception of c12.acme.com.
For full details on how to setup WEC in a non-domain environment see
WEC in a Non-AD Environment.
The DNS name in the subscription must match the forwarder’s computer name and primary DNS suffix which can be manually configured and verified in Control Panel \ System.
To manage this setting via Intune, use a Windows Configuration Profile under Administrative Templates \ Network \ DNS Client as shown below.
In addition to the proper DNS names, you must also specify which Certificate Authorities the collector should allow for authentication of non-domain forwarders attempting to connect. The forwarder must connect via HTTPS client certification having signed the attempt with the private key of a certificate issued by one of the Certification Authorities specified on the subscription. The client certificate subject or subject alternative names must include the DNS name of the forwarder and include Client Authentication among the key usages. Of course, the certificate can’t be expired or revoked, and the CA must be trusted by the collector, and the CA’s revocation list (CRL) must be available online for the collector to access. The subscription will also need to be configured to use HTTPS which is found in Event Viewer under “Advanced Subscription Settings as shown below.
Aside from subscription settings, the collector itself needs an HTTPS
listener based on a server certificate trusted by all forwarders. And the forwarder Certificate Authorities specified on the subscription must each have a
client certificate mapping.
On the forwarder side, the Network Service special principle (under which the WinRM service runs) must have Read access to the private key of the client certificate. WinRM will only use certificates where the subject or subject alternative name exactly matches the computer’s local full DNS name.
If you have more than a handful of non-domain forwarders, you will need a certificate management solution that uses SCEP (simple certificate enrollment protocol). In the past we have tested the combination of Intune and for the certificate authority both 1) the Azure Marketplace offering, SCEPman, to centrally manage Entra-joined Windows clients as WEC forwarders and 2) the newer Microsoft Cloud PKI.
WEC allows you to adjust frequency and batch size of the events sent by the forwarder. You can optimize for bandwidth usage or latency. You can customize these settings using Wecutil, or with Event Viewer, as shown above, you can select one of the pre-assigned profiles. See Subscription Property Reference under
Configuration Mode and related properties.
Heartbeat Interval
|
This value does not directly impact event delivery. Instead, this defines how often a forwarder will check in with the Collector even if no events need to be delivered, to let the Collector know that it is still active.
|
DeliveryMaxLatencyTime
|
How long the forwarder should wait before sending events if the waiting event quantity is less than DeliveryMaxItems
|
DeliveryMaxItems
|
How many waiting events should accrue before they are forwarded even if the DeliveryMaxLatencyTime is not yet reached
|
Configuration Mode
|
Heartbeat Interval
|
DeliveryMaxLatencyTime
|
DeliveryMaxItems
|
Normal
|
15 min
|
15 min
|
Not specified
|
Minimize Bandwidth
|
6 hours
|
6 hours
|
Not specified
|
Minimize Latency
|
1 hour
|
30 seconds
|
Not specified
|
Custom
|
User defined
|
To configure custom values for these or other advanced settings use
wecutil.
Here is a complete list of all properties comprising a WEC Subscription. Each property is listed by its XML tag name (see
Wecutil).
Included are the XML tag names and command line option names used by
Wecutil.
Enabled
Normally true. If set to False, the subscription is extant, the bookmarks for each forwarder’s source logs remain intact, but no events are sent until re-enabled.
Description
Self explanatory.
URI
Can be ignored. Normal value “"http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog";”
ConfigurationMode
WEC allows you to adjust frequency and batch size of the events sent by the forwarder. You can optimize for bandwidth usage or latency. Using Wecutil you can customize these settings or with Event Viewer, as shown above you can select one of the pre-assigned profiles.
Configuration mode impacts 3 other properties
Configuration Mode
|
Heartbeat Interval
|
DeliveryMaxLatencyTime
|
DeliveryMaxItems
|
Normal
|
15 min
|
15 min
|
Not specified
|
Minimize Bandwidth
|
6 hours
|
6 hours
|
Not specified
|
Minimize Latency
|
1 hour
|
30 seconds
|
Not specified
|
Custom
|
User defined
|
Expires
Normally null. Date when the subscription will end. The maximum date that can be used is 3000-12-31T23:59:59.999Z. If this property is not defined, the subscription will not expire.
Query
The Xpath query that determines which event logs and which events in those logs will be forwarded. See
Xpath queries.
TransportName
Either HTTP or HTTPS. By default, HTTP. Event flow is still encrypted even with HTTP using WinRM level encryption. HTTPS is only valuable when forwarding events from non-AD member computers. See
Non AD Domain Environments.
TransportPort
Defaults to 5985 for HTTP or 5986 for HTTPS. If forwarding events over the internet using HTTPS, we recommend 443.
DeliveryMaxItems
How many waiting events should accrue before they are forwarded even if the DeliveryMaxLatencyTime is not yet reached. Useful for optimizing event forwarding between bandwidth and latency.
DeliveryMaxLatencyTime
How long, in milliseconds, the forwarder should wait before sending events if the waiting event quantity is less than DeliveryMaxItems. Useful for optimizing event forwarding between bandwidth and latency.
HeartbeatInterval
This value does not directly impact event delivery. Instead, this defines how often, in milliseconds, a forwarder will check in with the Collector even if no events need to be delivered, to let the Collector know that it is still active.
Locale
Unclear what this affects if anything. In our environments the value is “en-US”.
ContentFormat
The Windows Event Log separates static text of events, such as value name and messages, from dynamic values, such as user names, handle IDs. This supports different languages and reduces storage. When you view an event, Event Viewer merges the static event message with dynamic values inserted at specified place holders.
This subscription property specifies how events will be rendered on the computer that sends the events before the events are sent to the event collector computer.
- Events - sends the raw event data only, and not any localized event data
- RenderedText - sends raw event data and localized event information
Default is RenderedText.
This property can reduce bandwidth, but it is important to make sure your Collectors are the same level of Windows or later than the forwarders so that the full event text will be rendered correctly at the time events are consumed by downstream SIEMs etc.
LogFile
The destination log on the local collector where received events will be written.
PublisherName
MS says “name of publisher that the event collector computer will raise events to the local log as. This is used when you want to collect events in a log other than the ForwardedEvents log”. But we haven’t seen this to be an important property even when using other logs. Normal value is Microsoft-Windows-EventCollector.
HostName
MS says “specifies the fully qualified domain name (FQDN) of the local computer. This property is used by an event source to forward events and is used in scenarios that involve multihomed servers that may have multiple FQDNs.” Normally null.
ReadExistingEvents
This property applies when a new forwarder first subscribes. Should it send all existing events in the specified source logs or should it pick up with the present, forwarding events that occur from now on?
Dialect
Normally null. MS says “dialect of the query string. For example, the dialect for SQL based filters would be SQL, and the dialect for WMI based filters would be WQL.”
Type
Either SourceInitiated or CollectorInitiated. In this document we only cover SourceInitiated.
AllowedIssuerCAs
Applies when using
HTTPS and client certificates for when forwarders are not in an AD environment trusted by the collectors such as Entra-joined Windows 11+ devices.
This is a comma separated list of the thumbprints of certificate authorities which can issue certificates to the devices forwarding events to this subscription. This is the issuing CA – not the root. Of course, the collector must have the root CA in its Trusted Root CAs store so that the certificate will ultimately be trusted.
When a source computer attempts to authenticate to a collector with a client certificate
- The root CA of the certificate must be trusted by the collector
- There must be
a certificate mapping for issuing CA
If the above succeeds, the source computer’s DNS name will be checked against AllowedSubjects and Denied Subjects and finally the certificate’s issuing CA’s cert against this AllowedIssuerCAs list. If those 2 checks succeed the source computer will subscribe to the subscription.
AllowedSubjects
Applies when using HTTPS and client certificates for when forwarders are not in an AD environment trusted by the collectors such as Entra-joined Windows 11+ devices.
This is a comma separated list of DNS names that specifies which computers should subscribe to this subscription. You can specify FQDNs of each source computer or wild cards such as *.acme.com.
DeniedSubjects overrides AllowedSubjects. Also, see AllowedIssuerCAs for more information.
DeniedSubjects
This comma separated list applies when using HTTPS and client certificates for when forwarders are not in an AD environment trusted by the collectors such as Entra-joined Windows 11+ devices.
This would be used to specify exceptions to AllowedSubjects.
AllowedSourceDomainComputers
This property applies when collectors and forwarders are part of an AD environment. It specifies the individual computer accounts and/or groups that should subscribe to this subscription.
Each entry can be allowed or denied. Denials override allows. So, for instance, you could allow a group but deny a specific member computer of that group.
Internally this property is implemented using a Windows access control list, so groups and computers are referenced by SID and immune to name changes.
The actual format of this property is SDDL.
SubscriptionRuntimeStatus
ActiveStatus specifies the status of the subscription:
- Disabled – The subscription is disabled
- Active – Normal status
- Inactive – When the subscription has an error
- Trying – We believe this only applies to collector-initiated subscriptions
If the ActiveStatus is Inactive there should be relevant information in
- LastError
- LastErrorMessage
- LastErrorTime
- NextRetryTime – only applied to collector -initiated subscriptions
Collector-initiated relevant properties
Properties only relevant to collector-initiated subscriptions which are not covered in this document
- DeliveryMode
- CredentialsType
- CommonUserName
- CommonPassword
Event Logs
At the end of the day, Event Logs are what WEC is all about on both sides of the WEC process: source and destination. Windows event logs are more than a simple, discreet text file. The actual file representing the event log is only directly accessed via the Windows Event Logging service. Event logs will not grow beyond the maximum size defined for each log via Event Viewer, group policy or Intune. Depending on the log’s retention settings, when the log reaches maximum size, as new events are logged, Windows either
- Overwrites the oldest events as needed
- Archives the log. Windows closes the file, renames it and opens a new file for new events. This does ensure no events are lost but 1) WEC does not forward events from archived logs and 2) archived event logs will continue to build until the volume fills up or you implement a process to delete archived event logs. The problem with this feature is that it is very I/O inefficient. Windows does not simply cut the current file free, renaming it to an archive and begin writing to a new file. Instead, it creates an empty archive and writes the old events out to it. Worse, you cannot specify a different path for archived files – meaning both the reading and writing I/O have to be handled by the same “spindle”.
- Windows itself crashes with a blue screen stop code of C0000244 {Audit Failed}. This extreme behavior is only enabled if the security option “Audit: Shut down system immediately if unable to log security audits” is enabled in group policy and the log is configured as Do Not Overwrite Events or Overwrite Events by Days.
It’s important to avoid lost events on both forwarders and collectors. On forwarders the goal is to forward source events before they are overwritten. This is accomplished by specifying a maximum log size sufficient to save up events to cover any expected / required outage and to keep collectors and the network between forwarders and collectors as healthy as possible. On collectors the goal is to get events out of destination logs and into your SIEM or other downstream consumers before being overwritten in the destination log. Configure the destination log’s maximum size large enough to save up events to cover the maximum amount of time required to survive outages of downstream consumers and the amount of time it will take them to catch up. You need to monitor the ingestion rate as reported by your SIEM and confirm that it meets or exceeds the incoming WEC rate of events to your collector. To make sure your SIEM is utilizing multiple streams of consumption, you may need to implement multiple destination logs instead of trying to push all the events through the Forwarded Events log on each collector.
How Supercharger Helps with Subscriptions
Supercharger provides policy based management of WEC subscriptions and allows to create,
modify and delete subscriptions on any collector without leaving the central web-UI. '
Supercharger monitors each subscription 24/7 and detects over 50 problem conditions,
automatically remediating many of them and alerting you only if necessary.
Many organizations require multiple collectors to handle all their forwarders.
Supercharger eliminates the need to re-create duplicate subscriptions on each
collector and automatically evenly distributes forwarders among available collectors.
There's no need to learn complicated Xpath syntax for Security log subscriptions when you can use Supercharger's Security Log Filter builder or our pre-built filters based on best practices.
Manage, Scale and Heal Windows Event Collection with Supercharger
Download •
Enterprise Pricing •
Ask Sales