Lesson 04 — Lateral Movement Across Cloud Environments

Welcome

Lateral movement is the process of expanding access from an initial foothold to additional identities, services, workloads, or cloud environments.

In a traditional network, attackers often move between servers, user accounts, applications, and network segments.

In cloud environments, lateral movement is primarily driven by:

Identity permissions
Trust relationships
Cross-account access
Cross-subscription role assignments
Cross-project permissions
Workload identities
Shared secrets
CI/CD integrations
Kubernetes access
Serverless execution roles
Hybrid cloud connectivity
Resource-based policies

An attacker may begin with access to a low-privilege development identity but later discover a path to a more valuable resource through legitimate cloud relationships.

For example:

Compromised Development Identity

↓

Access to CI/CD Pipeline

↓

Deployment Workload Identity

↓

Production Cloud Subscription

↓

Kubernetes Cluster

↓

Application Secret

↓

Sensitive Test Dataset

No single action in this sequence may appear critical when reviewed independently.

However, when combined, these relationships may allow an attacker to move across multiple security boundaries and reach a business-critical objective.

As an authorized Cloud Red Team Operator, your responsibility is to identify these paths, validate only approved transitions, measure whether segmentation and monitoring controls are effective, and document the complete business impact.

Authorization requirement: Lateral-movement testing must be limited to explicitly approved identities, accounts, subscriptions, projects, clusters, workloads, and synthetic resources. Stop immediately if a path reaches an unapproved environment, real customer data, a third-party system, or an unexpected privileged identity.

Learning Objectives

After completing this lesson, you will be able to:

Explain lateral movement in cloud environments.
Identify cloud trust boundaries.
Map relationships between identities and resources.
Review cross-account and cross-environment access.
Assess workload-to-cloud identity relationships.
Review Kubernetes and container pivot opportunities.
Assess serverless and automation-based movement.
Identify shared-secret and credential pathways.
Review hybrid cloud connectivity.
Build enterprise lateral-movement attack maps.
Prioritize realistic movement paths.
Design controlled validation scenarios.
Apply operational decision gates.
Measure segmentation, logging, and detection controls.
Document business impact and remediation priorities.

Business Scenario

CloudNova Technologies is conducting an authorized Cloud Red Team engagement for MedSecure Global.

The Red Team has already established a controlled foothold using an approved low-privilege development identity.

During identity analysis, the team identified:

An AWS development role with limited deployment permissions
An Azure DevOps pipeline connected to a test subscription
A Google Cloud Service Account used by an automation process
A Kubernetes test cluster using cloud workload identities
A serverless function with access to a synthetic secret
Shared monitoring and logging services
Hybrid connectivity between cloud environments
Several cross-account and cross-project trust relationships

Executive leadership wants to determine whether a realistic attacker could use these relationships to move from the initial test identity to an approved synthetic business asset.

The Rules of Engagement permit:

Controlled movement within designated test environments
Approved role assumption
Approved workload identity validation
Access to synthetic secrets and test datasets
Detection validation
Review of cross-account and cross-project trust
Safe interaction with designated test Kubernetes clusters

The Rules of Engagement prohibit:

Access to production customer data
Persistent access beyond the testing window
Modification of real employee identities
Disruption of workloads
Destructive actions
Movement into unapproved accounts or tenants
Interaction with third-party environments

Your task is to map all relevant trust relationships, identify candidate movement paths, validate one approved path using minimum necessary actions, and determine whether enterprise controls can detect and contain the activity.

What Is Cloud Lateral Movement?

Cloud lateral movement is the controlled or unauthorized expansion of access from one cloud identity, resource, service, or environment to another.

The objective is typically to reach:

More privileged identities
Sensitive data
Production-like workloads
Administrative systems
Secrets
CI/CD platforms
Kubernetes clusters
Serverless functions
Central logging
Backup systems
Additional cloud accounts
Hybrid infrastructure

Cloud lateral movement often relies on legitimate permissions rather than software vulnerabilities.

Why Lateral Movement Is Different in the Cloud

Traditional lateral movement frequently depends on:

Network reachability
Operating-system credentials
Remote administration protocols
Shared local accounts
Domain trust

Cloud lateral movement frequently depends on:

IAM permissions
Role assumption
Resource policies
Service Accounts
Managed Identities
Temporary credentials
API access
Workload deployment
Federation
Cross-account trust
CI/CD automation
Secret-store access

This means that network segmentation alone does not prevent movement.

Identity and resource relationships must also be reviewed.

Cloud Lateral Movement Lifecycle

Initial Foothold

↓

Resource Discovery

↓

Identity Discovery

↓

Trust Relationship Analysis

↓

Candidate Path Identification

↓

Segmentation Review

↓

Decision Gate

↓

Controlled Movement

↓

Synthetic Objective Access

↓

Detection Validation

↓

Containment or Rollback

↓

Reporting

Common Lateral Movement Targets

High-value targets include:

Administrative roles
Security administration accounts
CI/CD deployment identities
Kubernetes cluster administrators
Serverless execution roles
Secret-management platforms
Central logging accounts
Backup environments
Shared network hubs
Production-like subscriptions
Data-processing projects
Container registries
Artifact repositories

Enterprise Trust Boundaries

A trust boundary separates systems, environments, identities, or business units with different security requirements.

Common cloud trust boundaries include:

Production and development
Account and account
Subscription and subscription
Project and project
Tenant and tenant
Region and region
Kubernetes namespace and namespace
Cluster and cluster
Cloud and on-premises
Customer and third-party platform
Application and shared service
Human identity and workload identity

A professional Red Team must clearly understand where each boundary begins and ends.

Trust-Boundary Map

Corporate Identity Provider

↓

Cloud Federation

├── AWS Organization
│   ├── Development Account
│   ├── Security Account
│   └── Production Account
│
├── Azure Tenant
│   ├── Development Subscription
│   ├── Shared Services Subscription
│   └── Production Subscription
│
└── Google Cloud Organization
    ├── Development Project
    ├── Security Project
    └── Production Project

The GoHackersCloud Lateral Movement Assessment Workflow

Confirm Scope

↓

Identify Starting Foothold

↓

Inventory Reachable Resources

↓

Review Identity Relationships

↓

Review Network and Service Connectivity

↓

Map Cross-Environment Trust

↓

Identify Candidate Paths

↓

Evaluate Business Relevance

↓

Apply Decision Gate

↓

Perform Minimum Controlled Validation

↓

Validate Logging and Detection

↓

Rollback or Revoke Access

↓

Document the Complete Path

Phase 01 — Confirm Lateral Movement Scope

Objective

Ensure that every potential source, transition, and target is explicitly authorized.

Confirm

Starting identity
Starting account
Destination account
Destination subscription
Destination project
Kubernetes cluster
Namespace
Serverless function
Storage service
Secret store
CI/CD platform
Approved testing window
Approved regions
Approved synthetic target

Movement Scope Register

Source	Destination	Platform	Scope Status	Restrictions
AWS Development Role	AWS Test Workload Role	AWS	Approved	Synthetic data only
Azure DevOps Test Pipeline	Azure Test Subscription	Azure	Approved	No production resources
GCP Test Service Account	GCP Test Project	GCP	Approved	No organization-level permissions
Test Kubernetes Cluster	Production Cluster	Kubernetes	Out of Scope	No interaction

Scope Rule

Every stage must be approved.

An approved starting identity does not authorize access to every resource it can technically reach.

Phase 02 — Identify the Starting Foothold

Document the exact access already obtained.

Record

Identity name
Identity type
Cloud platform
Authentication method
Permission level
Session duration
Assigned roles
Accessible resources
Source IP
Session identifier
Monitoring status

Starting Foothold Record

Field	Value
Identity	RedTeam-Developer
Platform	AWS
Environment	Development
Privilege	Low
Session Type	Temporary
Approved Resources	Test Account
Restrictions	No production access

