During several months we worked together with a number of Dutch financial institutions to create the threat hunting methodology called TaHiTI. Which stands for Targeted Hunting integrating Threat Intelligence. You can obtain it from here: https://www.betaalvereniging.nl/en/safety/tahiti.
The goal of this collaboration was to reach a joint understanding of what threat hunting is and to come up with a common approach how to carry out threat hunting. As the name implies, threat intelligence has an important role within this methodology. It is used as a source for creating hunting hypotheses and during the hunting investigation to further contextualize and enrich the hunt.
Within the document the following topics are discussed:
Threat hunting is introduced: definition, purpose, characteristics, types of threat hunting, pyramid of pain in relation to hunting and hunting maturity.
Threat intelligence in relation to threat hunting: definition, purpose, characteristics and the relation between hunting and threat intelligence.
The TaHiTI methodology is explained in detail.
Threat hunting metrics are discussed.
Best practices for doing threat hunting and the implementation of a threat hunting program.
In this blog post I want to point out two topics from the methodology and explain parts in detail and provide some examples.
It was very nice and interesting to be part of this initiative as a co-author, and I want to thank the initiator and lead-author Rob van Os for starting and leading this!
The purpose and values of Threat Hunting
Within TaHiTI the purpose of threat hunting is stated as follows:
The main purpose of threat hunting is to reduce the time required to find traces of attackers that have already compromised the IT environment. By finding these traces as soon as possible, the impact of breaches to the organisation can be minimised. The breach detection gap is an important concept in the context of this purpose.
Within the methodology the breach detection gap is explained in more detail. It is also commonly referred to as dwell time. Besides reducing dwell time, threat hunting has other benefits:
Identification of gaps in visibility and detection necessary to detect and respond to a specific TTP (Tactics, Techniques, and Procedures).
For example: during your hunting investigation you may discover that you are lacking visibility, for whatever reason, within a certain part of your IT environment. Or you discover that you are missing Windows event ID 4769 (“A Kerberos service ticket was requested”) necessary to perform a hunt on Kerberoasting.
Development of new detection analytics used in the creation of new or improved security monitoring use cases.
For example: the analytics created to detect a specific technique used for lateral movement within your company, taking into account normal behaviour relevant to your IT environment.
Uncovering new threats and TTPs that feedback to threat intelligence.
During an investigation you may uncover a previously unknown TTP for an attacker. For example, a new procedure in relation to ATT&CK technique T1027 to obfuscate malicious commands that was previously unknown.
Recommendations on new preventive measures.
The result of the hunting investigation could also result in a recommendation to take certain preventive measures that will lower the chance on successful execution of a TTP.
Hunt at the top of the pyramid
The Pyramid of Pain is a concept that is closely related to threat hunting. In TaHiTI a short description is provided on the Pyramid of Pain:
TaHiTI focuses only on the top 3 layers of the pyramid and also states that hunting on the lower layers is not considered to be threat hunting. But why are the lower thee layers far less interesting for threat hunting? Hunting on the lower 3 layers will not yield high value in hunting investigation. The simple reason is that lower layers are based on information from past targeted attacks and wide scale global threat actor campaigns. This information includes known bad domain names, IP addresses and hashes.
The source of this information comes from attacks that have already been carried out. Therefore, the chances are very small that this information will uncover targeted attacks against your company. This does not mean that checks on these lower layers should not be done. They should be automated where possible and where it makes sense.
With this blog I covered a very small subset of the content of TaHiTI. The methodology is released under the creative common license with the intention that others can build on it and improve it. So, feel free to reach out to provide feedback and share your own findings and experience.