Runbook 01 — Cloud Red Team Methodology

Purpose

Use this runbook to plan and execute an authorized Cloud Red Team engagement in a controlled enterprise or training environment.

A Cloud Red Team operation is not simply:

Find Cloud Vulnerability
      ↓
Exploit It

The objective is to simulate how a realistic adversary could move through a cloud environment while answering:

Can Initial Access
Be Achieved?

      ↓

Can Cloud Identity
Be Compromised?

      ↓

Can Privileges
Be Escalated?

      ↓

Can the Adversary
Move Laterally?

      ↓

Can Persistence
Be Established?

      ↓

Can Sensitive Resources
Be Reached?

      ↓

Will Security Controls
Detect the Activity?

      ↓

Can the Organization
Respond Effectively?

The methodology is:

Authorization
      ↓
Intelligence
      ↓
Initial Access
      ↓
Identity
      ↓
Privilege
      ↓
Lateral Movement
      ↓
Persistence
      ↓
Objective
      ↓
Detection Validation
      ↓
Evidence
      ↓
Cleanup
      ↓
Reporting

Core Principle

Cloud Red Teaming must always be:

Authorized

Objective Driven

Controlled

Evidence Based

Reversible

Detection Aware

The goal is not maximum exploitation.

The goal is:

Minimum Necessary
Adversary Simulation

      +

Maximum Defensive
Learning

When to Use This Runbook

Use this runbook:

• before an enterprise cloud red team exercise.

• during authorized adversary simulation.

• when validating cloud attack paths.

• when testing cloud identity defenses.

• when evaluating privilege escalation controls.

• when testing cross-service lateral movement.

• when validating cloud security monitoring.

• when conducting purple team exercises.

• when assessing cloud incident-response readiness.

• when validating an enterprise cloud security architecture.

Supported Cloud Environments

The methodology can be adapted to:

AWS

Microsoft Azure

Google Cloud

Kubernetes

Hybrid Cloud

Multi-Cloud

The exact techniques will vary.

The methodology remains:

Identity
      ↓
Control Plane
      ↓
Workloads
      ↓
Data
      ↓
Trust Relationships

Required Inputs

Before starting, obtain:

Rules of Engagement

Authorized Scope

Cloud Accounts /
Subscriptions /
Projects

Permitted Identities

Permitted Techniques

Prohibited Techniques

Testing Window

Emergency Contacts

Stop Conditions

Detection Objectives

Cleanup Requirements

Required Records

Create:

01 Engagement_Profile.md

02 Rules_of_Engagement.md

03 Scope_Register.csv

04 Identity_Register.csv

05 Asset_Register.csv

06 Attack_Surface_Map.md

07 Attack_Path_Register.csv

08 Operation_Log.csv

09 Detection_Register.csv

10 Evidence_Register.csv

11 Cleanup_Register.csv

12 Findings_Register.csv

13 Red_Team_Assessment_Summary.md

Phase 1 — Engagement Authorization

Step 1 — Confirm Written Authorization

Before performing any activity, confirm:

Who Authorized
the Engagement?

What Environment
Is Authorized?

When Is Testing
Authorized?

Which Techniques
Are Authorized?

No active operation should begin without authorization.

Step 2 — Define the Rules of Engagement

Create:

02 Rules_of_Engagement.md

Document:

Engagement Name

Business Owner

Technical Owner

Red Team Lead

Blue Team Contact

Testing Window

Cloud Providers

Authorized Accounts

Authorized Regions

Permitted Techniques

Prohibited Techniques

Communication Process

Emergency Stop Procedure

Phase 2 — Define Scope

Step 3 — Identify Cloud Scope

Create:

03 Scope_Register.csv

Recommended fields:

Asset	Provider	Type	Environment	Status	Restrictions

Potential scope may include:

AWS Accounts

Azure Subscriptions

GCP Projects

Kubernetes Clusters

Cloud Applications

Cloud Identities

Development Environments

Step 4 — Identify Out-of-Scope Resources

Explicitly record:

Production Databases

Customer Data

Safety-Critical Systems

