Red Teaming is the process of using tactics, techniques and procedures (TTPs) to emulate a real-world threat, with the goal of measuring the effectiveness of the people, processes and technologies used to defend an environment.
Red Teaming is a process to emulate real word attack scenario to find out how effective the defence capabilities of an organisation are.
PoLP
The principle that a security architecture should be designed so that each entity is granted the minimum system resources and authorisations that the entity needs to perform its function.
Opsec
It’s generally used to describe the “ease” by which actions can be observed by “enemy(blue teamers)” intelligence. Both red and blue teams should assume that their actions are being monitored and disrupted by the opposite side. Wise operators would also assume that the team they’re up against are better than them.
Primum non nocere
Nobody should set out to do something that will cause predictable and preventable harm.For instance, we would not actually ransomware an entire organisation just because that’s what an adversary might do.
Engagement Planning
Scoping
A red team does not set out to carry out a review of every host but seeks to reach a particular objective.
Threat model
Identify the threats
- Script Kiddie
- Hacktivist
- APT groups
Once a threat has been identified, the red team must build a corresponding threat profile.
This profile defines how the team will emulate this threat by identifying its intent, motivations, capabilities, habits, TTPs and so on.
Breach Model
The breach model outlines the means by which the red team will gain access to the target environment.
This is usually by attempting to gain access in accordance with the threat (for example through OSINT and phishing); or provided by the organisation (often called “assume breach” or “ceded access”).
A compromise could be to fall-back to an assume breach model if the red team haven’t gained access within the first 25% of engagement timeframe.
Notifications & Announcements
Ultimately, the “correct” decision should come down to the existing culture and relationships within the organisation.
Rules of Engagement (RoE)
The Rules of Engagement (RoE) document defines the rules and methodologies against which the engagement will be conducted; and should be agreed and signed by all parties. The RoE should:
- Define the engagement objectives.
- Define the target(s) of the engagement, including domains and IP ranges.
- Identify any legal or regulatory requirements and/or restrictions.
- Contain emergency contact lists for key persons in all parties.
Any changes made to the RoE should also be agreed and signed by all relevant parties.
Record Keeping & Deconfliction
Throughout the engagement, the red team members should maintain records of their activity.
Tools used externally from the frameworks like Cobaltstrike that need to be recorded separately as they are not logged. Where feasible, record details of the dates and times tools are executed within the target environment.
Data Handling
Red teams may come across privileged or sensitive data such as personal, medical, financial. Where possible, avoid viewing this data unless it’s part of the agreed scope and objective; and never impact the confidentiality, integrity or availability of data.
Duration
The duration of an engagement should only be determined after the scope and objectives have been agreed. This allows you to provide an estimate based on the actual work that’s been agreed. Most engagements will require at least 4 weeks depending on size and complexity.
Costs
A team should have at least two members, and always at least one lead. The number of team members should be a reflection of the size of the engagement and the timeframe it should be completed in. Four members (three operators and one lead) is an average team size. If it’s required that the team travel (for instance, if they need to come on-site to emulate an insider threat), then those and other incidental costs should be accounted for.
Most red teams use commercial tools to help carry out their engagements. Cobalt Strike’s licence model is per-operator, so if a large team is required to complete the engagement in the agreed timeframe, additional licenses may be needed. Red teams may also need to acquire specialised or ad-hoc software, specific to the engagement.
Many red teams use public cloud to run part of their disposable infrastructure. They may also wish to purchase domain names for use in a phishing campaign or C2 traffic. The Team Server should be run on-premises of the red teaming company so the costs of running and maintaining that infrastructure should also be included.
It’s easy to forget factoring in the cost of activities that come prior to and after an engagement. That includes this whole planning process, pre-engagement meetings, threat profiling, research, tool customisations, infrastructure setup and so on. Post-engagement wash-up meetings and other follow-up meetings should also be considered.
Post-engagement and Reporting
The issues identified during a red team engagement are much more holistic and systemic, and therefore much harder to address than simply installing patches. Given that these engagements are scenario-based, it leads to a report style that is much more “story-focused”.
Attack Narrative
An attack narrative should contain the observations made during the engagement, in chronological order.
Indicators of Compromise
Red teams may also provide other useful indicators of compromise (IoC) that don’t necessarily fit into the observation sections. This is often provided as an annex to the report and can include everything from domain names, IP addresses, artifact filenames, md5 checksums and more. This also helps any deconfliction process at a later date
There is an excellent set of document templates available on https://redteam.guide.