Phase 03 — Enumerate Reachable Resources

Objective

Determine which approved resources the starting identity can discover or access.

Review

Cloud accounts
Subscriptions
Projects
Resource groups
VPCs and VNets
Storage services
Functions
Kubernetes clusters
Container registries
Secret stores
CI/CD platforms
Databases
Logging systems
Shared services

Classification

For each resource, record:

Visible
Readable
Writable
Executable
Administrable
Assumable
Impersonable
Deployable
Out of scope

Phase 04 — Review Identity Relationships

Lateral movement frequently depends on identity transitions.

Relationship Types

Can assume role
Can impersonate identity
Can assign role
Can pass identity to service
Can deploy workload using identity
Can update function using identity
Can modify pipeline
Can retrieve credentials
Can create temporary credentials
Can access federated identity
Can modify trust policy

Identity Relationship Map

Development User

↓

Member of DevOps Group

↓

Can Update Test Pipeline

↓

Pipeline Uses Deployment Identity

↓

Deployment Identity Can Access Test Subscription

↓

Test Subscription Contains Synthetic Secret

Phase 05 — Review Cross-Account Access in AWS

Assessment Areas

Review:

Role trust policies
AssumeRole permissions
AWS Organizations structure
Resource-based policies
Cross-account S3 access
KMS key policies
Lambda resource policies
ECR repository policies
EventBridge permissions
Shared services
Transit networking

Questions

Which roles trust the starting identity?
Are external IDs or restrictive conditions used?
Can the identity pass another role to a service?
Are resource policies broader than intended?
Can a development role reach a shared services account?
Are sensitive services accessible across accounts?
Is cross-account activity monitored?

Phase 06 — Review Cross-Subscription Movement in Azure

Assessment Areas

Review:

Azure RBAC assignments
Management Group inheritance
Subscription-level roles
Managed Identities
Service Principals
Azure DevOps service connections
Key Vault access
Storage permissions
Function App identities
Automation Accounts
Shared VNets
Private endpoints

Questions

Does the identity hold roles across subscriptions?
Are role assignments inherited?
Can the identity modify a deployment pipeline?
Can a Managed Identity reach additional resources?
Are development and production separated?
Can shared services provide a bridge?
Is Microsoft Entra activity monitored?

Phase 07 — Review Cross-Project Movement in Google Cloud

Assessment Areas

Review:

Service Account impersonation
Project IAM bindings
Folder-level inheritance
Organization-level roles
Shared VPC
Workload Identity Federation
Cloud Build Service Accounts
Cloud Functions Service Accounts
Secret Manager access
Artifact Registry access
Pub/Sub permissions
Cross-project resource access

Questions

Can the starting identity impersonate another Service Account?
Are Service Accounts shared between projects?
Are folder-level roles broader than intended?
Can a development project access shared production services?
Does Shared VPC create unexpected reachability?
Are cross-project actions logged?

Phase 08 — Review Kubernetes Pivot Paths

Kubernetes environments often provide paths between application workloads and cloud control planes.

Review

Kubernetes Service Accounts
Cloud workload identities
Mounted tokens
RBAC permissions
Node identities
Cluster-admin access
Secret access
Namespace isolation
CI/CD integrations
Cloud metadata access
Container registry permissions

Potential Relationships

Compromised Test Pod

↓

Kubernetes Service Account

↓

Cloud Workload Identity

↓

Cloud Secret Store

↓

Synthetic Application Credential

Assessment Questions

Which Service Account does the workload use?
What RBAC permissions are assigned?
Is cloud Workload Identity configured?
Can the workload access cloud APIs?
Are namespaces properly isolated?
Can the identity access secrets?
Are workload actions monitored?

Phase 09 — Review Container and Registry Movement

Container ecosystems can connect development and production environments.

Review

Container registry permissions
Image-push permissions
Image-pull permissions
CI/CD image promotion
Registry trust
Deployment automation
Image signing
Admission controls
Shared build agents
Runtime identities

