Using Windows Event Forwarding, a company can easily send all needed Windows security events to a Windows Event Collector server. It is straightforward to setup event generation and forwarding using group policy, before selecting the events to log by specifying their ID number. Narrowing the selection of events to log is a worthwhile exercise in capturing only relevant data centrally. Those event capture settings need to be enabled on each system and group policy is updated to perform this, see the guide below, followed by advice on what to log.
The basic setup process for Windows Event Forwarding is creating a log server, enabling certain windows WEF services across the IT estate, then selecting events to log, the tested steps are below.
A central server with a configured Windows Event Log Collector service, often referred to as the “WEC Server”. (Normally by running winrm qc on the nominated collector server)
Windows Remote Management aka WinRM enabled on and all servers that will forward log events. (Normally using winrm quickconfig)
Add the computer account of the WEC server, and network service to each servers Event log readers group.
Double check Windows Firewall rules permitting WinRM connectivity over HTTP through port 5985 between the devices. (note HTTPS transport could also be used, with a central ca.cert)
Add further Group Policy Object permissions (GPO) to switch on security auditing and event logging. Through the chosen Policy, computer configuration.. Security settings, local policies, you can enable ‘audit account logon events’, ‘audit logon events’ and ‘Audit privilege Use’.
Create one or more event log subscriptions on the WEC server; a subscription is a collection of events based on Event Ids, such as 4624 an account logged in. See picture.
On the collector machine resync to ensure security settings can be collected (This can be done by running wecutil rs “subscription”)
When adding auditing of logons and other events, use auditpol.exe /get /category:* or gpresult to check results on the servers the group policy is applied to.
If event details are not listed correctly update the type; wecutil ss “subscription” /cf:Events
If you want to then use advanced auditing it is wise to ensure they are not overwritten by setting Group Policy, computer configuration... security options ‘Audit: Force audit policy subcategory settings to override audit policy’ to disabled.
*/
Event log reader permisions setup on member servers, adding network service and collector server.
Adding security WEF subscriptions on a Windows Event Collector Server.
It is possible to collect all security event logs - and maybe if you don't have any other centralised logging in your domain you should do this for forensic reasons - but the common approach of WEF is targeted alerts, filtering on security events. WEF can also compliment a SIEM if you already have one in your environment - let the SIEM do the heavy lifting of collecting every single event and use WEF to get important security events from member servers. Regarding the security of event logging, once the authentication phase has completed, Kerberos session communications are encrypted using a symmetric 256-bit key, even with HTTP as the protocol. Below is a starting point for security event logging followed by further suggestions:
Events in security log: 4100 – PowerShell attempt to run script failed because of a restrictive execution policy. 4103 – PowerShell script invoked 4104 – PowerShell ScriptBlock 4624 - logon type 2 keyboard4 624 – logon type 3 network share 4624 – logon type 7 unlock 4624 – logon type 10 Remote interactive RDP/Terminal Services 4648 – Logon attempted using explicit credentials scheduled task/run as 4657 – A registry value changed (needs auditing “Set Value" auditing is set in registry key’s SACL. 4688 - An application process was started 4698 - A Scheduled task was created 4720 – New user account created 4732 – New local account created 4731 – New local security group created 4732 – New local security group changed 4738 – User account was changed 4798 – Account enumeration - local user 4799 – Account enumeration - local group 4778 – User reconnected to a workstation, RDP gives client name, IP (also alongside 4624 logon) 4779 - user disconnected from workstation, RDP 5861 - Permanent Consumer event creation WMI
WEF on the collector server showing source computer and security events
Local administrator groups being changed
Local users being created or deleted on member systems
New Services being installed, particularly on Domain Controllers (as this is often an indicator of malware or lateral movement behavior.)
Useful to log: Enable “Process Command Line” logging entry to every event ID 4688 via Group Policy for command line processes including PowerShell.
Enhanced logging in Powershell 5.0 and WMF 5.0
Remote Desktop Protocol usage Events 4778/4779
High value groups like Domain Admins being Changed
Rules added to the Windows Firewall exception list. Event ID: 2004/2005
Adding Sysmon logging is an advanced enhancement to system logging, enable capture of memory events.
In summary, using WEF will help to identify what has occurred on a Windows machine, therefore its best used alongside security defence systems and IDS. It makes you much more efficient in tracing infections or malicious processes on one central location. This guide was written for Windows servers, however WEF can be enhanced for subscription of security logs on client hosts as well.