TL;DR​​

I have created a new script to automate the ingestion of IOCs in MISP in object format. This script also automatically consumes information from VirusTotal to enrich the IOCs in case of exist in VT. However, the most interesting thing about this script is that it is able to automatically obtain the Sigma rules and MITRE techniques of the IOCs that we want to store in MISP, and add this information as Galaxies.

The stored galaxies are at the event level and at the object level, i.e. the event will have the total number of galaxies related to Sigma rules and MITRE techniques. Each object will have only the galaxies related to its behavior.

All you need to use the script is a VT API Key and to have the Sigma and MITRE galaxies in your instance. Since 2022-11-28 the Sigma galaxy is embedded in the default version of MISP. In case you don't have it, I recommend you to read this blog and use the script I made to create the sigma rules galaxy.

Version 2.0​

During the last weeks, I have been working on the script to improve it and to allow in this new version that I have recently published, the possibility to add relations in the galaxy with another already existing MITRE ATT&CK. This, among other things allows to know in a quick and visual way which sigma rule is related to which technique within MISP.

Suppose you have an event in MISP that is mapped to 5 MITRE ATT&CK techniques. Now, by clicking on those techniques and expanding the relationships, you will be able to see if there is any sigma rule that can cover any behavior of the expanded technique.

A threat intelligence analyst's brief​

In the threat intelligence world, we are continuously analyzing threat actors and threats in general that impact different sectors. From a threat intelligence analyst's point of view, it is important to know the motivations, objectives, TTPs and the overall context of the intrusion.

The results produced by these analysts are usually well defined. Frequently, a report is generated with a series of sections, where some of them are usually conclusions, recommendations, countermeasures.... Perhaps the least fun part for a threat intelligence analyst.

Also, in many cases additional products are generated and sent along with the report, such as STIX files with the analysis information, CSV files with IOCs, YARA rules and others. Another thing that most threat intelligence teams do is to dump all the information from the report into MISP including TTPs, IOCs and context information to help categorize, filter and relate the events.

From a threat intelligence point of view, our work should stop there. However, when it comes to generating a good security strategy, it is important to be able to map the techniques and behaviors identified in each intrusion with different types of rules, whether they are network or behavior-based endpoint rules.

TL;DR​

Previous blogs:

• https://jstnk9.github.io/jstnk9/blog/TIBER-EU-ES-Threat-Intelligence-Series-01
• https://jstnk9.github.io/jstnk9/blog/TIBER-EU-ES-Red-Team-Series-01

This is the last entry related to TIBER-EU and TIBER-ES. So far we have seen the processes related to Threat Intelligence and Red Team. Now it is the turn to learn about the Blue Team process, which, unlike the last two, is the Entity Blue Team itself. This team can be outsourced or belong to Entity itself, and its objective is to detect and defend the Entity business in case of an attack.

During the implementation of TIBER-EU, the Blue Team is not aware that any penetration test will be performed, so they must be able to detect the attacks performed by the Red Team provider. Subsequently, they must generate reports relating the Red Team's attacks to the Blue Team's findings.

As I did in the previous case, I have developed some cases in the The Hive tool so that blue team teams can import them quickly and know the different actions that they have to carry out, thus allowing the use of the Task logs to document and attach everything that they carry out on the test.

The developed cases contemplate all the phases that TIBER-EU mentions in its documentation, in addition I have also included good practices and ways of facing some phases.

The fact of using The Hive is due to the following reasons:

• Allows to merge cases
• Can be integrated with MISP
• Can be integrated with Cortex and its analyzers
• Case templates can be created

GitHub project: https://github.com/jstnk9/TIBER-Cases

About the tool​

ETW-Almulahaza is a python-based consumer tool that I've created and I'll be updating that help you to monitor ETW traces to see what happens when you execute some malware o tool. This tools is based in pywintrace of FireEye.