Example Relationship

Development Pipeline

↓

Can Push to Test Registry

↓

Shared Promotion Workflow

↓

Production-Like Cluster Pulls Image

↓

Workload Runs with Elevated Identity

The assessment should focus on whether governance and access controls prevent unauthorized movement through the software delivery chain.

Phase 10 — Review Serverless Pivot Paths

Serverless functions frequently connect multiple cloud services.

Review

Execution identities
Function resource policies
Event sources
API integrations
Secret access
Storage access
Database access
Cross-account invocation
CI/CD deployment permissions
Environment variables

Example Relationship

Approved Test API

↓

Serverless Function

↓

Execution Role

↓

Secret Manager

↓

Synthetic Database

Assessment Questions

Can the starting identity update the function?
Can it invoke the function?
Which execution identity does the function use?
Can the function access additional services?
Are resource policies restricted?
Are function invocations monitored?

Phase 11 — Review CI/CD and Automation Movement

CI/CD platforms often possess broad deployment permissions.

Review

Pipeline identities
Service connections
Build agents
Deployment roles
Repository permissions
Workflow modification permissions
Environment approvals
Secret storage
Artifact access
Branch protection
Production gates

Common Risks

Shared deployment identity
Excessive cloud permissions
Unprotected workflow changes
Weak branch controls
Long-lived credentials
Pipeline access to multiple environments
Missing deployment approvals
Incomplete audit logs

Phase 12 — Review Secret-Based Movement

Secrets may provide access to additional systems.

Secret Sources

AWS Secrets Manager
Azure Key Vault
Google Secret Manager
Kubernetes Secrets
CI/CD variables
Environment variables
Configuration files
Shared storage
Application logs

Safe Assessment Principles

Use synthetic secrets.
Do not retrieve real credentials.
Validate only approved access.
Do not reuse production credentials.
Capture minimal evidence.
Rotate or revoke test secrets after validation.

Phase 13 — Review Network-Based Movement

Identity is central, but network connectivity still matters.

Review

VPC peering
VNet peering
Shared VPC
Transit gateways
Private endpoints
VPN
Direct Connect
ExpressRoute
Cloud Interconnect
Service endpoints
Kubernetes networking
Firewall rules
Security Groups
Network Policies

Questions

Can development reach production-like services?
Are private endpoints properly restricted?
Does shared networking bypass segmentation?
Can cloud workloads reach on-premises assets?
Is east-west traffic monitored?
Are DNS and service-discovery paths restricted?

Phase 14 — Review Hybrid Cloud Movement

Hybrid cloud environments connect cloud and on-premises infrastructure.

Review

Federated identity
Active Directory integration
VPN connectivity
Private circuits
Shared DNS
Management tooling
Backup systems
Monitoring platforms
Endpoint-management systems
Administrative jump hosts

Hybrid Risks

Cloud identity trusted on-premises
On-premises account trusted in cloud
Shared administrative credentials
Broad network routing
Inadequate segmentation
Weak monitoring across boundaries
Shared automation systems

Phase 15 — Identify Candidate Lateral Movement Paths

A candidate path should connect the starting foothold to an approved objective.

Candidate Path Example

Low-Privilege Test Identity

↓

Can Update Test Pipeline

↓

Pipeline Uses Deployment Role

↓

Deployment Role Can Access Kubernetes Test Cluster

↓

Cluster Workload Identity Can Read Synthetic Secret

↓

Approved Objective Reached

Candidate Path Matrix

Path ID	Source	Destination	Business Relevance	Safety	Detection Value	Priority
LM-01	AWS Dev Role	Test Lambda Role	High	High	High	High
LM-02	Azure DevOps Pipeline	Test Subscription	High	Medium	High	High
LM-03	GCP Test SA	Shared Test Project	Medium	High	Medium	Medium

Phase 16 — Evaluate Segmentation Controls

Before validation, determine which controls should stop the path.

Identity Segmentation