Billing Systems

Third-Party SaaS

Shared Infrastructure

where applicable.

Use:

DO NOT TEST

for excluded resources.

Phase 3 — Define Objectives

Step 5 — Establish Red Team Objectives

Every operation should answer a security question.

Examples:

Can a Compromised
Developer Identity Reach
Production Resources?

Can an Attacker
Escalate from a Low-Privilege
Cloud Identity?

Can a Compromised
Workload Reach Sensitive
Cloud Services?

Will the SOC Detect
Suspicious Cloud
Identity Activity?

Step 6 — Define Objective States

For each objective define:

Starting Position

Target State

Success Criteria

Stop Condition

Example:

Starting Position

Compromised
Developer Identity

      ↓

Target

Sensitive Production
Storage

      ↓

Success

Demonstrate Authorized
Read Capability Against
Synthetic Test Object

      ↓

Stop

Do Not Access
Production Data

Phase 4 — Threat Model the Environment

Step 7 — Identify Relevant Threat Actors

Model realistic adversaries such as:

External Attacker

Compromised Developer

Malicious Insider

Compromised Workload

Compromised CI/CD Identity

Supply Chain Attacker

Step 8 — Select the Threat Model

Example:

Threat Actor

External Attacker

Initial Capability

Leaked Development
Credential

Objective

Reach Production
Cloud Resources

This prevents the engagement from becoming:

Random
Security Testing

Phase 5 — Build the Cloud Attack Surface

Step 9 — Identify Major Security Planes

Map:

Identity Plane

Control Plane

Network Plane

Compute Plane

Application Plane

Data Plane

Management Plane

Step 10 — Create Asset Register

Create:

05 Asset_Register.csv

with:

Asset	Type	Environment	Identity	Exposure	Sensitivity

Step 11 — Build Attack Surface Map

Create:

06 Attack_Surface_Map.md

Example:

Internet
   │
   ▼
Public Application
   │
   ▼
Cloud Workload
   │
   ├── Workload Identity
   │
   ▼
Cloud IAM
   │
   ├── Storage
   ├── Database
   ├── Secrets
   └── Compute

Phase 6 — Map Cloud Identities

Step 12 — Build Identity Register

Create:

04 Identity_Register.csv

Record:

Identity	Type	Environment	Privilege	Trust	Notes

Identity types may include:

Human User

Service Account

Service Principal

IAM Role

Managed Identity

Workload Identity

CI/CD Identity

Kubernetes Service Account

Step 13 — Identify Privileged Identities

Look for identities controlling:

IAM

Security Controls

Networking

Secrets

Compute

Storage

Logging

Step 14 — Identify Non-Human Identities

Pay particular attention to:

Service Accounts

Workload Roles

Automation Identities

CI/CD Credentials

because enterprise environments frequently contain:

Human Identity
      ↓
Automation Identity
      ↓
Cloud Privilege

Phase 7 — Map Trust Relationships

Step 15 — Identify Trust Paths

Examples:

User
      ↓ assumes
Cloud Role

Application
      ↓ uses
Managed Identity

CI/CD
      ↓ deploys
Cloud Workload

Kubernetes Pod
      ↓ assumes
Cloud Identity

Step 16 — Record Trust Boundaries

Important boundaries include:

Internet
      ↓
Cloud Workload

User
      ↓
Privileged Role

Development
      ↓
Production

Kubernetes
      ↓
Cloud IAM

CI/CD
      ↓
Cloud Control Plane

Phase 8 — Establish Initial Access Scenario

Step 17 — Select Authorized Initial Access

Possible starting conditions:

Compromised Test Credential

Low-Privilege Cloud Account

Developer Identity

Compromised Test Workload

Test API Credential

Do not acquire real credentials outside the engagement rules.

Step 18 — Record Starting Capability

Example:

Identity:
redteam-developer

Environment:
Development

Privilege:
Low

Initial Access:
Authorized Test Credential

Phase 9 — Establish Baseline

Step 19 — Record Initial Permissions

Determine what the starting identity legitimately can access.

Record:

Identity

