07 — Red Team Fundamentals

Traditional penetration testing often asks:

What vulnerabilities exist in this environment?

Red teaming asks a broader question:

Can a realistic adversary achieve a defined objective, and can the organisation detect and respond to the activity?

This represents an important change in mindset.

A penetration test may discover:

External Service
      ↓
Vulnerability
      ↓
System Compromise
      ↓
Finding

A red team engagement may evaluate an entire attack chain:

Adversary Objective
        ↓
Initial Access
        ↓
Execution
        ↓
Persistence
        ↓
Privilege Escalation
        ↓
Credential Access
        ↓
Discovery
        ↓
Lateral Movement
        ↓
Target System
        ↓
Objective

The technical activity is only one part of the exercise.

A professional red team also evaluates:

• Preventive controls

• Identity controls

• Endpoint security

• Network security

• Cloud security

• Logging

• Detection engineering

• SOC operations

• Incident response

• Security architecture

• Human processes

The objective is not simply:

Can we compromise something?

The objective is:

How well can the organisation prevent, detect, investigate, contain, and understand realistic adversary behaviour?

Module Mission

Your mission is to understand how authorised red team engagements simulate realistic adversaries without creating unnecessary business risk.

The core methodology is:

Business Objective
       ↓
Threat Intelligence
       ↓
Adversary Selection
       ↓
Rules of Engagement
       ↓
Attack Path Planning
       ↓
Controlled Execution
       ↓
Detection Observation
       ↓
Objective Validation
       ↓
Evidence Collection
       ↓
Attack Reconstruction
       ↓
Purple Team Collaboration
       ↓
Reporting
       ↓
Security Improvement

By the end of this module, you should understand that professional red teaming is not simply:

Advanced hacking.

It is a structured security-assurance discipline.

1. What Is Red Teaming?

Red teaming is an authorised security exercise designed to simulate realistic adversary behaviour against an organisation.

The engagement attempts to answer questions such as:

Can an attacker obtain initial access?

Can they expand privilege?

Can they move between systems?

Can they reach critical assets?

Will security controls stop them?

Will defenders detect them?

Can defenders investigate the activity?

Can the organisation respond effectively?

Red teaming therefore measures more than vulnerabilities.

It measures the effectiveness of the security program.

2. Red Team vs Penetration Test

These activities overlap, but their objectives differ.

Penetration Test	Red Team
Vulnerability focused	Objective focused
Broad technical coverage	Realistic attack path
Usually shorter	Often longer
Findings oriented	Scenario oriented
Known testing scope	May involve limited defender awareness
Tests vulnerabilities	Tests security capabilities
Technical remediation	Strategic security improvement

A penetration tester may ask:

What can I compromise?

A red team operator asks:

Can I achieve the agreed objective while following the engagement constraints?

3. Red Team vs Vulnerability Assessment

A vulnerability assessment primarily identifies weaknesses.

Assets
  ↓
Scanning
  ↓
Potential Vulnerabilities
  ↓
Risk Review

Red teaming instead follows realistic attack paths.

Adversary
   ↓
Initial Access
   ↓
Identity
   ↓
Movement
   ↓
Objective

Both provide value, but they answer different questions.

4. Red Team vs Purple Team

Red team:

Simulate
Adversary Behaviour

Blue team:

Detect
Investigate
Respond

Purple teaming brings both together:

Red Team
    ↘
      Collaboration
    ↗
Blue Team

The purpose is rapid defensive improvement.

5. Assume Breach

Some exercises begin with an assume-breach scenario.

Instead of spending significant time proving initial access, the red team may be provided with:

Standard User Account

Workstation Access

Cloud Identity

Application Access

The exercise then asks:

What could an attacker accomplish after obtaining this foothold?

This is useful for testing internal security controls.

6. Objective-Based Testing

A red team engagement should have meaningful objectives.

Weak objective:

Compromise as many machines as possible.

Better objective:

Determine whether an attacker with an initial employee foothold could reach systems supporting the organisation’s critical financial process.

The objective should connect technical activity to business risk.

7. Crown Jewels

Critical assets are sometimes described as crown jewels.

Examples include:

Identity Infrastructure

Payment Systems

Customer Databases

Source Code

Production Cloud

Backup Infrastructure

Security Infrastructure

Sensitive Intellectual Property

Red team scenarios should be designed around assets that matter to the organisation.

8. Threat-Informed Red Teaming

Strong red teams do not select techniques randomly.

They study relevant threats.

Sources may include:

Threat Intelligence

Industry Reports

Incident History

Known Threat Actors

MITRE ATT&CK

Internal Risk Assessments

The goal is to understand:

Which adversaries and techniques are realistically relevant to this organisation?

9. Adversary Emulation

Adversary emulation attempts to reproduce selected behaviours associated with realistic threat actors.

Conceptually:

Threat Intelligence
       ↓
Adversary Behaviour
       ↓
Relevant Techniques
       ↓
Controlled Simulation
       ↓
Security Validation

The goal is not theatrical imitation.

The goal is realistic security testing.

10. MITRE ATT&CK

MITRE ATT&CK provides a structured knowledge base describing adversary behaviours.

A simplified attack sequence might include:

Reconnaissance

Resource Development

Initial Access

Execution

Persistence

Privilege Escalation

Defense Evasion

Credential Access

Discovery

Lateral Movement

Collection

Command and Control

Exfiltration

Impact

ATT&CK provides a common language between offensive and defensive teams.

11. Tactics

A tactic represents an adversary objective.

Examples:

Initial Access

Persistence

Credential Access

Discovery

Lateral Movement

Think of a tactic as:

What is the adversary trying to accomplish?

12. Techniques

A technique describes how an adversary may accomplish a tactic.

Conceptually:

Tactic
   ↓
Technique
   ↓
Implementation

During red team planning, techniques should be selected because they support the scenario—not simply because they are technically interesting.

13. ATT&CK Mapping

Maintain an engagement mapping such as:

Phase	ATT&CK Tactic	Technique	Status
Initial foothold	Initial Access	Approved simulation	Completed
Local action	Execution	Approved technique	Completed
Environment mapping	Discovery	Account discovery	Completed
Movement	Lateral Movement	Approved method	Tested

This later becomes valuable for detection engineering.

14. Rules of Engagement

Rules of Engagement are critical.

They define exactly what the red team may and may not do.

A typical ROE covers:

Scope

Objectives

Testing Period

Permitted Techniques

Prohibited Techniques

Target Systems

Excluded Systems

Data Handling

Communication

Escalation

Stop Conditions

15. Written Authorization

Every red team engagement requires explicit authorization.

Never rely on:

Someone told us it was okay.

The engagement should identify:

Authorising Authority

Scope

Testing Window

Approved Activities

Escalation Contacts

This protects both the organisation and the assessment team.

16. Scope

Scope may include:

Domains

Networks

Applications

Cloud Accounts

Identity Systems

Endpoints

Facilities

Employees

Some areas may explicitly remain outside scope.

Example:

IN SCOPE

Corporate Lab Network
Test Active Directory
Training Cloud Account

OUT OF SCOPE

Production Payment System
Medical Systems
Third-Party Networks
Personal Employee Devices

17. Prohibited Actions

Red team engagements commonly restrict activities capable of creating excessive business impact.

Examples may include:

Denial of Service

Destructive Data Modification

Unapproved Social Engineering

Safety-Critical Systems

Unapproved Third Parties

Production Data Destruction

Never infer permission for these activities.

18. Stop Conditions

Define when testing must stop.

Examples:

Unexpected Production Impact

Safety Concern

Unintended Third-Party Access

Critical System Instability

Sensitive Data Exposure Beyond Requirement

Emergency Request from Engagement Controller

Operators must know exactly who can invoke the stop condition.

19. Engagement Control

A professional engagement should have designated contacts.

Example:

Executive Sponsor
      ↓
Engagement Controller
      ↓
Red Team Lead
      ↓
Red Team Operators

The controller helps resolve uncertainty during testing.

20. White Team

Some exercises use a white team.

The white team understands the exercise and coordinates between participants.

           White Team
          /          \
         ↓            ↓
     Red Team      Blue Team

The white team may manage:

• Safety

• Scope

• Escalations

• Exercise injects

• Business impact

• Final deconfliction

21. Deconfliction

A defender may discover suspicious activity during the exercise.

The organisation needs a controlled process to determine:

Red Team Activity?

or

Real Attacker?

This is called deconfliction.

It must not weaken genuine incident response.

22. Operational Security

Red teams also practice operational security.

In an engagement context, OPSEC means preventing unnecessary exposure of:

Engagement Information

Testing Accounts

Infrastructure

Evidence

Client Data

Operator Identity

Assessment Plans

The goal is controlled execution—not concealment for malicious purposes.

23. Red Team Infrastructure

Authorised engagements may require controlled infrastructure for:

Testing Systems

Logging

Payload Delivery Simulations

Communication

Evidence Collection

Scenario Support

Infrastructure should be:

Authorised

Documented

Controlled

Monitored

Removed After Engagement

24. Attack Infrastructure Governance

