Table of contents
In this blogpost, we present the integration of Indicators of Compromise (IoCs) in our Cyber Threat Intelligence (CTI) from the results of Hatching’s Triage sandbox analysis. To provide some context to this integration, we briefly describe our vision of CTI in SEKOIA.IO. We then summarize the sources that feed our threat knowledge used for detection in SEKOIA.IO eXtended Detection and Response (XDR). And finally, we detail the integration of IoCs produced by the Hatching Triage sandbox and completed by our Security Orchestration, Automation and Response (SOAR) module.
Cyber Threat Intelligence vision in SEKOIA.IO
At SEKOIA.IO we designed the CTI to be at the heart of SEKOIA.IO XDR and more globally to enhance anticipation, detection and response capabilities. As explained in our previous blog post, CTI has three main orientations: strategic, tactical and operational.
- Strategic CTI enables the assessment of cyber risks and consequently drives the high-level organisational cybersecurity strategy. To do so, data must be contextualized and understandable to decision-makers.
- Tactical CTI allows users to better know the modus operandi of the adversaries, their campaigns, their motivations and eventually to identify the threat actors.
- Operational CTI is about the technical artifacts that are relevant for real-time detection or investigation. Armed with this knowledge, incident response is also greatly facilitated and accelerated.
To produce intelligence that fits these three goals, it is necessary to have a highly structured, contextualised and actionable CTI. Indeed, strategic and tactical intelligence need understandable data and operational intelligence requires actionable data. In SEKOIA.IO, we decided to use STIX, which is a structured language specifically designed for Cyber Threat Intelligence. With its graph approach, STIX enables the association of an OSINT report on a hot topic, with a campaign linked to malware which is itself associated with indicators. Relationships are preserved to keep context and ensure traceability of intelligence. Indicators are the cornerstone of our XDR. To do real-time and high-quality detection, we continuously collect, enrich and contextualize a lot of technical artifacts on cyber threats, which are called Indicators of Compromise (IoCs). To ensure that our customers can fully trust our detection events, this data has a validity date and a thorough traceability. A limited validity enables us to keep only useful IoCs in our knowledge base, while tracking their sources enables fine tuning of the detection engine. Last, each IoC indicates one or several objects to add context to the threat, such as malware, tools, intrusion sets, threat actors, campaigns, etc. The design of our CTI therefore enables an improved threat detection in SEKOIA.IO XDR, mainly thanks to the Indicators of Compromise that we will now describe further.
How do we collect and enrich the Indicators of Compromise?
Indicators from our CTI are the result of several stages that are performed automatically or manually by the SEKOIA.IO team. The journey of an IoC starts with the aggregation of data from several sources and their validation. Potential threat information is then enriched, structured, and put into perspective within its context. Eventually, threat knowledge is ready to be used by our clients, regardless of their technical environment. Our work allows them to save a considerable amount of time and effort on OSINT threat modelling and monitoring thanks to exclusive indicators coming from proprietary trackers.
We tap into multiple threat intelligence sources, either from the community or from exclusive sources. To mention just a few, we integrate information from:
- Open-Source Intelligence (OSINT) threat reports:
Blog posts, government agencies statements, DFIR reports or any other OSINT content are transformed into contextualized intelligence by the SEKOIA analysts. It also includes vetted and enriched IoCs shared through these reports.
- Threat feeds from community sources:
Indicators from community feeds, such as MalwareBazaar, MWDB, Feodo Tracker, URLhaus, are automatically verified, contextualized and integrated into our CTI database.
- Adversary infrastructures trackers:
Based on artifacts from past campaigns, we identify characteristics of the adversary infrastructures to track their current deployments. To do this, we use data from third-party scanners (like Onyphe, Shodan or others) to identify active Command & Control (C2) infrastructures sometimes even before the adversary uses it. To learn more about this proactive hunting approach, read our blog post on the matter (in French only).
- Dark Web monitoring:
For more exclusive intelligence, we also monitor part of the Dark Web to collect information on cybercriminals’ activities.
The use of all these multiple methods allows us to have wide coverage on threats, ranging from widespread spyware to APT groups targeting specific sectors.
In an effort to continuously improve our CTI, we constantly need to unlock new sources of information. For instance, as a way to increase our coverage of malware trends, we were interested in results from automated malware analysis, which is usually done in a sandbox. Sandboxing technologies execute malware samples to analyse their behaviour and extract information, such as IoCs. Sandboxes can therefore be a rich source of information on popular malware, since public submissions reveal a lot about the threats companies are facing.
Looking for a sandbox that meets our expectations
The selection of a sandboxing technology involved the definition of our needs and the analysis of the capabilities of different solutions.
Our requirements to select a sandbox solution include a lot of capabilities that can be involved in the CTI production cycle, ranging from the collection of IoCs from sample analysis, to writing detection rules based on sample behaviour, including the retrieval of data from extracted malware configurations, tracking malware campaigns, etc.
To find the perfect sandbox for our needs, we have built a benchmark of solutions. They were submitted several samples from state-sponsored actors, proficient cybercriminals or single attackers acting out of opportunism. For each sample, we scored the sandbox based on our criteria list. We also took into account the speed, the correctness and the efficiency of the sandbox. The presence of an API was also essential to automate our processes as much as possible.
If you have read the title of this post, it should come as no surprise that we selected the Hatching Triage sandbox. Beyond satisfying our basic requirements and displaying many interesting features, one feature really appealed to us and we would like to congratulate the Hatching teams for it. This feature is the automated extraction of malware configurations. In short, configuration extractors are available for some malware families, such as Cobalt Strike, IcedID, Trickbot, Qakbot, and many others. They extract the Command & Control (C2) servers associated with the malware sample that can be IP addresses, domain names or URLs.
Extracted IcedID configuration on Triage : https://tria.ge/210623-fa6mx24cr2
By the way, the port is often informed when the C2 uses an IP address, which matters a lot, especially for Remote Access Tool (RAT) C2s. Indeed, for the most common RATs, the attackers often share a single server as illustrated in the following figure. In a SOC context, the knowledge of the port, especially when collecting and adding IoCs automatically, is thus valuable to avoid false positives on detection and accelerate the alerts’ analysis.
Extracted Quasar RAT configuration including a port on Triage : https://tria.ge/210624-tmff1at666
As explained previously, the available data on the C2 servers is extremely valuable. We can create qualified IoCs from information extracted from sample analysis. The submission of samples is important in our CTI, because we collect fresh IoCs of trendy threats faced by companies in near real-time. Moreover, the C2 servers are extracted from malware samples whose family has been identified by the Triage sandbox. The network artifacts are therefore already qualified and we can be relatively confident in their accuracy.
Sample hashes or URLs are also interesting IoCs which can be collected, contextualized and added into our CTI database.
Automated extraction of malware configurations is a great feature to collect contextualized IoCs with good confidence in SEKOIA.IO, and that’s the reason why the Hatching Triage sandbox best fitted our needs
Integrate Triage results into SEKOIA.IO
Now that we have identified the source, it is time to ingest it with our integrated Security Orchestration, Automation and Response (SOAR) module.
Our SOAR module is used in the SEKOIA.IO XDR product to automate recurrent processes (repetitive actions, enrichment) or to perform an automated action at a large scale. This saves time for SOC analysts and limits fatigue, and thus turns out to be the perfect feature to integrate the results from Triage’s analyses. Each automation was made using playbooks, which can be considered as visual block programming or no-code automation.
We have therefore implemented new blocks in the SOAR module to collect what we needed. A block fetches IoCs associated with a specific malware family tagged by Triage. Another block normalizes the data into STIX content before being ingested. These blocks also aim to contextualize collected data, to assign them a validity date, an external reference, a source, a kill chain phase (using MITRE ATT&CK) and link them to the associated threat.
SEKOIA.IO playbook collecting IoCs from Triage sandbox analysis
The final result of the playbook is an IoCs bundle which is pushed into our CTI database. A great added value of the Triage data source is that each indicator is associated with the complete sandbox results which are very useful for threat hunting. Indeed, an analyst needs information regarding the threat. Its behavior at system and network level helps the analyst to better qualify an alert or investigate during global incidents.
IcedID malware IoC and its context in SEKOIA.IO
During one month, 9000 indicators have been collected.
Widget example on SEKOIA.IO listing statistics from Triage.As expected, the collected indicators are relevant for detection and investigation purposes. Indeed, compromises at our customers have been detected in SEKOIA.IO XDR using these indicators and in particular an Agent Tesla infection detected on several stages: the delivery, the execution and the C2 communication.
Conclusion
In summary, SEKOIA.IO CTI relies on community and exclusive sources to provide a highly structured, contextualized and actionable intelligence to our customers. With the aim of enhancing our precision and extending our threat coverage, we integrated results from malware configuration extraction produced by Triage sandbox analysis. This data is already highly qualified by the sandbox solution and our SOAR module deals with the integration and enrichment. We are proud to cooperate with Hatching, a European tech company offering a high quality product in cybersecurity. By the way, we take the opportunity of this blog to thank the community working on these projects as well as individuals and organizations sharing valuable information through OSINT threat reports.
Chat with our team!
Would you like to know more about our solutions? Do you want to discover our XDR and CTI products? Do you have a cybersecurity project in your organization? Make an appointment and meet us!
On our blog, you can read also:
