What Is Threat-Informed Red Teaming? Building Scenarios from Real Threat Actors

Not every organisation faces the same threats.

A financial institution's attack surface is not the same as an energy company's.

A defence industry company's threat profile is not the same as an e-commerce firm's.

In the same way, attackers' objectives, the methods they use and the systems they prioritise can vary by sector.

Applying the same attack scenario to every organisation in a Red Team operation may therefore not overlap sufficiently with the real threats, however technically comprehensive it is.

The modern approach asks this question:

“How do the threat actors most likely to target us actually behave?”

The answer to that question is produced by cyber threat intelligence.

That intelligence is then fed into the Red Team operation.

This model is called threat-informed Red Teaming.

Threat-informed Red Teaming is an advanced Red Team approach in which attack scenarios are built taking into account the organisation's sector, geography, technology infrastructure and the TTPs of real threat actors.

The aim here is not to use random attack techniques.

The aim is:

to simulate genuine attacker behaviour in a controlled way and measure how prepared the organisation is against it.

What Is Threat-Informed Red Teaming?

Threat-informed Red Teaming is the approach of feeding Red Team operations with cyber threat intelligence, MITRE ATT&CK, threat actor profiling and adversary emulation data.

In a classic Red Team operation the team may use various attack techniques such as;

initial access,

privilege escalation,

lateral movement,

persistence,

command & control.

The choice is largely the team's own.

In the threat-informed model these questions are asked first:

Which threat actors target us?

Which sectors do those actors attack?

Which initial access techniques do they use?

Which malware families are they associated with?

Which persistence methods do they prefer?

Which lateral movement techniques do they use?

Which C2 behaviours are observed?

The Red Team operation then stops being a generic attack simulation.

It becomes an adversary simulation shaped around the organisation's real threat profile.

Why Should Every Red Team Scenario Not Be the Same?

Standardised attack scenarios can be useful for testing particular security controls.

But every organisation's;

business model,

critical assets,

employee profile,

technology infrastructure,

regulations,

geographic location

are different.

In a financial institution, for example;

payment systems,

customer accounts,

Microsoft 365,

Active Directory,

SWIFT-like financial infrastructure

may be high-value targets.

In an energy company, meanwhile;

OT/ICS,

SCADA,

engineering systems,

remote maintenance infrastructure,

the production network

may be more critical.

In a software company;

Git repositories,

the CI/CD pipeline,

cloud IAM,

source code,

secret management

may come to the fore.

Applying the same attack scenario to every organisation may therefore not be realistic.

What Is a Threat Profile?

A threat profile is the model describing the likely attacker types and attack methods an organisation faces.

When building a threat profile, the following can be assessed;

sector,

country,

organisation size,

critical technologies,

business model,

past attacks,

threat intelligence data.

Together they define the likely adversary.

For a finance company, the threat profile may include;

ransomware groups,

financially motivated cyber crime,

credential theft,

business email compromise,

initial access broker activity.

For the defence industry, meanwhile;

APTs,

espionage,

supply chain attacks,

targeted phishing,

credential theft

may take priority.

How Does Threat Actor Profiling Shape the Red Team Scenario?

During threat actor profiling the behaviour of particular attacker groups is examined.

A threat actor's attack chain might look like this:

Reconnaissance

↓

Spear Phishing

↓

Valid Accounts

↓

PowerShell Execution

↓

Credential Access

↓

RDP Lateral Movement

↓

Scheduled Task Persistence

↓

HTTPS Command & Control

This information is extremely valuable to a Red Team.

The team can design the attack scenario around the same behavioural pattern.

The security team is then asked:

“Can you detect this real threat actor's behaviour in your environment?”

What Is Adversary Emulation?

Adversary emulation is the reproduction of a particular threat actor's known behaviour as realistically as possible in a controlled environment.

This approach is more specific than classic attack simulation.

Instead of saying:

“Let us run a phishing scenario.”

the Red Team can take the approach:

“Let us emulate the initial access and post-exploitation behaviour used by the specific threat actor targeting your sector.”

The aim here is not to create an exact copy of the attacker group.

The aim is to test that actor's known TTPs safely and under control.

The Difference Between Adversary Simulation and Adversary Emulation

These two concepts are close but there is a small difference.

Adversary Simulation

Simulates real attacker behaviour in general terms.

Adversary Emulation

Tries to reproduce behaviour closer to a specific threat actor or threat profile.

For example:

“Simulating a ransomware attack”

may be adversary simulation.

Following the known TTPs of a specific ransomware group is closer to adversary emulation.

Why Does MITRE ATT&CK Matter for Threat-Informed Red Teaming?

MITRE ATT&CK provides a common language for threat-informed Red Teaming.