Maintain an inventory:

Asset	Purpose	Owner	Engagement	Status
RT-LAB-01	Test server	Red Team	ENG-001	Active
RT-DOMAIN-01	Scenario support	Red Team	ENG-001	Active
RT-LOG-01	Evidence	Red Team	ENG-001	Active

This prevents forgotten infrastructure after testing.

25. Red Team Attack Lifecycle

A simplified lifecycle is:

Planning
   ↓
Reconnaissance
   ↓
Initial Access
   ↓
Execution
   ↓
Persistence
   ↓
Privilege Escalation
   ↓
Credential Access
   ↓
Discovery
   ↓
Lateral Movement
   ↓
Collection
   ↓
Objective
   ↓
Cleanup

Not every engagement needs every phase.

26. Reconnaissance

Reconnaissance develops an understanding of the target environment.

Potential information includes:

Domains

Applications

Technology

Cloud Providers

Public Services

Identity Providers

Remote Access

Business Functions

Only interact with systems according to the engagement rules.

27. Attack Surface Mapping

Build a high-level map:

Enterprise
│
├── Internet Applications
├── Remote Access
├── Email
├── Cloud
├── Identity
├── Endpoints
├── Network
└── Third Parties

Then identify likely trust relationships.

28. Initial Access

Initial access represents the first authorised foothold in the scenario.

Possible categories include:

Application Exposure

Valid Account Scenario

Remote Access Scenario

Cloud Identity Scenario

Approved Social Engineering Simulation

The exact mechanism must align with the ROE.

29. Initial Access Is Not the Objective

A common mistake is treating the first foothold as success.

The real sequence may be:

Initial Access
      ↓
Low Privilege
      ↓
Internal Discovery
      ↓
Identity Analysis
      ↓
Privilege Path
      ↓
Critical Asset

Initial access is often only the beginning.

30. Execution

Execution represents the ability to run approved actions within the compromised or simulated context.

From an assessment perspective, ask:

Which Security Context?

Which User?

Which Host?

Which Controls?

Which Telemetry?

Execution should always remain within the authorised scenario.

31. Persistence

Persistence describes techniques adversaries use to maintain access.

In red teaming, persistence should be tested only where required.

The objective may be to determine:

Would the organisation detect an approved persistence simulation?

Avoid unnecessary persistent changes.

32. Persistence Safety

Any persistence mechanism used during an engagement must be:

Documented

Reversible

Tracked

Approved

Removed

Cleanup is mandatory.

33. Privilege Escalation

Privilege escalation asks whether the current foothold can obtain greater authority.

Conceptually:

Standard User
     ↓
Weak Control
     ↓
Elevated User
     ↓
Administrator

The weakness may exist in:

Identity

Permissions

Configuration

Application

Operating System

Cloud IAM

34. Privilege Is Contextual

Privilege does not always mean:

Local Administrator

It may mean:

Domain Privilege

Cloud Administrator

Database Administrator

Application Administrator

CI/CD Administrator

Backup Administrator

Always relate privilege to the engagement objective.

35. Credential Access

Credential access represents attempts to obtain authentication material.

During professional testing, credentials are highly sensitive evidence.

Controls should define:

What May Be Collected?

How Is It Stored?

Who May Access It?

How Long Is It Retained?

When Must It Be Deleted?

36. Credential Access Is Not the Goal

Finding a credential matters because of what it enables.

Think:

Credential
    ↓
Identity
    ↓
Privilege
    ↓
Accessible Systems
    ↓
Trust
    ↓
Objective

37. Discovery

Discovery allows an attacker to understand the environment.

Questions include:

Where Am I?

Who Am I?

Which Systems Exist?

Which Users Exist?

Which Trusts Exist?

Which Security Controls Exist?

Where Are Critical Assets?

Discovery should be purposeful.

38. Avoid Noisy Discovery Without Purpose

Poor approach:

Scan Everything
     ↓
Generate Noise
     ↓
Collect Huge Output

Better:

Form Hypothesis
      ↓
Perform Focused Discovery
      ↓
Validate
      ↓
Continue

This is more professional and safer.

39. Identity Discovery

Modern red teams place significant emphasis on identity.

Map:

Users

Groups

Roles

Service Accounts

Cloud Identities

Administrative Accounts

Trust Relationships

Then ask:

Which identities provide meaningful movement toward the objective?

40. Lateral Movement

Lateral movement describes movement between systems or security contexts.

Conceptually:

Host A
  ↓
Identity / Trust
  ↓
Host B
  ↓
Additional Access

The important question is not simply whether movement is technically possible.

Ask:

Why was Host A trusted by Host B?