Event Tracing for Windows (ETW) provides a mechanism to trace and log events that are raised by user-mode applications and kernel-mode drivers. ETW is implemented in the Windows operating system and provides developers a fast, reliable, and versatile set of event tracing features. Microsoft documentation.

TL;DR​

Previous blog: https://jstnk9.github.io/jstnk9/blog/TIBER-EU-ES-Threat-Intelligence-Series-01

After posting the first post in relation to TIBER-EU/ES from the point of view of the threat intelligence provider, now is the time to talk about the figure of the red team provider.

The purpose of the red team provider is to execute the final security test on the Entity. This execution will be supported by an extensive analysis previously carried out by the threat intelligence team where, among other cases, different scenarios are provided that should be executed, all of them with the perspective of a real attacker. Additionally, as we saw in the previous blog, the threat intelligence team provides a series of flags for the red team to obtain during its execution, thus motivating the execution.

As I did in the previous case, I have developed some cases in the The Hive tool so that red team teams can import them quickly and know the different actions that they have to carry out, thus allowing the use of the Task logs to document and attach everything that they carry out on the test.

The developed cases contemplate all the phases that TIBER-EU mentions in its documentation, in addition I have also included good practices and ways of facing some phases.

The fact of using The Hive is due to the following reasons:

• Allows to merge cases
• Can be integrated with MISP
• Can be integrated with Cortex and its analyzers
• Case templates can be created

GitHub project: https://github.com/jstnk9/TIBER-Cases

TL;DR​

After the Bank of Spain (BDE) published the TIBER-ES guide adapted to the national territory in January 2022, I was thinking about the complexity that in some cases it would entail for Threat Intelligence and Red Team providers to give this service to financial entities.

For this reason, I wanted to carry out a development so that the Threat Intelligence teams speed up their work through predefined cases of the famous platform used in the world of CTI called The Hive.

The developed cases contemplate all the phases that TIBER-EU mentions in its documentation, in addition I have also included good practices and ways of facing some phases.

The fact of using The Hive is due to the following reasons:

• Allows to merge cases
• Can be integrated with MISP
• Can be integrated with Cortex and its analyzers
• Case templates can be created

GitHub project: https://github.com/jstnk9/TIBER-Cases

TL;DR​

Thanks to threat modeling, a strategic view of the main threats can be given in order to focus prioritization efforts on those points where the greatest risk may exist.

From a Cyber Threat Intelligence vision, the focus is on the identification of actors and events along with the TTPs and Tradecraft used in them, thus relating it to the activity of our organization.

The model has an advantage in that it can be as flexible as we want, which helps to adapt to our intelligence needs.

TL;DR​

The threat hunting process that currently exists can be used in parallel with another process called indicator life cycle.

Both cycles are based on the same, aiming at proactive detection of threats and behaviors in corporate networks, leaving aside the reactive approach which is increasingly being avoided.

This is because traditional incident response processes have a methodology based on working on an event that has taken place, whereas the indicator lifecycle and threat hunting process work from the perspective of working to prevent something from happening.

During this blog I will explain the indicator lifecycle and how it can be used in parallel with the threat hunting process, also presenting a case study at the end.

TL;DR​

Lately I am analyzing many malware samples from different families written in C#, C++ and other languages based on the .NET framework (.NET assembly).

This has led me to find a problem when correlating different samples using hashing techniques, and that is that the imphash in a high percentage was always the same, even with different malware families, however, using other fuzzy hashing techniques I couldn’t find any similarity.

The problem is due to the fact that during the compilation of the .NET programming languages, the source code is converted into Microsoft Intermediate Language (MSIL), which causes the same imphash to always exist, corresponding in some cases to the import of the mscoree.dll DLL and the _CorExeMain function.

I have solved this problem by using another hashing tool called TypeRef Hasher developed by the folks at G Data CyberDefense. This tool provides a solution to imphash only for .NET malware samples.

Taking advantage of the CLI they have available on GitHub, I have developed a small solution that implements and complements it.