The threat intelligence team can map an attacker group's behaviour to MITRE ATT&CK techniques.

For example:

Initial access: phishing

Execution: command and scripting interpreter

Credential access: OS credential dumping

Lateral movement: remote services

Persistence: scheduled task/job

Command and control: application layer protocol

This information can be turned into the technical scenario of the Red Team operation.

The Blue Team can then measure whether each technique was detected.

How Is MITRE ATT&CK Mapping Used?

The techniques used in a threat-informed Red Team engagement can be marked against ATT&CK.

At the end of the operation a matrix can show;

which techniques were simulated,

which were seen by the EDR,

which turned into SIEM alerts,

which were detected by the SOC.

All of it in one view.

A detection coverage map can then be built for the organisation.

That map shows the security team where it is strong or weak.

What Is Detection Coverage?

Detection coverage is the measurement approach showing how well an organisation can detect particular attacker behaviours.

An organisation may, for example, be;

strong on initial access techniques,

average on credential access techniques,

weak on lateral movement techniques.

The picture is rarely uniform.

This information affects not only technology selection but detection engineering priorities.

Threat-informed Red Teaming allows that coverage to be measured against the real threat profile.

How Is Threat Intelligence Data Turned into a Red Team Scenario?

The first step is to define intelligence requirements.

These questions can be asked for the organisation:

Which threat actors target our sector?

Which TTPs are most commonly seen?

Which critical systems are targeted?

Which attack chains are more likely?

Threat intelligence data is then analysed.

After that the technical scenario is built.

For example:

Threat Intelligence Finding

Certain attackers use targeted phishing in the finance sector.

Red Team Scenario

An authorised spear phishing simulation.

Threat Intelligence Finding

Compromised identities are being used to attempt access to cloud applications.

Red Team Scenario

An identity-based initial access assessment.

Threat Intelligence Finding

Lateral movement over RDP is being observed.

Red Team Scenario

An authorised remote services simulation.

This method turns intelligence directly into a security test.

The Cyber Kill Chain and Threat-Informed Red Teaming

Besides MITRE ATT&CK, the cyber kill chain approach can also be used to describe the attack chain in threat-informed Red Team operations.

An attack can generally be assessed through stages such as;

reconnaissance,

weaponization,

delivery,

exploitation,

installation,

command & control,

actions on objectives.

Each marks a step towards the goal.

In modern Red Teaming, MITRE ATT&CK provides more detailed technical mapping while the cyber kill chain can be used to describe the higher-level attack flow.

The two approaches are not rivals.

They provide visibility at different levels.

Why Do Crown Jewels Matter in Threat-Informed Red Teaming?

A real attacker does not merely try to become Domain Admin.

Their actual aim is to reach a valuable asset.

These assets are called crown jewels.

For example;

the customer database,

the SWIFT system,

the ERP,

the source code repository,

the cloud tenant,

an OT engineering workstation,

the backup infrastructure

can each be a crown jewel.

In a threat-informed Red Team operation the scenario must be designed around these critical assets.

The question asked is:

Using the real attacker's TTPs, can the crown jewels be reached?

A Threat-Informed Red Team Example for the Finance Sector

Threat intelligence analysis at a financial institution may highlight the following risks:

targeted phishing,

credential theft,

MFA abuse,

Microsoft 365 compromise,

lateral movement,

data exfiltration.

In that case the Red Team scenario can be modelled as;

OSINT

↓

Spear Phishing Simulation

↓

Identity Compromise

↓

Internal Discovery

↓

Lateral Movement

↓

Critical Finance Application

This scenario will sit far closer to the organisation's real threat profile.

Threat-Informed Red Teaming for the Energy and OT/ICS Sector

In the energy sector the attack scenario can differ.

Here access to IT systems may not be the final objective on its own.

The attacker's aim may be;

to reach the OT/ICS network,

to target engineering workstations,

to use remote maintenance infrastructure.

The production floor is the real prize.

But Red Team work in OT environments must be carried out far more carefully.

Production safety always comes first.

On critical OT systems, therefore, more controlled methods can be used instead of real exploitation, such as;

simulation,

tabletop exercises,

attack path validation.

Threat-Informed Red Teaming for the Defence Industry

For defence industry organisations one of the most important threats can be cyber espionage.

In that case the attacker's aim may not be to encrypt systems but to reach;

technical documents,

R&D data,

project files,

source code,

design information.

Quietly and without disruption.

The Red Team scenario can therefore focus more on;

targeted reconnaissance,

spear phishing,

credential access,

persistence,

stealthy lateral movement,

data collection.

Threat-Informed Red Teaming in Holding Structures

In holding groups the attack surface can be more complex.

There may be;

different companies,

different domains,

