Threat Inteliigence / OSINT / NETSEC / NATSEC

Hunting - putting CTI to work

I have already devoted a lot of space on to OSINT and threat intelligence. We must not forget, however, that the intelligence in its various forms is primarily a supporting function. It supports decision-making, incident response and detection of malicious activity. Threat hunting is an activity that one way or another must be based on intelligence. So let's start with the basics - what is threat hunting?

Briefly and simplified, it is the activity of manual search for malicious activity in the environment. Why are such manual actions necessary? We have so many alerting and monitoring systems, SIEM, AV, EDR, XDR and so on? There are two main reasons. First of all, although these systems are constantly developed, they will never be perfect and the creation of signatures, patterns of behavior to be detected and so on will always be subject to a certain margin of lack of visibility resulting from, for example, the continuous development of techniques used by attackers. Secondly, some behaviors are very difficult to identify as malicious, if only because of the use of living off the land techniques, i.e. the use of system tools to conduct activity. Lets look at an example from the report provided by CrowdStrike Overwatch for 2020:

If we would like to use the above-mentioned commands as a basis for creating automatic alerts, we will quickly be flooded with false alerts as a result of commands being used by administrators and ordinary users. Stating that this is malicious activity requires looking at the context of using the commands, who was executing them, and so on. The task of threat hunters is therefore to extract from the general behavior of users elements that may indicate the actions of attackers and to pull these threads by a string to understand what is happening in the environment.

So where is the role of threat intelligence in all this? There will be hundreds, if not thousands, of potential behaviors to watch out for. Threat Hunters must therefore be aware of what techniques are used by groups active in a given threat model to know where to focus their attention and how to use the time at their disposal most effectively. However, there are many types of indicators that CTI analysts can provide to hunters - so what will be the most useful?

To categorize the indicators that CTI analysts can provide threat hunters, we will use the pyramid of pain model by David Bianco. Why a pyramid of pain? This is by no means a pain for the defenders, but for the attackers who, depending on the degree of the pyramid, have to spend more time and effort to avoid detection. Coming to the point, the pyramid model looks like this:

Emulating Attacker Activities and The Pyramid of Pain ...

So at the very bottom we see "atomic" indicators of hostile activity - hashes and IP addresses. Changing these values is very easy for attackers - in the case of a hash, even a minimal change of the file, such as adding a meaningless function, will change the value. It is similar with IP addresses. Changing the infrastructure at this level, even using DDNS, is simple and does not require too much effort. More importantly, however, hashes and IP addresses are let's call them "impersonal". They are assigned automatically, preparing the operations has little effect on their value. Therefore, it is difficult to hunt here for the characteristic elements of the intrusion enabling the detection of large-scale activity. To be precise, it should be pointed out that the IP addresses are one step higher because, unlike the IP hash, it has additional characteristics - the entity hosting the server, geographic location.

Domain names are another step, as ultimately the name must be "manually" defined by attackers. Even if we are talking about the automatic generation of domains by DGA, the scheme of the algorithm's operation had to be selected and configured by the attackers. CTI analysts, however, like domains because their names are often created to be in human readable format because they are used, among others, as addresses for sending phishing emails. Therefore, the analysis of the names used, e.g. pretending to be addresses of governmental organizations, can be used for infrastructure mapping. When we talk about hunting, however, they are usually still not of great value - domains change so quickly that a proactive search for malicious activities based on them will not bring the expected results.

The situation changes when we enter the top three levels of the pyramid where we find network artifacts and left on hosts, tools and finally tactics, techniques and procedures used by attackers. So let's take a closer look at these categories:

  1. Network artifacts are found in communication between victims' and attackers' machines. So they can be elements in the traffic such as user-agent string, used services or HTTP methods.
  2. The artifacts on the hosts are any traces left on the victim's machine. Here we can indicate registry keys used by implants, created folders and files or services.
  3. The tools are already specific implants and intrusion support software. Examples here will include both publicly available and open source tools such as Mimikatz and Empire, as well as implants created by groups for specific operations. The ability to effectively detect tools is already very high on our pyramid, as it forces us to change methods of accessing, maintaining it in the system or exfiltrating data. In the case of groups that rely on ready-made tools and do not have access to developers who can properly transform the tools or create new ones, this may already be a serious obstacle in further activities.
  4. Finally, at the very top, there are tactics (high-level description of the activity, such as performing a specific action), techniques (description of achieving the activity goal, such as using PowerShell) and procedures (detailed description of the implementation of the technique, such as the steps to bypass AMSI in PowerShell). The ability to detect this level of activity is so valuable because it forces the attackers to rewrite some elements of the activity (or maybe even all of it), which will not always be possible within the timeframe for the operation. In the case of criminal groups using methods and action plans, such far-reaching difficulties may even make the operation unprofitable and attackers start looking for other targets.

