Lesson 01 — Cloud Red Team Operations Fundamentals

Welcome

Welcome to Module 08 — Cloud Red Team Operations.

In earlier modules, you assessed individual cloud platforms, services, identities, containers, Kubernetes clusters, and serverless environments.

Cloud Red Team Operations bring these capabilities together into a controlled enterprise attack simulation.

A Cloud Red Team does not simply search for isolated vulnerabilities. It evaluates whether a realistic adversary could combine weaknesses across identities, applications, cloud services, workloads, networks, and security processes to achieve a defined business objective.

A professional Cloud Red Team engagement may evaluate whether an authorized assessment team can:

Discover externally exposed cloud assets.
Compromise a controlled test identity.
Escalate privileges.
Move between accounts, subscriptions, projects, clusters, or services.
Access an agreed test data asset.
Establish a safe persistence simulation.
Evade selected preventive controls.
Test logging and detection.
Measure Security Operations Centre response.
Demonstrate business impact without harming production.

These engagements require more discipline than ordinary penetration tests because the activities can span multiple technologies, teams, and business-critical environments.

This lesson introduces the operational, legal, technical, and reporting foundations required before conducting any Cloud Red Team activity.

Authorization requirement: All activities described in this module must be performed only within environments you own or have explicit written permission to test. The approved Rules of Engagement always take priority over technical objectives.

Learning Objectives

After completing this lesson, you will be able to:

Explain the purpose of Cloud Red Team Operations.
Differentiate vulnerability assessments, penetration tests, Red Team engagements, and Purple Team exercises.
Understand the Cloud Red Team lifecycle.
Define engagement objectives and success criteria.
Prepare Rules of Engagement.
Establish safety controls and communication procedures.
Build a cloud-focused threat model.
Select appropriate adversary behaviours.
Map engagement activities to MITRE ATT&CK.
Plan evidence collection and reporting.
Understand when an operation must stop.
Prepare an enterprise Cloud Red Team engagement plan.

Business Scenario

CloudNova Technologies has been engaged by MedSecure Global, a multinational healthcare organization operating across AWS, Microsoft Azure, Google Cloud, Kubernetes, containers, and serverless platforms.

The organization has already completed several technical security assessments. Individual findings have been remediated, and management now wants to know whether the security programme can withstand a realistic cloud-focused attack campaign.

Executive leadership asks the Red Team to evaluate whether an authorized adversary could:

Obtain access through a controlled initial-access scenario.
Discover cloud identities and resources.
Escalate privileges within an approved test environment.
Move between selected cloud services.
Access a synthetic healthcare dataset.
Trigger security alerts.
Measure SOC detection and response.
Produce an executive report showing the complete attack path.

Before any technical testing begins, your team must design the engagement, define safety controls, agree on communication procedures, establish evidence requirements, and obtain formal authorization.

What Is a Cloud Red Team Operation?

A Cloud Red Team operation is an authorized adversary-emulation engagement designed to evaluate the effectiveness of an organization’s security controls, people, processes, and response capabilities across cloud environments.

The purpose is not to cause damage.

The purpose is to answer questions such as:

Can an attacker obtain an initial foothold?
Can compromised permissions be expanded?
Can attackers move between cloud resources?
Can sensitive business assets be reached?
Would existing controls interrupt the attack?
Would the SOC detect and investigate the activity?
Are incident-response teams prepared?
Which defensive improvements would break the attack chain?

Cloud Red Team vs Other Security Assessments

Assessment Type	Primary Focus	Typical Output
Vulnerability Assessment	Identify known weaknesses	Vulnerability list
Configuration Review	Evaluate settings and standards	Configuration gaps
Penetration Test	Validate exploitable weaknesses	Technical findings
Red Team Engagement	Simulate a realistic adversary against business objectives	Attack narrative and control effectiveness
Purple Team Exercise	Red and Blue Teams collaborate to improve detection and response	Detection improvements
Incident-Response Exercise	Test investigation and recovery processes	Readiness assessment

A penetration test may ask:

Is this IAM permission exploitable?

A Red Team engagement asks:

Can an attacker combine this IAM weakness with other conditions to reach a business-critical objective without being stopped?

