Introduction to Red Team
Red Teaming comes under the level of assessment in the information security domain. Red Teamers have to identify the risk to the network infrastructure of an organisation as a measure of pre-evaluation so that the execution of engagement can be carried properly. In order to determine such risks, it is the primary responsibility of Red Team operators to recognise potential threats or vulnerability. Various tools, whether open-source or commercial, can be used by Red Teamers to acknowledge vulnerabilities and to exploit them to their advantage. However, the Red Teaming approach is more in-depth than what most potential attackers follow because they are attempting to find a single vulnerability, whereas security professionals need to find all possible vulnerabilities for a given infrastructure in order to assess the associated risk. Attackers typically only target a single vulnerability for a specific exploit because to do otherwise would increase the possibility for detection. Nevertheless, Red Teaming should test for all types of attacks to provide a complete security assessment. Appropriate situational awareness of security infrastructure is a result of detailed Red Team research. But the process of Red Team will not be sufficient in identifying risk; the organization should continue maintaining the security measures from their end in order to appropriately manage risk and provide security protection.
What is the Red Team?
Red Team is a group of highly skilled pentesters that are summoned by an organization to test their defence and improve its effectiveness. Basically, it is the way of utilizing strategies, systems, and methodology to simulate real-world scenarios so as to prepare and measure the security defences of the organisation. The objective of the Red Team is to simulate the real-world attacks in order to measure the organization’s defences and their incident response Team. Red Team follows the Roles of Engagement (RoE).
What are the aspects of the Red Team?
Threat Emulation: This is the process of mimicking the TTP’s of a specific threat. Emulation can be done of various attacks such as – zero attacks, script kiddie to the advanced adversary or a specific threat like botnets, ransomware, DDOS, etc. No matter what the scenario, the TTP outline by the scenario drive the rules a Red Team must follow to perform an engagement. When creating the threat emulation scenario, that threat’s key component should be defined. When in Practice it can be difficult to simulate the real-world scenario in an exact manner. Therefore, the main focus of the Red Team is should be on the key component and then use their own TTP to fill in the gaps. The biggest challenge in threat emulation is simulating the threat to a level where an analyst believes the threat is real, Approaches range from using real malware to developing custom malware that models a real threat, to using tools that generate the indicators of compromise (IOCs) an attack from a real threat leaves behind. In any case, effective planning and determination of the critical components of a threat will lead to better threat emulation design.
Operational Impacts: Operational Impacts are actions or effects performed against a target designed to demonstrate physical, informational or operational weaknesses in security. These effects can be as general as performing a denial of service attack or more specific such as using high jacked ICS equipment to control a city’s power grid. It is operational impacts that distinguish Red Teamer from others. Operational Impacts can be very effective in demonstrating realistic impacts against a target. The level of depth and of the impact can be as ‘painful’ as an organization is willing to explore. These impacts are typically performed against live production systems to have the highest level of fidelity but can be executed on test and development environments if they are representative systems.
Comparing Red Team Engagement to other security testing types
Difference b/w Pentesting and Red Team: Pentesting is used to monitor control and identify vulnerability in order to secure them along with testing the efficiency of the vulnerability management process. It further helps to lay the foundation for security policies. Basically, Pentesting is testing the security environment of infrastructure in order to find and patch vulnerabilities in a limited span of time, so that we can eliminate the false positive scenarios. In comparison to Red Team, Pentesting is the most rigorous and methodical testing of a network, hardware or application. During Pentesting, the pentesters search for vulnerabilities, analysis them and exploit them. Penetration tests are well defined and usually takes up to one to two weeks for the whole process.
Red Team includes tactics, techniques and procedures (TTPs) by adversaries. Red -Team is just like Pentesting in many ways but it is more targeted. A Red-Team overall accesses and evaluates various areas of security through a multi-layered approach. The mission is to present real-world scenarios and hard facts in an attempt to improve the company’s response. Every area of security defines how the target will respond or how it is accessed. It follows the concept of defence in depth; therefore, the target must be tested on each layer. The goal of the Red Team is to not find as many vulnerabilities as possible but to test the detection and response capabilities of infrastructure along with their security environment.
Difference b/w Read Team and Vulnerability Assessment: Vulnerability assessment is the process of analysing of a system that focuses on finding the vulnerability and prioritizing them by risk. Validation or exploitation of a vulnerability is not performed during while vulnerability assessment. When compared to Red Team engagement vulnerability assessment doesn’t take priority. A Red Team may not use any vulnerabilities. They may generate an operational impact that any insider can perform to test the response of an insider attack. Red Teams rarely if ever run common vulnerability assessment tools as they are loud and generate more traffic than a typical Red Team engagement is willing to accept.
Difference b/w Red Team and Blue Team: Red Teams are the attackers whereas Blue Teams are the defenders. Red Team members are adept at all forms of digital attack, as well as social engineering and other methods to find ways to break into the systems of a company – but they are bound by employment agreements or legal contracts to not disclose what they find to anyone but the company that is being tested. While Team almost always works as employees of the company that is undergoing the testing, and are usually members of the IT Security or Data Security divisions of the company’s IT group. Blue Teams have two major areas of operations. Their only focus is to find the vulnerability and patch them as it seems fit. They can also keep providing security during the Red Team engagement.
Red Team operator traits
An effective Red Team is comprised of a team of individuals who can contribute the overall success. Diversity is crucial, but the Team as a whole must be comprised of the core operator traits. A Team can be even more successful when multiple Team members contribute in multiple areas.
Core Operator Traits :
Red Teams are given opportunities to touch and manipulate target networks in ways typically only done by real threats. Full-scale Red Team operations can allow Red Team operators to really put on their bad guy hats, engagement can be very intellectually stimulating and enjoyable for an operator, but operators must respect target organizations. A great deal of trust is placed on an operator. It is common for a Red Team to position themselves to do serious damage or embarrassment to an organization. And with all this, each Red Team operator should comply the following:
Why do we need Red Team?
To challenge the extend of an organisation’s defences so that when and if a real attack happens then they stay protected or come up with a counter measure. For example, a group of hackers has a goal of stealing critical data from a target. A targeted phishing attack tests the end user’s awareness of the attack. The payload of the attack tests the network and host defences against delivery of malware and ultimately code execution, If the attack does trigger a defence, the response tests the defender’s actions in identifying, responding or stopping the attack. In any case, the entire scope of security defence is analysed. A highly skilled Red Teamer can tune their attacks to identify where the failure points are by turning up or down that ‘volume’ of an attack.
Red Teams are able to execute custom threat as part of their engagement. It can test a subset of security of new threat type or validate the effectiveness of security controls against a new or specific threat types. Threat emulation scenarios are a valuable distinguisher of Red Teaming from other types of security assessments and can be used to understand how an organization stands up to new zero-day attack.
Working of Red Teamers?
Red Team tactics contains a full scope, multi layered diverse attacks to simulate real world attacks to measure the security alignments that are applied. Assessments of Red Team starts with reconnaissance to collect as much information as possible about the target in order to determine the way best way possible to exploit it. This collecting of information also helps to build attacking environment and selection of tools. Most of the working of Red Team is on offensive side rather than defensive. Once the remote access to exploited system is managed and stabilised, the actual attacking takes action.
What is the specialization of Red Teamer?
Red Teamers must understand and be an expert in a diverse set of technologies such as :
Red Teaming Operations Modules
Methodology of Red Team
What are the Pre-Engagement Data Requirements?
The pre-engagement data requirements are :
What is a Red Team Standard Attack Platform?
A standard attack platform is the common set of tools and hardware used by a Red Team to perform an engagement. The term standard is critical. Using a standard platform allows for:
What are Red Team engagement roles and responsibility?
White Cell : A white cell basically enforces the rules of the engagement to ensure neither Red Team nor defender activities cause unexpected alerts or problems on the target environment. It helps to co-ordinate activities to ensure engagement goals.
Engagement Control Group : It represents the management of target environment as well as provides required information that is necessary for constructing valid scenarios. Also, it helps to establish blacklist if its needed.
Physical Access Team : The sole purpose of Physical Access Team in Red Team is to enter gates, buildings, offices, server rooms, etc. along with demonstrate physical access to systems and network in order to gain access to devices or anything desirable.
General Guidelines for Red Teaming :
How to handle client data?
Client data should be handled with extreme care. The information collected during an engagement can be misused if fallen in wrong hands.
The ROE should identify permissions for Authorization :
Policy Controls :
It is implemented by the Red Team and it includes :
Physical Controls :
There should be multi-layer of physical controls applied to protect the engagement tools and operating system from any kind of loss. Therefore, Red Teamers should be accustomed with physical controls that are in place. Such security mechanisms include :
Software Controls :
The following software controls are designed to ensure the confidentiality, anonymity and safety of information should always be employed in whatever context :
Common repository :
Data collection is the core of every engagement. Data collection is directly proportionate to the success of engagement. in other words, the collection of data drives the value of the engagement. Data collection should be complete with the enabling of replication of activities and results. It should also help you to identify the items of significant interest to the operators. Final Data sets should include :
Execution data requirements
Under this, the Team has to make sure that all data that is being handled is safely logged. All activities related to Red Team operations should be logged as the engagement begins and only terminates after all the activity related to the engagement is completed. The events that should be logged are :
As stated earlier, all the activity should be logged accurately and concisely. at the very least, the following information must be collected and logged for each action performed :
Also, when creating log entries, documenting actions, uploading/downloading files, dropping binaries, etc. It is recommended to document this in the YYYYMMDDHHMM_IPDescription format.
Automated Data Collection
Where ever the chance, the Team should use tools and scripts available to capture and consolidate engagement data. Data collected by automated tools will never be enough for Red Team. However, if employed properly, complements the Red Team workflow and enables the operator to continue operations with the manual capture of data pertinent to the activity performed.
All Red Teams engagement systems should have automated collection of raw terminal data. Each command should be prefixed with operator’s IP and UTC timestamp. It is more important that data is accurately captured rather than being captured in a novel way.
Most tools used for Red Team have some level of logging the activities, but the location of logs that will be maintained is different depending on the tool and many of them requires for the operator to trigger log generation. In any case it is quite handy to use commercial tools.
Daily transfer of these logs to the engagement repository is recommended. Preference should be to create a backup script that copies each set of logs to the repository when executed at the end of the day.
Details concerning Red Team actions are often met with disbelief. Even when the Team has undeniable evidence of access to a highly restrictive network or physical area, target personnel sometimes have issues conceding access was obtained. And so, provide the proof whenever required.
What is Red Team Engagement flow?
The Red Team engagement flow is a dynamic process but can be managed through distinct steps. the flow of Red Team includes
Engagement planning starts when first contacted by the customer and realistically doesn’t end until the day of execution. Engagement determines the objectives of the working of the Team. Engagement planning includes :
Rules of Engagement : The rule of Engagement establishes the responsibility, relationship and guidelines between the Red Team, the customer and the system owner. This Rules of Engagement drives the whole process of execution. Rules of Engagement includes :
The Rule of Engagement document consist of Red Team methodology with detailed description of activities and execution process along specification of the hardware and software to be employed. It also includes deconfliction process with the mention of threats available and their comparison. It also must include identification and references to appropriate legal requirements along with the legal responsibility disclaimer. Task of each Red Teamer must also be documented along with the whole information of the target. This information of the target has organization name, address, specific groups or divisions, organizational identifiers, senior management contact info.
Pre-coordination is the base of successful engagement. To construct an effective plan, the Red Team must understand the target environment, all stakeholders, and any addition legal and contractual requirements of the target environment.
Management Risk : It is a process of identifying, accessing and controlling that risk that comes from the engagement factors. The main aim of managing risk to remove unnecessary risks instead of eliminating all of them, along with implementing efforts that are outlined in ROE without causing any irreversible damage to target environment. It is the responsibility of Red Team to implement risk management and accepting all the risks at an initial stage. Risk Management is important to Red Team engagement as it helps to conserve resources, avoid unwarranted risk, making alternative decision when required and taking effective control measures. The Risk management process includes :
Risk Evaluation under Management Risk
Evaluation is often visualized by constructing a Risk Assessment Matrix. This matrix is commonly used to estimate the degree of severity and probability for each potential vulnerability.
Standard 3×3 Vulnerability Risk Matrix Example:
Probability: The likeliness that an event will occur
Impact: is the expected result of an event (degree of injury, property damage or other mission impairing factors) measure as:
Standard 5×4 Vulnerability Risk Matrix Example:
Probability: The possibility of occurrence of an event
Severity: is the expected result of an event (degree of injury, property damage or other mission impairing factors) measure as:
The key in the above matrix construct is vulnerability; however, Red Teaming is not vulnerability focused. Given that thought process, the Red Team’s alternative risk matrix should be constructed to determine the risk of potential threat actions.
It is a major factor in Red Teaming engagement. In this stage following information is obtained from the customer and OSINT:
The realism of threat must be taken under consideration by the Red Team. It is the job of Red Team to select attack types and strategies to simulate realistic threats even if the organization decide not to unleash the full capabilities of the threat. Defining threat-based attacks will provide a viable mechanism for training the target audience and strengthening the target environment. In order to outline the initial list of attacks the Red Team to carefully weigh the different options in regard to the engagement.
The end goal of threat planning is to portray the threat as real as possible in order to protect the organization from the real attack.
De-confliction allows Red Team to clearly identify which activity is to be and not be generated by them. The said activity includes both network and physical activities. In this stage of engagement is to be able to distinguish between Red Team activity and real-world attack as quickly and as correctly as possible. deconfliction process includes :
When the De-confliction is requested it is the duty of the Red Team lead to assess the information and isolate the information from Red Team activity. This includes:
The engagement planning process should include the estimate amount of time required to properly execute the De confliction process and when to use it.
Free play is an excellent concept to greatly enhance the results of A Red Team engagement. This concept allows the time to deviate from plan in order to explore for interesting operations. A Red Team lead can always provide guidance to freely explore as time allows them to.
Halting an engagement simply means pausing current actions for a certain span of time. It is important to decide and plan the conditions where a pause is required. In following conditions, a HALT is required:
A SITREP (Situation Report) is generally performed by Red Team lead. It is to be maintained at all times. And it should contain the following information:
Detailed methodology of Red Team
How to End the Red Team Engagement?
After the execution of engagement is done, it is very important to systematically end the Red Team Engagement. Some of the important things to remember when ending the Red Team engagement are reverting modifications, executive out brief and tech on tech sessions.
Once the execution of Red Team is done with, all the tools, artefacts, exploits and persistence mechanisms should be auto destroyed by a self-destruct code written as both time-based and target-based; for it to be able to prevent execution outside the engagement window or to prevent exploitation outside the target environment. And for all the things that could be self-destroyed, it is the responsibility of Red Team to essentially remove it from the environment.
In the event that target system security controls were disabled:
In the event that target system modifications were made:
For all restoration actions:
Executive out brief is a meeting dedicated towards impact of Red Team engagement on the organization and how to protect it. In this meeting, Red Team lead has to highlight critical observations made during the engagement along with additional information security or technical staff. Legal staff and critical system information’s can also be included with the observation of ‘where the organization is vulnerable’.
A tech on tech briefing can be extremely valuable to the organization as it provides bi-directional exchange of information between Red Team and blue Team. During this exchange, both the Red and defensive elements provide a highly detailed step-by-step technical review of the actions and results (including all associated detail) of the engagement.
The role of Red Team during tech-on-tech:
The role of Defensive Team tech-on-tech:
Reporting is a critical aspect of Red Team Engagement. Reports are major form of evidence that can be analysed and used to provide a base for improving security. Reports are important as they confirm the existence of engagement. Reports not only document the activity that occurred during a specific engagement, but provide an excellent reference that can be used to plan and design other engagements. Many engagements can share similar approaches and goals. Reports can provide a roadmap to design and plan future engagements. Reporting a Red Team engagement can be quite different than reports generated in penetration tests or vulnerability assessments. Red Team engagements are highly scenario focused. This leads to a report that is story driven. Penetration testing or vulnerability assessment reports focus on findings. security tests. Rather than discover that an out-of-date patch can cause successful exploitation of a workstation, a Red Team may use the exploit to deploy a command and control agent. This agent can be used to explore an organization and ultimately steal proprietary organizational data. The Red Team is driven by goals intended to stimulate or measure not only technical flaws but security operations as a whole. This includes people, processes, and technology. A Red Team report will use a story-based format where observations instead of findings are listed.
Report includes various perspectives such as attack narrative. The Attack Narrative section of the report contains the observations made during a Red Team engagement. These are typically written in a chronological format. Key observations that a Red Team uses to achieve goals must be documented. This includes any step Red Team takes to achieve a goal. Threat profiles or other lOCs that Blue can use during post analysis should be included. The end of a Red Team engagement is can be the beginning of post forensic analysis. Blue Teams who take advantage Red Team lOCs by performing post analysis can use this information to find blind spots or tune security tools to better protect against threats.
Types of observation that should be documented:
Key actions that led from initial access to the final goal
An observation should include the following elements