41. Trust Relationships

Trust is often the real attack surface.

Examples:

User → Workstation

Workstation → Server

Server → Database

Application → Cloud Role

CI/CD → Production

Active Directory → Cloud

Cloud → SaaS

Red teams should map these relationships.

42. Lateral Movement Across Technologies

Modern attack paths may look like:

Endpoint
   ↓
Enterprise Identity
   ↓
Cloud SSO
   ↓
Cloud Application
   ↓
Workload Identity
   ↓
Production Data

Movement is no longer limited to Windows machines.

43. Command and Control Concepts

Real adversaries require mechanisms for interacting with compromised systems.

Red team exercises may simulate aspects of this behaviour to test defensive visibility.

From a defensive perspective, evaluate:

Outbound Connections

DNS Activity

Proxy Logs

Endpoint Telemetry

Network Analytics

Unusual Destinations

The goal is security-control validation.

44. C2 Testing Safety

Command-and-control simulations must remain:

Authorised

Controlled

Engagement Specific

Logged

Removable

Do not use uncontrolled infrastructure or techniques outside the ROE.

45. Defense Evasion

Real adversaries may attempt to avoid security controls.

Red teams can safely test whether approved adversary behaviours are visible to defenders.

The objective is not:

Become invisible at any cost.

It is:

Determine which behaviours security controls can and cannot observe.

46. Detection Gap

Suppose:

Red Team Action
      ↓
Endpoint Telemetry Exists
      ↓
No Detection Rule
      ↓
SOC Receives No Alert

This is a detection gap.

The remediation may involve detection engineering rather than patching a vulnerability.

47. Prevention vs Detection

Security controls may:

Prevent

Detect

Delay

Contain

Respond

A mature assessment determines which occurred.

Example:

Technique	Prevented	Detected	Investigated
Initial access simulation	No	Yes	Yes
Privilege change	No	Yes	No
Internal discovery	No	No	No
Sensitive access	Yes	Yes	Yes

This provides much richer information than a vulnerability list.

48. Collection

Collection represents gathering information relevant to the adversary objective.

During an engagement:

Collect the minimum data required to demonstrate impact.

Do not unnecessarily collect real customer or employee information.

49. Simulated Data

Whenever possible, use:

Canary Files

Test Records

Dummy Credentials

Synthetic Documents

Scenario Data

This reduces unnecessary exposure to production information.

50. Exfiltration Simulation

If data-exfiltration controls must be evaluated, simulation is often preferable.

Conceptually:

Test Data
   ↓
Approved Transfer Simulation
   ↓
Security Controls
   ↓
Detection

The objective is validating controls, not removing genuine sensitive data.

51. Impact

Some adversary behaviours target availability or integrity.

Real destructive activity can create unacceptable business risk.

Red team engagements should therefore commonly use:

Simulation

Proof of Access

Controlled Demonstration

rather than destructive execution.

52. Stop at Sufficient Proof

Suppose the objective is:

Determine whether the red team could access the payroll database.

If the team proves:

Current Identity
      ↓
Database Authorization
      ↓
Payroll Database

it may not be necessary to extract payroll records.

Proof should be proportional to the objective.

53. Attack Chains

Individual weaknesses become more important when chained.

Example:

Weak Application Control
        ↓
Standard User
        ↓
Excessive Internal Trust
        ↓
Service Account
        ↓
Cloud Role
        ↓
Production Storage

No single weakness may explain the full risk.

The attack chain does.

54. Attack Path Documentation

Record every meaningful transition:

Step 01 — Initial foothold

Step 02 — Identity discovered

Step 03 — Internal trust identified

Step 04 — Privilege increased

Step 05 — Cloud access obtained

Step 06 — Target resource reached

Each transition should have evidence.

55. Attack Path Register

Example:

ID	Start	Transition	Target	Status
AP-01	User	Workstation trust	Server	Validated
AP-02	Server	Service identity	Cloud	Validated
AP-03	Cloud	Excessive role	Storage	Validated

This provides a clear engagement narrative.

56. Attack Graph Thinking

An enterprise can be visualised as:

User
 ├──→ Workstation
 │       ├──→ Server
 │       │      └──→ Database
 │       │
 │       └──→ Cloud SSO
 │              └──→ Production
 │
 └──→ SaaS

Each arrow represents trust or access.

Red teaming asks:

Which sequence of relationships leads to the objective?

57. Attack Path vs Vulnerability

A vulnerability is usually a weakness.

An attack path is:

Weakness
   +
Identity
   +
Trust
   +
Privilege
   +
Reachability
   =
Path to Impact