Core Characteristics of Cloud Red Team Operations

A professional engagement is:

Objective Driven

The operation is built around business outcomes rather than an unrestricted search for vulnerabilities.

Example objective:

Determine whether an authorized attacker can move from a compromised development identity to a controlled production-like data asset.

Threat Informed

Activities are selected based on realistic attacker behaviours relevant to the organization.

Controlled

Every action is governed by written scope, safety controls, and stop conditions.

Evidence Driven

Every important action, observation, and conclusion is documented.

Business Focused

Technical activity is connected to business impact.

Detection Aware

The operation evaluates whether security controls and personnel can identify and respond to adversary behaviour.

The GoHackersCloud Enterprise Cloud Red Team Operations Framework

Business Context

↓

Threat Modelling

↓

Engagement Authorization

↓

Rules of Engagement

↓

Attack Scenario Design

↓

Operational Preparation

↓

Controlled Execution

↓

Detection Validation

↓

Impact Demonstration

↓

Evidence Preservation

↓

Risk Analysis

↓

Executive & Technical Reporting

↓

Purple Team Improvement

Phase 01 — Understand the Business Context

Objective

Understand what the organization does, which services are critical, and what type of attack would create meaningful business risk.

A technically successful operation is not useful if it does not evaluate something important to the business.

Review

Business model
Critical services
Revenue-generating systems
Customer-facing applications
Sensitive information
Regulatory requirements
Cloud operating model
Security priorities
Risk appetite
Business continuity requirements

Questions to Ask

Which cloud services support critical operations?
Which applications process sensitive data?
Which identities have administrative privileges?
Which systems must not be disrupted?
Which environments are production?
Which environments may be used for controlled validation?
What would represent a serious business impact?
What scenarios concern executive leadership most?

Deliverable

Create a Business Context Summary containing:

Critical business services
Important cloud assets
Sensitive data categories
Key dependencies
Operational constraints
Executive concerns

Phase 02 — Define Engagement Objectives

Objective

Translate business concerns into measurable Red Team objectives.

Good objectives are:

Specific
Authorized
Measurable
Safe
Relevant to the business
Bound by clear completion criteria

Weak Objective

Test cloud security.

This is too broad.

Strong Objective

Determine whether the Red Team can use a controlled test identity to reach a synthetic dataset stored within the approved AWS test account without using destructive actions.

Example Objectives

Evaluate whether an exposed cloud service could support controlled initial access.
Determine whether an approved low-privilege identity can obtain additional permissions.
Validate whether cross-account or cross-subscription trust is properly restricted.
Test whether security monitoring identifies unusual role assumptions.
Evaluate whether a compromised Kubernetes workload could access cloud resources.
Determine whether a serverless execution identity has excessive permissions.
Validate the SOC response to simulated cloud credential abuse.

Objective Matrix

Objective ID	Objective	Success Condition	Safety Restriction
OBJ-01	Obtain controlled initial access	Test identity accessed	No real user credential collection
OBJ-02	Assess privilege escalation	Approved test role assumed	No production administration
OBJ-03	Access synthetic data	Test object retrieved	No customer data accessed
OBJ-04	Validate detection	SOC alert generated	Activity coordinated with control team

Phase 03 — Establish the Scope

Objective

Clearly define what the Red Team may and may not test.

In-Scope Elements

The scope may include:

AWS accounts
Azure subscriptions
Google Cloud projects
Identity tenants
Kubernetes clusters
Container platforms
Serverless functions
APIs
Storage services
CI/CD systems
Test users
Approved IP ranges
Test applications
Specific regions

Out-of-Scope Elements

Examples include:

Production databases
Customer records
Payment systems
Destructive actions
Denial-of-service testing
Social engineering
Physical access
Third-party platforms
Unapproved cloud accounts
Unapproved geographic regions

Scope Register

Asset	Environment	Cloud	Status	Restrictions
Red Team Test Account	Test	AWS	In Scope	No resource deletion
Development Subscription	Development	Azure	In Scope	No production peering
Security Lab Project	Test	GCP	In Scope	Synthetic data only
Production Database	Production	AWS	Out of Scope	No access permitted