Separate roles
Permission boundaries
Conditional access
Resource restrictions
Deny policies
Temporary elevation

Network Segmentation

Firewalls
Security Groups
Network Security Groups
Network Policies
Private endpoints
Route restrictions

Environment Segmentation

Separate accounts
Separate subscriptions
Separate projects
Separate clusters
Separate CI/CD pipelines
Separate registries

Operational Segmentation

Deployment approvals
Change management
Privileged access management
Two-person approval
Security reviews

Phase 17 — Design a Controlled Movement Scenario

Scenario Template

Field	Description
Scenario ID	Unique identifier
Starting Foothold	Approved identity or workload
Transition 1	First approved relationship
Transition 2	Second approved relationship
Objective	Synthetic business asset
Minimum Action	Smallest required validation
Expected Controls	Preventive and detective controls
Evidence	Required proof
Rollback	Required cleanup
Stop Condition	Immediate halt trigger

Example Scenario

Field	Value
Scenario ID	LM-VAL-01
Starting Foothold	Azure Dev Test Identity
Transition 1	Approved DevOps service connection
Transition 2	Test subscription deployment identity
Objective	Synthetic Key Vault secret
Minimum Action	Confirm controlled secret access
Expected Controls	RBAC restriction and Sentinel alert
Evidence	Activity log and secret access event
Rollback	Remove temporary deployment
Stop Condition	Production subscription reached

Phase 18 — Lateral Movement Decision Gate

Before each transition, confirm:

Scope

Safety

Synthetic target is available
No real customer data is involved
No destructive action is required
Rollback procedure exists
Operational owner is identified

Detection

Decision

Condition	Action
All controls confirmed	Proceed
Destination ownership uncertain	Pause
Production access possible	Stop
Logs unavailable	Delay or record limitation
Third-party system involved	Exclude
Rollback untested	Redesign

Phase 19 — Perform Minimum Controlled Validation

The objective is to prove the relationship, not maximize access.

Controlled Workflow

Confirm Decision Gate

↓

Record Current Identity

↓

Perform First Approved Transition

↓

Confirm Destination Context

↓

Capture Evidence

↓

Perform Minimum Next Transition

↓

Access Synthetic Objective

↓

Validate Logs and Alerts

↓

Revoke Access

↓

Confirm Cleanup

↓

Document Outcome

Minimum-Action Principles

Use temporary access.
Avoid policy modification where possible.
Do not change production configurations.
Do not copy real data.
Stop after proving the objective.
Do not extend the path without approval.
Validate the destination identity after every transition.

Phase 20 — Validate Context After Every Transition

After movement, confirm:

Current identity
Current account
Current subscription
Current project
Current region
Current cluster
Current namespace
Current resource
Current privilege level
Current scope status

This prevents accidental movement into an unapproved environment.

Phase 21 — Validate Logging and Detection

Each movement step should generate observable telemetry.

AWS Sources

CloudTrail
GuardDuty
Security Hub
CloudWatch
IAM Access Analyzer
VPC Flow Logs
EKS Audit Logs

Azure Sources

Azure Activity Logs
Microsoft Entra ID logs
Microsoft Defender for Cloud
Microsoft Sentinel
Network Watcher
AKS logs
Key Vault logs

Google Cloud Sources

Cloud Audit Logs
Cloud Logging
Security Command Center
VPC Flow Logs
GKE Audit Logs
Secret Manager access logs

Kubernetes Sources

Kubernetes Audit Logs
Runtime monitoring
Admission-controller logs
Network telemetry
SIEM
Workload identity logs

Detection Validation Table

Movement Activity	Expected Telemetry	Expected Alert	Actual Result
Cross-account role assumption	Cloud audit log	Unusual role usage	Detected / Not Detected
Pipeline identity used	DevOps audit log	Unusual deployment	Detected / Not Detected
Kubernetes identity accessed secret	Audit and secret log	High-value secret alert	Detected / Not Detected
Cross-project Service Account use	IAM audit log	Impersonation alert	Detected / Not Detected