This distinction is fundamental.

58. Detection Validation

For each important action ask:

Was Telemetry Generated?

Was It Collected?

Was It Analysed?

Was an Alert Generated?

Did SOC See It?

Was It Investigated?

Was It Escalated?

This creates the detection lifecycle.

59. Telemetry Validation

A detection may fail because:

No Log Generated
      ↓
or

Log Generated
      ↓
Not Collected
      ↓
or

Collected
      ↓
No Detection
      ↓
or

Alert Generated
      ↓
Not Investigated

Each represents a different remediation problem.

60. Time to Detect

Measure:

Red Team Action
      ↓
Telemetry
      ↓
Alert
      ↓
Analyst Investigation

Useful metrics may include:

Time to Detection

Time to Triage

Time to Escalation

Time to Containment

61. Purple Teaming

Purple teaming converts red team observations into defensive improvement.

Workflow:

Red Executes Technique
        ↓
Blue Observes
        ↓
Telemetry Reviewed
        ↓
Detection Improved
        ↓
Technique Repeated
        ↓
Detection Validated

This creates immediate learning.

62. Purple Team Exercise

Suppose an approved technique produces no alert.

Instead of simply reporting:

SOC failed.

The teams collaborate:

Review Endpoint Logs
      ↓
Identify Available Event
      ↓
Build Detection
      ↓
Repeat Simulation
      ↓
Validate Alert

The result is measurable security improvement.

63. Detection Engineering

Red team observations can help defenders create detections around:

Authentication

Privilege Changes

Suspicious Processes

Identity Abuse

Network Movement

Cloud API Activity

Sensitive Resource Access

The best red teams understand how their activity appears to defenders.

64. Red Team Evidence

Maintain evidence throughout the engagement.

Example:

Evidence ID:
RT-EV-021

Timestamp:
2026-08-28 11:20

Phase:
Discovery

Source:
Authorised Test Workstation

Target:
Training Domain

Observation:
Approved identity discovery activity successfully enumerated information required for the defined attack-path scenario.

Detection:
No SOC alert observed during exercise review.

65. Evidence Timeline

Maintain a chronological timeline.

Time	Action	Asset	Result	Detection
10:00	Initial foothold simulation	WS01	Success	Detected
10:20	Discovery	WS01	Success	No alert
11:00	Privilege validation	SRV01	Success	Detected
11:30	Target access	APP01	Success	Escalated

This becomes extremely valuable during reporting.

66. Operator Journal

Each operator should maintain notes containing:

Timestamp

Objective

Action

Source

Target

Result

Evidence ID

ATT&CK Mapping

Detection Status

Cleanup Status

Do not reconstruct the engagement from memory afterward.

67. Evidence Handling

Red team evidence may contain:

Credentials

Screenshots

Configuration

Internal Hostnames

Security Architecture

Sensitive Business Information

Protect it accordingly.

68. Cleanup Register

Maintain:

Item	System	Created By	Removal Required	Status
Test account	LAB-AD	Red Team	Yes	Removed
Test file	WS01	Red Team	Yes	Removed
Cloud resource	Training AWS	Red Team	Yes	Removed

Cleanup should be verifiable.

69. Reporting

A red team report should explain the attack as a story.

Not:

Finding 1
Finding 2
Finding 3
Finding 4

Instead:

Initial Access
      ↓
Internal Foothold
      ↓
Identity Weakness
      ↓
Privilege Path
      ↓
Cloud Access
      ↓
Critical Objective

Then identify the controls that failed at each stage.

70. Executive Reporting

Executives need to understand:

What Was the Objective?

Was It Achieved?

How?

What Business Assets Were at Risk?

Which Security Layers Failed?

Which Security Layers Worked?

What Should Be Fixed First?

Avoid overwhelming executives with tool output.

71. Technical Reporting

Technical teams need:

Attack Timeline

Affected Assets

Identity Paths

Evidence

ATT&CK Mapping

Detection Results

Root Causes

Remediation

Retest Guidance

Both views should describe the same engagement.

72. Report Security Control Successes

A professional red team report should not document only failures.

Example:

Initial Access
      ↓
Succeeded

Privilege Escalation
      ↓
Succeeded

Cloud Movement
      ↓
Blocked by Conditional Access

The final control worked.

That matters.

73. Root Cause Analysis

Suppose the engagement identified:

Weak Workstation Controls

Excessive Service Account Privilege

Broad Network Access

Weak Cloud Role

The deeper root cause may be:

Excessive implicit trust between enterprise security zones and identities.

This gives leadership a strategic remediation theme.

74. Security Control Mapping

