🆕 The new HTB Certified Offensive AI Expert (HTB COAE) is officially here! Learn More

Threat Planning and Reconnaissance

This module covers the planning and reconnaissance that precede a red team engagement, exploring how operators decide which adversary to emulate and how they gather information about a target while remaining undetected. That includes selecting relevant threat actors through cyber threat intelligence, identifying their tactics, techniques, and procedures (TTPs), and building threat profiles and emulation plans. Also discussed are passive and active reconnaissance techniques across domains, networks, web applications, and people, with a consistent focus on the operational security (OPSEC) required to gather information quietly.

Created by bmdyy

Hard Offensive

Summary

Effective adversary emulation begins long before the first packet is sent. It starts with deciding which threat actor to emulate, understanding how they operate, and quietly gathering the information needed to act like them. As organizations mature their defenses, the ability to plan a realistic engagement and conduct reconnaissance without being detected is what separates a convincing emulation from a noisy one.

This module covers:

  • Introduction to Threat Planning: What is adversary emulation, and how does it differ from adversary simulation?
  • Threat Landscape: What kinds of threat actors exist, and what motivates them?
  • Fundamentals of Cyber Threat Intelligence: What is CTI, and how is it used to select a relevant adversary?
  • Identifying TTPs: How do we gather and map a threat actor's tactics, techniques, and procedures?
  • Profiles and Plans: How are threat profiles, attack scenarios, and emulation plans built and used?
  • Reconnaissance for Red Teamers: What information do adversaries gather, and why does OPSEC matter?
  • Domains and Certificates: How can domain, DNS, and certificate data be enumerated quietly?
  • Machines and Network: How do we profile hosts and services without being detected?
  • Web Applications: How is an application's attack surface mapped while avoiding defensive controls?
  • People and Organizations: How is people- and organization-specific intelligence gathered and validated?

This module is broken into sections, each with accompanying hands-on exercises to practice the tactics and techniques we cover. The module ends with a practical hands-on skills assessment to gauge your understanding of the various topic areas.

You can start and stop the module at any time and pick up where you left off. There is no time limit or "grading", but you must complete all of the exercises and the skills assessment to receive the maximum number of cubes and have this module marked as complete in any paths you have chosen.

As you work through the module, you will see example commands and command output for the various topics introduced. It is worth reproducing as many of these examples as possible to reinforce further the concepts presented in each section.

It is recommended (and assumed) that students taking this module are familiar with the techniques taught in the following related modules:

Introduction to Threat Planning

In the previous module (Red Team Mindset), we learned that red teams emulate the tactics, techniques, and procedures (TTPs) of real-world threat actors against target organizations in order to test their detection and response capabilities. This leads us to the question: How do red team operators decide which threat actors/TTPs to emulate?

Adversary Simulation vs. Adversary Emulation

There are two main styles of red teaming: adversary simulation (aka. "classic red teaming"), and adversary emulation. One is not better than the other, rather, they are different approaches to slightly different questions:

  • Adversary simulation defines an objective and lets the red team decide how to reach it. From the organization's perspective, an example scenario would be: "Could a motivated adversary gain access to our SWIFT transaction terminal?".
  • Adversary emulation selects a specific adversary and requires the red team to mimic their observed behavior. An example scenario here could be: "If APT38 attacked us, could we detect them and respond effectively?"

Note: These two terms are used inconsistently throughout the industry. For this module, as well as those that follow, we will stick to the convention above.

Most red team engagements are structured as adversary simulations, but it is important to understand both approaches, as adversary emulation is becoming more common. Under the EU's Digital Operational Resilience Act (DORA), for example, significant financial entities identified by authorities must undergo threat-led penetration testing (TLPT) every three years, following frameworks such as TIBER-EU.

Threat Planning Process

In the previous module, the concept of a threat profile was introduced, albeit briefly. As a refresher, a threat profile describes the adversary the red team should play the part of, including a description of its objectives, motivation, and capabilities. Both simulations and emulations require threat profiles, but the way they are built differs.

Adversary Simulation

On a classic red team engagement, the red and white teams collaborate to develop a threat profile that describes the type of adversary to be simulated.

A key part of this is developing clear objectives for the red team. Reaching domain admin is a common suggestion, but it is not a great one. Consider the true motives of an adversary: their end goal might be to steal credit card data, so that they can sell it online. Reaching domain admin may be a step they take along the way, but it is not always required. A better objective would be: "demonstrate access to our internal database which contains credit card data".

In this case, the threat profile is more like "guidance". It does not tell the red team exactly what to do, but how to act. For example, a red team operating under a "typical ransomware group" profile should not spend months hunting a zero-day RCE in Google Chrome, as this is typically not how such groups operate.

Adversary Emulation

On an adversary emulation engagement, there is much more research going on beforehand, as the point is to emulate a specific threat actor. The process looks more like this:

  1. Gather cyber threat intelligence specific to the target organization.
  2. Select a relevant threat actor who poses an identified risk to the organization.
  3. Identify and understand the TTPs of the chosen threat actor.
  4. Develop a threat profile, attack scenario(s), and emulation plan from those TTPs, mimicking the chosen threat actor as closely as possible.

The resulting threat profile, scenarios, and emulation plan are rigid, specifying in detail what the red team should do. An important note is that red teams are often not the ones doing most of this planning. On TLPTs under TIBER-EU, for instance, the threat intelligence and red teaming phases are performed by separate providers. In such cases, the red team provider receives a Targeted Threat Intelligence Report from the threat intelligence provider, describing the exact threat actor to emulate, as well as multiple attack scenarios.

In the next few sections, we will focus primarily on understanding the adversary emulation process, including gathering cyber threat intelligence, and identifying TTPs. Following that, we will look at developing threat profiles for both styles.

For the following questions, answer with "adversary emulation", "adversary simulation", or "not enough information", depending on the type of red teaming being described.

Sign Up / Log In to Unlock the Module

Please Sign Up or Log In to unlock the module and access the rest of the sections.

Sections