Testing phase: red team testing

Overview

Following completion of the targeted threat intelligence process, the RT provider takes the lead. During the red team testing phase, the RT provider plans and executes a TIBER-EU intelligence-led red team test of the target systems and services that underpin each CF in scope. This is followed by a review of the test and issues arising.

It is important that sufficient time be allocated to the red team testing phase to allow the RT provider to conduct a realistic and comprehensive test in which all attack phases are executed and all test objectives are achieved. The test objectives (i.e. compromise actions) agreed during the scoping phase (and possibly updated during the targeted threat intelligence process) are the flags that the RT provider must attempt to capture during the test as it progresses through the scenarios.

The time allocated for testing should be determined by the scope, the entity’s resources, any external requirements for a given engagement, and the availability of supporting information supplied by the entity (e.g. regular vulnerability reports or previous assessment data). In general, the time allocated to testing should be proportionate to the scope, although based on experience it is envisaged that 10–12 weeks would be a reasonable amount of time for testing.

Testing methodology

The RT provider should deploy a range of TTPs during the test. The following is just one example of a testing methodology that the RT provider may use.

Reconnaissance – The first phase in a red team test is focused on collecting as much information as possible about the target. Reconnaissance is one of the most critical steps, and it is usually possible to learn a great deal about the target’s people, technology, surroundings and environment. This step may also involve building or acquiring specific tools for the engagement. Reconnaissance should primarily be undertaken by the TI provider, although the RT provider will also take part in this activity during the build up to the test.

Weaponisation – Another important phase in a red team test involves analysing the information gathered about the infrastructure, facilities and employees. By means of this thorough analysis, the red team begins to form a picture of the target and its primary operations. Effective weaponisation involves preparation for the operations specific to the targets.

Delivery – This is a critical stage of the execution phase and marks the active launch of the full operation. The red team begins to carry out the actions on the target(s) intended to reach the targets or flags, such as social engineering, analysing cyber vulnerabilities, planting hardware trojans for remote network persistence, etc. One of the most important objectives is to identify the best opportunities for exploitation.

Exploitation – During exploitation, the red team’s goal is to “break in”, i.e. to compromise servers/apps/networks and exploit target staff through social engineering. The exploitation stage paves the way for the control and movement phase.

Control and movement – Once a successful compromise has been performed, attempts to move from initial compromised systems to further vulnerable or high- value systems will be made. For example, this may consist of “hopping” between internal systems, continually reusing any increased access obtained in order to eventually compromise agreed target systems.

Actions on target – This entails gaining further access to compromised systems and acquiring access to previously agreed target information and data. At this point, the red team aims to complete the test and achieve the objectives agreed upon and set by the entity during the scoping and threat intelligence processes.

Red Team Test Plan

Prior to the commencement of the test, the TI provider must have a handover session with the RT provider, providing a detailed explanation of the TTI Report and discussing possible threat scenarios for the testing. The RT provider should gain insight from this handover meeting and further review the TIBER-EU Scope Specification, the GTL Report (if produced) and the TTI Report to finalise the Red Team Test Plan. This information and documentation provides the evidential basis for designing and justifying the proposed Red Team Test Plan and attack scenarios.

The RT provider should align its test objectives with the goals of each of the actors, map these to the CF-supporting systems, and produce credible real-life attack scenarios for the test. The attack scenarios are designed to provide background to the tradecraft employed by each threat to conduct a successful attack. The RT provider should therefore adapt its attack methodology to replicate the real-life attack scenarios.

The RT provider should additionally draw upon the TTI Report, which reveals some of the entity’s attack surfaces, as a basis for deeper and more focused targeting activities.

The RT provider could also add some elements which test the response of the entity, including evidence on whether the compromise action would be immediately detected or could have a fair chance of succeeding.

Performing any sort of red team test always carries a level of risk to the target system and the business information associated with it. Risks to the entity, such as degradation of service or disclosure of sensitive information, need to be kept to an absolute minimum. The RT provider should therefore include an appropriate plan for managing these risks.

The output of this activity is the final Red Team Test Plan, including the attack scenarios to be followed and the risk management controls that will be applied to ensure that the test is conducted in a controlled manner.

Scenarios

The attack scenarios are written from the attacker’s point of view and should define the concrete targets to be reached (i.e. the flags to be captured). The RT provider should indicate various creative options in each of the attack phases based on various TTPs used by advanced attackers to anticipate changing circumstances or in case the first option does not work. The scenario writing is a creative process. The TTPs do not simply mimic scenarios seen in the past, but combine the techniques of the various relevant threat actors.

