Running an effective security programme relies on visibility, so it is no surprise that the popularity of Endpoint Detection and Response (EDR) toolsets has increased dramatically in recent years. However if you don’t have EDR, all is not lost! Native Windows Event Logging can yield valuable information relating to suspicious activity, and actually supplement EDR tooling in certain scenarios.
Through our Managed Detection and Response (MDR) service, Context has experience of monitoring a diverse range of businesses using a wide variety of tooling, across the entirety of the technology stack (network / cloud / endpoint). Here we outline where to focus your detection efforts for quick win results, and explore some of the considerations surrounding the development of a Windows log collection strategy.
Some examples of “low hanging fruit” that are ripe for detection:
- PowerShell; given the rich functionality of PowerShell, it’s inevitable that threat actors will seek to utilise it throughout the kill chain. Audit logging can be enabled to provide a verbose record of activity; of particular relevance is Module and Script Block logging. Enabling these will result in a variety of rich data being captured – this includes scripts, de-obfuscated code, and output, all valuable for developing detection logic, and any subsequent Incident Response.
- Command line process auditing; newer Windows variants enable the Process Command Line to be captured as part of the standard process creation audit event (ID 4688). Well-placed threat actors will often seek to use legitimate system tools to further their objects (i.e. “living off the land”), in favour of dedicated malware. Analysis of command line parameters, in combination with other data recorded in the same log (such as username and parent process) provides an opportunity to detect non-legitimate activity. Frequency analysis and keyword detection are both valid starting points, but ideally, some form of statistical trend logic could be used to highlight scenarios such as User-A running Application-B for the first time.
- Vulnerability exploit attempts; the CveEventWrite function introduced by Microsoft for newer Windows variants enables events to be published when an attempted security vulnerability is detected. By default, messages are written to the Application event log, and can be identified by the Source “Microsoft-Windows-Audit-CVE” or “Audit-CVE”. Naturally, these events are only written once software patches have been applied for specific vulnerabilities (an example being CVE-2020–0601). Nonetheless, identifying exploit attempts anywhere within your environment is a valuable exercise.
If you’re looking to develop your Windows log collection strategy, here are some useful considerations:
- Control audit policies via Group Policy Objects (GPO); the default Windows audit policy settings need to be refined to realise maximum benefit. Doing this via GPO will ensure you capitalise on all the inherent benefits such as centralised management and ease of deployment. For more information, refer to these Audit Policy Recommendations as a starting point, and consider audit policies as a key pillar of your Active Directory / GPO management.
- Utilise Windows Event Forwarding (WEF); enterprise-wide monitoring will necessitate some form of central log collection. WEF provides a mechanism to forward events to a Windows Event Collector (WEC) server, ready for onward distribution to a SIEM or other analytics platform. A by-product of this model is a reduction in the number of collection agents deployed within the environment, thereby reducing complexity and management overhead. As a technology, WEF is scalable, secure, and configurable via GPO – music to any System Administrators’ ears.
- Understand what logs should be in scope of collection; it’s a big mistake to assume that all events of interest will be written to the “Security” log. For example; PowerShell, Windows Remote Management and AppLocker will all write events to distinct log files. Audit configuration and collection must therefore be considered carefully. Granular auditing can also be configured using System Access Control Lists (SACL’s) – a practical example would be monitoring changes to specific registry keys that are associated with persistence mechanisms.
- Consider Sysmon for even better detection; the capabilities of native Windows event logging can be enhanced considerably through the use of Sysmon, part of the SysInternals suite. This introduces the ability to capture more verbose data such as process hashes, library imports, DNS queries and more. Flexible configuration enables administrators to filter event collection in a granular fashion – in many cases, capturing everything will be excessively noisy, increasing bandwidth, computational and storage costs in any subsequent processing pipelines.
Critical analysis of potential log sources should always be undertaken to determine the quality and relevance of the data; the primary goal is to collect logs that contain rich metadata, enabling interrogation against detection logic for threat intelligence IOC’s or threat actor TTP’s. It should also be noted that there is sound justification for collecting log data that could provide tangible benefit during an investigation, even if it is not likely to be contributory to initial detection in itself.
With that in mind, the collection and analysis of Windows event logs can be a valuable component within a wider log collection strategy, and should not be overlooked, even if you have dedicated EDR tooling deployed.