Effective Permissions

Accessible Services

Accessible Resources

Trust Relationships

Step 20 — Preserve Baseline

The baseline answers:

What Could
the Identity Do
Before Testing?

Without this, privilege escalation cannot be demonstrated accurately.

Phase 10 — Create Attack Path Register

Step 21 — Create Attack Path Register

Create:

07 Attack_Path_Register.csv

Use:

ID	Start	Technique	Target	Expected Control	Status

Example:

| AP-01 | Developer | Role assumption | Production Role | Trust policy | Candidate |

Phase 11 — Build Attack Hypotheses

Step 22 — Use Hypothesis-Driven Testing

Example:

Because the developer
identity can interact with
a deployment service,

I believe it may be able
to influence a workload
that possesses stronger
cloud permissions.

Another:

Because a workload
can assume a cloud role,

I believe compromise
of that workload may
provide access to resources
outside its intended
security boundary.

Phase 12 — Initial Access Validation

Step 23 — Validate the Starting Identity

Confirm:

Credential Works

Expected Identity

Expected Environment

Expected Permissions

Do not expand activity yet.

Step 24 — Record Initial Access

Create an operation entry:

OP-001

Initial Access Established

Identity:
redteam-developer

Environment:
Authorized Lab

Result:
Successful

Phase 13 — Cloud Identity Assessment

Step 25 — Enumerate Current Identity Context

Determine:

Who Am I?

Which Tenant /
Account /
Project?

Which Roles?

Which Permissions?

Which Sessions?

Step 26 — Map Reachable Identity Paths

Look for authorized relationships such as:

Assume Role

Impersonation

Managed Identity

Service Account

Workload Identity

Delegated Permission

The objective is not:

Try Every
Identity

It is:

Identify
Plausible
Privilege Paths

Phase 14 — Privilege Escalation Assessment

Step 27 — Identify Privilege Boundaries

Look for paths involving:

Identity Administration

Role Assignment

Policy Modification

Workload Modification

Credential Management

Automation Control

Deployment Control

Step 28 — Ask the Core Question

Can the Current
Identity Influence
Something More
Privileged?

This is often more important than asking:

Is the Current
Identity an Admin?

Phase 15 — Indirect Privilege

Cloud privilege may occur indirectly.

Example:

Low-Privilege User
      ↓
Can Modify
Deployment
      ↓
Deployment Uses
Privileged Identity
      ↓
Effective Privilege
Expansion

Model:

Direct Permission

      +

Influence Over
Privileged Resource

Phase 16 — Validate Privilege Escalation Minimally

If an authorized path is identified:

Current Identity
      ↓
Controlled Action
      ↓
Higher Privilege

validate only enough to prove:

Privilege Boundary
Can Be Crossed

Do not unnecessarily use the resulting privilege.

Phase 17 — Lateral Movement Assessment

Step 29 — Identify Adjacent Resources

From the current position, identify authorized:

Cloud Accounts

Subscriptions

Projects

Workloads

Clusters

Services

Identities

Step 30 — Model Lateral Movement

Examples:

Identity A
      ↓
Role B
      ↓
Account B

Workload A
      ↓
Managed Identity
      ↓
Service B

Kubernetes Pod
      ↓
Cloud Identity
      ↓
Storage

Phase 18 — Cross-Environment Boundaries

Pay special attention to:

Development
      ↓
Production

Tenant A
      ↓
Tenant B

Cloud A
      ↓
Cloud B

Kubernetes
      ↓
Cloud Control Plane

These represent major enterprise security boundaries.

Phase 19 — Persistence Assessment

Step 31 — Identify Potential Persistence Mechanisms

At a conceptual level, persistence could involve:

Additional Identity

Credential

Role Assignment

Application Registration

Automation

Workload Configuration

Only perform persistence actions explicitly authorized by the Rules of Engagement.

Step 32 — Prefer Simulation

Where possible:

Identify
Persistence Path

      ↓

Demonstrate
Controlled Capability

      ↓

Do Not Establish
Long-Lived Persistence

Phase 20 — Defense Evasion Assessment

