Anatomy of a Red-Team exercise - Chapter 1

22 March 2021

Important note before starting: each phase is not fully detailed, the provided information here permits to illustrate the context and to provide a better understanding of this write-up, some details are missing – we apologize for this.

What the hell are we talking about? (aka introduction to Red Teaming)

A Red Team engagement can be shortly described as a real-life targeted attack simulation.

As a threat actor, it uses a blended approach through several facets of social engineering, physical intrusion, application/network penetration testing, targeted phishing campaign… simultaneously to reach some pre-defined objectives.

It’s aimed at revealing real-world opportunities for external attackers to be able to compromise all aspects of your organization by granting themselves unauthorized (virtual and/or physical) access to your infrastructure. This allows them to recover sensitive information that could lead to data breaches, total system/network compromise and more.

Red team engagement is an attack simulation carried out by highly trained experts in several domains that require specific skills in an effort to:

  • Identify exploitable weaknesses and their associated impacts (physical, hardware, software, human, policies…);
  • Have a better understanding on the path/scenario that an attacker may use to target your company to prevent it to happen;
  • Obtain a realistic understanding of risk exposure for your organization;
  • Measure your incident response capabilities and policies in place to address risks efficiently;
  • Challenge processes in place in terms of crisis management, patch management, effectiveness of password policies (in case of credential theft for example) and so on;
  • Establish a remediation plan and mitigate all identified security weaknesses before it is too late;
  • … and to protect your business!

It really differs than Penetration Testing in sense that this approach is not scope based but “flag” oriented and uses objectives called “flags” (to reach) that are defined before the test begins, during a pre-engagement meeting.

In Europe, a framework called “TIBER-EU” was released by ECB and provides a very useful and well-structured basis in term of methodology, expectation, philosophy and the deliverables that should be provided.

The TIBER-EU framework is described as follow:

“TIBER-EU tests mimic the tactics, techniques and procedures of real-life attackers, based on bespoke threat intelligence.

They are tailor-made to simulate an attack on the critical functions of an entity and its underlying systems, i.e. its people, processes and technologies.

The outcome is not a pass or fail; instead the test is intended to reveal the strengths and weaknesses of the tested entity, enabling it to reach a higher level of cyber maturity.”


To go further in terms of applicable methodology and framework we can also mention the well-known but so useful MITRE ATT&CK framework for any I.T aspect or the wonderful RedTeamOPSEC methodology for physical intrusion testing.

Ref. : et

In Luxembourg, the financial regulator (CSSF) himself incite financial companies (but of course Red Teaming is not for finance only) to switch to this realistic mode in the Circ. 20/750 –chap. 3.4.6:

“For instance, financial institutions may perform gap analysis against information security standards, compliance reviews, internal and external audits of the information systems, or physical security reviews. Furthermore, the institution should consider good practices such as source code reviews, vulnerability assessments, penetration tests and red team exercises”

Ref. :

Entering the Game

Based on this, we can define the main Red Team exercise phases as following – since we focus on the technical part we voluntary skipped the “closure phase”:

Overview and Preparation Phase (TIBER-EU 7)

During this phase role and responsibility for the “white team” and the “red team” will be clearly defined to avoid any misunderstanding and contact information will be exchanged to permits a perfect communication during the mission.
The second phase is to define both flags – that should not be focused on the IT part – and the rules of engagement, in our case it could be defined (example) as follows:

Rules of engagement: 

  • A large-scale phishing campaign is forbidden, the test will be executed under control but in a realistic mode;

  • Social engineering is limited:

    • No social engineering against the company employees to have direct access to the network or data as, e.g., auditor or new employee is forbidden;

    • It is forbidden to manipulate people in a way to directly obtain the “flag” (ex: “can you open this door please?” to access a specific office containing flag, etc…);

    • However social engineering to access the building itself is allowed of course;

  • Each flag is considered to have been reached if the goal is achieved without detection (physical or logical);

Objectives to reach (aka “flags”):

  • Flag 1: I.T security related objective
    • Obtain “Enterprise Admin” privileges within the corporate network;
  • Flag 2: Business related objective
    • Obtain and exfiltrated a structured list of clients with personal data;
  • Flag 3: Complete scenario:
    • Identify the members of the Board of Directors;
    • Identify the location of their office;
    • Enter the office;
    • Access and/or exfiltrate a confidential document;
  • Flag 4: Complete scenario
    • Enter the main data centre;
    • Enter the area of the racks with servers;
    • Drop malicious device to prove persistence capabilities and to access data within the infrastructure without being detected.

Once all these steps have been defined, an “out of the jail” letter is signed by both Red Team manager and customer in order to ensure that in case of being caught, Red Teamers are well covered by a legal document.

This document should be brought for each on-site operation to avoid issue and is structured as following:

Once all documents have been signed, rules of engagement defined, objectives agreed by both part and the roles and responsibilities are clearly defined, the exercise can begin according to the pre-defined conditions.

Threat intelligence and scenarios definition (TIBER-EU 8)

