Security Vision
In this article, I would like to discuss attack indicators - the part of Threat Intelligence that is responsible for effective threat response and incident investigation. In this context, let us remember one of Zeno of Eleusis' aporias about Achilles and the tortoise. Modern business often finds itself in the position of a fast-footed Achilles, who, catching up with the tortoise, always remains slightly behind.
Correlation rules are written and deployed in a SIEM system, but after a week or two they are no longer as relevant as they were when they were released, because the world does not stand still and new vulnerabilities and new groups of attackers using new techniques are constantly appearing. And correlation rules are well written and work effectively with most threats, but they don't cover the techniques and tactics that came after them. Another problem is that there is not enough data from sources to fully analyse the situation in a SIEM. When we build a kill chain from initial access to impact, we find huge holes in it because some sources were under-configured or configured for less coverage than we would like. Analysts write correlation rules based on new data: resurveys, analysis of reports from specialised sources, but given that they have the main workload related to the highest priority incidents and tasks, they often simply do not have enough time to update correlation rules often enough.
Threat Intelligence
In this difficult situation, Threat Intelligence technology comes to the rescue. It collects up-to-date information from all over the Internet. One of the symbols of Threat Intelligence that you may have seen is a pyramid with four levels of detection indicators: technical, tactical, operational and strategic.
Commercial feed providers in our country supply primarily technical data. This is probably why TI is most often associated specifically with indicators of compromise (IoC). This information is of course very valuable and useful, but sometimes additional context is needed to develop a better understanding of your threat landscape. That's why commercial feeds often include, in addition to malicious IPs, information about the attackers exploiting those IPs and the vulnerabilities that are most likely to penetrate the victim's infrastructure from that domain. There may be a specific MITRE ATT&CK technique and tactic tied to the malicious domain that is most often used by that attacker. However, there is a deeper level of analysis, namely the behavioural characteristics of the attack.
Behavioural indicators
Behavioural analysis first of all answers the question: what, exactly, will the attacker do when he manages to penetrate the infrastructure of the attacked company? Everyone who walks leaves footprints, and the attacker did not enter your information space to stand quietly in a corner. When, for example, a vulnerability has been successfully exploited - a process has been created, a malicious library is being loaded somewhere, in other words, there are behavioural signs.
What makes behavioural indicators so useful in real life? The fact is that in the case of proactive Threat Hunting based on hypothesis generation, where an incident is a successful test of a hypothesis, we only assume that a vulnerability has been exploited. These are often only attempts at unauthorised access to data. An incident may include legitimate removal of shadow copies - or not. The task of the IS analyst is to find out during the investigation: was the incident a false positive or is it a real attack, was there an impact or is it just noise? Behavioural analysis helps to do just that. For example, the Follina vulnerability (CVE-2022-30190) has strong indicators of an attack, such as running the MS Diagnostic Tool. And it seems that the process is legitimate, just a diagnostic tool, but the process has: a specific parent, in this case the Winword process, a suspicious payload, malicious PowerShell code. And when you have this information, when trying to exploit a vulnerability, it is not difficult to check: was MS DT running on the host in the vicinity of this incident and was there any suspicious PowerShell payload, i.e. any payload? In this way, we get operational hypothesis solving, but there are other pluses that lie in the very essence of TI.
An integrated approach
Threat Intelligence is a technology based primarily on a community driven (CDD) approach, where the development of technology is not focused on a specific company, but on an entire community of information security specialists. Today we have access to a huge number of very diverse sources. There are various Sigma reports, vendor reports, DFIR reports. We see the digital forensics and information security community sharing information internally from real-world experience with particular threats.
TI applications are tasked with selecting from this data stream the most useful, relevant information on compromised IPs, vulnerabilities, hacker groups, new tactics and techniques relevant to your threat model and attacker, resulting in the ability to update and expand your threat landscape. From this sample, we can already infer whether we are at risk for certain relevant IoCs, CVEs or techniques. In this way, Threat Intelligence allows for an integrated approach, where on the one hand we use the good old Alert base approach based on SIEM triggers, and on the other hand we build hypotheses about the presence of indirect signs of a particular threat. Then we test these hypotheses: we test certain processes, named channels, and the Threat Intelligence Platform not only supplies us with these hypotheses, but in conjunction with SOAR allows us to test them semi-automatically, thus reducing the burden on the most qualified information security specialists.
Example from life
Of course, it looks great in theory, but it would be much more interesting to see how everything works in reality. I propose to analyse a real-life example from our rich experience. An incident occurred within a segment that had access to the Internet. It was quickly resolved, but it is very illustrative in terms of identifying the different stages of an attack. It usually starts with Reconnaissance, followed by Initial access. As a rule, these are automatic scans and attempts to exploit vulnerabilities. It is not always immediately obvious whether these attempts to penetrate the infrastructure were successful or not.
In our example, the TIP was aggregated by src and dst, which allowed us to see the attack chain. We noticed that there were reverse requests from one asset in the dmz segment, which is a very serious sign of potentially successful exploitation of a vulnerability, loading malware into the infrastructure and preparing a springboard for further horizontal spread. With regard to C2, it is quite a common story when scanning and intrusion attempts are started from one address range, and malicious payloads are launched from another address range, after a reference point has been obtained, with the expectation that if the entry point is blocked, an access point will remain in the other location.
In this example, we can see that the two C2 IP addresses had Cobalt Strike attribution, but one of them also had behavioural attributes such as commandlines, specific processes, named pipes and specific dns requests. After comparing all the information collected, TIP automatically built a graph that captured all the data that could be applied in the context of the investigation.
What was learnt? It turned out that events were received from the compromised host that indicated the presence of behavioural indicators typical of the Cobalt Strike VPO (named channels and PowerShell-specific commandlines).
In this way we were able to localise the attack. We built a landscape and saw the network calls from the inside from the hosts that participated in the incident. SOAR got the actual information on the host (in case of named channels it is memory dump), then, comparing this information with its database, identified indicators of compromise. After that it was a matter of technique to block the compromised hosts from the same graph interface.
Conclusions
To detect behavioural indicators it makes sense to analyse the following information:
- lists of running processes and their parameters
- files, folders, registry branches
- WMI
- Windows logs
- EDR
- Sysmon
- other areas (memory dump, application logs)
You may be asking, ‘What do we do if there is no Sysmon and EDR? How do I collect telemetry in this case?’. This problem can be solved by choosing the right SOAR-TIP mapping. Ours, for example, could provide basic information on the signs of an attack by collecting memory dumps, process information, and this is already enough to draw basic conclusions and make decisions quickly. So use the maximum capabilities of TIP to search for behavioural indicators, and you will see that Threat Hunting is more accessible than it seems.