Defense-evasion validation should focus on:

Would the Existing
Monitoring Detect
the Activity?

not:

How Can We
Disable Security?

Prefer controlled validation against:

Logging

Alerting

Correlation

SOC Procedures

Phase 21 — Command-and-Control Simulation

If C2 simulation is explicitly authorized, define:

Approved Infrastructure

Approved Protocol

Approved Destination

Approved Time Window

Expected Detection

Do not establish uncontrolled or persistent C2 infrastructure.

The goal is:

Detection
Validation

Phase 22 — Data Access Simulation

Step 33 — Identify High-Value Data Paths

Examples:

Object Storage

Databases

Secrets

Backups

Analytics

Configuration

Step 34 — Use Synthetic Data

Where possible use:

redteam-test-object.txt

synthetic-customer-record

test-secret

rather than production data.

Step 35 — Apply Data Stop Condition

Once authorized access is proven:

Access One
Synthetic Object
      ↓
Capture Evidence
      ↓
Stop

Phase 23 — Business Impact Simulation

Translate technical capability into business context.

Instead of:

Storage Access

document:

A compromised developer
identity could traverse the
identified trust path and
reach a storage service
classified as production.

But clearly distinguish:

Demonstrated

Potential

Not Tested

Phase 24 — Detection Validation

Step 36 — Create Detection Register

Create:

09 Detection_Register.csv

with:

Activity	Expected Telemetry	Expected Alert	Observed	Status

Examples:

Unusual Role Assumption

Privileged API Call

Cross-Account Access

Sensitive Storage Access

New Identity Activity

Phase 25 — Validate Telemetry

For each authorized red team action ask:

Was It Logged?

Where?

Was It Correlated?

Was an Alert Generated?

Did the SOC Receive It?

Was It Investigated?

Phase 26 — Detection Outcome Classification

Use:

Detected

Logged but Not Alerted

Alerted but Not Investigated

Investigated

Blocked

Not Visible

This creates significantly more defensive value than simply:

Attack Worked

Phase 27 — Purple Team Handoff

Where appropriate:

Red Team Action
      ↓
Blue Team Observation
      ↓
Telemetry Review
      ↓
Detection Gap
      ↓
Detection Improvement
      ↓
Retest

Phase 28 — Maintain Operation Log

Create:

08 Operation_Log.csv

Use:

Time	Operator	Identity	Action	Target	Result	Evidence

Every important operation should be traceable.

Phase 29 — Maintain Evidence

Create:

10 Evidence_Register.csv

Evidence may include:

Cloud Audit Events

Redacted CLI Output

Screenshots

API Responses

Permission Evidence

Detection Events

SOC Alerts

Phase 30 — Evidence Structure

For an attack path:

Evidence/
└── AP-001/
    ├── 01-starting-position.txt
    ├── 02-permission-baseline.txt
    ├── 03-path-validation.txt
    ├── 04-target-access.txt
    ├── 05-detection-evidence.txt
    └── 06-timeline.md

Phase 31 — Redact Sensitive Material

Remove:

Passwords

Access Keys

Tokens

Secrets

Private Keys

Production Data

Customer Information

from reports and learning artifacts.

Phase 32 — Build Attack Path Diagram

For each confirmed path create:

Initial Access

Developer Identity
      ↓

Permission / Trust

Deployment Control
      ↓

Privileged Workload
      ↓

Workload Identity
      ↓

Sensitive Cloud Service
      ↓

Synthetic Data

Phase 33 — Record Security Controls

At each transition document:

Expected Control

Observed Control

Control Result

Example:

Developer
      ↓
Production Role

Expected Control:
Trust restriction

Observed:
Restriction effective

Result:
Attack path blocked

Blocked paths are valuable results.

Phase 34 — Record Findings

Create:

12 Findings_Register.csv

Use:

ID	Attack Path	Control Failure	Impact	Detection	Status

Do not turn every observation into a vulnerability.

Phase 35 — Classify Findings

Useful categories include:

Identity Governance

Excessive Privilege

Trust Relationship

Workload Identity

