• Oxford: +44 (0)1865 877830 
  • Manchester: +44 (0)161 713 0176 
  • Edinburgh: +44 (0)131 541 0118 
  • New York: +1 646-781-7580 
  • Minneapolis: +1 612-324-7410 
  • Dubai: +971 (0)4 427 0429

Introduction To Red Teaming

You are here



Introduction To Red Teaming

When a company is in the process of proactively improving security posture, there are various services and standards that comes into help. Performing a penetration test of a production website or a vulnerability assessment of the internal network are valid methods to identify material security issues. Despite the advantages of this approach, organisations are still getting breached daily and sensitive data about users, employees or business partners are sold to competitors or used for identity theft by attackers.

There are a number of questions to which companies concerned about their security should ask themselves: in case of a real attack, what is your capability for a proportional reaction to an intrusion event? What level of penetration will attackers be able to gain with regards to your sensitive data? How long would it take to detect the intrusion?

A red team engagement, unlike a traditional penetration test, aims to simulate a real world attack by expanding the scope of the engagement to include the entire organisation. If the scope of a penetration test is typically defined by the client, and typically involves the test of a production website or a sample of the company network, the scope of a red team is not limited to specific systems. This scope could even involve attacks against the company's employees by launching a phishing campaign or physically trying to gain access to the company's offices in order to plant a backdoor into the network.

An attack simulation is typically structured in different phases which try to mimic as far as possible a real world scenario.

Red Team Phases

The following sections explain the phases of a red team assessment based on a real engagement performed by Dionach.


This is the initial phase of any red team engagement and should be regarded as intelligence-driven reconnaissance. During the reconnaissance phase, the attackers try to get as much information about the company as possible. These includes but not limited to:

  • External websites and systems
  • Employees’ names and roles
  • Organisational structure
  • Email addresses and phone numbers


This information can be retrieved by querying the public internet databases, identifying external systems on Shodan (https://www.shodan.io/) or simply by browsing the company social media profiles and gathering information about employees through open source intelligence techniques. For this phase, during our engagement, we collected the following information which helped us for the next phase:

  • Key personnel: from the company website and LinkedIn profiles, this helped us to reconstruct the organisational structure of the company.
  • Employees' names and email addresses: these were collected by performing search engine queries for email addresses in the format of "@company.com", and by browsing the LinkedIn profile of each employee.
  • Office information and floor plan: knowing the location of the offices, photos can be found on Facebook and floor plans can be retrieved from websites such as Zoopla.


Initial Compromise

This is the phase in which attackers try to get an initial foothold into the company internal network. Nowadays, a very common and effective way of getting access to the target's internal network is through spear phishing. A narrowly targeted spear phishing campaign can be launched against the company's employees and create a convincing scenario based on the information gathered during the reconnaissance phase. In our engagement, a targeted phishing campaign was launched against the company. In this scenario, we masqueraded as a Senior IT System Engineer asking to login to a fake Outlook Web Access portal:

Although the security team identified the phishing attack in progress, one pair of credentials had already been captured. From the information gathering phase, we also knew that the company is using VPN software to facilitate remote logins to within the corporate network. This VPN software required two things to authenticate: valid credentials and a valid 2FA token. We already obtained valid credentials from the previous campaign, therefore we decided to phish the token over the phone. We masqueraded as an employee working from home and unable to work and we asked for the token to be provided over the phone. After a few attempts, the token was eventually provided over the phone and we managed to use Citrix to access the target network.

Having access to the internal mail, we also decided to launch a second phishing campaign. This second scenario involved sending an attachment containing an Office document with a malicious Macro embedded. By default, Office will prompt the user a warning before enabling the macro, but users can be tricked into enabling the content by making the document looks like the following:

The macro will open a reverse connection to our server so that remote access to the internal network could be obtained. The campaign was a success, and we obtained an initial access to the company internal network.

Escalation of Privileges

When a remote machine is compromised, the access obtained is typically with low privileges. As the purpose of a red team engagement is to simulate a real attack, this would probably involve looking for sensitive information. These are typically stored on restricted servers, therefore an attacker would need to find ways to escalate their privileges. In a Windows Active Directory environment, this would mean that ultimately an attacker will try to get access to a Domain Admin account.

In our engagement, we found that one of the users on the machine compromised through phishing was a local administrator on two Windows XP boxes on the domain. This allowed us to dump the memory with ProcDump (a Windows Sysinternals tool) and extract clear-text credentials using Mimikatz, a tool that allows a local administrator to extract both Windows logon clear text credentials and Kerberos tickets from memory, as shown in the example below:

From the memory dump, it was possible to extract the credentials of a domain administrator account.

Persistent Access

Remote access can be removed very quickly after the initial compromise, as systems can be rebooted, or users can logout from their workstations. Persistent access can be achieved in a number of ways, and the optimal strategy for the maintenance of persistent access is to deploy multiple techniques at the same time. For instance, it is possible to plant a physical backdoor into the network which can be then later accessed by whoever is in wireless range. Although the backdoor planted during our engagement was fully working, it was disconnected after some time. Another common technique of getting persistent access that was used during the engagement, is setting up a schedule task on the compromised machine to run at boot and to execute periodically, for example once a day.

Additionally, we attempted to get persistent access to the company's offices by deploying a Wi-Fi backdoor into the internal network. Having already obtained access to the internal network and having an account in Active Directory, we created an invite and booked a meeting room on a specific date. We then arrived at the office, where our meeting was confirmed by checking the electronic calendar at the reception. Once in, we were provided with valid visitor badges and were free to explore the area. When a working network socket was found, we successfully implanted the Wi-Fi backdoor that was reachable from the parking area.

Lateral Movement

During a red team engagement, an attacker would need to jump from one compromised device to another to reconnoitre potential privilege escalation vulnerability or to access sensitive information stored on other systems. During our engagement, we used our level of access to browse the SharePoint server and download a large number of sensitive documents, where we found evidence of a non-routable network.

As the security team did not identify our attack, we could have maintained a presence within the network for a long period of time, even months, and download all the information stored on the secure servers.

Lesson Learned

The ultimate goal of a red team assessment is not to compromise a website or assess the security of the firewall, but rather to evaluate the security of the whole organisation and its readiness to a real world attack. In order to do that, there is an ongoing phase during the assessment in which the red team works closely with the security team (or blue team) to understand if threats are detected on time and how long it took for the blue team to detect each phase illustrated in the blog post. For example, following our engagement, typical points that the blue team should be able to answer are:

Did people react promptly to the phishing campaign?
If a C2 (Command and Control) channel was in use, how long did it take to remove this channel of communication?
Were the privilege escalation attempts noticed?
Was access to restricted servers logged and did it raise any alert?

Based on these points, a blue team will identify the areas that need improvement and define how these areas in order to develop a more robust incident handling and response capability going forward.


Penetration tests, security audits and vulnerability assessments are a great way to evaluate the security of specific systems or networks. However, they can often provide a false sense of security, making organisations believe that they are secure against a targeted attack. A red team engagement has the main goal to simulate a real world attack and evaluate the readiness and response of the blue team before a real attack does actually happen.

Posted by Luca

Leave a comment