January 2, 2018 | 3 minute read
Whether the process is called threat hunting, cyber hunting or cyber threat hunting, each term essentially means the same thing: security professionals look for threats that are already in their organization’s IT environment. This differs from penetration or pen testing, which looks for vulnerabilities that an attacker could use to get inside a network.
With every vendor offering some type of threat hunting service, security professionals may wonder if hunting can actually benefit a company or if it’s just a fad. But threat hunting isn’t based on flashy technology that will become irrelevant in a few months. It’s a return to one of the basic tenets of information security: reviewing your IT environment for signs of malicious activity and operational deficiencies. With hunting, you can answer the question, “Am I under attack?”
To help security professionals better facilitate threat hunting, here are step-by-step instructions on how to conduct a hunt. And to read the latest from Cybereason about threat hunting, check out the 2017 Threat Hunting Survey Report.
If you decide to conduct a threat hunting exercise, you first need to decide whether to use your internal security team or outsource it to an external threat hunting service provider. Some organization have skilled security talent that can lead a threat hunt session. To enable a proper exercise, they should solely work on the hunting assignment for the span of the operation, equipping them to solely focus on this task.
When a security team lacks the time and resources hunting requires, they should consider hiring an external hunting team to handle this task.
Whether using an internal or external vendor, the best hunting engagements start with proper planning. Putting together a process for how to conduct the hunt yields the most value. Treating hunting as an ad hoc activity won’t produce effective results. Proper planning can assure that the hunt will not interfere with an organization’s daily work routines.
Next, security teams need a security topic to examine. The aim should be to either confirm or deny that a certain activity is happening in their environment. For instance, security teams may want to see if they are targeted by advanced threats, using tools like fileless malware, to evade the organization's current security setup.
The analysts then establish a hypothesis by determining the outcomes they expect from the hunt. In the fileless malware example, the purpose of the hunt is to find hackers who are carrying out attacks by using tools like PowerShell and WMI.
Collecting every PowerShell processes in the environment would overwhelm the analysts with data and prevent them from finding any meaningful information. They need to develop a smart approach to testing the hypothesis without reviewing each and every event.
Let’s say the analysts know that only a few desktop and server administrators use PowerShell for their daily operations. Since the scripting language isn’t widely used throughout the company, the analysts executing the hunt can assume to only see limited use of PowerShell. Extensive PowerShell use may indicate malicious activity. One possible approach to testing the hunt’s hypothesis would be to measure the level of PowerShell use as an indicator of potentially malicious activity.
To review PowerShell activity, analysts would need network information, which can be obtained by reviewing network logs, and endpoint data, which is found in database logs, server logs or Windows event logs.
To figure out what PowerShell use look like in a specific environment, the analyst will collect data including process names, command line files, DNS queries, destination IP addresses and digital signatures. This information will allow the hunting team to build a picture of relationships across different data types and look for connections.
Once that data has been compiled, analysts need to determine what tools they’re going to use to organize and analyze this information. Options include the reporting tools in a SIEM, purchasing analytical tools or even using Excel to create pivot tables and sort data. With the data organized, analysts should be able to pick out trends in their environment. In the example reviewing a company’s PowerShell use, they could convert event logs into CSV files and uploaded them to an endpoint analytics tool.
Discussions about automation may turn off some security analysts get turn off. However, automating some tasks is key for hunting team's’ success. There are some repetitive tasks that analysts will want to automate, and some queries that are better searched and analyzed by automated tools.
Automation spares analysts from the tedious task of manually querying the reams of network and endpoint data they’ve amassed. For example, analysts may want to consider automating the search for tools that use DGAs (domain generation algorithms) to hide their command and control communication. While an analyst could manually dig through DNS logs and build data stacks, this process is time consuming and frequently leads to errors.
Analyst will should now have enough information to answer their hypothesis, know what’s happening in their environment and take action. If a breach is detected, the incident response team should take over and remediate the issue. If any vulnerabilities are found, the security team should resolve them.
Continuing with the PowerShell example, let’s assume that malicious PowerShell activity was detected. In addition to alerting the incident response team, security teams or IT administrators should the Group Policy Object settings in Windows to prevent PowerShell scripts from executing.
Have more questions about threat hunting? Maybe Cybereason's threat hunting team answered them in this Q&A.
Fred is a Senior Content Writer at Cybereason who writes a variety of content including blogs, case studies, ebooks and white papers to help position Cybereason as the market leader in endpoint security products.