Network Segmentation

Secret Management

Logging

Detection

Incident Response

Phase 36 — Attack Path vs Individual Finding

A red team engagement should show relationships.

Example:

Finding 01
Excessive Developer Permission

      ↓

Finding 02
Privileged Workload Identity

      ↓

Finding 03
Weak Environment Boundary

      ↓

Attack Path

Developer
      →
Production Data

This is more useful than presenting three disconnected issues.

Phase 37 — Measure Attack Path Length

Document:

Initial Position

Number of Security
Boundaries Crossed

Privileges Obtained

Target Reached

Detection Events

Example:

Developer Credential

      ↓ 1

Deployment Service

      ↓ 2

Privileged Workload

      ↓ 3

Production Storage

Phase 38 — Identify Choke Points

Ask:

Where Could
One Control
Have Broken
the Entire Path?

Potential choke points:

Conditional Access

IAM Trust Policy

Workload Identity

Network Boundary

Secret Management

Service Control Policy

Detection Rule

These are often the most valuable remediation opportunities.

Phase 39 — Evaluate Preventive Controls

Document whether the path was affected by:

Least Privilege

MFA

Conditional Access

Network Controls

Organization Policies

Workload Isolation

Secrets Controls

Phase 40 — Evaluate Detective Controls

Assess:

Cloud Audit Logging

SIEM

Cloud-Native Detection

Identity Monitoring

Workload Detection

SOC Alerting

Phase 41 — Evaluate Responsive Controls

Determine whether defenders could:

Identify Identity

Understand Activity

Revoke Credentials

Disable Sessions

Isolate Workload

Contain Account

Investigate Timeline

This produces:

Prevent

Detect

Respond

coverage.

Phase 42 — Define Stop Conditions

Immediately stop an operation if:

Unexpected Production
Impact Occurs

Customer Data Appears

Out-of-Scope Resources
Are Reached

Service Availability
Is Affected

Unapproved Persistence
Occurs

Unapproved Privilege
Is Obtained

Emergency Contact
Requests Stop

Phase 43 — Stop After Objective Proof

If the objective is:

Can Developer Identity
Reach Production Storage?

and the authorized test proves:

Synthetic Production
Object Read

then:

Objective Proven
      ↓
Collect Evidence
      ↓
Stop

Do not continue accessing additional objects.

Phase 44 — Cleanup

Every red team operation must include cleanup.

Create:

11 Cleanup_Register.csv

Use:

Resource	Created By	Purpose	Cleanup Action	Verified

Phase 45 — Remove Test Artifacts

Review:

Test Users

Temporary Roles

Temporary Policies

Test Keys

Test Tokens

Test Workloads

Test Files

Temporary Rules

Test Infrastructure

Phase 46 — Verify Cleanup

Do not assume deletion succeeded.

Verify:

Artifact Removed

Permission Removed

Credential Revoked

Temporary Infrastructure
Destroyed

Phase 47 — Credential Hygiene

Any credentials created for the engagement should be:

Revoked

Rotated

Deleted

as appropriate after testing.

Phase 48 — Detection Retention

Do not remove legitimate:

Audit Logs

Security Alerts

SOC Cases

created by the exercise unless explicitly required.

These are valuable evidence.

Phase 49 — Build Final Attack Path Register

Update:

07 Attack_Path_Register.csv

with:

Confirmed

Blocked

Partially Confirmed

Not Tested

Rejected

Phase 50 — Create Final Assessment Summary

Create:

13 Red_Team_Assessment_Summary.md

Use:

# Cloud Red Team Assessment Summary

## Engagement

## Objective

## Scope

## Threat Model

## Starting Position

## Cloud Environments

## Identities Assessed

## Attack Surface

## Confirmed Attack Paths

## Blocked Attack Paths

## Privilege Escalation Paths

## Lateral Movement Paths

## Persistence Opportunities

## Business Impact

## Preventive Controls

## Detection Results

## Response Results

## Evidence

## Cleanup Status

## Findings

## Strategic Recommendations

## Overall Conclusion

Operational Attack Path Model

