Using Windows Event Forwarding (WEF) to a Windows Event Collector (WEC) server, and then ingesting those Event Logs with Winlogbeats seems simple enough; however, there are a number of serious pitfalls that this document will guide you through.

WEC Forward log file

The windows server, on which you enable the WEC role, has only one log file for forwarded events.
Consider the consequences of sending all forwarded events to this one file:

Poor write performance, since all writes are to a single file
Poor search/read performance, as events are not partitioned in separate files
Poor data life cycle management, as this is per log file therefore all forwarded events are treated as equal
Poor resource utilisation of the WEC server, because all work is bottle-necked to a single file
Poor access management, separate files would allow differentiated file access controls
Poor coverage/visibility; due to the issues above many heavily restrict what event logs are forwarded, leaving gaps in their visibility

Even the Microsoft Security team uses multiple log files [MS Blog: Creating Custom Windows Event Forwarding Logs] on the WEC servers, and this document will guide you though doing the same.

There are many ways that one might divide event logs over multiple log files. There are projects and guides on the internet that use an event-type paradigm; that is all DNS logs in a DNS file, all PowerShell logs in another file, etc.

This guide uses an asset-type paradigm. i.e. All domain controller logs in one set of files, client systems in another set of files, etc.

WEF via HTTPS (instead of HTTP)

If you are only using hosts/systems that are all Domain members, it is safe to use the standard HTTP connectivity. In this setup encryption and authentication is handled via AD mechanisms, such as Kerberos. Even though HTTP is being used only the WEC server will be able to decrypt and read forwarded event logs.

However, if you wish to forward logs from an non-Domain member, you will want to use HTTPS for encryption and certificate-based authentication.

Disclaimer

This cookbook guide is written with the best of intentions, but it may contain mistakes, or mistakes may be made in the implementation of the steps documented herein. It is distributed in the hope that it will be useful, but without any warranties, express or implied. You are responsible for the changes you enact on your environment; neither the author nor Elastic are accountable for anything that may break as a result. If you do not understand the changes you are making, we recommend that you desist and seek assistance.