a shared Microsoft 365,

a central Active Directory,

shared finance systems,

supplier connections.

All interlinked.

An attacker may start at a subsidiary and try to progress to the holding centre.

Threat-informed Red Teaming can therefore assess not only a single company but the trust relationships between organisations.

Threat-Informed Supply Chain Scenarios

Threat intelligence may show that certain threat actors use suppliers rather than targeting the main organisation directly.

In that case the Red Team scenario can focus on areas such as;

third-party access,

vendor accounts,

remote support,

B2B applications.

This approach is valuable for supply chain security validation.

The Difference Between a Threat-Led Scenario and a Generic Scenario

A generic Red Team scenario might be:

“Let us start from the internet and try to become Domain Admin.”

A threat-led scenario is more specific:

“Using the observed TTPs of the threat actors targeting the finance sector, is access to the critical payment system possible?”

The second approach is far more meaningful for management.

Because the test has been connected to a real threat model.

What Happens if the Threat Intelligence Is Out of Date?

One of the important risks of threat-informed Red Teaming is stale intelligence.

Threat actor behaviour can change over time.

They may use new malware.

They may adopt a new initial access method.

They may change their C2 infrastructure.

CTI data must therefore be current.

Threat-informed Red Teaming is not a fixed, one-off scenario.

As the threat environment changes, the scenarios must be updated too.

Is IOC-Based Red Teaming Enough?

No.

It is not possible to emulate a threat actor using IOCs alone.

IOCs are technical indicators such as;

IPs,

domains,

hashes.

The attacker can change them easily.

What matters more for a Red Team are TTPs.

Because behaviour shows the attacker's operational method.

In threat-informed Red Teaming, therefore:

IOC → supporting data

TTP → the main scenario input

is the right way to think about it.

Threat-Informed Red Teaming and Detection Engineering

One of the strongest outputs of threat-informed Red Teaming is that it provides direct data to detection engineering.

Suppose the Red Team simulates a particular MITRE ATT&CK technique.

The EDR raises no alert.

The SIEM produces no detection.

The SOC does not see the activity.

A clear detection gap has been found.

The detection engineering team then;

identifies the necessary telemetry,

develops a SIEM rule,

changes the EDR policy,

builds a new correlation.

The Red Team then tests the same technique again.

This cycle is the Purple Team model.

Where Does the Purple Team Sit in Threat-Informed Defense?

Purple teaming is one of the areas where threat-informed defense becomes operational.

The cycle can run like this:

1. CTI identifies the threat

↓

2. The threat actor's TTPs are extracted

↓

3. The Red Team simulates the TTPs

↓

4. The Blue Team tries to detect them

↓

5. The detection gap is identified

↓

6. The Purple Team improves the detection

↓

7. The technique is tested again

This model improves the security defence continuously.

How Does It Work with Threat Hunting?

Threat intelligence is not used only to build future Red Team scenarios.

It can also be used to search past system activity for traces of attack.

Suppose the CTI team identifies that a particular threat actor is using a new TTP.

The threat hunting team can search historical EDR and SIEM telemetry for that behaviour.

This approach answers the question:

“Could this threat already have targeted us?”

Threat-informed Red Teaming then asks the next question:

“If they do target us, will we see it?”

The Difference Between Breach and Attack Simulation and Red Teaming

Breach and attack simulation (BAS) platforms can test security controls automatically.

Particular attack techniques can be simulated on a regular basis.

This approach is useful for continuous security validation.

But it is not the same as Red Teaming.

Red Teaming involves elements such as;

human intelligence,

adaptation,

an objective-driven attack chain,

OSINT,

decision making.

BAS, by contrast, focuses more on repeatable, automated control validation.

The two can be used together.

What Is Continuous Security Validation?

Because the threat environment changes constantly, testing security controls once a year may not be enough.

Continuous security validation aims to test security controls regularly and repeatably.

Within this model;

BAS,

Purple Team,

Red Team,

detection engineering,

threat intelligence

can be used together.

The aim is to move cyber security from being an annual project to a continuously measured process.

How Is a Threat-Informed Red Team Operation Planned?

A professional engagement generally consists of the following stages:

1. Intelligence Requirements

Which threats matter to the organisation is determined.

2. Threat Profiling

Threat actors relevant to the sector and organisation are analysed.

3. TTP Mapping

Behaviours are mapped to MITRE ATT&CK.

4. Crown Jewel Analysis

Critical assets are identified.

5. Attack Scenario Design

A realistic attack chain is built.

6. Rules of Engagement

Safe operational boundaries are defined.

7. Adversary Emulation

The scenario is executed under control.

8. Detection & Response Measurement

Blue Team performance is assessed.

9. Purple Team Improvement