Map attack stages to defensive controls.

Attack Stage	Expected Control	Result
Initial Access	Endpoint protection	Detected
Discovery	Endpoint telemetry	Logged only
Privilege	Identity monitoring	Not detected
Movement	Network segmentation	Failed
Cloud Access	Conditional Access	Blocked

This makes the report actionable.

75. Red Team Success Is Not Domain Admin

A red team is not successful merely because it obtains:

Domain Admin

or:

Cloud Administrator

Success means the engagement answered the security question it was designed to test.

Sometimes the most valuable result is:

Attack Stopped
      ↓
Detected
      ↓
Investigated
      ↓
Contained

That demonstrates effective security.

76. Failure Can Be a Successful Outcome

Suppose the red team cannot reach the objective because:

Segmentation Blocks Movement

MFA Prevents Identity Abuse

EDR Detects Execution

SOC Responds Correctly

That is useful evidence.

Red teaming is not a competition between red and blue teams.

77. Red Team Maturity

A mature red team progresses from:

Tool Focus
   ↓
Technique Focus
   ↓
Attack Path Focus
   ↓
Threat Focus
   ↓
Business Objective Focus

This is the professional progression you should aim for.

78. Common Beginner Mistakes

Treating Red Teaming as Stealthy Pentesting

The objective is security validation, not showing how clever the operator is.

Randomly Selecting Techniques

Techniques should support the scenario.

Chasing Domain Admin

Privilege only matters when it advances the objective.

Ignoring Business Risk

Every major attack path should connect to meaningful impact.

Ignoring Detection

A red team must understand defensive visibility.

Creating Unnecessary Persistence

Only use what the scenario requires.

Collecting Too Much Data

Demonstrate impact with minimum necessary access.

Forgetting Cleanup

Every change introduced during testing must be tracked.

Ignoring Control Successes

Successful defensive controls belong in the report.

Treating Blue Team as the Enemy

Both teams ultimately work toward the same objective.

79. Practical Red Team Lab Scenario

Consider an isolated enterprise lab:

Internet Simulation
        ↓
Test Workstation
        ↓
Lab Active Directory
        ↓
Application Server
        ↓
Training Cloud Account
        ↓
Synthetic Finance Data

Objective:

Determine whether an attacker beginning with an authorised standard-user foothold could reach the synthetic finance data and whether the security monitoring environment detects the attack path.

80. Step 1 — Define Objective

Start:
Standard User on LAB-WS01

Target:
Synthetic Finance Data

Goal:
Demonstrate authorised access

Secondary Goal:
Measure detection

81. Step 2 — Define Rules

Allowed:

Identity discovery
Approved host discovery
Controlled privilege validation
Approved lateral movement
Training cloud access
Synthetic data access

Not Allowed:

DoS
Production systems
Real employee credentials
Destructive actions
Third-party infrastructure

82. Step 3 — Map the Environment

Initial architecture:

LAB-WS01
   ↓
LAB-AD
   ↓
APP01
   ↓
Cloud SSO
   ↓
Training Cloud
   ↓
Finance-Test

Now identify which trust relationships require validation.

83. Step 4 — Establish Initial Position

Record:

Identity:
LAB\student01

Host:
LAB-WS01

Privilege:
Standard User

Objective:
Finance-Test

This becomes the beginning of the attack timeline.

84. Step 5 — Perform Focused Discovery

Determine:

Current Identity
      ↓
Relevant Groups
      ↓
Reachable Systems
      ↓
Business Application
      ↓
Potential Trust

Do not enumerate unrelated systems without reason.

85. Step 6 — Form an Attack Hypothesis

Suppose discovery indicates:

student01
   ↓
Can Access APP01
   ↓
APP01 Uses Cloud Integration

Hypothesis:

Compromise or abuse of the application trust may provide a path toward the training cloud environment.

86. Step 7 — Validate the Next Transition

Validate only the approved relationship:

User
 ↓
APP01

Record:

Evidence

Timestamp

Security Context

Detection Status

87. Step 8 — Analyse Application Trust

Suppose:

APP01
  ↓
Uses
  ↓
Cloud Application Identity

The attack path becomes:

Standard User
     ↓
APP01
     ↓
Cloud Identity
     ↓
Training Cloud

88. Step 9 — Validate Cloud Scope

Before continuing, confirm that:

Training Cloud Account

is explicitly included in scope.

Never follow an attack path into an environment simply because the path exists.

89. Step 10 — Determine Cloud Privilege

Suppose the application identity has:

Read Finance-Test

The attack path now becomes:

LAB-WS01
    ↓
APP01
    ↓
