Fantastic TI and Where He Dwells

Security Vision

In this article, we will talk about threat intelligence as another source of incident generation and investigation. However, before we get into the topic of investigation and additional data flow, let's define what TI is. Threat Intelligence (TI) is information about threats and attackers in the cyber space.

Threat Intelligence

TI is divided into several layers of data. At the lowest level are technical indicators of compromise such as IP, Hash, URL, Domain, Email. This data is most often associated with TI. The next two layers are operational and tactical data. This includes data on the attacker's various TTPs (tactics, techniques, procedures, tools) described by behavioural indicators, command lines, registry keys, malicious certificates, named pipelines - things that show malicious activity over time. This type of indicator is described in Sigma's threat detection rules.

The topmost level of strategic attribution data tells us about attackers, VPOs, malicious campaigns, and this data is rarely changed, unlike low-level data that is easily altered by an attacker to hide the traces of their activity. Such data is not difficult to find on the Internet in public sources, it is quickly identified in host assets, but it is not always enough to fully analyse the situation. It's as if Sherlock Holmes only used 3 criminal's landmarks such as eye colour, ear shape and foot size, while completely ignoring the rest of the data landscape that can be used in an investigation.

Problematic use of technology

Through strategic attribution, the context of a particular indicator is formed. This provides the opportunity to investigate an information security incident on a fuller scale, but with it comes a number of challenges. The fact is, TI is quite a popular field today. A large number of organisations are interested in analysing their own threats and are willing to invest significant amounts of money in this area. However, there are cases when TIP is used ineffectively and, faced with a huge flow of data, IS specialists simply ignore most of this information. This happens because the objectives of the implementation were not clearly defined before implementation. For example, a TIP may track credit and financial indicators, take into account a specific infrastructure stack, country location, and a specific threat model of intruders. And in the event that feeds are not properly customised, an organisation may ‘choke’ on a flood of false positives or, conversely, TI will fail to deliver on expensive feeds, leading to disillusionment with the technology (as happened relatively recently in the foreign IS world when TI fell into the valley of disillusionment according to Gartner curve analytics).

Another issue is that the heterogeneity of data formats, the lack of standards and a common conceptual framework, coupled with a huge shortage of skilled cyber security personnel, are not conducive to maximising the use of the solution. There is simply no universally accepted standard for a common description of a threat indicator. There are, of course, common and most commonly used formats such as STIX and MISP, but even there, attribute composition can vary widely from source to source, and some data providers offer their own proprietary format. The technical, operational and strategic attribution data model is often different for each vendor.

So how do you solve all of these problems? First and foremost, you can limit the flow of data to the threat landscape that is relevant to you. Knowing the specifics of your own infrastructure, you can build boundaries based on the risks that are relevant to you, focus on the threats that are most relevant to you, and monitor the malicious processes that are most dangerous to your infrastructure. This will ensure that you are not drowning in a vast amount of information and that you are using TIP as a data source in the most efficient way possible. In addition, you need to build TI into your processes, procedures, playbooks, and response plans. This needs to be done both for preventative analysis and for investigating specific incidents.

The ‘perks’ of TI

The biggest benefit of TI is the relevance of the data. When we talk about signature analysis, about decisive rule bases, about correlation rules, we understand that new data comes to us according to some release cycle (it varies from vendor to vendor: it can be a week or a month). In between releases, we are the least protected for the newest threats. TIP can close this security hole due to the information it can provide the day after it occurs on GitHub or the darknet. Through the raw events we store, there is a way to retrospectively check if a new threat was in our infrastructure yesterday. That is, we saw a new C2 domain when we got it, for example, from a crawler, then we go to our infrastructure and check if our hosts were accessing that malicious domain yesterday when we didn't know it was malicious. This is accomplished by quickly connecting a new data source with a logistical shoulder of a day or a few hours rather than a month or two.

TI use cases: IOC detection and situational awareness

