Developing various data sets for threat hunting engagements will further mature your program and help uncover the unknown
Beyond having some necessary skills, the first building block is visibility: you must have access to some type of log or set of logs to hunt through. Each log source will bring with it a set of behaviors or event types that you’ll want to focus on.
The second step is analysis – you should have a centralized location of logs that are being fed into a Security Information and Event Management (SIEM) or some type of database. Sure, you can individually query each endpoint’s event logs, but that would take forever. It’s better to have a lake of information to sift through versus a few puddles. When I started out with my own program back in 2009, our organization didn’t initially have a SIEM. I ended up locating a spare Linux server with some storage that provided me the means for aggregating this data. If there is a will, there is a way!
The third step is conducting research for the types of events you’ll be searching through. If you have access to security event logs from all devices in your environment, come up with a list of event IDs to look for that may indicate malicious activity.
Establishing a plan of action before jumping right in will save you from scrolling through millions of events that may lead nowhere. Filtering and sorting will become your best friend and will help you identify anomalous events. However, the existence of a particular event ID doesn’t always mean there’s a threat lurking on a device. Determining the root cause may require additional forensics and pivoting around that data.
As you establish a baseline of normal, consistent patterns of end-user activity, it’s worth considering filtering this data from view while hunting. This will help eliminate distractions so you can focus more on oddities occurring on your network.
These initial steps will help you get your program off the ground, but it’s just the beginning. The goal for any threat hunting program should be to further mature it and staff it appropriately. It may start out as something that’s done when you have time; but eventually you’ll want this to be a part of a normal cadence that is set.
As the program matures, consider what types of tools will yield the most return. Security event logs will only accomplish so much. Collecting process execution events, registry activity, file movement, network connections, etc., will take your threat hunting engagements to the next level. Incorporating an endpoint detection and response (EDR) tool can give you a treasure trove of data worth exploring. There’s a plethora of security solutions available today, and there are a bunch of freeware utilities such as Microsoft’s Sysmon that’ll provide the necessary visibility.
With this data, it’s now time to consider building alarms or detection signatures. These will allow you to immediately respond to high severity threat activity that is triggered, which enables build-out of lower severity events for threat hunting purposes. Lower severity events may mean that it’ll generate a bunch of false positives; however, each one of those detections can also be tuned.
As you build out these detections, it’s important to align them with an attack matrix such as the MITRE ATT&CK framework. This publicly available framework contains a knowledge base of adversary tactics and techniques that have been observed out in the real world. The matrix is broken down into 14 areas such as Reconnaissance, Execution, Credential Access, Exfiltration, etc., and then further broken down into sub-techniques that you can focus on. You don’t need to create a detection for every single technique that is available, but it’s important to build these out over time.
I recommend initial detection focus on areas that would generate a high severity event. Developing detections for OS Credential Dumping, Abuse Elevation Control Mechanism, Masquerading, Exploitation of Remote Services, etc. will all lead to events for your level 1 analysts to respond to. Then develop signatures for your threat hunting team to pivot off of such as Creation of Accounts, Scheduled Task Jobs, Account Discovery, Lateral Movement, etc., which can all be used by this team to seek out adversary activity.
These detections can be developed server-side within your SIEM or even locally by a tool such as Sysmon. Either way, developing various data sets for threat hunting engagements will only further mature your program and help uncover the unknown.
Another solid threat hunting technique is frequency analysis. I like to apply this method when hunting through command line activity or network connections. You can make it high fidelity when you pair it with additional meta-data attributes. If we’re looking at outbound connections by process, for example, name and pair that with an executable’s current signature status, such as unsigned. You can quickly develop a listing of infrequent connections being made by potentially suspicious processes.
Installing tools like Sysmon will only give you a current view into what’s occurring across the environment – not necessarily a historical view. The past can be just as critical as the present when attempting to uncover attack activity. Once you’ve reached a comfortable state with your detections for your endpoint logs, I recommend expanding your engagements to more proactive techniques whereby you collect existing data from each device in your enterprise such as specific registry keys. You can even perform targeted scans using utilities such as YARA for a historical view. This can provide insight into attacks that have occurred already and may have been missed. YARA is an open source, multi-platform tool that can be downloaded for free on GitHub. It’s used by malware hunters, incident responders, etc., to detect malware based on certain characteristics or rules.
Threat hunting is a critical component to your cybersecurity program that should never be ignored, but matured. The more you identify within your program, the more opportunity you may have at expanding with additional budget. Never let an incident go to waste.