Phase 22 — Measure Segmentation Effectiveness

For each attempted movement, record whether it was:

Prevented
Allowed
Detected
Contained
Delayed
Inconclusive

Segmentation Scorecard

Control Area	Result
Account Separation	Effective / Partial / Ineffective
Identity Segmentation	Effective / Partial / Ineffective
Network Segmentation	Effective / Partial / Ineffective
Kubernetes Isolation	Effective / Partial / Ineffective
Pipeline Governance	Effective / Partial / Ineffective
Detection Coverage	Effective / Partial / Ineffective
Response Capability	Effective / Partial / Ineffective

Phase 23 — Review Containment Capability

The Red Team should assess whether defenders can interrupt movement.

Containment Actions

Revoke sessions
Disable test identities
Remove role assignments
block source IP
disable service connections
isolate workload
suspend pipeline
block API
rotate test secret
quarantine container image

Measure

Time to detection
Time to triage
Time to escalation
Time to containment
Accuracy of investigation
Completeness of evidence
Communication effectiveness

Phase 24 — Roll Back All Temporary Changes

Cleanup Checklist

Phase 25 — Document the Complete Movement Path

Do not report each cloud action separately.

Document the connected path.

Example

Approved Development Identity

↓

Can Modify Test CI/CD Workflow

↓

Pipeline Uses Shared Deployment Identity

↓

Deployment Identity Can Access Test Kubernetes Cluster

↓

Cluster Workload Identity Can Read Synthetic Secret

↓

Synthetic Business Objective Reached

↓

SOC Detected Activity After Final Stage

For Every Stage Record

Source identity
Destination identity
Permission used
Trust relationship
Resource accessed
Expected control
Observed control
Evidence
Detection result
Business relevance
Recommended remediation

Phase 26 — Risk Classification

Severity	Description
Critical	Movement path reaches critical business assets or administrative control
High	Path crosses major trust boundaries and accesses sensitive resources
Medium	Path contributes to broader movement but requires additional conditions
Low	Limited segmentation or governance weakness
Informational	Maturity or architecture recommendation

Risk Factors

Consider:

Number of boundaries crossed
Starting privilege
Final privilege
Data sensitivity
Production proximity
Ease of movement
Detection capability
Containment capability
Persistence potential
Business impact

Phase 27 — Prepare the Lateral Movement Report

Executive Summary

Include:

Engagement objective
Starting foothold
Movement path achieved
Trust boundaries crossed
Synthetic objective reached
Detection and response result
Business impact
Strategic recommendations

Technical Report

Include:

Scope
Methodology
Trust-boundary map
Identity relationship map
Network relationship map
Candidate path matrix
Controlled validation steps
Audit evidence
Detection results
Segmentation scorecard
Findings
Remediation roadmap

Common Enterprise Findings

Cloud lateral-movement assessments frequently identify:

Cross-account trust without restrictive conditions
Broad subscription-level permissions
Shared Service Accounts
Shared Managed Identities
CI/CD identities spanning multiple environments
Development access to production-like services
Kubernetes workloads with cloud permissions
Shared container registries
Excessive secret-store access
Weak network segmentation
Missing environment separation
Incomplete cross-cloud logging
Delayed SOC detection
Poor ownership of shared services

Remediation Strategy

Identity Controls

Restrict trust policies.
Use dedicated identities per workload.
eliminate shared Service Accounts.
reduce cross-account permissions.
require temporary elevation.
restrict impersonation.
apply explicit deny controls.

Environment Separation

Separate development and production.
use separate accounts, subscriptions, and projects.
separate CI/CD pipelines.
separate registries.
isolate Kubernetes clusters.
limit shared services.

Network Controls

Restrict peering.
tighten private endpoint access.
apply Network Policies.
review routing.
monitor east-west traffic.
segment hybrid connectivity.

Pipeline Controls

Use environment-specific deployment identities.
require approvals.
protect branches.
sign artifacts.
limit secret access.
monitor service connections.