Use:

Initial Access
      ↓
Identity Context
      ↓
Permission Discovery
      ↓
Trust Relationships
      ↓
Privilege Escalation
      ↓
Lateral Movement
      ↓
Persistence Opportunity
      ↓
Target Resource
      ↓
Controlled Impact
      ↓
Detection Validation
      ↓
Cleanup

Cloud Identity Attack Path Model

Compromised Identity
      ↓
Current Permissions
      ↓
Influence Over Resource
      ↓
Resource Identity
      ↓
Additional Permissions
      ↓
Sensitive Resource

Workload Attack Path Model

Application
      ↓
Workload
      ↓
Workload Identity
      ↓
Cloud API
      ↓
Sensitive Service

CI/CD Attack Path Model

Developer
      ↓
Repository / Pipeline
      ↓
Deployment
      ↓
Workload
      ↓
Deployment Identity
      ↓
Cloud Environment

Kubernetes-to-Cloud Model

Pod
      ↓
Service Account
      ↓
Workload Identity
      ↓
Cloud IAM
      ↓
Cloud Service

Multi-Account Attack Path Model

Account A Identity
      ↓
Trust Relationship
      ↓
Role in Account B
      ↓
Resource in Account B

Detection Validation Model

Red Team Activity
      ↓
Cloud Audit Log
      ↓
Security Analytics
      ↓
Detection Rule
      ↓
Alert
      ↓
SOC
      ↓
Investigation
      ↓
Containment

At every stage ask:

Did the Chain
Continue?

Evidence Standard

Every confirmed attack path should answer:

Where Did
We Start?

What Permission
Did We Have?

What Boundary
Was Crossed?

Which Control
Failed?

What Capability
Was Gained?

What Business
Asset Was Reached?

Was It Detected?

What Evidence
Proves It?

Common Failure 1 — Starting Without an Objective

Avoid:

Enumerate Everything

Try Everything

Escalate Everywhere

Use:

Threat Scenario
      ↓
Objective
      ↓
Attack Path

Common Failure 2 — Treating Enumeration as Red Teaming

Enumeration produces:

Information

Red teaming evaluates:

Attack Paths

Security Controls

Detection

Response

Common Failure 3 — Focusing Only on Network Paths

Cloud attacks frequently follow:

Identity
      ↓
API
      ↓
Trust
      ↓
Service

rather than traditional:

Host
      ↓
Network
      ↓
Host

Common Failure 4 — Ignoring Non-Human Identities

Do not focus only on users.

Modern cloud environments depend heavily on:

Service Accounts

Roles

Managed Identities

Workload Identities

CI/CD Identities

Common Failure 5 — Privilege Equals Admin

An identity does not need:

Administrator

to create a high-impact attack path.

The more useful question is:

What Can
This Identity
Influence?

Common Failure 6 — Ignoring Indirect Permissions

Remember:

Can Modify
Privileged Resource

      ≈

Potential Indirect
Privilege

depending on the resource and controls.

Common Failure 7 — Ignoring Environment Boundaries

A path from:

Development
      ↓
Production

may be more important than privilege escalation within development.

Common Failure 8 — Accessing Real Data

Use:

Synthetic Data

wherever possible.

Do not use unnecessary production data to demonstrate impact.

Common Failure 9 — Disabling Security Controls

Cloud red team exercises should usually validate defensive controls rather than destroy them.

Prefer:

Can We
Trigger Detection?

over:

Can We
Turn Detection Off?

Common Failure 10 — No Cleanup Plan

Never create:

Identity

Credential

Role

Workload

Policy

without knowing:

Who Will
Remove It?

Common Failure 11 — Reporting Only Vulnerabilities

A red team report should include:

Successful Controls

Blocked Paths

Detection Successes

Response Successes

as well as weaknesses.

Common Failure 12 — Reporting Only Technical Details

Executives need:

Starting Position

Attack Path

Business Asset

Business Impact

Control Failure

Recommended Choke Point

not only API events.

Quality Checklist

Before closing the engagement confirm:

[ ] Written authorization confirmed