We've looked at Threat Intelligence as a source of indicators of compromise, but there's another data set that needs to be processed - our raw events. To most effectively look for signs of malicious activity, raw events should cover as much of your infrastructure as possible: network, host and email traffic, taking into account industry and domain; industry protocols, legitimate and illegitimate applications on your perimeter.

Having these two sources of data gives us two key use cases for the TI platform. The first case study is situational awareness. Let's say we have some domain, we got this information from SIEM as part of an incident of addressing a malicious domain. What can we do with that? We can open up the TIP and find out what IP addresses have been behind that domain for the last week. Even if the IPs change quickly, we can see the entire pool of addresses and check for them in our infrastructure. We can see the file hashes associated with the malicious domain so we can take action to investigate the incident. We can find out which attacker is behind this domain and what malware they are using. This case is most relevant for small SOCs with 1-2 people - for such a small team another source of incidents would be redundant: it would increase the data flow, which would be simply not handled by anyone.

For a mature and large SOC team, incident detection can be added in addition to situational awareness. Earlier I mentioned two databases - an indicator repository and historical raw events. These are combined in the TIP to perform detection. TIP monitors raw events (most often in conjunction with SIEM) and syslog, the event processing selects 5-6 key parameters such as source IP, destination IP, destination network port, domain, hash, url, mail address. Next, matches are searched against a database of compromise indicators. If a detection occurs, the TIP automatically generates an incident. The next detection checks for an open incident with one of these parameters. If such an incident is found, automatic aggregation occurs, so that the SOC is not inundated with a large number of identical incidents.

The next parallel data stream is anomalous activity. This covers machine learning, heuristics, deviations from standard behaviour, weighted Markov chains, random forrest, dga. By analysing this data, potential malicious activity can be identified and an incident can be created.

Another data stream is retro-analysis, and here there is no repetition of SIEM functionality. TIP stores the previously mentioned 5-6 key indicators in an optimised form. When new indicators are received, they are checked for interaction with indicators of compromise in the past, when nothing was known about these indicators yet. It is up to each organisation to determine for which period to store data for effective analysis.

Case Study

Let's look at this process with a concrete example.

An incident is detected in SIEM using correlation, the key parameter in our case is the hash from the antivirus. What can be done with it? TIP analyses the context of the indicator and checks for correlations with other indicators. If an indicator is detected, an incident is automatically created where we can trace all the connections of this hash: for example, which attacker is associated with this hash, what vulnerabilities and malware this attacker is using, and the ip addresses associated with this malware. So we have realised that we have potentially malicious ip addresses that need to be checked. After that, the logical move would be to perform a retro search to see if there have been any hits from our infrastructure to ip addresses associated with the attacker.

Let's assume that we found a dozen hits to some of these addresses, and this is already a potential attack landscape. The next step we perform enrichment. From the analytical services we trust (VirusTotal, ANY.RUN, Kaspersky, etc.), we automatically collect information about related TTPs. As a result, we have another set of indicators, but this time behavioural. Next, we look for indicators of attacks in our infrastructure, i.e. we check if there are any malicious processes on hosts that have not been in contact with the C2 server that would indicate that they belong to this attack. Once we have found 3-5 more assets affected by this threat, we can say that we have formed a complete attack landscape. I would like to emphasise that much of this analytics can be done automatically if your TIP allows it.

Once the investigation is done, there is usually a standard operational activity that involves blocking malicious ip addresses, quarantining some assets, running anti-virus checks on hosts, blocking compromised accounts, etc. When the attack is stopped and its consequences are eliminated, it is time for post-incident processing. First of all, it is hardening of assets that could potentially be exposed to an attack. Based on triggered indicators, correlation rules and IDS/IPS signature rules can be configured, and indicators can be automatically moved to table lists or SIEM asset lists so that correlations can be worked out. The threat model can also be updated.

Conclusion

Thus, we can see that TIP (with a competent approach to customisation in the process of implementing the solution) is effective in various information security processes and should be end-to-end integrated into many procedures of the SOC-centre or IS department. And, of course, we should not forget that the platform allows you to create and keep up-to-date a model of threats and intruders.