When running threat hunting, we will be interested in the last three levels. Detecting attackers' tools and methods of operation will enable us to take real proactive actions - instead of counting that we will "hit" with an indicator such as a domain, we go on the offensive and we can counteract malicious activity at various stages. So even if the attackers managed to gain access to the system, by detecting the tools they use to exfiltrate the data, we will ultimately thwart their plans. Therefore, the assumption that we make when starting hunting is "assume breach", i.e. we assume that the attackers have already managed to gain access and are active in the environment. It may seem strange - after all, we should probably be preventing attacks? We should do so, but let's not forget that a successful break-in ends when the objectives are achieved (Actions on objectives). From this perspective, it is not important whether we catch, for example, ransomware at the stage of phishing e-mail or escalation of privileges, as long as we finally prevent data encryption. Second, it is simply unrealistic to assume that we will not be able to stop any hacking attempts at the access stage. Therefore, better results will be obtained if we approach the defense realistically and start attacking the attackers with our actions in the full spectrum of the chain.

We start hunting by developing hypotheses that we will verify in the course of environmental analysis. This is where cooperation with the CTI plays a key role, providing us with information on the methods of action used by attackers. Knowing what groups are potentially interested in our environment, we can start to create hypotheses taking into account the tools they use, how the implants behave or what are the favorite methods of moving around in the environment. So let's assume that we received information from CTI that the group uses CobaltStrike and a proprietary implant that maintains access to the system by creating a website named according to the scheme "sys [0-9] {3} [az] {4}". Based on this information, we can create example hypotheses:

  1. We will find rundll32.exe processes running without parameters in the environment, which are used by CobaltStrike as a code injection process.
  2. We find functionality artifactsand Windows named pipes with names that Cobalt Strike uses.
  3. Finally, we will find services with the names "sys [0-9] {3} [az] {4}" on hosts in the environment.

The next step will be to analyze the logs and verify whether we can confirm our assumptions about traces of malicious activity on their basis. If found, it will usually lead to the initiation of the incident response process. The available range of sources that we can use in hunting is naturally much wider and limited only by the visibility of the environment. The most popular data sources include logs from:

  1. Windows Event Logs.
  2. Proxy
  3. Firewall
  4. EDR
  5. VPN
  6. AD / LDAP

And it could be exchanged for so long. The sources we will use depend on what behavior we are trying to find and, of course, what logs are collected and actually available to us.

But what if we didn't find anything? Does this mean that we can deal with other hypotheses and forget about those already proven? It would be a big waste of our effort and time - we have information about how threat actors behave, and our research in the environment allowed us to assess whether these behaviors stand out among normal activities. So why not record the effects of our actions and create a detection rule that will help find similar behaviors in the future and perhaps lead SOC to activity, without the help of hunting. I talked about the cooperation between detection, incident response and CTI teams during my speech at x33fcon 2021, where I also presented a diagram of model relationships between teams:

For effective operation, the relationship between CTI and threat hunting analysts must therefore be two-sided - the CTI provides the data to build hypotheses, and hunters tell analysts what they see, enriching the knowledge of attacks. This process of operation describes well the F3EAD diagram that appears on my chart. F3EAD is derived from military operations methodology connecting the intelligence cycle with active threat detection. Its phases are as follows:

  1. Find - on the basis of available CTI data, we determine threats to our environment and methods of its detection.
  2. Fix - the use of analysts and environmental analyzes (e.g. log files) to find malicious activity. Here we find the machines accessed by the attacker and define the scope of the break-in. You could say the actual threat hunting is happening right here.
  3. Finish - incident response activities aimed at removing activity from the environment, cutting off attackers' access and repairing the effects of an attack.
  4. Exploit - after we have stopped hostile activity, we start to look at its activities and collect as much data about the break-in as possible. This phase therefore corresponds to the phase of gathering information from the intelligence cycle.
  5. Analyze - after collecting the data, analysts summarize their observations regarding the TTPs used, analyze malware samples to discover their functionality and create signatures, so they process the data obtained in the previous step.
  6. Disseminate - in the end, the results of the analyzes are disseminated among the teams forming the security organization (at the tactical, operational and strategic level) in order to broaden the knowledge about the threats and better prepare for the next break-in attempts.

As we can see, threat hunting is a powerful tool that allows you to turn your defense into an attack. By actively looking for malicious activity, we force attackers to change the tools used and methods of operation, increasing the cost of their actions and discouraging attacks against our environment. Successful hunting, however, requires not only technical knowledge, but also interaction between teams and the exchange of information. Then even the most advanced groups will have to be on thier tip-toes when trying to attack our environment.

Leave a Reply

Your email address will not be published. Required fields are marked *