Phase 04 — Prepare Rules of Engagement

The Rules of Engagement define how the operation will be conducted.

No Red Team activity should begin until the Rules of Engagement are approved.

Mandatory Rules of Engagement Sections

Engagement Information

Engagement name
Customer
Start date
End date
Authorized testers
Executive sponsor
Technical owner
Control-team contact

Scope

In-scope assets
Out-of-scope assets
Approved accounts
Approved regions
Approved identities
Approved testing locations

Permitted Activities

Examples:

Passive reconnaissance
Approved authenticated enumeration
Controlled IAM validation
Safe privilege-path testing
Synthetic data access
Detection validation
Evidence collection

Prohibited Activities

Examples:

Denial of service
Data destruction
Malware deployment
Ransomware simulation without special approval
Production secret extraction
Real customer data access
Persistence beyond the approved test window
Unapproved third-party interaction

Testing Windows

Define:

Approved dates
Approved hours
Change-freeze periods
Restricted business periods
Maintenance windows

Communication Procedures

Define:

Daily updates
Emergency contact method
Escalation channel
Status reporting
Evidence transfer process

Stop Conditions

Define exactly when testing must stop.

Examples:

Production instability
Unexpected data access
Unapproved identity compromise
Service degradation
Customer emergency request
Third-party impact
Loss of control over a test action
Detection of an unrelated active compromise

Phase 05 — Define Stop Conditions

Stop conditions protect the customer, users, and Red Team.

The Red Team must stop immediately when:

An out-of-scope system is reached.
Real sensitive data is exposed unexpectedly.
A production service becomes unstable.
An unapproved account is accessed.
Customer operations may be affected.
A third-party resource may be impacted.
The control team issues a stop command.
The activity creates an uncontrolled condition.
Evidence suggests a real attacker is active.

Stop Procedure

Stop Activity

↓

Preserve Current Evidence

↓

Do Not Expand Access

↓

Notify Control Team

↓

Document Time and Context

↓

Await Written Direction

↓

Resume Only After Approval

Phase 06 — Establish the Control Team

A control team manages operational risk without disclosing the exercise broadly.

Typical Members

Executive sponsor
Security leader
Cloud platform owner
Legal representative
Incident-response lead
Red Team lead
Engagement coordinator

Responsibilities

The control team:

Approves the engagement.
Maintains emergency contact details.
Confirms scope.
Receives escalation notices.
Decides whether testing should pause.
Coordinates operational issues.
Protects the secrecy of the exercise where required.

Phase 07 — Build the Threat Model

Objective

Identify the adversaries and behaviours most relevant to the organization.

Threat Sources

Consider:

Financially motivated groups
Credential theft operators
Ransomware affiliates
Malicious insiders
Supply-chain attackers
Cloud-focused threat actors
Nation-state operators
Opportunistic attackers

Threat Model Components

Document:

Adversary profile
Likely objectives
Initial-access methods
Targeted identities
Targeted cloud services
Expected lateral movement
Data objectives
Detection opportunities

Example Threat Profile

Area	Description
Adversary	Cloud-focused credential theft group
Objective	Access sensitive application data
Initial Access	Compromised development identity
Primary Target	Over-permissioned execution role
Movement	Cross-account role assumption
Impact	Synthetic data access
Detection Goal	Validate IAM anomaly alerts

Phase 08 — Map Activities to MITRE ATT&CK

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

Cloud Red Team operations may map activities across tactics such as:

Reconnaissance
Resource Development
Initial Access
Execution
Persistence
Privilege Escation
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Command and Control
Exfiltration
Impact

ATT&CK Mapping Table

Engagement Activity	ATT&CK Tactic	Expected Defensive Control
Discover cloud resources	Discovery	Cloud inventory monitoring
Assume approved test role	Privilege Escalation	IAM anomaly alert
Access synthetic storage object	Collection	Data-access logging
Trigger controlled test function	Execution	Function invocation monitoring
Validate SOC alert	Detection Validation	SIEM correlation rule

The purpose is not to maximize the number of ATT&CK techniques used.

The purpose is to select behaviours relevant to the threat model and engagement objective.