Detection gaps are closed.

10. Retest

The controls are re-verified.

This model turns the results of a Red Team operation directly into security maturity.

Which Metrics Should Be Measured in Threat-Informed Red Teaming?

The metric “was the objective reached?” alone is not enough.

More meaningful measurements are these:

Time to Detect (TTD)

How long did it take for the attacker behaviour to be noticed?

Time to Respond (TTR)

How long did the SOC take to respond?

Attack Path Length

In how many steps was the critical objective reached?

Detection Coverage

How many of the threat actor's TTPs are visible?

Prevention Coverage

How many techniques were blocked by security controls?

Dwell Time

How long could the simulated attacker remain unnoticed?

Containment Effectiveness

Once detected, could the attacker's spread be stopped?

These metrics can also form meaningful security KPIs for management.

How Should Red Team Success Be Assessed?

The Red Team getting past every security control does not always mean a successful operation.

Equally, the Blue Team detecting the attack early does not mean the Red Team failed.

The purpose of the operation is not to compete.

The purpose is to measure the organisation's defence.

If the Red Team's attack was stopped at the initial access stage, that is an important security success.

The next question is then:

“Which other TTPs should we test?”

In good Red Team programmes, success should therefore be measured by the capacity to learn and improve.

What Should a Threat-Informed Red Team Report Contain?

A professional report must be structured so that both technical teams and management can understand it.

For example:

Executive Threat Profile

The threat actors and risks that matter to the organisation.

Adversary Profile

The behaviour model of the threat actor emulated.

Attack Narrative

The chronological attack story of the operation.

MITRE ATT&CK Mapping

The techniques used.

Attack Path

The route formed from initial access to the critical objective.

Detection Coverage

SOC, SIEM, EDR/XDR and NDR visibility.

Control Effectiveness

Which security controls worked.

Detection Gaps

Behaviours that were not detected.

Business Impact

The business impact of a successful real attack.

Remediation Roadmap

A prioritised improvement plan.

This structure lifts the report out of being a technical exploit list and turns it into a cyber resilience assessment.

Why Is Threat-Informed Red Teaming Valuable for Management?

Senior management's core question is usually:

“Are we secure?”

It is not possible to answer that with a simple “yes” or “no”.

Threat-informed Red Teaming provides a far more meaningful answer:

“We tested 18 critical techniques used by the real threat actors targeting your sector. Eleven techniques were detected by security controls, four were blocked, and in three we found a significant detection gap.”

This output is measurable for management.

It also shows which areas cyber security investment should be directed towards.

How Is the Real Effectiveness of Security Investments Measured?

An organisation may have;

EDR,

XDR,

SIEM,

SOAR,

NDR,

PAM,

DLP,

MFA,

WAF,

a firewall.

But the question should be this:

Do these technologies work together against real threat behaviour?

Threat-informed Red Teaming can measure that.

It can test, for example;

email security through phishing,

EDR and identity security through credential theft,

NDR and segmentation through lateral movement,

the firewall and NDR through C2,

PAM through privileged access.

Threat-informed Red Teaming is therefore also a security control validation method.

Where Threat-Informed Red Teaming and Cyber Threat Intelligence Meet

Threat intelligence tries to understand the attacker.

The Red Team behaves like the attacker.

The Blue Team tries to detect the attacker.

The Purple Team improves the defence.

When these four functions work together, the organisation's security model evolves from theoretical threats towards real ones.

The cycle is simply this:

Who is targeting us?

↓

How do they attack?

↓

Can we simulate it?

↓

Can we see it?

↓

Can we stop it?

↓

Can we be better next time?

That is the essence of threat-informed defense.

Conclusion: The Best Red Team Scenario Is Not the Most Complex One, but the Most Realistic

The purpose of Red Teaming is not to demonstrate the most complex attack techniques possible.

The purpose is to simulate meaningfully the real threats an organisation could face.

A good Red Team operation therefore does not begin with attack tools.

It begins with threat intelligence.

The organisation's sector is analysed.

Threat actors are identified.

TTPs are examined.

MITRE ATT&CK mapping is built.

Crown jewels are determined.

A realistic attack scenario is then prepared.

This approach connects attack simulation directly to corporate risk.

And it answers the critical question:

“How prepared are we against the methods of the attackers who could genuinely target us?”

That is the greatest value of threat-informed Red Teaming.

But the process does not end when the Red Team operation is complete.

One of the truly important stages is assessing the results correctly and turning the attack chain into the organisation's defensive capacity.

Which attack techniques succeeded?

Which were detected?

Which security product genuinely worked?

When did the SOC see the attack?

At which point could the attack path have been broken?

And most importantly:

If the same attack is repeated tomorrow, will the result be different?