Once the exercise starts, we first need to identify the real attack surface through information on the geopolitical and criminal threats to the key institutions in the targeted sector.

This entails a description of their motives/modus operandi, and the tactics, techniques and procedures (TTP) they use to attack.

The ongoing campaigns and incidents demonstrate that the main motivation is still money.

For example, in Luxembourg the major incidents were divided in several parts such as:

  • Physical attack (explosives against the Bancomats all around the country and internal threat);
  • Phishing campaign targeting users in order to obtain sensitive information;
  • Internal threat-based breach;
  • Human-operated ransomware campaign using phishing as initial attack vector (ex: Ryuk – full analysis).

After identifying the main threat, Red Team operators started the OSINT and reconnaissance phases.

These steps combined to real-life risks will permits to develop representatives’ scenarios to execute in the next phases covering the major risk exposure for the CLIENT infrastructure bringing a real high added value.

The last of this part phase consists to define the available scenarios the Red Team will use in order to accomplish the mission and to valid each flag defined previously using the most valuable approach because, you know, we love challenges ?.

Red Team execution (TIBER-EU 9.0)

HERE WE GO! Fun is starting here!

Here is the short list of the scenario we planned to use to pwn our target and that will be detailed through our “Analysis of a Red-Team Exercise” series.

Scenario 1: The USB dropping approach

The USB dropping scenario was previously defined based on the fact that the parking is open to public and USB dropping is a commonly used attack vector.

It allows to test the security and hardening of used laptops but also the security awareness of employees themselves and the policies in case such incident occurs and is reported to the IT security department.

In order to perform a successful USB dropping attack, we had to make it legitimate for the client’s employees, thus several steps were required:

  • A realistic attack scenario;
  • An undetected proxy-aware payload for AV/EDR/AMSI evasion etc…;
  • Automatic persistence mechanism;
  • A fake web site due to what we planned to do;
  • A way to trick employees in order to make them click on a link and execute our dropper.

Scenario 2: Raspberry device addition

A raspberry device including a 4G modem connected allowing to remotely control the device without requiring being in proximity for operation, this one will be plugged on a ground floor office.

This scenario was developed due to our initial physical reconnaissance with the objective being order to gain an access to the network.

Scenario 3: Targeted phishing campaign (simulated)

Phishing campaign were excluded from this exercise as defined in the pre-engagement part.

However, since this attack vector represent a large entry point that is actively exploited in the wild, POST Red Team recommended to, at minimum, simulate a successfully executed campaign in order to assess the whole chain and to cover the risk in the best ways and bring more added value to this exercise by challenging:

  • E-mail gateway filtering effectiveness;
  • Capability for an attacker to perform code execution on a standard workstation (hardening);
  • AV/EDR solution limits;
  • Capability for the executed malicious code to connect to internet through the web gateway policies (proxy);
  • Alerting and in case of alert, reactions and processes in place – incident response;
  • Risk exposure for CLIENT being compromise from this attack vector.

Scenario 4: Physical intrusion on Head Quarters

During the reconnaissance phase, several ways to access our defined objectives were identified.

Based on that we started to prepare through several short intrusions in order to obtain several information:

  • Check camera coverage;
  • Brand of their badge reader system and type of card they used;
  • Types of locks and doors used (can it be lock-picked easily? Can we open this door with a slammed door tool?);
  • Analysis of the building configuration and its potential weaknesses. Since a badge is required to access the upper floors, are there access points that allow access to a specific floor without having to go through several doors?
  • Preferred hours for intrusion specifically because of the COVID-19 situation that perturbate a bit people behaviour.

All this information is important because it allows us to anticipate the tools to be prepared when the day of the physical intrusion phase will come.

End of the teasing

This first chapter ends here now but stay tuned: since you now have all the info to understand what/why we used this or these techniques, the incoming chapters will describe each technical step we used to accomplish the tasks and reach the different objectives!

We hope that you will enjoy this write-up series, see you on Chapter 2:

Scenario 1: The USB dropping approach

Our experts answer your questions

Do you have any questions about an article? Do you need help solving your IT issues?

Other articles in the category Cybersecurity

DDoS attacks in Luxembourg in 2024

Discover the statistics of DDoS attacks detected in Luxembourg in 2024 by POST Cyberforce.

Read this article

Published on

01 February 2024

Preventing DDoS attacks by blocking illegitimate traffic

The number of so-called Denial of Service (DDoS) attacks in Luxembourg is increasing month after month. Cybercriminals are hijacking connected devices to send illegitimate traffic to organisations and saturate connections. These attacks have the effect of degrading the level of service or paralysing the business. To help Luxembourg businesses protect themselves against these attacks, POST has solutions for blocking illegitimate traffic (in real time if needed) before it reaches the organisation's systems.

Read this article

Published on

19 December 2023

DDoS attacks in Luxembourg in 2023

Discover the statistics of DDoS attacks detected in Luxembourg in 2023 by POST Cyberforce.

Read this article

Published on

15 February 2023