Engagement Planning

Proper Planning and Preparation Prevents […] Poor Performance.

It cannot be overstated how important it is to properly plan a red team engagement - not just for achieving good outcomes, but for ensuring everybody involved is protected. The majority of that planning is the responsibility of the red team leads, and although this course is aimed at operators, it's useful to get an early understanding of that process.

\

Scoping

Don't be constrained by typical "penetration testing scoping" questions, such as the number of hosts or IP ranges in the network. A red team does not set out to carry out a review of every host but seeks to reach a particular objective. The size of the environment may still be relevant (finding a needle in a small haystack is easier than in a large haystack after all), but scoping conversations should be more geared towards building a scenario for the engagement.

\

Threat Model

The role of a red team is to emulate a genuine threat to the organisation. This could be anything from relatively low-skilled and low-motivated "script kiddies", to more capable and organised "hacktivist" groups, or even APTs and nation-states. More mature organisations have an idea of their threats based on past events, threat intel or market reports; whilst others do not. In my experience, the latter default towards APT threats, which is not always realistic. As part of this planning, be prepared to temper or help align their expectations.

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. If it's a known threat, much of this information can be found from various threat intel sources. If it's a generic threat, the red team may construct a profile that reflects the typical capabilities of that type of threat.

The MITRE ATT&CK is a great source of tactics and techniques.

\

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").

There are pros and cons for each approach depending on the objective(s) of the assessment.

If assume breach is not chosen and the red team attempt to gain access, it's important to have a back-up plan in the event access is not gained within a predetermined time period. 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. This is critical because red team assessments are more about detection and response, rather than prevention, so those portions of the assessment are more important than trying to "prove" a breach can happen in the first place.

\

Notifications & Announcements

These types of assessments are often arranged by upper management in security or compliance roles, and they face a choice as to whether they inform the rest, or part of the organisation about an upcoming engagement. They may elect to tell nobody, everybody, or just the relevant security/support teams.

Not providing any notification allows everybody to react as they would on any given day and will lead to the most authentic outcomes. However, security teams may feel like they're being tested or are not trusted by management, which can lead to bad relationships and negatively impact the outcomes. On the flip side, having prior notification may lead them to be extra vigilant or to (temporarily) increase security measures, which is not an accurate reflection of their every-day security posture.

Ultimately, the "correct" decision should come down to the existing culture and relationships within the organisation.

\

Rules of Engagement

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.

Even though physical red teaming (physically attempting to gain entry to a premise or property) is out of scope of this course, members of those engagements should carry a suitable "get out of jail letter", signed and authorised by the client. In the event the team is caught and apprehended by actual law enforcement, they need to prove they were acting with permission to avoid any prosecution.

\

Record Keeping & Deconfliction

Throughout the engagement, the red team members should maintain records of their activity. In the event an incident occurs now or in the future, the organisation and any supporting Digital Forensics & Incident Response (DFIR) needs to be able to identify whether observed activity is a result of the engagement or not.

Frameworks such as Cobalt Strike maintain a data model and reporting templates of all activity carried out via the client. This includes commands run, target IP addresses and hostnames, payloads generated with their file hash, and more. However, you will often run tools externally from these frameworks that need to be recorded separately. Where feasible, record details of the dates and times tools are executed within the target environment.

The use of terminal auto-logging and screen recording (e.g. record your screen at 1FPS) software can be useful to facilitate this.

\

Data Handling

Red teams must ensure that they adhere to any organisational, regulatory and/or legal requirements for handling data. You will frequently gain access to credential material for the target environment, which must be treated as confidential during and after the engagement. When the engagement is concluded that data should be destroyed by an appropriate means.

Red teams may also 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

When costing an engagement, there are many factors to consider.

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.