Centralisation of logging using WEF

What I find in my daily incident response work with different sites is the need to promote the importance of logging: namely centralised log collection. It cannot be understated how logs prove invaluable in a security incident. Tracing through logs on a central location makes investigation so much easier, and allows incident responders to locate a security event. There shouldn’t be any surprise for Windows Infrastructure owners that a free method to centralise logs from servers exists. That is Windows Event Forwarding. You can choose to centrally audit logon events and powershell process events specifically to capture these security events and aid security incident investigation. Central logging will also retain logs and better ensure they are not lost in a disaster recovery scenario.

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.

Creating a central Event Collector server

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.

The steps for WEF components:

• 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.

What should you monitor?

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:
Event ID 4732 A new local account was created. Comes supplied with local account SID.
Event ID 4624 An account was successfully logged on. Supplied with account name.
Event ID 4731 A local security group was created
Event ID 4735 A local security group was changed
Event ID 4673 Sensitive Privilege Use

Events in GPO Enhanced advanced security audit logs:

Audit Policies, Logon/Logoff, Audit Other Logon/Logoff Events enabled: Event ID 4778 Remote Desktop session connected, supplied with account and machine.

Audit Policies, Logon/Logoff, Audit Other Logon/Logoff Events enabled: Event ID 4779 Remote Desktop session ended

Audit Policies, Detailed Tracking, Audit Process creation enabled; Success and Failure: Event ID 4688 Process creation.

WEF on the collector server showing source computer and security events

*/

Further deciding what event IDs to log

• 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.

Further References:

• https://blogs.technet.microsoft.com/mspfe/2011/11/22/setting-up-security-event-log-subscriptions-with-windows-server-20032008/
• Https://blogs.technet.microsoft.com/jepayne/2015/11/23/monitoring-what-matters-windows-event-forwarding-for-everyone-even-if-you-already-have-a-siem/
• https://docs.microsoft.com/en-us/windows/threat-protection/use-windows-event-forwarding-to-assist-in-instrusion-detection#bkmk-appendixa
• https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html
• https://azure.microsoft.com/en-us/blog/detecting-in-memory-attacks-with-sysmon-and-azure-security-center/