Monitoring Controls

Alert on cross-account role usage.
monitor Service Account impersonation.
detect unusual Managed Identity activity.
correlate pipeline and cloud events.
monitor secret access.
alert on unexpected cluster access.

Consultant Best Practices

Professional Cloud Red Team Operators should:

Map trust boundaries before testing movement.
Confirm scope before every transition.
Treat shared automation identities as high-risk assets.
Review workload identities alongside human identities.
Use synthetic secrets and test datasets.
Apply decision gates at every major boundary.
Validate current identity and environment after each transition.
Perform only the minimum action required.
Preserve timestamps and evidence.
Test both segmentation and detection.
Revoke temporary access immediately.
Report the complete attack path and business impact.
Recommend controls that break multiple movement stages.

Key Takeaways

Cloud lateral movement is primarily identity and trust driven.
Cross-account, cross-subscription, and cross-project relationships require careful review.
Kubernetes, serverless, container registries, CI/CD pipelines, and secret stores can bridge security boundaries.
Network segmentation alone is insufficient.
Every transition must be explicitly authorized.
Controlled validation requires synthetic assets, minimum actions, decision gates, and rollback procedures.
Detection and containment are essential engagement outcomes.
Findings should be reported as complete movement paths rather than isolated permissions.

Lesson Summary

In this lesson, you learned how authorized Cloud Red Teams assess lateral movement across AWS, Microsoft Azure, Google Cloud, Kubernetes, containers, serverless platforms, CI/CD systems, and hybrid environments.

You mapped trust boundaries, reviewed cross-environment relationships, identified candidate movement paths, evaluated segmentation controls, designed controlled validation scenarios, applied operational decision gates, measured detection and containment, rolled back temporary changes, and documented business impact.

A professional lateral-movement assessment demonstrates how legitimate cloud relationships can combine into a meaningful attack path while ensuring that every action remains controlled, reversible, and aligned with the approved business objective.

Knowledge Check

Why is cloud lateral movement primarily identity driven?
What is a trust boundary?
Why must every intermediate service be in scope?
How can CI/CD pipelines enable movement between environments?
How can Kubernetes workload identities create cloud access paths?
Why should serverless execution roles be reviewed?
What must be confirmed at the lateral-movement decision gate?
Why should the operator validate context after every transition?
Which telemetry supports lateral-movement detection?
Why should findings be reported as complete attack paths?

Practical Assignment

Create an Enterprise Cloud Lateral Movement Assessment Plan for a fictional multi-cloud organization.

Your plan must include:

Starting foothold
Approved scope
Trust-boundary diagram
AWS cross-account relationships
Azure cross-subscription relationships
Google Cloud cross-project relationships
Kubernetes workload identity map
Serverless identity map
CI/CD service-connection map
Hybrid connectivity review
Three candidate movement paths
Path-prioritization matrix
Controlled validation scenario
Decision-gate checklist
Expected telemetry
Detection-validation plan
Containment plan
Rollback checklist
Risk-rating model
Reporting structure
Remediation roadmap

Assignment Deliverables

Submit:

Lateral Movement Assessment Plan
Trust-Boundary Diagram
Identity Relationship Map
Network Relationship Map
Cross-Environment Access Matrix
Candidate Path Matrix
Controlled Validation Plan
Decision-Gate Checklist
Evidence Register
Detection Validation Table
Segmentation Scorecard
Executive Movement Summary
Technical Assessment Report
Remediation Roadmap

What’s Next?

➡️ Lesson 05 — Persistence & Defense Evasion

In the next lesson, you will learn how authorized Cloud Red Teams assess persistence and defense-evasion risks across cloud identities, automation platforms, Kubernetes workloads, serverless services, logging systems, and multi-cloud environments.

You will identify conditions that could support long-term access, design safe persistence simulations, review opportunities to weaken visibility, validate monitoring controls, apply strict decision gates, and recommend enterprise controls that prevent attackers from maintaining access or hiding their activity.