Cloud Application Identity
    ↓
Finance-Test

The technical objective may already be proven.

90. Step 11 — Use Synthetic Evidence

Instead of accessing real financial information, retrieve only the approved marker:

REDTEAM-LAB-OBJECTIVE-ACHIEVED

This demonstrates objective completion safely.

91. Step 12 — Review Detection

Now work with defenders.

Ask:

Was Initial Activity Logged?

Was Discovery Logged?

Was APP01 Access Logged?

Was Cloud Identity Use Logged?

Was Finance-Test Access Logged?

Which Actions Generated Alerts?

Which Were Investigated?

92. Step 13 — Build the Detection Matrix

Example:

Stage	Telemetry	Alert	Analyst Action
Initial foothold	Yes	Yes	Investigated
Discovery	Yes	No	None
Application access	Yes	No	None
Cloud identity use	Yes	Yes	Investigated
Sensitive data access	Yes	Yes	Escalated

Now the engagement has defensive value.

93. Step 14 — Map ATT&CK

Map relevant simulated behaviours:

Initial Access
      ↓
Discovery
      ↓
Privilege / Trust Abuse
      ↓
Lateral Movement
      ↓
Cloud Resource Access
      ↓
Collection

Use the appropriate ATT&CK techniques documented for the actual approved simulation.

94. Step 15 — Identify Control Failures

Possible failures:

Excessive Application Trust

Weak Segmentation

Overprivileged Cloud Identity

Insufficient Discovery Detection

95. Step 16 — Identify Control Successes

Possible successes:

Initial Access Alerted

Cloud Authentication Logged

Sensitive Resource Access Alerted

SOC Escalated Correctly

Both belong in the final report.

96. Step 17 — Determine Root Cause

Potential root cause:

The application integration created excessive trust between a standard internal user context and sensitive cloud resources.

This explains the attack path better than isolated findings.

97. Step 18 — Recommend Improvements

Possible remediation:

Reduce Application Privilege

Strengthen Segmentation

Reduce Cloud Role Scope

Improve Identity Monitoring

Create Discovery Detections

Monitor Sensitive Resource Access

98. Step 19 — Purple Team Retest

After detection improvements:

Repeat Approved Technique
       ↓
Telemetry Generated
       ↓
Detection Triggered
       ↓
SOC Receives Alert
       ↓
Analyst Investigates

Now improvement is measurable.

99. Step 20 — Cleanup

Confirm:

[ ] Test accounts removed
[ ] Test files removed
[ ] Temporary access removed
[ ] Cloud changes reverted
[ ] Infrastructure removed
[ ] Synthetic artifacts removed
[ ] Credentials revoked
[ ] Evidence secured

The engagement is not finished until cleanup is complete.

100. Think Like a Red Team Operator

When you obtain:

Standard User

think:

Identity
   ↓
Trust
   ↓
Reachability
   ↓
Privilege
   ↓
Next Security Boundary

When you reach:

Server

think:

What Is This Server Trusted By?

What Does It Trust?

Which Identities Does It Use?

Which Cloud Services Does It Reach?

When you reach:

Cloud

think:

Which Identity?

Which Permissions?

Which Workloads?

Which Secrets?

Which Critical Assets?

When you achieve the objective, think:

What Detected Us?

What Did Not?

Why?

What Should Change?

101. Think Like the Defender

For every red team action ask:

Which Log Should Exist?

Where Should It Be Collected?

Which Detection Should Trigger?

What Context Does the Analyst Need?

What Response Should Follow?

This mindset makes you a much stronger red team professional.

102. Red Team Engagement Checklist

[ ] Business objective defined
[ ] Executive sponsor identified
[ ] Written authorization obtained
[ ] Scope confirmed
[ ] Threat model developed
[ ] Adversary profile selected
[ ] ATT&CK techniques mapped
[ ] Rules of Engagement approved
[ ] Prohibited actions documented
[ ] Stop conditions documented
[ ] White team identified
[ ] Deconfliction process defined
[ ] Communication plan established
[ ] Test infrastructure approved
[ ] Evidence handling defined
[ ] Data handling defined
[ ] Cleanup requirements defined
[ ] Initial position documented
[ ] Attack hypotheses developed
[ ] Attack paths tracked
[ ] Security boundaries identified
[ ] Identity transitions documented
[ ] Privilege transitions documented
[ ] Objective evidence collected
[ ] Minimum necessary validation followed
[ ] Detection results recorded
[ ] Control successes recorded
[ ] Control failures recorded
[ ] ATT&CK mapping completed
[ ] Purple team opportunities identified
[ ] Root causes identified
[ ] Recommendations developed
[ ] Cleanup completed
[ ] Retesting completed
[ ] Executive report prepared
[ ] Technical report prepared

