Red Teaming

Red Teaming

Another Level of Cybersecurity Testing

Do you feel confident about the cybersecurity of your company? Many people say yes because their company regularly undergoes pentests and security audits of their unit systems and infrastructure. They also say yes because they feel confident that their company constantly works with suppliers to remove vulnerabilities. To that, we’d say: “Well done, BUT…”

It’s great to hear that you’re doing everything that’s recommended, or more importantly, required by law. How then, is it possible that companies that do the same thing still suffer from huge data leaks?

The answer is SIMPLE…

Individual systems can be secured very well. However, there’s always the unpredictable human factor. We can’t be 100% sure that employees won’t accidentally provide attackers with information that could be used to get into the company’s infrastructure. The only way to prevent this is to run regular simulated attacks so that employees can practice their resistance to social engineering tactics such as phishing, and the many other popular methods of today.

After reading the title of this article, you may have said to yourself, “What is RED TEAMING and why haven’t I heard of it?”

Well, it’s a technique that combines information gathering, blackbox penetration testing, and social engineering. The goal is to simulate an attack, exactly how real hackers would do it. Therefore, you don’t test just your system unit, but the whole infrastructure, together, with your own employees. So instead of focusing on finding all of the possible vulnerabilities in all of the systems inside of the network, the red team ninjas’ goal is to sneak in and achieve a defined objective by any means necessary. The objective usually represents something valuable to the customer, and may vary from “Get data from our CRM” to “Gain access to our TEST network”, or even offering some alternative objectives. An added benefit is that your IT Department or IT Security Team can also test if they would be able to detect such an attack. What a way to practice proper procedure, but better yet, with trusted hackers on your side!

To get started, let’s take a look at the main differences between standard penetration testing and Red Teaming:

PENETRATION TEST RED TEAMING
Broad testing - Find as many vulnerabilities as possible In-depth testing - Find the one major vulnerability to get into the system and take full advantage of it to achieve the objective
A short period of time A longer period of time
The goal is to identify the vulnerabilities of a specific area (unit) The goal is to test the resilience of the entire company’s defenses
Clearly defined scope of the project (several systems or applications) The scope of the project is to test the entire company’s security and vulnerabilities to achieve the objective and identify aspects that could be misused
The IT department knows about the testing and closely cooperates with the security/pentesting company The IT department (blue team) has no idea about the ongoing exercise
To test the system unit The goal is to test the IT department’s ability to recognize and defends against any random cybersecurity attack
- To test the employees’ knowledge and capability of resisting the social engineering techniques that are used today
- The company’s physical security is also part of the test
Applications are tested according to the OWASP methodology Is not possible to follow any methodology

This is a game of 3 teams, so who’s involved?

The Red Team - This team is composed of senior ethical hackers whose goal is to infiltrate the company in any way possible.

The Blue Team - This is the team of professional security or infrastructure defenders. They’re usually the client’s system administrators, whose goal is to detect attacks. In order to simulate a real attack, the Blue Team doesn’t have a clue about the planned attack.

The White Team - This is a small group of people from the company who ordered the Red Teaming and who are actually aware of the attack.


So how does it work? Let’s take a deeper look into the individual phases of Red Teaming:


  • Information Gathering (OSINT)
  • The aim of this introductory phase is to gather as much information as possible. The sources are usually publicly available resources (databases, registers, search engines, social networks, etc). To gather this kind of information, we use the Open-source intelligence (OSINT) framework.

  • External Attack of the Infrastructure
  • After the information is gathered, the next phase begins by starting an attack on the infrastructure without any physical access. Black box penetration testing We examine the functionality of the infrastructure without peering into its internal structures or inner workings. The main goal is to get any access to the internal infrastructure (usually by using a compromised server). Social engineering (without the need for physical access) In this phase, we use all of the methods of social engineering, except for physical infiltration techniques (i.e. spear phishing), with specially modified malware that will allow us to get into the internal network.

  • An Infrastructure Attack with Physical Access
  • In this part, we implement various situations in which employees could get caught up. For example, we’ve used the “baiting” attack by which we spread our USB flash drives around the company. In addition to standard USB sticks, we also dispose of so-called “rubber duckies”, which are improved by our firmware.

  • Physical Intrusion (Getting Someone into the Building)
  • In this part, the task is to infiltrate the system by getting a member of the red team into the company. The goal is usually to get into their network, steal sensitive documentation or hack unlocked PCs (the “rubber ducky” tactic). This is one of the fun parts, though the potential results tend to be a bit unclear during the planning stage. As you can imagine, it also requires a great deal of creativity. Luckily, or unluckily rather, there are many ways to infiltrate a company. For example, someone could go in for a job interview, or even pretend that they are a delivery person with mail or other items to be dropped off.

  • Lateral Movements
  • In this case, we’ve already infiltrated the company’s infrastructure by hacking a server, or based on “spear phishing”/”baiting”, we’re able to hack the employee’s desktop. Now the task is to get from the unit server or desktop further to their network and obtain some sensitive data. By obtaining that sensitive information, we have fulfilled our task and at this stage, we inform the white team on how to communicate the steps we took. Usually, our job in the field is over here.

  • Final Report
  • The last stage is where we hand the client a detailed report. The report usually consists of a detailed description of:

    • All of the tactics that we used
    • The paths that we have tried (including the not wrong ones)
    • How we exploited the vulnerabilities
    • Instructions on how to eliminate an individual vulnerability

    We then read out the report with the appropriate organization stakeholders to review each vulnerability identified during the assessment. We answer any questions that the team might have about each vulnerability, and most importantly, we discuss mitigation/remediation strategies.

    To some, this might sound scary, and to others, perhaps a bit thrilling. No matter the case, it’s a good idea to take the next step in protecting yourself and your company. Learn how Citadelo stops breaches, identifies vulnerabilities, and gets your team in a better position to protect what’s important. Contact our Sales Team ([email protected]) to learn more about Citadelo Red teaming services and start planning for your improved security.

    About the author

    Citadelo
    Citadelo
    Citadelo is a firm of ethical hackers on your side. We think like hackers, but we don't abuse it. On the contrary, our main goal is to reveal vulnerabilities without causing damage. We have been conducting simulated attacks for our clients since 2006
    Show more from author

    Related blogs