[ ] Rules of engagement reviewed

[ ] Scope validated

[ ] Exclusions documented

[ ] Objectives defined

[ ] Threat model established

[ ] Starting position documented

[ ] Cloud assets mapped

[ ] Identities mapped

[ ] Trust relationships mapped

[ ] Baseline permissions recorded

[ ] Attack hypotheses created

[ ] Privilege paths assessed

[ ] Lateral movement assessed

[ ] Persistence opportunities reviewed

[ ] Sensitive access used only as authorized

[ ] Detection telemetry reviewed

[ ] SOC response reviewed

[ ] Operation log maintained

[ ] Evidence collected

[ ] Sensitive information redacted

[ ] Stop conditions followed

[ ] Cleanup completed

[ ] Cleanup independently verified

[ ] Attack paths documented

[ ] Findings registered

[ ] Assessment summary completed

Runbook Success Criteria

This runbook is complete when you can clearly explain:

Where the
Adversary Started

      ↓

Which Identity
Was Compromised

      ↓

Which Permissions
Were Available

      ↓

Which Trust
Relationships Existed

      ↓

Which Security
Boundaries Were Crossed

      ↓

Which Privileges
Were Obtained

      ↓

Which Resources
Were Reached

      ↓

Which Controls
Blocked the Attack

      ↓

Which Activities
Were Detected

      ↓

How the Organization
Responded

      ↓

Which Controls Would
Break the Attack Path

Professional Cloud Red Team Workflow

Use:

Authorization
      ↓
Rules of Engagement
      ↓
Threat Model
      ↓
Objectives
      ↓
Initial Position
      ↓
Cloud Mapping
      ↓
Identity Mapping
      ↓
Trust Mapping
      ↓
Attack Hypotheses
      ↓
Initial Access
      ↓
Privilege Escalation
      ↓
Lateral Movement
      ↓
Persistence Assessment
      ↓
Objective Validation
      ↓
Detection Validation
      ↓
Response Validation
      ↓
Evidence
      ↓
Cleanup
      ↓
Reporting

Key Takeaways

Remember:

Cloud Red Teaming
      ≠
Cloud Pentesting

A penetration test primarily asks:

What Is
Vulnerable?

A red team exercise asks:

Can a Realistic
Adversary Achieve
a Defined Objective?

Remember:

Permission
      ≠
Effective Privilege

because:

Permission

      +

Trust

      +

Resource Influence

      +

Identity Relationships

      =

Effective Attack Surface

Also:

Successful Attack
      ≠
Successful Red Team

A successful engagement provides:

Attack Path

      +

Preventive Control
Assessment

      +

Detection Validation

      +

Response Validation

      +

Actionable Remediation

The professional mindset is:

Do Not Ask Only:

"Can I Exploit This?"

Ask:

"Which Security Boundary
Does This Represent?"

"Can I Cross It?"

"Would Defenders See It?"

"Can They Respond?"

"What Single Control
Could Break This Path?"

Runbook Output

At completion, archive:

01 Engagement_Profile.md

02 Rules_of_Engagement.md

03 Scope_Register.csv

04 Identity_Register.csv

05 Asset_Register.csv

06 Attack_Surface_Map.md

07 Attack_Path_Register.csv

08 Operation_Log.csv

09 Detection_Register.csv

10 Evidence_Register.csv

11 Cleanup_Register.csv

12 Findings_Register.csv

13 Red_Team_Assessment_Summary.md

Handoff to Next Runbook

This runbook establishes the overall:

Cloud Red Team
Operating Methodology

The next runbook moves deeper into:

Identity Relationships

Trust Relationships

Privilege Paths

Workload Identities

Cross-Account Access

Cross-Environment Movement

Attack Graphs

Security Choke Points

Next Runbook

➡️ Runbook 02 — Enterprise Cloud Attack Path Assessment

The transition is:

Runbook 01
Cloud Red Team
Methodology

      ↓

Runbook 02
Enterprise Cloud
Attack Path Assessment

➡️ Next: Runbook 02 — Enterprise Cloud Attack Path Assessment