103. Build Your Red Team Toolkit

Create:

Red Team Toolkit/
│
├── 01 Engagement Authorization
├── 02 Rules of Engagement
├── 03 Scope Register
├── 04 Threat Intelligence
├── 05 Adversary Profiles
├── 06 MITRE ATT&CK Mapping
├── 07 Attack Surface Mapping
├── 08 Attack Path Register
├── 09 Operator Journal
├── 10 Evidence Register
├── 11 Identity Mapping
├── 12 Trust Mapping
├── 13 Detection Matrix
├── 14 Control Validation
├── 15 Purple Team Worksheets
├── 16 Cleanup Register
├── 17 Finding Templates
├── 18 Attack Narrative
├── 19 Executive Report
└── 20 Technical Report

104. The Most Important Red Team Questions

At the start ask:

What business question are we trying to answer?

During reconnaissance ask:

Which attack paths are relevant to the selected adversary?

After initial access ask:

What trust does this identity or system possess?

During movement ask:

Which security boundary are we crossing?

Before sensitive validation ask:

What is the minimum evidence required?

After each major action ask:

Did the organisation see us?

When reaching the objective ask:

Which combination of control failures allowed this?

During reporting ask:

What should the organisation change to prevent this attack path?

These questions matter more than memorising tools.

105. Definition of Success

A successful red team engagement is not:

We compromised 50 machines.

It is not:

We obtained Domain Admin.

It is not:

The SOC never detected us.

Success means the organisation can understand:

Relevant Threat
      ↓
Initial Attack Path
      ↓
Security Boundary
      ↓
Identity / Trust
      ↓
Privilege
      ↓
Critical Asset
      ↓
Control Failure
      ↓
Detection Performance
      ↓
Business Risk
      ↓
Security Improvement

That is the purpose of professional red teaming.

Key Takeaways

Red teaming is an objective-driven security-assurance discipline.

Remember:

Every engagement requires explicit authorization.

Business objectives should drive technical activity.

Threat intelligence should influence scenario design.

MITRE ATT&CK provides a common language for adversary behaviour.

Rules of Engagement define what operators may and may not do.

Red teaming is not simply a more aggressive penetration test.

Initial access is only the beginning of the attack path.

Identity and trust relationships are central to modern red teaming.

Privilege matters only when it advances the objective.

Use minimum necessary validation around sensitive systems and data.

Destructive impact should generally be simulated rather than performed.

Every meaningful action should be documented.

Detection performance is part of the assessment.

Successful defensive controls should be reported alongside failures.

Purple teaming converts offensive observations into defensive improvement.

Cleanup is part of the engagement, not an optional final task.

Red and blue teams ultimately share the same objective: improving organisational security.

Your core methodology is:

Business Objective
       ↓
Threat Intelligence
       ↓
Adversary Scenario
       ↓
Authorization
       ↓
Rules of Engagement
       ↓
Attack Surface
       ↓
Initial Position
       ↓
Attack Path
       ↓
Identity & Trust
       ↓
Controlled Validation
       ↓
Objective
       ↓
Detection Analysis
       ↓
Purple Teaming
       ↓
Root Cause
       ↓
Reporting
       ↓
Remediation
       ↓
Retesting

The strongest Red Team professionals understand:

adversary behaviour, enterprise architecture, identity, trust, attack paths, business objectives, defensive telemetry, detection engineering, operational safety, and communication.

What’s Next?

➡️ 08 — Enterprise Penetration Testing Projects

In the next module, you will bring together the skills developed across:

• Ethical hacking foundations

• Network penetration testing

• Web application security

• Active Directory security

• Wireless security

• Cloud security testing

• Red team fundamentals

You will work through realistic enterprise penetration-testing projects that require you to think across multiple security domains rather than treating each technology independently.

You will learn how to:

• Understand enterprise scope

• Build attack-surface inventories

• Develop testing plans

• Assess external exposure

• Assess internal networks

• Assess applications

• Analyse enterprise identity

• Review Active Directory

• Assess cloud environments

• Identify cross-platform trust

• Develop multi-stage attack paths

• Validate business impact

• Maintain professional evidence

• Prioritise findings

• Develop remediation strategies

• Produce executive reports

• Produce technical reports

• Conduct remediation retesting

You will move from asking:

How does a professional red team simulate and measure realistic adversary behaviour?

to asking:

Can I independently plan, execute, document, and report a complete enterprise penetration-testing engagement across network, application, identity, and cloud environments?