Phase 09 — Design the Attack Scenario

Objective

Develop a realistic but controlled attack path.

A scenario should explain:

Where the operation begins.
What the simulated adversary knows.
Which actions are permitted.
Which security controls are being evaluated.
What represents success.
Where the operation must stop.

Example Scenario

Controlled Test Identity

↓

Cloud Resource Discovery

↓

Permission Analysis

↓

Approved Role Assumption

↓

Serverless Function Access

↓

Synthetic Secret Retrieval

↓

Synthetic Data Access

↓

SOC Detection Validation

↓

Engagement Stop

Scenario Validation Questions

Is every step authorized?
Does each step support the objective?
Are production systems protected?
Is synthetic data used?
Can the scenario be safely stopped?
Are defensive controls mapped?
Is evidence collection planned?
Are rollback steps available?

Phase 10 — Design the Operational Plan

The operational plan translates the scenario into controlled work packages.

Work Package Template

Field	Description
Activity ID	Unique identifier
Objective	What the activity validates
Target	Approved asset
Preconditions	Required access or setup
Method	High-level authorized approach
Expected Result	Anticipated outcome
Safety Control	Risk-reduction measure
Evidence	Required proof
Stop Condition	When to stop
Owner	Assigned operator

Example Work Package

Field	Value
Activity ID	RT-IDENTITY-01
Objective	Validate least privilege
Target	Approved AWS test role
Preconditions	Controlled low-privilege identity
Method	Review and safely validate approved role path
Expected Result	Role assumption succeeds or is blocked
Safety Control	No production resources
Evidence	CloudTrail event and sanitized screenshot
Stop Condition	Unexpected account reached
Owner	Red Team Operator 01

Phase 11 — Prepare the Red Team Infrastructure

Objective

Prepare a controlled environment for conducting and documenting the engagement.

Required Components

Approved operator workstations
Secure credential storage
Dedicated test identities
Approved source IP addresses
Evidence repository
Time synchronization
Encrypted communication channel
Activity log
Backup communication method

Operational Security Requirements

Use dedicated engagement accounts.
Do not reuse personal credentials.
Store secrets in an approved secrets manager.
Encrypt evidence at rest and in transit.
Synchronize systems to a trusted time source.
Separate customer engagements.
Restrict access to engagement data.
Remove test access after completion.

Phase 12 — Establish the Communications Plan

Daily Communication

A daily status report may contain:

Activities completed
Objectives achieved
Issues encountered
Safety concerns
Planned next steps
Required customer decisions

Emergency Communication

Define:

Primary emergency contact
Secondary contact
Telephone number
Secure messaging channel
Escalation phrase
Maximum response time

Example Escalation Levels

Level	Situation	Action
Level 1	Minor technical issue	Record and continue
Level 2	Unexpected access path	Pause affected activity
Level 3	Production risk	Stop and notify immediately
Level 4	Confirmed uncontrolled impact	Activate emergency response

Phase 13 — Plan Evidence Collection

Every important conclusion must be supported by evidence.

Evidence Types

Cloud audit logs
IAM policy exports
Role-assumption records
Function invocation logs
API request logs
Screenshots
CLI outputs
Architecture diagrams
Detection alerts
SOC tickets
Operator notes

Evidence Standards

Evidence should be:

Timestamped
Relevant
Sanitized
Securely stored
Traceable to an activity
Reproducible where possible
Free from unnecessary sensitive data

Evidence Register

Evidence ID	Activity	Source	Timestamp	Classification
EV-001	Role assumption	CloudTrail	UTC timestamp	Confidential
EV-002	Detection alert	SIEM	UTC timestamp	Confidential
EV-003	Synthetic data access	Storage audit log	UTC timestamp	Restricted

Phase 14 — Define Data-Handling Requirements

Cloud Red Team operations may encounter sensitive data unexpectedly.

Data-Handling Principles

Use synthetic data wherever possible.
Do not collect more data than necessary.
Do not store real credentials in notes.
Sanitize screenshots.
Mask account identifiers when required.
Encrypt evidence.
Follow retention requirements.
Delete evidence according to the agreement.