In some cases, the implementation of the framework (TIBER-XX) may also include using TTPs which look to breach the physical security of the entity to gain access to the network or plant a device. However, if such a method is adopted as part of the TIBER-XX implementation, appropriate safeguards (e.g. formal consent by the entity) should be in place and no legal boundaries should be crossed.

In addition to these scenarios, an RT provider may develop other types of scenarios. In many cases, the use of conventional TTPs may not be successful in achieving a target; to emulate a real-life attacker in such a case, the RT provider could deploy creative and innovative TTPs, stretching itself to its absolute limits. The RT provider can leverage its full range of professional knowledge, research, expertise and tools to build forward-looking scenarios based on TTPs that have not yet been seen but are expected in the future.

Additional information from the entity and TI provider

The TIBER-EU process is designed to create realistic scenarios mimicking possible future attacks against the entity. Real-world threat actors may have months to prepare an attack. They are also able to operate freely without the constraints that TI/RT providers face, such those on time and resources – not to mention the moral, ethical and legal boundaries. This difference can cause challenges when attempting to create realistic scenarios, as knowledge about the internal network is often the hardest to gain using morally, ethically or legally justified techniques.

Similar constraints apply to the systems underpinning the CFs, which typically do not have a large footprint on the public internet. Whether they are internal bespoke systems or external systems that span multiple organisations with a common connecting infrastructure, the RT provider’s knowledge of the functioning of these systems may be limited in comparison with that of attackers who have the capacity and time to study them extensively.

Therefore, to facilitate a more effective and efficient test, the entity may deliver additional information to the RT provider on the scenarios chosen, including on the people, processes and systems targeted in the scenario. This information may give the RT provider further insights and allow a better use of time. However, it is up to the entity to provide this additional information and the underlying level of detail at its discretion.

If the entity provides additional information, the TIBER-EU test will reflect a “grey box” testing approach in contrast with the “black box” approach. Experience shows that the more relevant information an entity gives to the RT provider, the more the participating entity will gain from the test. However, it should be evident that the information given to the RT provider could have been obtained by an advanced attacker with more time and unhindered by moral, ethical and legal constraints.

In addition to the information provided by the entity, the role of the TI provider can be enhanced during the testing phase. For the test to succeed, the TI provider can provide ongoing threat intelligence to the RT provider during the test, which may provide more useful reconnaissance and more insight on how to achieve the targets. In real life, the attacker can leverage threat intelligence while attempting to compromise an entity. Allowing a fluid relationship between the TI and RT providers during the test may add greater value to the entity. Where TI and RT providers decide to work more closely during the test, the working arrangements and information sharing arrangements must be agreed between the two parties.

Execution of the test

During the execution of the test, the RT provider should perform a stealthy intelligence-led red team test of the target systems. The attack scenarios are not a prescriptive playbook which must be followed precisely during the test. If obstacles occur, the RT provider should show its creativity (as advanced attackers would) to develop alternative ways to reach the test objective or flag.

RT providers are constrained by the time and resources available as well as by moral, ethical and legal boundaries. It is therefore possible that the RT provider may require occasional leg-ups from the WT to help them progress. During the testing phase, the RT provider may be unable to progress to the next stage owing to time constraints or because the entity has been successful in protecting itself. In such scenarios, the RT provider, with agreement from the WT and TTM, may be given a leg-up, where the entity essentially gives the RT provider access to its system, internal network, etc. to continue with the test and focus on the next flag/target. Should this happen, then the leg-up should be duly logged. This ensures that maximum benefit is derived by all stakeholders from a time-limited test.

The TTM should be updated at least once a week by the RT provider, while the WT should be kept abreast of progress on an ongoing basis. If feasible, physical meetings between the WT, TTM and RT provider during this phase are strongly encouraged, since the discussions add significantly to the quality of the test and help build a relationship of trust. However, any such meeting should be conducted cautiously to ensure that the BT is not made aware of the ongoing test.

Irrespective of the methodology used by the RT provider, the test should be conducted in a controlled manner, taking a stage-by-stage approach, and in a way that does not bring risks to the entity and its CFs. It is important for the WT and TTM to be continuously informed about progress being made at each stage, as soon as a flag or target is in sight, or at least when the RT provider has achieved the “capture the flag” moment. These updates provide the WT with the opportunity to discuss with the RT provider and TTM what actions can and cannot be taken next. It also provides a chance for escalation procedures to be invoked where necessary. The WT can halt the test at any time if it considers it necessary to do so. All of the RT provider’s actions should be logged for replay with the BT, as evidence for the Red Team Test Report, and for future reference.

TIBER-EU testing phase – overview of the red team test