The accompanying code to this guide is provided under the AGPL 3.0 licence (https://github.com/ElasticSA/wec_pepped/blob/master/LICENSE).

WEC Server setup

Preparation and configuration

Download and unpack the latest ZIP file from the WEC_Pepped GitHub repository:
https://github.com/ElasticSA/wec_pepped

The PowerShell scripts provided here will define your WEC server’s entire setup, and thus how it fits into your Active Directory (AD) architecture. Therefore you will need to understand this setup, so that you can adapt it to your AD environment.

It all starts with what are known as “Providers” and “Channels” therein. You can have multiple Providers; however, each Provider can only have upto 8 log “Channels,” and a Channel ultimately means a log file.

In our setup we have created a Provider based on the usual Domain member assets:

Controllers
Servers
Clients (user systems; desktop/laptops)
Privileged (e.g. Jumphosts or WEC)
Members (normal domain members; NOT in the other groups)
Misc (miscellaneous, for those hosts that don't fit)

You can alter the list of Providers to match your AD’s hierarchy — perhaps to create a Provider per Business Unit or Area of Operation. Source Hosts are mapped to Providers via AD Groups (a limitation of the WEC server); however, we provide a script to keep these AD group members synchronised with your AD’s OUs. It is important that membership of these groups is exclusive; a source host being in more than one group will forward its logs to more than one Provider, leading to duplication. This can be made easier to handle through group exclusions, such as the Domain-Members Provider uses.

All of the Providers, which should map to asset groups, have the same set of (max eight) Channels; our defaults are:

Application: “Application” and similar logs
Security: “Security” and similar logs
Sysmon: “Microsoft-Windows-Sysmon/Operational”
System: “System”, “HardwareEvents”, “Setup” and similar logs
Script: “Windows PowerShell” and similar logs
Service: DNS, DHCP, and other service logs
Misc: Any other miscellaneous logs

You can change this list of Channels and the Event Log filter associated with them. These filters select what events are forwarded to that given Channel from all source hosts assigned to that Channel’s Provider.

To edit Providers, Group/OU mapping, and Channels open wec_config.ps1 in PowerShell ISE:

Let's discuss each of these configuration variables:

$GroupList

This Hashmap lists groups that we want to keep synchronised with our OU hierarchy. The Key/Name is the Group name, and the value is an array of one or more OU distinguished names.

Note: Do not list “Domain Computers”, “Domain Controllers”, or any other group that is already automatically managed by Active Directory.

$ProviderList

This Hashmap lists the Providers we are going to create and their configuration:

GUID: A unique GUID for this Provider. You can use “[guid]::NewGuid()” in PowerShell to get new GUIDs for any Provider you add. Also if you rename an existing Provider, please give it a new GUID.
LogDir: The directory that this Provider’s logs should be placed in. It is good practice to store WEC logs on a separate dedicated disk, and not on the OS Disk.
LogSize: The size that this Provider’s log can grow to before rolling over.
Inc_Groups: An Array/List of AD groups, whose members will send their logs to this Provider.
Exc_Groups: An Array/List of AD groups, whose members will be excluded from sending logs to this Provider.

Note: The “Domain-Members” Provider (example in wec_config.ps1) has some special logic in this configuration file. It uses “Domain Computers” to ‘include’ all domain computers, but then ‘excludes’ all groups used in the ‘include’ list of any other Providers. This creates a catch-all to capture any system that has not yet been assigned to another WEC Group (or OU mapped to such a group).

$ChannelList

This Hashmap lists the (maximum) eight Channels that all Providers get. The value is a hashmap of possible forward filter profiles; these filters are used to select what events are sent to a Channel (log file) from all systems mapped to that Channel's Provider.

You can use Event Viewer to help create this (XML) XPath-based filter.

Create a new Custom View:

In the Filter tab, build the Event Log Selection as you want, then switch to the XML tab to copy out the XML:

Paste that XML query into the Channel forward filter (profile)

$FFProfile

This selects which Forward Filter (FF) is used, from those available in the $ChannelList definition. Two FF profiles are included in the current version of wec_config.ps1:

Standard: Collect all non-debug logs from various recommended Event log files/Channels
Minimal: Collect specific Event (IDs) to meet various security use cases

Note: $FFProfile = “Standard” would select “FFStandard” from $ChannelList. (i.e. “FF${$FFProfile}”)

Other variables

$NewGroupOU

The scripts that use $GroupList and $ProviderList will create any missing groups; these groups will be created under the OU distinguished name provided here. Its default is the AD’s “Users” container.

$BaseOU

The Base OU of the AD LDAP tree, used in various places to save typing, and so that the script will just work in different AD environments. The default is the current AD’s distinguished name (i.e. its Base).

$WlbProcessorsExtra, $WlbEventLogsExtra, $WlbEventLogOptions

You can use these to insert extra configuration and options into the winlogbeat.yml generated by gen_winlogbeat_config.ps1. See: Set up Winlogbeat.

Creating additional forward log files

The following will add new forward log files on your WEC server that can be stored on a dedicated disk (if need be) and have individual controls for data lifecycle and access control:

Install the Windows 8.1 SDK

Although this guide used (and was tested with) Windows 10, we will use utilities that are in the Windows 8.1 SDK and not in the Windows 10 SDK.

https://developer.microsoft.com/en-us/windows/downloads/windows-8-1-sdk

Note: These three steps can be done on another computer than the WEC server to avoid installing an SDK on it. Just be sure to use exactly the same wec_config.ps1 here as you will use on the WEC server, so that the DLL is correctly built.

Create the custom Channels manifest

Be sure to have all the scripts available, as detailed above.

In a PowerShell console ‘cd’ to the directory where you unpacked the files; and edited wec_config.ps1
Then run:

.\gen_manifest.ps1

Build the custom Channels .dll

To build the DLL from the MAN file do the following:

Ensure that the build_man2dll.ps1 PowerShell script is in the same directory as your WecFwdChans.man file
Run the build script:

.\build_man2dll.ps1

A new WecFwdChans.dll will be created in the same directory, as well as a number of other intermediary files that you can ignore.

Set up the WEC subscriptions

The following will setup all the required WEC server subscriptions:

Install the custom Channels (man/dll) on the WEC server

This step will install the new Event log Channels on the current system.

In an Administrator PowerShell console, run:

.\install_channels.ps1

Note: If you built the WecFwdChans.dll and WecFwdChans.man on a different system with the Windows SDK, be sure to have copied them into the wec_pepped directory here, and that the wec_config.ps1 is the same on both systems.

Configure the custom Channels

This step will configure the new event Channels/log files, such as log location and size.

In an Administrator PowerShell console, run:

.\configure_channels.ps1

You can re-run the script to apply can configuration changes made in wec_config.ps1

Start the WEC Server

Before we can setup our WEC subscriptions, we need to initiate the WEC Service.

In an Administrator PowerShell console, run:

wecutil.exe qc

This just runs a “quick config” setup, there are other more in depths methods to setup the WEC Service.

Create WEC subscriptions

This step will create and configure all the WEC Subscriptions needed for all the Channels you have created. Each Channel will have its own Subscription, and presumably each of your Providers has eight Channels.

In an Administrator PowerShell console, run:

.\setup_subscriptions.ps1

Note: If you make changes in wec_config.ps1 that affect these Subscriptions, such as changing a Channel’s filter, you can run this script again to update all your existing Subscriptions.

Active Directory configuration (GPO, OUs, and Groups)

You will need Domain Administrator privileges for this part of the guide.

Maintaining group assignments

Source hosts are assigned to Subscriptions (and thus Providers) via AD Group membership. However, it is very likely that you would like to manage this via the OU that the host system is placed in. To enable this we provide the map_ou2group.ps1 script.

Schedule a task to regularly run map_ou2group.ps1, to keep group membership in sync with OU location.

	Create a new Scheduled Tasks Ensure it runs with Domain Administrator privileges, so that it can update Domain Groups
	Set it to Trigger Daily at 00:00:10 During the day you might want it to repeat, for example every 2 hours. Be sure the repeats do not run longer than 1 day. You could set the task to be stopped if it takes longer than 1 hour.
	Add a “Start a program” action. Set the program to powershell.exe. To find where this is on your system type “echo $PSHOME” in a powershell window. Set the argument to: “” -File C:\Path\To\map_ou2groups.ps1 “” We recommend you avoid Paths with spaces or other special characters!
	You can leave the Conditions on default
	You can leave or tune the further Settings
	When you click OK to save/create the Task, you will be asked for the Password to the Domain Admin user that you set.

Configure an Audit Policy

It is no use to have Event Log Forwarding setup if the source host is not logging anything. At the very minimum you will need to set up one or more Audit Policy GPO within your domain.

Creating an Audit Policy

	In Group Policy Management navigate to your domain’s “Group Policy Objects” folder. Right Click and select “New”
	Name your new policy
	Right Click on the new Policy and select Edit
	In the Policy Editor navigate to: → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies We will be configuring each of the items in each of the Categories under “Audit Policies”

You can repeat the previous steps to create any of the following policies.

Generic minimal audit policy

The following is based on guides, such as this recommendation on a minimal policy by Microsoft Security [WEF-ID Appendix A - Minimum recommended minimum audit policy]. This policy does not consider a systems role and could be used as a minimum fallback policy.

Create the new policy as described in: Creating an Audit Policy
Use the following to configure the policy items inside each of the categories

Note: Remember this is a minimum recommendation; you can deviate from this list.

Category	Item	Audit settings
Account Logon	Credential Validation	Success & Failure
Account Management	Security Group Management	Success
Account Management	User Account Management	Success and Failure
Account Management	Computer Account Management	Success and Failure
Account Management	Other Account Management Events	Success and Failure
Detailed Tracking	Process Creation	Success
Detailed Tracking	Process Termination	Success
Logon/Logoff	User/Device Claims	Not configured
Logon/Logoff	IPsec Extended Mode	Not configured
Logon/Logoff	IPsec Quick Mode	Not configured
Logon/Logoff	Logon	Success and Failure
Logon/Logoff	Logoff	Success
Logon/Logoff	Other Logon/Logoff Events	Success and Failure
Logon/Logoff	Special Logon	Success and Failure
Logon/Logoff	Account Lockout	Success
Object Access	Application Generated	Not configured
Object Access	File Share	Success
Object Access	File System	Not configured
Object Access	Other Object Access Events	Not configured
Object Access	Registry	Not configured
Object Access	Removable Storage	Success
Policy Change	Audit Policy Change	Success and Failure
Policy Change	MPSSVC Rule-Level Policy Change	Success and Failure
Policy Change	Other Policy Change Events	Success and Failure
Policy Change	Authentication Policy Change	Success and Failure
Policy Change	Authorization Policy Change	Success and Failure
Privilege Use	Sensitive Privilege Use	Not configured
System	Security State Change	Success and Failure
System	Security System Extension	Success and Failure
System	System Integrity	Success and Failure

Domain Controller audit policy

These policy recommendations are based on the advice given in Microsoft’s own guides (SAP Security auditing); they are based on this spreadsheet [Security (threat detection) Audit Policies and windows events (SAP)], which aggregates all the tables from the source documentation.

Create the new policy as described in: Creating an Audit Policy
Use the following to configure the policy items inside each of the categories
Items not listed, if left unconfigured, will inherit from policies in parent OUs; therefore, you may wish to explicitly disable any policy not listed in the table below

Note: Remember these are just recommendations; you can deviate as you see fit, and you should consult the detailed information linked from the main table (Security (threat detection) Audit Policies and windows events (SAP)), if you so wish.

Category	Item	Audit Setting (Enable)
Account Logon	Audit Credential Validation	Success & Failure
Account Logon	Kerberos Authentication Service	Success & Failure
Account Logon	Kerberos Service Ticket Operations	Success & Failure
Account Management	Computer Account Management	Success only
Account Management	Distribution Group Management	Success only
Account Management	Other Account Management Events	Success only
Account Management	Security Group Management	Success only
Account Management	User Account Management	Success & Failure
Detailed Tracking	PNP Activity	Success only
Detailed Tracking	Process Creation	Success only
DS Access	Directory Service Access	Failure only
DS Access	Directory Service Changes	Success only
Logon/Logoff	Account Lockout	Failure only
Logon/Logoff	User/Device Claims	Success only
Logon/Logoff	Group Membership	Success only
Logon/Logoff	Logoff	Success only
Logon/Logoff	Logon	Success & Failure
Logon/Logoff	Other Logon/Logoff Events	Success & Failure
Logon/Logoff	Special Logon	Success only
Object Access	Detailed File Share	Failure only
Object Access	File Share	Success & Failure
Object Access	Filtering Platform Connection	Failure only
Object Access	Other Object Access Events	Success & Failure
Object Access	Removable Storage	Success & Failure
Policy Change	Audit Policy Changes	Success only
Policy Change	Authentication Policy Changes	Success only
Policy Change	MPSSVC Rule-Level Policy Change	Success & Failure
Policy Change	Other Policy Change Events	Failure only
Privilege Use	Sensitive Privilege Use Events	Success & Failure
System	Other System Events	Success & Failure
System	Security State Change	Success only
System	Security System Extension	Success only
System	System Integrity	Success & Failure

Domain Server audit policy

These policy recommendations are based on the advice given in Microsoft’s own documentation (SAP Security auditing); they are based on this spreadsheet [Security (threat detection) Audit Policies and windows events (SAP)], which aggregates all the tables from the source documentation.

Create the new policy as described in: Creating an Audit Policy
Use the following to configure the policy items inside each of the categories
Items not listed, if left unconfigured, will inherit from policies in parent OUs; therefore, you may wish to explicitly disable any policy no listed in the table below

Category	Item	Audit Setting (Enable)
Account Logon	Audit Credential Validation	Success & Failure
Account Management	Security Group Management	Success only
Account Management	User Account Management	Success & Failure
Detailed Tracking	PNP Activity	Success only
Detailed Tracking	Process Creation	Success only
Logon/Logoff	Account Lockout	Failure only
Logon/Logoff	User/Device Claims	Success only
Logon/Logoff	Group Membership	Success only
Logon/Logoff	Logoff	Success only
Logon/Logoff	Logon	Success & Failure
Logon/Logoff	Other Logon/Logoff Events	Success & Failure
Logon/Logoff	Special Logon	Success only
Object Access	Certification Services	IF CA Server Role installed
Object Access	Detailed File Share	If File Server: Failure only Others: Success & Failure
Object Access	File Share	Success & Failure
Object Access	Filtering Platform Connection	Failure only
Object Access	Other Object Access Events	Success & Failure
Object Access	Removable Storage	Success & Failure
Policy Change	Audit Policy Changes	Success only
Policy Change	Authentication Policy Changes	Success only
Policy Change	MPSSVC Rule-Level Policy Change	Success & Failure
Policy Change	Other Policy Change Events	Failure only
Privilege Use	Sensitive Privilege Use Events	Success & Failure
System	Other System Events	Success & Failure
System	Security State Change	Success only
System	Security System Extension	Success only
System	System Integrity	Success & Failure

Domain Workstation audit policy

Create the new policy as described in: Creating an Audit Policy
Use the following to configure the policy items inside each of the categories
Items not listed, if left unconfigured, will inherit from policies in parent OUs; therefore, you may wish to explicitly disable any policy no listed in the table below

Category	Item	Audit Setting (Enable)
Account Logon	Audit Credential Validation	Success & Failure
Account Management	Security Group Management	Success only
Account Management	User Account Management	Success & Failure
Detailed Tracking	PNP Activity	Success only
Detailed Tracking	Process Creation	Success only
Logon/Logoff	Account Lockout	Failure only
Logon/Logoff	User/Device Claims	Success only
Logon/Logoff	Group Membership	Success only
Logon/Logoff	Logoff	Success only
Logon/Logoff	Logon	Success & Failure
Logon/Logoff	Other Logon/Logoff Events	Success & Failure
Logon/Logoff	Special Logon	Success only
Object Access	Detailed File Share	Success & Failure
Object Access	File Share	Success & Failure
Object Access	Filtering Platform Connection	Failure only
Object Access	Other Object Access Events	Success & Failure
Object Access	Removable Storage	Success & Failure
Policy Change	Audit Policy Changes	Success only
Policy Change	Authentication Policy Changes	Success only
Policy Change	MPSSVC Rule-Level Policy Change	Success & Failure
Policy Change	Other Policy Change Events	Failure only
Privilege Use	Sensitive Privilege Use Events	Success & Failure
System	Other System Events	Success & Failure
System	Security State Change	Success only
System	Security System Extension	Success only
System	System Integrity	Success & Failure

Applying/linking an audit policy

You will need to link each of the policies created above into appropriate OUs:

You could link the Generic Minimal Audit Policy at the root of your AD tree as a catch-all for any system that doesn’t match any of the more specific policies
The Domain Controller Audit Policy should be linked into the Domain Controllers container
The Domain Server Audit Policy should be linked into any OU branch that contains your servers
The Domain Workstation should be linked into any OU branch that contain client (or workstation) systems

To link an Audit Policy GPO into the relevant OUs for your AD, right click the target location and select Link to an Existing GPO.

Logging addendum

You might want to consider enabling further event Channels (logging), such as CAPI; see: WEF-ID Appendix C - Event channel settings (enable and channel access) methods

Configure Windows Event Forwarding (WEF)

We need to configure a GPO to tell systems to forward their logs.

Create a WEF Policy

	In Group Policy Management, navigate to your AD’s “Group Policy Objects” folder Right-Click and select New
	Name the Policy
	Right-Click it and select Edit
	Navigate to: → Computer Configuration → Policies → Administrative Templates → Windows Components → Event Forwarding Open “Configure target Subscription Manager” to edit.
	Enable the policy Then next to SubscriptionManagers click Show
	Enter the URL to your WEC server’s Subscription Manager (you can have more than one WEC). Use the form: “” Server=http://FQDN:5985/wsman/SubscriptionManager/WEC “” Note: For redundancy you can forward to multiple WEC servers!
	Next (in the same GPO edit) navigate to: → Computer Configuration → Policies → Windows Settings → Security Settings → System Services The WEF service is a part of WS Management, so that needs to be running.
	Edit “Windows Remote Management (WS-Management)” Enable the policy and set the startup mode to Automatic Since we are using Source Initiated WEF, we do not need to open the WinRM ports on the Firewall, as these connections are outbound. (For Collector Initiated, you will need to make WinRM reachable from WEC server.)
	Next (in the same GPO edit) navigate to: → Computer Configuration → Preferences → Control Panel Settings → Local Users and Groups
	We need to allow the WEF service, which runs as “Network Service” to be able to access and read all Event Logs. Right-Click and select New-->Local Group
	Click the “...” button next to Group Name. Be sure that location is set to the local system and not the AD domain. Enter the “Event Log Readers” group
	Under Members, Click the Add button Next to the Name field click the “...” button Be sure that location is set to the local system and not the AD domain. Enter the “Network Service” user.
	Finally you should have the displayed (left) Group name; note the “(built-in)” next to it. You should also be ‘Updating’ this group with “BUILTIN\NETWORK SERVICE” with SID S-1-5-20 and action ADD
	Your new WEF Policy is now complete and you can close the Editor

Once created, link the new WEF Policy to the relevant OUs in your AD:

In addition to the GPO doing so for Domain members, you will need to add ‘Network Service’ to ‘Event Log Readers’ in your AD “Builtin” container, so that your Domain Controllers will be able to forward logs:

Set up Winlogbeat

The Winlogbeat MSI installer can be found here: https://www.elastic.co/downloads/beats/winlogbeat

	Download the Winlogbeat MSI installer from: https://www.elastic.co/downloads/beats/winlogbeat
	Run and Click next through the installer
	The last screen will give you the option to open the configuration directory in Windows Explorer

In the wef_pepped directory in an Administrator PowerShell console, run:

.\gen_winlogbeat_config.ps1

Note: If this is the first time it will take winlogbeat.example.yml and generate a new configuration. All subsequent runs it will take winlogbeat.yml and update it with any changes from wec_config.ps1, keeping other configurations, like output, intact.

It does this by replacing everything between “winlogbeat.event_logs:” or “processors:” and the first comment line starting with “# =”

Auto-configure output with Cloud ID

In the winlogbeat.yml config you can set “cloud.id” and “cloud.auth”, which will then automatically configure everything else for you. You have a Cloud ID if you use Elastic Cloud (https://cloud.elastic.co) for Cloud SaaS deployments or you use ECE/ECK on-premises (or in your own VPC); if not follow: Manually configure the Elasticsearch output

Use the helper script to add the keystore variable CLOUD_ID and its value:

.\beat_cmd.ps1 keystore add CLOUD_ID

Enter value for CLOUD_ID: <<PASTE CLOUD ID>>

Successfully updated the keystore

You can use --force to overwrite an existing value

Then add the keystore variable CLOUD_AUTH in the form “USERNAME:PASSWORD” (no quotes):

.\beat_cmd.ps1 keystore add CLOUD_AUTH

Enter value for CLOUD_AUTH: <<PASTE USERNAME:PASSWORD>>

Successfully updated the keystore

Note: Do not use the Elasticsearch “elastic” user. This user is equivalent to Administrator for Elasticsearch, and so using it for Beats is a big security risk. We recommend you create and use the “beat_agent” user as documented here: https://ela.st/tj-qsg-sec-roles#h.3zzmxhst4mfz

Open C:\ProgramData\Elastic\Beats\winlogbeat\winlogbeat.yml with an editor running as Administrator
Uncomment cloud.id: and set it to “${CLOUD_ID}”
Uncomment cloud.auth: and set it to “${CLOUD_AUTH}”

cloud.id: ${CLOUD_ID}

cloud.auth: ${CLOUD_AUTH}

You might want to comment the output.elasticsearch out, as it will not be used when one uses cloud.id.

Don’t forget to save.

Run Winlogbeat setup to prepare your Elasticsearch and Kibana to ingest Winlogbeat data:

.\beat_cmd.ps1 setup

Note: If you ever upgrade Beats again to a new version you will have to run setup again to prepare Elasticsearch and Kibana for that version of Beats.

(Re-)Start Winlogbeat and the Event Logs should flow! In an Administrator PowerShell console:

Restart-Service -name winlogbeat

Manually configure the Elasticsearch output

In the winlogbeat.yml you will need to configure “output.elasticsearch:” and “setup.kibana:”

Use the helper script to add the keystore variable BEAT_UN (Beat UserName) and its value:

.\beat_cmd.ps1 keystore add BEAT_UN

Enter value for BEAT_UN: <<PASTE BEAT USERNAME>>

Successfully updated the keystore

You can use --force to overwrite an existing value

Then add the keystore variable BEAT_PW (Beat PassWord) and it value:

.\beat_cmd.ps1 keystore add BEAT_PW

Enter value for BEAT_PW: <<PASTE BEAT PASSWORD>>

Successfully updated the keystore

Open C:\ProgramData\Elastic\Beats\winlogbeat\winlogbeat.yml with an editor running as Administrator
Ensure cloud.id and cloud.auth remain commented (out).
Configure “host:” under “setup.kibana:” with the URL to Kibana (uncommenting as needed)
Under “output.elasticsearch:” configure:

The host list “hosts:” to all your Hot or Ingest Elasticsearch nodes
username: to “${BEAT_UN}”
password: to “${BEAT_PW}”

setup.kibana:

host: "https://URL-to-Kibana.exmaple.com/"

output.elasticsearch:

hosts: ["FQDN-of-ES1:9200","FQDN-of-ES2:9200","FQDN-of-ES3:9200"]

protocol: "https"

username: ${BEAT_UN}

password: ${BEAT_PW}

Don’t forget to save.

Run Winlogbeat setup to prepare your Elasticsearch and Kibana to ingest Winlogbeat data:

.\beat_cmd.ps1 setup

Note: If you ever upgrade Beats again to a new version you will have to run setup again to prepare Elasticsearch and Kibana for that version of Beats.

(Re-)Start Winlogbeat and the Event logs should flow! In an Administrator PowerShell console:

Restart-Service -name winlogbeat

Other useful winlogbeat.yml configuration options

name: - Give this beat a name to help make it more easily identifiable
processors: - The script already adds necessary ones, but you can add others by editing winlogbeat.yml directly or adding them to $WlbProcessorsExtra in wec_config.ps1 and running gen_winlogbeat_config.ps1 again (this second option ensures they’re not overwritten).
More info on Winlogbeat processors: https://www.elastic.co/guide/en/beats/winlogbeat/current/filtering-and-enhancing-data.html
monitoring.enabled: - Set to “true” to receive telemetry about the health and performance of this beat in your Remote Monitoring/Telemetry Cluster
monitoring.elasticsearch: - Takes the same options as “output.elasticsearch” but should point to your Remote Monitoring/Telemetry Cluster

Appendix

Troubleshooting

WEC Server troubleshooting

WEC on Windows Server 2016 or 2019 and no Subscription is working

If you’ve set up WEC on Windows Server 2016 or Windows Server 2019, you will probably find that Event Logs are not being forwarded.

If you look at a source host, you will find a log entry similar to:

To fix this:

On the WEC server in an Administrator PowerShell console, run:

netsh http delete urlacl url=http://+:5985/wsman/

netsh http add urlacl url=http://+:5985/wsman/ sddl='D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)'

netsh http delete urlacl url=https://+:5986/wsman/

netsh http add urlacl url=https://+:5986/wsman/ sddl='D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)'

You will then need to restart the WEC service, so run: Restart-Service -name wecsvc

Restart-Service -name wecsvc

Reference: [Events are not forwarded if the collector is running Windows Server]

Only receive Event ID 111

Once you deployed your WEC and the required GPOs, you might see the following from source hosts:

This is likely because the Event Forwarder (running as Network Service) can not read the local logs. For this reason the WEF Policy (detailed in Configure Windows Event Forwarding (WEF)) adds the local “Network Service” user to the local “Event Log Readers” group. However, if that GPO was published recently many of the source systems will have already started their services without that new group assignment.

To fix this problem, simply reboot the source host. However you may want to ensure that it has up-to-date GPOs by running the following command in an Administrator console:

gpupdate.exe /force /boot

Despite the /boot argument, the new group assignment won't trigger a reboot, so you still need to do that. This is because any already started process will already have the old group assignment. You can also check the membership of the local “Event Log Readers” group.

This problem will also resolve itself over time. It only affects systems that last booted before the new GPO existed. So it won't affect any new systems (new domain members) or existing systems that have booted after receiving the new GPO.

References & further reading

Security (threat detection) Audit Policies and windows events (SAP)

This spreadsheet summaries and maps the recommendations of the follow document: https://ela.st/tjs-winevt-auditing

SAP Security auditing

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/security-auditing-overview

SAP Advanced security audit policies

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-auditing

SAP Advanced security audit policy settings

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-audit-policy-settings

SAP Advanced security auditing FAQ

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-auditing-faq

Events are not forwarded if the collector is running Windows Server

https://docs.microsoft.com/en-us/troubleshoot/windows-server/admin-development/events-not-forwarded-by-windows-server-collector

Palantir WEC

An alternate way to setup a WEC server: https://github.com/palantir/windows-event-forwarding (for your consideration)

Author

See other Cookbook guides that I have written: https://ela.st/tjs-cookbook-lib

Introduction

WEC Forward log file

WEF via HTTPS (instead of HTTP)

Disclaimer

WEC Server setup

Preparation and configuration

$GroupList

$ProviderList

$ChannelList

$FFProfile

Other variables

$NewGroupOU

$BaseOU

$WlbProcessorsExtra, $WlbEventLogsExtra, $WlbEventLogOptions

Creating additional forward log files

Install the Windows 8.1 SDK

Create the custom Channels manifest

Build the custom Channels .dll

Set up the WEC subscriptions

Install the custom Channels (man/dll) on the WEC server

Configure the custom Channels

Start the WEC Server

Create WEC subscriptions

Active Directory configuration (GPO, OUs, and Groups)

Maintaining group assignments

Configure an Audit Policy

Creating an Audit Policy

Generic minimal audit policy

Domain Controller audit policy

Domain Server audit policy

Domain Workstation audit policy

Applying/linking an audit policy

Logging addendum

Configure Windows Event Forwarding (WEF)

Set up Winlogbeat

Auto-configure output with Cloud ID

Manually configure the Elasticsearch output

Other useful winlogbeat.yml configuration options

Appendix

Troubleshooting

WEC Server troubleshooting

WEC on Windows Server 2016 or 2019 and no Subscription is working

Only receive Event ID 111

References & further reading

Creating Custom Windows Event Forwarding Logs

Use Windows Event Forwarding to help with intrusion detection (WEF-ID)

WEF-ID Appendix A - Minimum recommended minimum audit policy

WEF-ID Appendix B - Recommended minimum registry system ACL policy

WEF-ID Appendix C - Event channel settings (enable and channel access) methods

WEF-ID Appendix D - Minimum GPO for WEF Client configuration

WEF-ID Appendix E – Annotated baseline subscription event query

WEF-ID Appendix F – Annotated Suspect Subscription Event Query

Security (threat detection) Audit Policies and windows events (SAP)

SAP Security auditing

SAP Advanced security audit policies

SAP Advanced security audit policy settings

SAP Advanced security auditing FAQ

Events are not forwarded if the collector is running Windows Server

Palantir WEC

Author