Security of Windows Event Collection
As this document restricts its scope to source-initiated WEC, there are no incoming connections to forwarders – only collectors - the security considerations are principally
- Confidentiality, authenticity and integrity of log data
- Collector security
Authentication
In an Active Directory domain environment, mutual authentication is automatically provided via Kerberos and the collector’s and forwarder’s respective computer accounts. This protects your logging pipeline from being poisoned by bogus log data or threatened by protocol-based denial of service.
The forwarder is sure it’s talking to the AD computer associated with the DNS name specified in the target subscription manager. The collector is sure the incoming WinRM connection and log data within is coming from the computer claiming to send it. Securing the Kerberos authentication of WEC is really just a matter of good care and feeding of the Windows computers involved and of Active Directory. Then the collector looks for any subscriptions where the computer account or a group to which it belongs is allowed in the AllowedSourceDomainComputers (and isn’t excluded by a deny entry).
In a non-AD WEC environment – such as with Entra-joined Windows 11 forwarders – authentication is based on computer certificates and of course their private keys. The forwarder is sure it’s talking to the collector because the collector presents a certificate where the subject corresponds to the DNS name specified in the target subscription manager and demonstrates it has the private key of the certificate by signing authentication data with that private key which the forwarder verifies with the public key in the certificate. The forwarder knows the certificate is legitimate because it’s signed by a CA chain that ultimately ends in a root CA in the forwarders Trusted Root CAs store. Likewise, the server knows it’s talking to a computer with a certificate and private key issued by one of the certificate authorities defined in its WinRM client certificate mappings. Then the collector looks for any subscriptions where the forwarder’s CA is specified and where the forwarder’s DNS name matches the AllowedSubjects and doesn’t match DeniedSubjects. The strong authentication of client certificates is especially welcome when forwarding events over the Internet since the WinRM port of the collector must be exposed to the Internet. Other than volumetric denial of service attacks, attackers must first defeat Windows TLS based client certificate authentication which is equivalent to the security provided by an SSL based VPN using certificates – not passwords.
In all cases WEC traffic is authenticated based on high-entropy secrets (either computer account passwords or certificate private keys) – not on human specified passwords.
Events forwarded by WEC, and for that matter all WEC traffic, is encrypted by WinRM. In an Active Directory domain environment where WinRM by default communicates over HTTP port 5985, encryption is provided at the application level by WinRM and is based on secrets exchanged during Kerberos authentication. In a non-AD WEC environment – such as with Entra-joined Windows 11 forwarders – encryption is provided at the HTTPS layer on port 5986 (or a custom configured port such as 443). In this case, the encryption is the same TLS security that protects all other HTTPS traffic on the web. In all cases, WEC data is encrypted by a strong key based on high-entropy secrets (either computer account passwords or certificate private keys) – not on human specified passwords.
Administration
Configuration of WEC on Windows Servers requires membership in the local Administrators group; Windows does not carve out specific delegate-able privileges for WEC.
Beyond the local Windows Server, WEC administrative security also depends on the proper secure administration of
- Active Directory or Entra ID
- Group Policy or Intune
- Any other infrastructure upon which collectors have a security dependency
What If?
It is best practice to assume breach and work through the subsequent risks and exposures.
Malicious Log Data Injection
In the case of a WEC collector exposed to the Internet, what are risks of a rogue forwarder being put forward by an attacker that could defeat the strong client authentication of a WEC collector and begin sending events? The rogue forwarder could poison the logging pipeline with imposter log data or theoretically inject malformed log data to compromise the collector itself or downstream consumers like SIEMs. Beyond being theoretical, we think this is a low risk because consumption, parsing and processing of log data is very different than transactional data where vulnerabilities like buffer overflow or SQL injection are observed.
Arbitrary Code Execution on Collector
What if an attacker, via WinRM HTTPS, somehow gained arbitrary code execution ability such as via an as yet undiscovered buffer-overflow vulnerability in Windows TLS? This is not a WEC specific or even WinRM specific vulnerability. It would impact all of the countless Windows servers accepting incoming HTTPS connections.
The point is, before an attacker can attempt either of the above scenarios, they must first defeat client certificate authentication at the Windows TLS level which is stronger than normal password-based online banking.
The key is to carefully limit network accessibility to Internet exposed collectors to the one port used for WinRM HTTPS.
Manage, Scale and Heal Windows Event Collection with Supercharger
Download •
Enterprise Pricing •
Ask Sales