Unexpected Sensitive Data Procedure

Stop Viewing

↓

Do Not Copy

↓

Record Minimal Metadata

↓

Notify Control Team

↓

Follow Customer Direction

↓

Document the Decision

Phase 15 — Define Success Criteria

Success should not be measured only by whether the Red Team reached the final objective.

A strong engagement may be successful because the organization stopped the attack early.

Possible Success Outcomes

Preventive controls blocked the scenario.
SOC detected the activity.
Incident responders contained the activity.
An attack path reached the approved objective.
Evidence demonstrated an important control gap.
Purple Team collaboration improved detection coverage.

Success Matrix

Outcome	Meaning
Prevented	Security control blocked the activity
Detected	Activity occurred but was identified
Contained	Response team limited further progress
Successful Path	Approved objective reached
Not Tested	Scenario could not proceed safely
Inconclusive	Evidence was insufficient

Phase 16 — Conduct a Pre-Engagement Readiness Review

Before execution, confirm:

Authorization

Safety

Operations

Reporting

Activity log prepared
Evidence template prepared
Finding template prepared
ATT&CK mapping template prepared
Executive-report structure prepared

Phase 17 — Execute Using Controlled Decision Gates

Red Team activity should not progress automatically from one phase to the next.

Use decision gates.

Decision Gate 1 — Initial Access

Confirm:

Initial access is within scope.
The identity is approved.
No real user account was affected.
Evidence has been collected.

Decision Gate 2 — Privilege Escalation

Confirm:

The path is authorized.
The target role is in scope.
Production access will not be obtained.
Detection objectives are ready.

Decision Gate 3 — Lateral Movement

Confirm:

Destination assets are in scope.
Movement will not affect operations.
Synthetic targets are available.
Control team approval exists where required.

Decision Gate 4 — Impact Demonstration

Confirm:

Only synthetic data will be accessed.
No destructive action will occur.
Required evidence is defined.
Stop immediately after success.

Phase 18 — Maintain the Operator Activity Log

Every operator should maintain a detailed activity record.

Activity Log Fields

Date
Time in UTC
Operator
Activity ID
Target
Action
Result
Evidence reference
Safety observation
Next decision

Example

Time	Activity	Result	Evidence
09:10 UTC	Reviewed test identity permissions	Limited read access confirmed	EV-001
09:30 UTC	Validated approved role path	Role assumption permitted	EV-002
09:35 UTC	Checked SIEM alert	Alert generated	EV-003

Phase 19 — Coordinate Detection Validation

Cloud Red Team Operations should evaluate both attack-path security and defensive visibility.

Detection Areas

IAM policy changes
Role assumptions
Service Account activity
Managed Identity usage
API abuse
Function invocation anomalies
Storage access
Kubernetes administrative actions
Privileged container deployment
Secret retrieval
Cross-account activity

Detection Validation Record

Activity	Expected Telemetry	Expected Alert	Actual Result
Test role assumption	Cloud audit event	Unusual role alert	Detected / Not Detected
Synthetic secret access	Secret access log	High-risk secret alert	Detected / Not Detected
Test API burst	API logs	Rate anomaly	Detected / Not Detected

Phase 20 — Plan the Reporting Structure

A professional Cloud Red Team report should explain the complete attack story.

Executive Report

Include:

Engagement objective
Executive summary
Overall result
Business impact
Attack path overview
Security-control effectiveness
Detection and response performance
Strategic recommendations
Remediation roadmap

Technical Report

Include:

Scope
Rules of Engagement
Methodology
Threat model
Detailed attack path
Activity timeline
Evidence
ATT&CK mapping
Technical findings
Detection observations
Remediation guidance

Attack Path Reporting

Represent the full sequence rather than isolated findings.

Controlled Initial Access

↓

Excessive Identity Permission

↓

Approved Role Assumption

↓

Serverless Resource Access

↓

Synthetic Secret Retrieval

↓

Synthetic Data Access

↓

Delayed SOC Detection

For each stage document:

Enabling condition
Control expected
Control observed
Evidence
Business impact
Recommended improvement

Finding Structure

Every finding should contain:

Finding ID
Title
Description
Affected assets
Attack-path relevance
Technical impact
Business impact
Likelihood
Severity
Evidence
Recommendation
Remediation owner
Target date

Risk Rating

Severity	Description
Critical	Attack path enables immediate access to critical business assets
High	Significant progression toward a critical objective
Medium	Weakness contributes to an attack path under additional conditions
Low	Limited security weakness or hardening opportunity
Informational	Observation or maturity recommendation

Common Planning Failures

Cloud Red Team programmes frequently fail because of:

Unclear objectives
Broad or ambiguous scope
Missing written authorization
Weak communication
No stop conditions
Uncontrolled production testing
Poor evidence collection
Technical findings without business context
No detection objectives
No remediation ownership
Lack of post-engagement collaboration

Consultant Best Practices

Professional Cloud Red Team Operators should:

Obtain written authorization before every engagement.
Treat the Rules of Engagement as the controlling document.
Use synthetic data and dedicated test identities.
Separate technical ambition from business need.
Stop immediately when scope or safety becomes uncertain.
Preserve accurate timestamps and evidence.
Avoid unnecessary access to sensitive information.
Test defensive visibility, not only offensive paths.
Clearly distinguish confirmed facts from assumptions.
Communicate business impact in plain language.
Recommend controls that break multiple attack paths.
Close all temporary access after the engagement.

Key Takeaways

Cloud Red Team Operations are controlled business-risk simulations, not unrestricted hacking exercises.
Written authorization and Rules of Engagement are mandatory.
Objectives should be measurable and connected to business impact.
Threat modelling and ATT&CK mapping help select realistic adversary behaviours.
Stop conditions, control teams, and communication procedures protect the organization.
Evidence collection and activity logging are essential.
Detection and response validation are core Red Team outcomes.
Success may mean the organization prevented, detected, or contained the simulated attack.
Professional reporting should explain complete attack paths rather than isolated weaknesses.

Lesson Summary

In this lesson, you learned how professional Cloud Red Teams prepare authorized enterprise adversary-emulation engagements.

You defined business objectives, scope, Rules of Engagement, stop conditions, threat models, attack scenarios, operational plans, communication procedures, evidence requirements, decision gates, detection objectives, and reporting structures.

These foundations must be completed before technical Cloud Red Team activity begins.

A disciplined engagement protects the customer, provides trustworthy evidence, and ensures the results improve the organization’s ability to prevent, detect, and respond to cloud attacks.

Knowledge Check

What is the primary difference between a penetration test and a Red Team engagement?
Why should Red Team objectives be connected to business outcomes?
What information must be included in Rules of Engagement?
Give three examples of mandatory stop conditions.
What is the purpose of a control team?
Why should synthetic data be used during impact validation?
How does MITRE ATT&CK support engagement planning?
What is the purpose of operational decision gates?
What evidence should be collected during identity-abuse validation?
When can a defensive block still represent a successful engagement outcome?

Practical Assignment

Create a Cloud Red Team Engagement Plan for a fictional organization.

Your plan must include:

Business context
Executive objective
Three measurable technical objectives
In-scope assets
Out-of-scope assets
Permitted activities
Prohibited activities
Testing window
Control-team contacts
Five stop conditions
Threat profile
High-level attack scenario
MITRE ATT&CK mapping
Evidence requirements
Communication plan
Success criteria
Reporting deliverables
Remediation review process

Assignment Deliverables

Submit:

Cloud Red Team Engagement Plan
Rules of Engagement
Scope Register
Threat Model
Attack Scenario Diagram
ATT&CK Mapping Table
Evidence Register
Communication Matrix
Stop-Condition Checklist
Reporting Outline

What’s Next?

➡️ Lesson 02 — Initial Access & Cloud Reconnaissance

In the next lesson, you will learn how authorized Cloud Red Teams prepare and conduct cloud reconnaissance, identify exposed assets, map external attack surfaces, review public cloud metadata, discover identity entry points, and evaluate controlled initial-access scenarios without disrupting enterprise operations.

You will apply the planning, scope, safety, evidence, and decision-gate requirements established in this lesson throughout the reconnaissance and initial-access phase.