Threat hunting is an active cyber defense activity that proactively searches for threats, generally from advanced persistent threats, already in the environment that have not been either identified by the existing tools or may not have been actioned by the network defense team. It is a separate but related sets of skills from a SOC analyst and requires additional tools and access to data sources that may not be currently available but will be critical to its mission success.
1 Set Expectations
Threat hunting is not a magic silver bullet for the enterprise to fix all cyber security vulnerabilities. It is not another part of a generic Cybersecurity toolset but a logical development in advanced capabilities deigned to be proactive not reactive to threats.
Threat hunting is:
Finding advanced persistent threats that have evaded the current set of security tools and removing both the threat and then its attack vector where possible.
Based in hypotheses derived from analyst knowledge and threat intelligence
Difficult to define management style metrics
Not for all enterprises, there is a maturity component.
Are we ready to threat hunt?
If an enterprise has all of the foundational cybersecurity is in place, has a culture of curiosity/agility (as this is going to require some changes), and there is significant intelligence pointing to threat adversaries and enterprise may be ready for a structured hunt.
Management should be aware engaging in a successful threat hunting program is a long journey that is not going to pay off with truly reportable management style results. Done correctly it will strengthen the cyberposture and allow business to continue to operate knowing its valuable assets are being protected.
2 Define/refine the crown jewels
This is the first step that should really be part of any good cybersecurity program to ensure that the right amount of resources are guarding the most valuable assets and the inverse that an enterprise is not spending way too much on guarding low value assets. Once these are defined properly, and by that I mean with the business assistance for value, we can begin to produce the crown jewels analysis which can act as a starting point for where a hunt is most valuable, the most valuable assets.
3 Review/write the incident response plan (IRP)
In a mature organization that is looking to start threat hunt, it is imperative that a good incident plan is written, reviewed by management, and exercised. If one is not already in use or needs refinement, the guidance from NIST in their Special Publication 800-61 Computer Security Incident Handling Guide 1 As was stated above, the finding of a potential threat needs to be handled accordingly. Feeding an IRP with the results of an initial threat hunt provide a great exercising tool.
4 Define initial hypothesis
Although hypothesis are unique to each enterprise, there are some generic hypothesis that can be used to start as a baseline2:
1) An infected system on the network is generating command and control traffic that has not yet been detected.
Why: Malware does not run in a vacuum. It needs to contact the attacker’s infrastructure to download additional payloads, receive instructions on which actions to execute on the endpoints, and to report information from the victim’s network. This requires outbound connections originating from the compromised hosts to the attacker’s control server.
Questions: Are there any outbound DNS requests with a high degree of entropy? Is there a large volume of incoming NX (nonexistent) domain responses coming back into the network? Are there any abnormally long TXT records in either DNS requests or responses? Are there any abnormal user-agent strings in HTTP requests? Are there any outbound connections generated at regular intervals?
Artifacts: DNS requests and responses, user-agent strings in HTTP requests.
Source: DNS logs from DNS servers with Microsoft DNS Analytics/Proxy logs, or Network Security
Monitor (NSM) data from Bro sensors.
2) At least one system is infected by some malware variant that has established itself to autostart and that has not yet been detected.
Why: In most cases, attackers need to establish some persistent mechanism in their malware so they can control the infected system across sessions and survive a reboot to achieve their objectives.
Questions: Are there any new items set to autostart in the investigated system, across this subnet, or in critical servers?
Artifacts: Windows ASEPs. Source: Windows Registry, output of Microsoft Sysinternals Autoruns.
3) An attacker already present on a compromised system is trying to elevate privileges by adding a user to a privileged group.
Why: As a result of a successful exploitation, an attacker may have obtained nonprivileged credentials, forcing the attacker to elevate the privilege level to achieve their goals.
Questions: Is there a new user in a privileged local or domain group? Are there any missing patches that could have been used to attempt a local privilege escalation? Is there any binary set as a service that could have been replaced due to poor file-system permissions?
Artifacts: Windows Event Logs (IDs 4728, 4732, 4756). Source: Windows endpoints and servers.
4) An active attacker on the network is trying to move laterally by employing PsExec.
Why: Usually attackers do not have direct access to targeted information from the initial compromised system, requiring them to “jump” to other systems or execute commands on remote computers using harvested credentials.
Questions: Is there any evidence of PsExec use? Is there a new service on any critical servers? Are there any errors associated with the start of new services? Is there any workstation-to-workstation traffic on the network?
Artifacts: Windows Event Logs (IDs 7045, 7030, 4624).
Source: Windows endpoints and servers. How to: Examine the creation of Event ID 7045 for evidence of PsExec execution and ID 7045 in combination with ID 7030 for evidence of Metasploit’s PsExec execution.
5) An attacker is attempting to exfiltrate a large volume of data to a nonbusiness-related geolocation.
Why: Exfiltration is the last step in a data breach caused by a motivated attacker. Attackers may send a large volume of data outside of the network using different protocols.
Questions: Is any workstation or server sending a large volume of data outside the network? Are there any outbound connections to nonbusiness related geolocations? Is data being sent at abnormal times? Are there any connections that remain pinned for an abnormally long time?
Artifacts: Network session data (flows). Source: Border router, switches, or other collectors (SiLK, Argus, etc.). Firewalls, proxies, and NSM devices can also provide similar information.
5 Define Datasources required
Not all systems will have the data required to perform this hunt. These initial hypothesis will identify the data required and should allow that to be captured forward. Logging will generally need to be refined for these hypothesis and may be incomplete initially as data may not exist and this can be used to build a business case to get more data, since data may be expensive in terms of processing power or storage
6 Start hunting
There are many tools, techniques and procedures for doing these hunts and we are not recommending any in particular as tools are highly subjective to each hunter. One thing we do want to have installed is a coordination tool like theHive to allow analysts to share their methods and findings and then collaborate with the SOC analysts their findings. This is also a good tool to use for the SOC as allows a much more aligned SOC and information sharing capability in addition to showing management style metrics.
2Taken from https://www.mcafee.com/enterprise/en-us/assets/reports/rp-quarterly-threats-sept-2017.pdf Threat hunting like a pro ―Ismael Valenzuela and Douglas Frosst