Cybersecurity analysts often struggle with logging endpoints into their security information and event management (SIEM). This can cause major network blind spots and challenges for security teams conducting threat investigations. If you relate, you’re not alone! In this blog, we’ll explore key tips for overcoming these challenges and define best practices for ingesting log data and improving visibility across the environment.
Challenges of endpoint logging
Depending on your environment, the most common attack points within your network are typically going to fall into two categories:
- Exposed services and environments (e.g., websites, cloud offerings, applications, open firewall ports)
- User endpoints (e.g., opening attachments, visiting malicious sites, using unchecked USB devices, phishing emails, installing software, using public Wi-Fi)
When security analysts ingest data into a SIEM, there is a large focus with onboarding domain controller logs, server logs, firewall syslog feeds, web server access logs, and more. These assets are typically online 24/7, keep the same IP address, and can easily collect logs when they’re generated.
However, monitoring user endpoints (e.g., laptops, desktops, VDI environments) in the SIEM can seem too complex to implement because endpoints are not always connected to networks or IP addresses, and where they are connected can change often. Typically, these user endpoints will have a larger turnover of devices and rebuilds, meaning that managing and ensuring all systems are monitored becomes an even bigger task. With many attack vectors stemming from endpoints, security operations center (SOC) teams struggle with blind spots and identifying the root cause of an incident during investigations.
In my role as an Analytic Co-Pilot consultant, I often hear that teams are using an EDR/AV solution to monitor their endpoints and sending logs from those solutions to their SIEM. In this case, we don’t need to collect logs directly from the endpoints. The issue is these solutions send alerts on events that it deems malicious. However, if you want to monitor logs for all activities from your endpoints within your SIEM, then EDR event logs are not your best option. A SIEM’s ability to monitor endpoints relies directly on the EDR solution, its configuration, and alerts that it sends. An EDR or AV can be an important part of your security posture, but you must leverage best practices to have a clearer picture of what’s happening on every endpoint in your entire environment, not just the server farms.
What logs should I be collecting from endpoints?
When looking at user endpoints within an environment, typically security analysts monitor Microsoft Windows. So, we will focus on Windows logs even though these concepts can be applied to other technologies, albeit with different log source configurations.
To get a holistic view of what’s happening on your endpoints, let’s look at the Windows Security Logs, PowerShell, and SysMon logs.
Windows Security Logs
When collecting from servers, three logs to look at are Windows Application, System, and Security logs. The Security Log is a main focus for most use cases because it provides great information as to who is logging in, failed logins, processes started, and much more. When assessing failed logins, you should see failed domain login attempts from your Domain Controller logs, however, local administrator or other accounts on endpoints can be attacked without a single log leaving the endpoint.
A common challenge with endpoint logs is the fluctuation in numbers when systems are not on the network all the time (e.g., when workstations are powered off or laptops are used remotely), as well as the management overhead of collecting these logs. This is where Windows Event Log Forwarding can help. This is a solution built into Windows. Logs are sent to a centralized system with no requirements to install an agent or extra features. It is available within the base Windows OS. There is a guide on the LogRhythm Community (community access required) that provides recommendations on how to configure Windows Event Forwarding (WEF); however, the overview is that Windows can be configured via Group Policy to connect to the WEF Server and subscribe, where the Subscription will dictate what logs should be forwarded to the centralized system. You can specify certain Event IDs, channels, severity, and more, when setting this up. Meaning, you can collect the logs you are only interested in and reduce extra noise from being sent to the SIEM. You can then use LogRhythm System Monitor or Collector to gather these logs from the WEF server and provide that visibility into the Windows Security logs.
When using WEF, there are tools built into Event Viewer which will help manage and provide visibility of subscribed systems, but this can be limiting. One product that several LogRhythm customers use is LogBinder’s Supercharger. This can be installed to give overview and management capabilities over WEC/WEF. Windows Security logs are typically enabled by default; however, the level of auditing within Windows can be configured with Group Policies and should cover the requirements for use cases dealing with your environment. More information on baselining auditing policies can be found via CIS Benchmarks. You can use this method for any Windows Event Logs other than Security logs, it just needs to be configured in the Subscription on the WEF server, such as PowerShell.
According to McAfee, PowerShell threats grew 208% between Q3 and Q4 2021. This proves that the importance of logging PowerShell is increasingly vital to understand what is happening within your environment. With PowerShell now available on every Windows instance since Windows 7, it is a known factor for attackers to use and have available if they can get a payload into their target system. Windows Security logs provide information for what processes are run, so you may see that powershell.exe has been launched, but not what has run once PowerShell has opened. That’s why the importance of enabling PowerShell logging and ingesting all endpoints and servers into your SIEM is key to monitor what is happening in your environment. You can read through this blog to learn how to enable PowerShell logging and consuming this into your LogRhythm SIEM.
For even more visibility into your endpoints, Microsoft has the SysInternals Sysmon tool, which you can use for implementing granular auditing of your systems to the Windows Event logs, and can either be collected directly or via Windows Event Log Forwarding. The great advantage of the Sysmon tool is it can be configured with an XML file to monitor different types of events, including Process Creation, Network Connection, Process Terminated, File Creation, Registry Event, and even DNS requests. With the XML configuration you can include or exclude expected entries, meaning that you can reduce noise easily from the XML file and build the config suitable for your devices. There are even config files which can start as a baseline, allowing you to tune them to your requirements; one of the most popular being SwiftOnSecurity, providing XML configs removing noise from typical Windows features and activity.
The Sysmon tool writes into Windows Event Logs, meaning that as with Security and PowerShell, you can collect this with either direct Windows Event Log Collection from a LogRhythm agent, or you can use Event Log Forwarding and centralize the collection via Group Policy. For Sysmon deployment, you can push the configuration and executable to install out via Group Policy, making it possible for centralized deployment for medium to larger deployments.
How LogRhythm can help with endpoint logging use cases
If it seems like a lot of effort to bring these logs in, you should know that a lot of your existing use cases within LogRhythm SIEM will need little (or even no) tuning to use some of these logs. For example, looking at Windows Security logs, over 75% of the use cases within our User and Entity Behaviour Analytics (UEBA) Module either require or recommend Host Logs for the rules. When looking at MITRE ATT&CK Module (version 2.6.0 at time of writing), over 70% of the rules would be applicable to log sources onboarded from endpoints. This shows that a large majority of use cases that come out-of-the-box are able to use Windows Security logs. However, looking at the MITRE ATT&CK Module, there are certain rules that require Sysmon or PowerShell as a log source, as Windows Security logs alone cannot detect some attack vectors. For example, the Rename of System Utilities (T1036.003) is looking for the hash of the executables within System32, but run from elsewhere in the system, this hash information isn’t available from the Security log (Windows event ID 4688), but is available with the Microsoft Sysmon logs.
For assistance, the LogRhythm Analytic Co-Pilot Team works with customers weekly to focus on use cases and threat detection. We have a plethora of use cases available, ranging from looking at what is being run with PowerShell, PowerShell Obfuscation, and PowerShell Encoding, with log sources mostly comprising of PowerShell logs. We also work with customers to monitor is ransomware delivery via PowerShell. Underpinning these use cases are the important PowerShell and SysMon logging that provides great visibility into what is happening in the environment.
Aren’t EDR events enough?
As with any solution, there will be gaps in detection for nefarious activity; for example, an attack modified to specifically evade EDR detection or a 0-day which hasn’t been added to the EDR library or techniques to monitor. Also, alert fatigue may occur with EDR alerts and events, which could lead to missing important detections. When EDR is integrated to a SIEM, it is only the triggered events and alerts which are forwarded, and the original raw logs are kept within the EDR platform. I suggest in addition to this integration, you have logs sent into your SIEM to allows for use cases and correlation to run across all systems in an environment. This way detection can align across the whole estate, rather than treating Servers and Endpoints as separate silos. This helps identify trends, suspicious activity on user endpoints, as well as attacks that may not leave the user’s machine or local network (e.g., data exfiltration, local account brute force, lateral movement within the same network, spoofing, DNS spoofing, DHCP poisoning). If these attacks aren’t crossing network boundaries (so that Firewalls see them), and logs from local systems aren’t being captured, then attackers can go on without leaving a footprint of logs within your SIEM.