In a previous blog we discussed how crucial network log data is for threat hunters. The data provided by network logs offers valuable information about how an actor is communicating in and out of an environment. However, this is only one side of the threat hunting data coin. We also need a full slate of log data on the endpoint in order to understand what the attackers are doing once they establish a beachhead on a system.

Many organizations choose to limit their overall collection of endpoint logs, restricting collection solely to critical systems and servers, often due to the sheer volume of data that a whole portfolio of endpoints can put out every day. While there are a number of methods to manage this, organizations often leverage endpoint detection and response (EDR) platforms, which typically stream data to the cloud storage. Other organizations may face data residency issues, and in which case other on-premise (on-prem) solutions may be a better fit. Regardless, at the end of the day, the lesson is that the following data sources can be extremely useful for effective threat hunting.

Windows Event Logging

Windows event logging (WEL), a default administrative tool in Windows, is going to be one of the most data rich sources for threat hunters to piece together endpoint activity. WEL logs come in three flavors: system, security, and application, and logs will record errors, warnings, information and audit success within a Windows system.

This data gives threat hunters the visibility to see what’s going on both within a single endpoint, an environment, or a federation of environments.

Linux Audit Logging

Linux audit logging is similar to Windows event logging, just for another operating system. However, Linux logging tends to provide more granular data about even more components of the operating system, giving hunters greater visibility. Again, its purpose is to offer up details about changes to the systems, network connection attempts, and any activity on the system that warrants a logged event.

PowerShell Logging

PowerShell, introduced in 2006, is an exceptionally powerful command line environment. While much of the enhanced logging has only been available since version 5, Microsoft has also backported some of those powerful logging functions to version 4 (though it is still highly recommended that organizations update to version 5). Enhanced PowerShell logging not only logs executed commands, but paths and deobfuscated code as well. As PowerShell is extremely flexible and powerful compared to the traditional Windows Command Prompt, this is typically the go-to for attackers. Many phishing attempts begin with a simple Word document embedded with a malicious macro designed to invoke PowerShell to begin downloading and executing malicious code. Additionally, attackers can use it to gather system and network information, download additional toolsets, and move laterally within an environment. An attacker is very likely to utilize that shell environment once they get onto an endpoint making this prime hunting ground for security teams.

In addition to that, from a threat hunting perspective, PowerShell can offer excellent visibility for seeking out anomalous activity within an environment. Through techniques such as stack counting and “the principle of least frequency of occurrence (LFO),” threat hunters can look through all of the different PowerShell commands executed across an environment in order to identify suspicious activity.

Process Monitoring

Process monitoring and logging, using tools such as the free and excellent Procmon, offers hunters visibility into all processes that are spawned, where they were spawned from, as well as their child and/or parent processes.

Ultimately, threat hunters will be looking for unusual process names or common process names from uncommon paths. Lots of malware, for instance, will randomize process names so a threat hunter can look for very suspicious, or randomized process names. At scale, hunters may also look for uncommonly high, or low, entropy of names (e.g. how predictable is the next letter in the process name compared to a baseline set of data?). Similarly, threat hunters can seek out suspicious parent-child process relationships. For example, should Word.exe really be spawning PowerShell? Should that PowerShell process really spawn something called ‘svch0st.exe’?

Registry Data

Threat hunters gain a huge amount of information out of the Windows registry. Many attackers may touch the registry as part of reconnaissance to get an idea of what’s installed on the system. Additionally, attackers frequently use the registry to establish persistence for their tools and malware to ensure it persists across reboots, or hinders attempts to remove it. For example, one of the most common (and oldest!) methods malware uses to establish persistence is through so-called registry run keys, inserting an entry into that key to have it point to the tool or malware that’s on the system. This way every time the system reboots, the malware comes back online.

These endpoint data sources can offer up extremely rich information for threat hunters seeking out activity within a single endpoint or across the entire environment. While solid network logs are a staple for threat hunting, it’s important to remember that visibility at the endpoint can provide a more enriched data set, and therefore more valuable hunts.

Haven’t read part one of this series? Be sure to catch up on You Can Only Hunt What You Can See: Best Network Log Sources for Threat Hunting.