Project 05 — Multi-Cloud Enterprise Red Team Capstone

Project Overview

Modern enterprises rarely operate in only one technology environment.

A realistic organisation may simultaneously use:

AWS for production workloads
Microsoft Azure for enterprise applications
Microsoft Entra ID for workforce identity
Google Cloud for analytics or development
Kubernetes for container platforms
SaaS platforms for collaboration
Git repositories and CI/CD pipelines
Internet-facing applications
VPN and remote-access services
Centralised SIEM and security monitoring

A real attacker does not necessarily remain inside the platform where the initial weakness was discovered.

An attack might begin with an exposed application in one cloud and eventually affect identities or workloads hosted elsewhere.

The goal of this capstone is therefore not to find isolated vulnerabilities.

The goal is to understand enterprise attack paths across multiple cloud platforms.

External Exposure → Initial Access Opportunity → Identity → Privilege → Trust Relationship → Cloud Resource → Cross-Cloud Path → Critical Asset → Business Impact

This final project brings together the reconnaissance, cloud security, identity, application security, attack-path analysis, evidence collection, and reporting skills developed throughout the learning path.

1. Mission

You have been engaged as part of an authorised red team assessment for a fictional enterprise:

ApexNova Technologies

The organisation operates workloads across:

                        Internet
                           |
              +------------+------------+
              |                         |
         Public Web Apps             SaaS Services
              |
        +-----+------+-------------------+
        |            |                   |
       AWS          Azure               GCP
        |            |                   |
      EC2 /        App Service /       Compute /
      EKS          VMs / AKS           GKE
        |            |                   |
      IAM        Microsoft Entra       Cloud IAM
        |            ID                  |
        +------------+-------------------+
                     |
               Enterprise Identity
                     |
               Critical Assets

Your objective is to determine whether weaknesses across these environments could be combined into meaningful enterprise attack paths.

2. Engagement Objectives

By the end of this project, you should be able to:

Establish the authorised engagement scope.
Map a multi-cloud enterprise attack surface.
Identify internet-facing cloud assets.
Analyse AWS, Azure, and GCP identities.
Review workload and service identities.
Identify excessive permissions.
Analyse trust relationships.
Review exposed applications and APIs.
Evaluate network segmentation.
Identify cloud privilege-escalation opportunities.
Analyse cross-cloud relationships.
Identify paths toward critical enterprise assets.
assess defensive visibility.
demonstrate impact safely.
collect professional evidence.
construct attack-path narratives.
prioritise findings by business risk.
recommend remediation.
produce a professional red team report.
deliver an executive-level summary.

3. Authorisation Requirement

This capstone must only be performed against:

your own cloud accounts;
intentionally vulnerable training environments;
isolated GoHackersCloud Labs;
environments where you have explicit written authorisation.

Do not test production infrastructure, third-party SaaS services, public cloud tenants, or organisations without written permission.

The purpose of the project is to develop professional assessment methodology—not uncontrolled exploitation.

4. Mission Information

Item	Details
Project	Multi-Cloud Enterprise Red Team Capstone
Difficulty	Advanced
Environment	AWS + Azure + GCP
Assessment Type	Authorised Red Team Simulation
Duration	6–10 Hours
Primary Skills	Recon, IAM, Cloud Security, Attack Paths, Reporting
Platforms	AWS, Azure, Google Cloud
Optional Platforms	Kubernetes, GitHub, CI/CD
Deliverables	Evidence Pack, Attack Path Register, Findings Register, Final Report
Destructive Testing	Not Required

5. Fictional Enterprise Scenario

ApexNova Technologies is a growing software company.

The environment contains approximately:

Employees:                1,200
Cloud Accounts:           Multiple
Primary Identity:         Microsoft Entra ID
Production Platform:      AWS
Enterprise Applications:  Azure
Analytics Platform:       GCP
Container Platforms:      EKS / AKS / GKE
Remote Workforce:         Enabled
Central Logging:          SIEM

The organisation recently acquired another business and has rapidly integrated several cloud platforms.

Management is concerned that:

identity permissions have grown excessively;
cloud resources may be publicly exposed;
service accounts may have unnecessary privileges;
legacy trust relationships remain;
cloud logging may be incomplete;
development environments may provide paths into production.

You have been asked to validate these concerns.

6. Scope

Example authorised scope:

AWS
Account: 111111111111
Regions:
- us-east-1
- us-west-2

Azure
Tenant:
apexnova-lab.onmicrosoft.com

Subscriptions:
- Development
- Production

Google Cloud
Projects:
- apexnova-dev
- apexnova-prod

Approved domains:

*.apexnova.lab
api.apexnova.lab
portal.apexnova.lab
dev.apexnova.lab

Approved testing identities:

AWS:
redteam-lab-user

Azure:
redteam.user@apexnova.lab

GCP:
redteam@apexnova.lab

7. Out of Scope

Example exclusions:

Denial-of-Service testing
Production customer data
Employee personal devices
Social engineering
Third-party SaaS platforms
Third-party infrastructure
Destructive database actions
Persistence outside the agreed lab
Credential attacks against real users

8. Rules of Engagement

Before starting, document:

Authorised cloud accounts
Authorised subscriptions
Authorised projects
Approved regions
Approved identities
Approved IP ranges
Approved applications
Testing windows
Logging expectations
Emergency contacts
Stop conditions
Evidence requirements

9. Stop Conditions

Immediately stop the relevant activity if you encounter:

real customer data;
production credentials outside scope;
healthcare or regulated data not covered by the engagement;
infrastructure outside the authorised tenant;
instability affecting production;
evidence that the testing could cause disruption.

Escalate according to the engagement communication plan.

10. Red Team Methodology

Use the following methodology throughout the project.

Authorisation
     |
     v
Scope Validation
     |
     v
External Reconnaissance
     |
     v
Cloud Asset Discovery
     |
     v
Identity Enumeration
     |
     v
Permission Analysis
     |
     v
Application Analysis
     |
     v
Trust Relationship Analysis
     |
     v
Attack Path Development
     |
     v
Controlled Validation
     |
     v
Business Impact Analysis
     |
     v
Detection Review
     |
     v
Evidence Collection
     |
     v
Reporting

11. Create Your Project Workspace

Create a structured workspace before beginning.

Project-05-Multi-Cloud-Capstone/
|
├── 01-Scope/
├── 02-Recon/
├── 03-AWS/
├── 04-Azure/
├── 05-GCP/
├── 06-Applications/
├── 07-Identity/
├── 08-Network/
├── 09-Attack-Paths/
├── 10-Evidence/
├── 11-Findings/
├── 12-Detection/
├── 13-Remediation/
└── 14-Final-Report/

Professional assessments become much easier when evidence is organised from the beginning.

12. Build the Enterprise Asset Model

Start with the enterprise rather than individual vulnerabilities.

Create an asset inventory.

Platform	Asset	Environment	Exposure	Criticality
AWS	Production API	Production	Internet	Critical
AWS	EKS Cluster	Production	Internal	Critical
Azure	Admin Portal	Production	Internet	High
Azure	AKS Cluster	Production	Internal	High
GCP	Analytics Platform	Production	Internal	High
GCP	Storage Bucket	Development	Restricted	Medium

13. Identify Critical Assets

Determine what an attacker would consider high-value.

Possible examples:

Customer Database
Identity Platform
Production AWS Account
Azure Subscription Owners
GCP Organisation Administrators
CI/CD Platform
Container Registry
Secrets Manager
Key Vault
Production Kubernetes Cluster
Source Code Repository
Backup Infrastructure
Security Monitoring Platform

Mark each asset:

Critical
High
Medium
Low

This allows attack paths to be prioritised according to impact.

14. Phase 1 — External Reconnaissance

Begin with the authorised external footprint.

Identify:

Domains
Subdomains
Public IP addresses
Web applications
APIs
Cloud-hosted services
Authentication portals
Storage endpoints
Developer environments
Administrative interfaces

Create:

External Attack Surface Register

Example:

Asset	Platform	Exposure	Authentication	Notes
portal.apexnova.lab	Azure	Public	Entra ID	Customer portal
api.apexnova.lab	AWS	Public	API token	Production API
dev.apexnova.lab	AWS	Public	Local auth	Development
analytics.apexnova.lab	GCP	Restricted	Google Identity	Analytics

15. Analyse the Attack Surface

For each externally accessible service ask:

Why is this exposed?
Who should access it?
What authentication protects it?
What application is behind it?
What identity system is used?
Does it expose management functionality?
Does it connect to internal services?
Does it use cloud workload identities?

You are already beginning to build attack paths.

16. Phase 2 — AWS Assessment

Authenticate using only the provided laboratory identity.

Confirm the current identity.

aws sts get-caller-identity

Record:

Account ID
Principal ARN
Identity type
Session context

17. AWS Inventory

Create an inventory of authorised AWS resources.

Focus on:

IAM
EC2
S3
Lambda
ECS
EKS
RDS
Secrets Manager
Systems Manager
CloudTrail
CloudWatch
VPC
Security Groups
KMS

Do not treat resource discovery as a vulnerability.

The objective is to understand architecture.

18. AWS IAM Review

Evaluate:

Users
Roles
Groups
Policies
Service roles
Permission boundaries
Cross-account roles
Trust policies
Access keys
Federated identities

Build an identity table.

Identity	Type	Privilege	Trust	Risk
dev-user	User	Limited	None	Low
app-role	Role	Moderate	EC2	Medium
automation-role	Role	High	CI/CD	High

19. AWS Permission Questions

For every important identity ask:

What can this identity access?

What identities can it assume?

Can it modify IAM?

Can it attach policies?

Can it change resource policies?

Can it access secrets?

Can it deploy compute resources?

Can it affect logging?

Can it reach another AWS account?

20. AWS Trust Relationships

Cloud privilege often comes from trust, not direct permissions.

Review:

IAM role trust policies
Cross-account relationships
Federation
Workload identities
Service-linked roles
CI/CD roles
Third-party integrations

Represent relationships visually.

Developer
   |
   v
Development Role
   |
   v
Automation Role
   |
   v
Production Deployment Role

21. AWS Data Exposure Review

Evaluate authorised resources such as:

S3 buckets
RDS databases
EBS snapshots
Secrets Manager
Parameter Store
Container registries

Questions:

Is the resource public?

Who can access it?

Are permissions broader than required?

Could one cloud identity reach sensitive data?

Does the resource policy trust another account?

22. AWS Network Review

Map:

VPCs
Subnets
Internet Gateways
NAT Gateways
Security Groups
Network ACLs
Load Balancers
Private Endpoints
Peering
Transit Gateways

Create a simple network diagram.

Internet
   |
Load Balancer
   |
Application Tier
   |
Database Tier

Identify unintended trust.

23. AWS Workload Identities

Cloud workloads often receive credentials indirectly.

Examples include:

EC2 IAM Roles
Lambda Execution Roles
ECS Task Roles
EKS Workload Identities
CI/CD Deployment Roles

Ask:

If the workload were compromised, what cloud permissions would the attacker inherit?

This question is critical during cloud red team assessments.

24. Phase 3 — Azure Assessment

Authenticate only using the authorised test identity.

Confirm the active account and subscription.

az account show

Record:

Tenant
Subscription
Identity
Role
Environment

25. Azure Resource Inventory

Review:

Subscriptions
Resource Groups
Virtual Machines
Storage Accounts
App Services
Functions
AKS
Key Vault
SQL
Networking
Managed Identities
Microsoft Entra ID
Defender for Cloud
Azure Monitor

26. Microsoft Entra ID Review

Enterprise Azure environments frequently depend on Entra ID as their identity control plane.

Review:

Users
Groups
Applications
Service Principals
Enterprise Applications
Administrative Roles
Managed Identities
Conditional Access
Federation

27. Azure RBAC

Understand the relationship:

Identity
   |
   v
Role Assignment
   |
   v
Scope
   |
   v
Resource

Important roles may include:

Owner
Contributor
Reader
User Access Administrator

Do not evaluate roles only by name.

Evaluate what effective privileges they provide.

28. Azure Managed Identity Review

Workloads may authenticate using:

System-assigned Managed Identities
User-assigned Managed Identities
Service Principals
Federated Workload Identities

Ask:

Which workloads use this identity?

What permissions does it have?

Can it access Key Vault?

Can it modify infrastructure?

Can it influence another identity?

29. Azure Key Vault Review

Assess:

Secrets
Keys
Certificates
RBAC
Access policies
Network restrictions
Logging
Workload access

The existence of a secret is not automatically a vulnerability.

The question is:

Can an identity access secrets that it does not need?

30. Azure Network Architecture

Map:

Virtual Networks
Subnets
Network Security Groups
Private Endpoints
Application Gateways
Load Balancers
Firewalls
VNet Peering
VPN
ExpressRoute

Look for paths between:

Development
Production
Management
Identity
Security

31. Phase 4 — Google Cloud Assessment

Confirm the authorised identity.

gcloud auth list

Identify the selected project.

gcloud config get-value project

32. GCP Resource Inventory

Review:

Projects
Compute Engine
Cloud Storage
Cloud Run
Cloud Functions
GKE
Cloud SQL
Secret Manager
VPC
Firewall Rules
Service Accounts
Cloud Logging
Cloud KMS

33. GCP IAM Model

Understand:

Principal
   |
   v
Role
   |
   v
Resource

Review:

Users
Groups
Service Accounts
Custom Roles
Predefined Roles
Project IAM
Folder IAM
Organisation IAM

34. GCP Service Accounts

Service accounts are particularly important during cloud security assessments.

Review:

Which workloads use them?

What roles are assigned?

Can users impersonate them?

Can they access sensitive resources?

Are permissions inherited?

Can one service account influence another?

Create a relationship graph.

Developer
    |
    v
Application Service Account
    |
    v
Storage / Secret / Compute Permissions

35. GCP Storage Review

Evaluate Cloud Storage for:

Public exposure
IAM bindings
Inherited permissions
Sensitive files
Logs
Backups
Application configuration

Always distinguish between:

Public identifier
Non-sensitive configuration
Sensitive credential
Actual security vulnerability

36. GCP Network Review

Map:

VPCs
Subnets
Firewall Rules
Cloud NAT
Load Balancers
Private Service Access
VPC Peering
Shared VPC

Ask:

Which workloads can communicate?

Which environments share networks?

Can development reach production?

Can management systems be reached unnecessarily?

37. Phase 5 — Application Security

Return to the externally accessible applications discovered during reconnaissance.

Map each application to its cloud environment.

Application
      |
      v
Cloud Platform
      |
      v
Workload
      |
      v
Workload Identity
      |
      v
Cloud Permission

This is where application and cloud security begin to converge.

38. Application Questions

Evaluate:

Authentication
Sessions
Authorization
APIs
Input handling
File handling
Administrative interfaces
Secrets
Cloud integrations
Storage integrations
Identity integrations

If weaknesses are found, determine whether they provide access to cloud resources.

39. API Security

Assess authorised APIs for:

Object-level authorization
Function-level authorization
Authentication
Token handling
Tenant separation
Data exposure
Rate limits
Input validation
Backend trust assumptions

A critical attack path may begin with something as simple as:

Web API Authorization Failure
          |
          v
Application Account Compromise
          |
          v
Backend Service Access

40. Phase 6 — Kubernetes Review

If Kubernetes environments are included, review:

EKS
AKS
GKE

Evaluate:

Cluster exposure
RBAC
Namespaces
Service accounts
Secrets
Network policies
Container privileges
Workload identities
Admission controls
Logging

41. Kubernetes Workload Identity

One important relationship is:

Pod
 |
 v
Kubernetes Service Account
 |
 v
Cloud Workload Identity
 |
 v
Cloud IAM Permission

A weak application container may therefore become a cloud identity problem.

42. Kubernetes Attack Path Example

Vulnerable Application
        |
        v
Application Container
        |
        v
Workload Identity
        |
        v
Cloud Secret Access
        |
        v
Production Service

Your job is to determine whether the complete chain is realistically possible.

43. Phase 7 — CI/CD Security

Modern cloud environments heavily depend on automation.

Review authorised:

Git repositories
CI/CD pipelines
Build agents
Deployment identities
Container registries
Infrastructure-as-Code
Secrets
Cloud roles

44. CI/CD Trust Model

Typical architecture:

Developer
    |
    v
Source Repository
    |
    v
CI/CD Pipeline
    |
    v
Deployment Identity
    |
    v
Cloud Production

A weakness early in this chain can have disproportionate impact.

45. Questions for CI/CD

Ask:

Who can modify pipelines?

Who can approve deployment?

Where are deployment credentials stored?

Does the pipeline use long-lived credentials?

What privilege does the deployment identity have?

Can development pipelines modify production?

Are production deployments independently approved?

46. Phase 8 — Secrets Analysis

Create a secrets exposure model across environments.

Possible locations:

Environment variables
Configuration files
Cloud secret managers
CI/CD variables
Container manifests
Repositories
Application logs
Object storage
VM disk images
Backups

Do not unnecessarily extract sensitive values.

Where possible, prove that access exists without exposing the secret itself.

47. Phase 9 — Identity Relationship Analysis

Now combine identity information across platforms.

Example:

Microsoft Entra ID
        |
        v
Enterprise User
        |
        +----------------+
        |                |
        v                v
      Azure            AWS SSO
        |                |
        v                v
Azure RBAC            AWS Role
                         |
                         v
                    Production

48. Multi-Cloud Identity Questions

Ask:

Which identity provider controls workforce access?

Is federation used?

Which roles are mapped?

Do administrators reuse accounts?

Are highly privileged identities synchronised?

Can compromise of one identity provider affect multiple clouds?

Are service identities isolated from human users?

49. Phase 10 — Cross-Cloud Trust Analysis

Multi-cloud security becomes especially important when environments are interconnected.

Potential relationships include:

AWS ↔ Azure
AWS ↔ GCP
Azure ↔ GCP
CI/CD → Multiple Clouds
Identity Provider → Multiple Clouds
Kubernetes → Cloud IAM
SaaS → Cloud API

Build an explicit trust matrix.

Source	Destination	Mechanism	Privilege	Risk
Entra ID	AWS	Federation	Admin	High
CI/CD	AWS	Workload Role	Deploy	High
CI/CD	Azure	Service Principal	Contributor	High
GKE	GCP	Workload Identity	Storage	Medium

50. Attack Graph Development

Start turning individual observations into relationships.

Example:

Developer Account
       |
       v
Source Repository
       |
       v
Deployment Pipeline
       |
       v
Production Deployment Role
       |
       v
AWS Production

Another:

Public Web Application
       |
       v
Application Workload
       |
       v
Managed Identity
       |
       v
Secret Store
       |
       v
Production Database

51. Build the Attack Path Register

Create:

Attack Path ID
Entry Point
Intermediate Systems
Identity Changes
Privilege Changes
Critical Asset
Business Impact
Evidence
Confidence

Example:

ID	Entry	Path	Target	Severity
AP-01	Dev portal	App → workload identity → secrets	Production DB	Critical
AP-02	Developer	Repo → pipeline → AWS role	AWS Prod	Critical
AP-03	Guest workload	Network → admin interface	Management	High

52. Attack Path 01 — Application to Cloud Identity

Possible scenario:

Internet
   |
   v
Public Application
   |
   v
Application Weakness
   |
   v
Application Workload
   |
   v
Cloud Workload Identity
   |
   v
Sensitive Cloud Resource

Questions:

Can the workload identity access sensitive services?

Is the privilege necessary?

Would compromise of the application inherit cloud permissions?

Can the permissions be reduced?

53. Attack Path 02 — Development to Production

Example:

Developer
   |
   v
Development Environment
   |
   v
CI/CD Pipeline
   |
   v
Production Deployment Identity
   |
   v
Production Cloud Account

This is frequently more important than a single software vulnerability.

54. Attack Path 03 — Cross-Cloud Identity

Example:

Enterprise Identity
       |
       v
Federation
       |
       v
AWS Administrative Role
       |
       v
Production AWS

If the same identity can also administer Azure or GCP, the potential blast radius grows dramatically.

55. Attack Path 04 — Kubernetes to Cloud

Example:

Application
     |
     v
Container
     |
     v
Kubernetes Service Account
     |
     v
Cloud Workload Identity
     |
     v
Cloud Secrets

Assess the complete trust chain rather than reporting the application issue alone.

56. Attack Path 05 — CI/CD to Multi-Cloud

Example:

Source Repository
        |
        v
Build Pipeline
        |
        +------------------+
        |        |         |
        v        v         v
       AWS      Azure      GCP

If one pipeline can deploy across all three providers, it may represent an enterprise privilege choke point.

57. Privilege Escalation Analysis

Evaluate whether an authorised low-privilege identity could gain additional privileges because of:

Excessive IAM permissions
Role assumption
Service identity impersonation
Poorly scoped RBAC
Inherited permissions
CI/CD deployment privileges
Workload identities
Resource policy trust
Administrative delegation

The objective is to identify the permission relationship, not to maximise control.

58. Lateral Movement Analysis

Cloud lateral movement may occur between:

Identity → Identity
Workload → Workload
Account → Account
Subscription → Subscription
Project → Project
Cloud → Cloud
Kubernetes → Cloud
Application → Cloud Service
CI/CD → Production

Model each transition explicitly.

59. Blast Radius Analysis

For every high-impact path ask:

What could this identity reach?

How many accounts?

How many subscriptions?

How many projects?

Which production systems?

Which data stores?

Which security systems?

Which backups?

Which identities?

60. Privilege Choke Points

Some identities or systems provide disproportionate control.

Examples:

Identity Provider Administrators
Cloud Organisation Administrators
Subscription Owners
AWS Organisation Administrators
Deployment Pipelines
Secrets Management Systems
Kubernetes Administrators
Backup Administrators
Security Platform Administrators

These should receive additional protection.

61. Phase 11 — Detection Assessment

A professional red team asks:

Could the organisation detect the behaviour being simulated?

Review defensive telemetry across:

AWS CloudTrail
AWS GuardDuty
AWS Security Hub
Azure Activity Logs
Microsoft Entra Logs
Microsoft Defender for Cloud
Google Cloud Audit Logs
Security Command Center
Kubernetes Audit Logs
Endpoint Telemetry
SIEM

62. Build a Detection Matrix

Activity	Expected Log	Monitoring	Alert
Role assumption	AWS CloudTrail	SIEM	Yes
Azure role change	Activity Log	SIEM	Yes
GCP IAM change	Audit Log	SIEM	Yes
Secret access	Cloud logs	SIEM	Expected
Kubernetes admin activity	Audit log	SIEM	Expected

Determine whether telemetry exists and whether defenders would realistically notice meaningful events.

63. Detection Gaps

Possible observations:

Cloud logs not centralised
Audit logging disabled
Short log retention
Privileged actions not alerted
Identity events excluded
Kubernetes audit logs unavailable
Cloud logs not connected to SIEM
Cross-cloud correlation missing

These may represent important systemic weaknesses.

64. Evidence Collection

Every finding and attack path must be supported by evidence.

Possible evidence:

CLI output
Cloud configuration
IAM policy
RBAC assignment
Resource policy
Network rule
Application request/response
Architecture diagram
Screenshot
Audit log
Access decision

65. Evidence Naming Standard

Use consistent naming.

EVID-AWS-001
EVID-AWS-002

EVID-AZ-001
EVID-AZ-002

EVID-GCP-001

EVID-APP-001

EVID-PATH-001

66. Evidence Log

Maintain:

Evidence ID	Platform	Description	Finding
EVID-AWS-001	AWS	IAM role policy	CLOUD-001
EVID-AZ-001	Azure	Role assignment	CLOUD-002
EVID-GCP-001	GCP	Service account privilege	CLOUD-003

Never rely on memory when writing the final report.

67. Example Finding — Excessive Workload Identity Privilege

CLOUD-001 — Application Workload Identity Can Access Production Secrets

Severity

High

Observation

A workload identity assigned to an internet-facing application was authorised to access secrets associated with production backend systems.

Attack Path

Internet
   |
Application
   |
Workload Identity
   |
Secret Store
   |
Production Service

Business Impact

Compromise of the application could potentially expand beyond the application host and affect production cloud services.

Root Cause

The workload identity was granted permissions broader than required for normal application functionality.

Recommendation

Reduce the workload identity to the minimum required permissions and separate production secret access from internet-facing application identities.

68. Example Finding — Development Pipeline Can Deploy to Production

CLOUD-002 — Development CI/CD Identity Has Production Deployment Privileges

72. Finding Register

Build a central register.

ID	Finding	Platform	Severity	Attack Path
CLOUD-001	Excessive workload privileges	AWS	High	AP-01
CLOUD-002	Pipeline production privilege	Multi-Cloud	Critical	AP-02
CLOUD-003	Cross-cloud admin identity	Identity	Critical	AP-03
CLOUD-004	Logging gap	Multi-Cloud	High	—
CLOUD-005	Segmentation weakness	Network	High	AP-04

73. Separate Findings From Attack Paths

This distinction is extremely important.

A finding is an individual weakness.

Example:

Development pipeline has excessive permissions.

An attack path explains how multiple conditions combine.

Developer
   |
Repository
   |
CI/CD Pipeline
   |
Production Deployment Identity
   |
Critical Production Resource

Executive stakeholders often understand attack paths more easily than long vulnerability lists.

74. Root Cause Analysis

Do not stop at:

This IAM role is overprivileged.

Ask:

Why was it allowed to become overprivileged?

Possible root causes:

No cloud permission governance
No least privilege process
No environment separation
Weak identity lifecycle
Legacy integration
Rapid acquisition
No privilege review
No architecture ownership

75. Enterprise Security Themes

Group findings into systemic themes.

Possible themes:

Identity Governance
Cloud IAM
Network Segmentation
Workload Identity
CI/CD Security
Secrets Management
Cloud Logging
Privileged Access
Application Security
Multi-Cloud Governance

This makes the report useful for strategic remediation.

76. Risk Prioritisation

Prioritise issues using:

Exploitability
Exposure
Privilege gained
Data sensitivity
Blast radius
Attack path position
Detection capability
Business criticality

Do not prioritise based only on CVSS.

77. Attack Path Severity

An attack path may be more severe than any individual weakness that forms part of it.

Example:

Moderate Application Weakness
        +
Moderate IAM Misconfiguration
        +
Weak Network Segmentation
        =
Critical Production Attack Path

This is one of the most important lessons in enterprise offensive security.

78. Remediation Strategy

Recommend remediation at three levels.

Immediate

Examples:

Remove excessive role
Block unnecessary network path
Rotate exposed secret
Disable obsolete identity
Restrict public resource

Tactical

Examples:

Separate development and production identities
Implement workload-specific IAM roles
Centralise logging
Introduce privileged access workflows

Strategic

Examples:

Multi-cloud identity governance
Cloud security architecture standards
Zero Trust architecture
Automated IAM review
Policy-as-Code
Continuous cloud posture management

79. Build the Before Architecture

Example:

                    Developer
                        |
                        v
                  CI/CD Pipeline
                 /       |       \
                v        v        v
              AWS      Azure      GCP
               |         |         |
               +---------+---------+
                         |
                  Broad Privilege

80. Build the Improved Architecture

Example:

                    Developer
                        |
                        v
                 Source Repository
                        |
                        v
                  CI/CD Platform
                 /       |       \
                v        v        v
          AWS Deploy   Azure    GCP Deploy
             Role       Role       Role
               |         |          |
             Scoped    Scoped     Scoped
               |         |          |
               v         v          v
          Approved Production Resources

Each environment has independently scoped privileges.

81. Executive Attack Narrative

Create a short business-oriented narrative.

Example:

The assessment identified several individually moderate cloud security weaknesses which, when combined, created a viable path from a lower-trust development environment to production cloud resources. The most significant exposure resulted from excessive privileges assigned to shared deployment identities and insufficient separation between development and production environments.

This is much stronger than listing individual scanner findings.

82. Technical Attack Narrative

A technical narrative may look like:

1. Internet-facing development service identified.

2. Application architecture mapped.

3. Associated deployment pipeline discovered.

4. Pipeline used shared deployment identity.

5. Identity possessed permissions within production.

6. Network architecture allowed production resource access.

7. Controlled validation confirmed unnecessary production privilege.

8. Testing stopped once sufficient evidence was collected.

83. Red Team Report Structure

Create:

Multi-Cloud Enterprise Red Team Report
|
├── Executive Summary
├── Scope
├── Rules of Engagement
├── Methodology
├── Enterprise Architecture
├── External Attack Surface
├── AWS Assessment
├── Azure Assessment
├── GCP Assessment
├── Identity Analysis
├── Application Assessment
├── Kubernetes Assessment
├── CI/CD Assessment
├── Attack Paths
├── Detection Assessment
├── Findings
├── Strategic Security Themes
├── Remediation Roadmap
└── Appendices

84. Executive Summary

The executive summary should answer:

What did we test?

What was the overall security posture?

What are the most important attack paths?

What business assets were at risk?

Could attackers move between clouds?

Would defenders detect the activity?

What should leadership fix first?

Avoid excessive technical detail.

85. Technical Findings

Each finding should contain:

Finding ID
Title
Severity
Affected assets
Description
Evidence
Attack scenario
Business impact
Root cause
Recommendation
References

86. Strategic Remediation Roadmap

Build a roadmap.

0–30 Days

Remove dangerous permissions
Restrict excessive network paths
Fix critical secrets exposure
Protect privileged identities
Centralise missing critical logs

30–90 Days

Implement environment separation
Improve workload identity
Review CI/CD privileges
Implement privileged access management
Improve cloud detection

90–180 Days

Establish multi-cloud governance
Introduce continuous IAM analysis
Implement policy-as-code
Improve Zero Trust architecture
Automate attack-path monitoring

87. Defensive Validation

For every significant attack path, add:

Prevent
Detect
Respond
Recover

Example:

Prevent

Least privilege deployment roles.

Detect

Alert when development identities interact with production.

Respond

Disable compromised pipeline identity.

Recover

Redeploy approved infrastructure and rotate affected secrets.

88. Purple-Team Thinking

A mature red team engagement should improve defence.

For each path ask:

Which event should have generated telemetry?

Was that telemetry collected?

Was an alert generated?

Would the SOC understand the alert?

Could responders contain the identity quickly?

Would investigation show the complete attack path?

89. Multi-Cloud Attack Path Diagram

Your final report should contain at least one enterprise-level attack-path diagram.

Example:

                    INTERNET
                       |
                       v
              Public Application
                       |
                       v
               Application Role
                       |
                       v
                   AWS Secret
                       |
                       v
                CI/CD Credential
                       |
                       v
                 CI/CD Platform
                  /          \
                 v            v
           Azure Deploy     GCP Deploy
               Role            Role
                 \             /
                  \           /
                   v         v
                   PRODUCTION
                       |
                       v
                Critical Data

90. Evidence Sanitisation

Before final submission:

Remove passwords
Remove access tokens
Remove API secrets
Mask sensitive identifiers
Mask customer information
Remove unnecessary personal information

Reports frequently become widely distributed inside organisations.

Evidence must therefore be handled securely.

91. Cleanup

After validation:

Remove temporary test resources
Delete test identities where required
Remove temporary permissions
Remove uploaded test files
Remove temporary firewall rules
Terminate test sessions
Verify cloud configuration
Document remaining artefacts

Never leave an environment weaker than you found it.

92. Project Deliverables

Your completed capstone should contain:

01 Scope Document
02 Rules of Engagement
03 Enterprise Architecture Diagram
04 External Attack Surface Inventory
05 AWS Assessment
06 Azure Assessment
07 GCP Assessment
08 Identity Relationship Map
09 Network Trust Matrix
10 Application Assessment
11 Kubernetes Assessment
12 CI/CD Assessment
13 Attack Path Register
14 Evidence Log
15 Finding Register
16 Detection Matrix
17 Remediation Roadmap
18 Executive Summary
19 Final Red Team Report
20 Executive Presentation

93. Capstone Toolkit

Create the following toolkit in your knowledge base:

Multi-Cloud Enterprise Red Team Toolkit/
|
├── 01 Engagement Scope Template
├── 02 Rules of Engagement
├── 03 External Attack Surface Worksheet
├── 04 Enterprise Asset Inventory
├── 05 AWS Assessment Checklist
├── 06 Azure Assessment Checklist
├── 07 GCP Assessment Checklist
├── 08 Cloud IAM Worksheet
├── 09 Workload Identity Review
├── 10 Federation Review
├── 11 Network Trust Matrix
├── 12 Kubernetes Review
├── 13 CI-CD Security Review
├── 14 Secrets Review
├── 15 Application Security Review
├── 16 Multi-Cloud Trust Matrix
├── 17 Attack Path Worksheet
├── 18 Attack Path Register
├── 19 Detection Matrix
├── 20 Evidence Log
├── 21 Finding Register
├── 22 Finding Template
├── 23 Remediation Roadmap
├── 24 Executive Summary Template
├── 25 Red Team Report Template
└── 26 Executive Presentation Template

94. Final Assessment Checklist

Before marking the capstone complete, verify:

Governance

Written authorisation exists
Scope documented
Rules of engagement documented
Stop conditions understood
Out-of-scope systems identified

Reconnaissance

External attack surface mapped
Domains reviewed
Applications inventoried
Cloud platforms identified

AWS

AWS identities reviewed
IAM permissions reviewed
Trust policies reviewed
Workload identities reviewed
Network architecture reviewed
Sensitive resources reviewed
Logging reviewed

Azure

Entra identities reviewed
Azure RBAC reviewed
Managed identities reviewed
Key Vault reviewed
Networking reviewed
Logging reviewed

GCP

GCP IAM reviewed
Service accounts reviewed
Resource permissions reviewed
Networking reviewed
Sensitive resources reviewed
Logging reviewed

Enterprise

Federation reviewed
Multi-cloud relationships mapped
CI/CD reviewed
Kubernetes reviewed where applicable
Secrets management reviewed
Environment separation reviewed

Attack Paths

Individual weaknesses identified
Relationships mapped
Critical assets identified
Attack paths constructed
Blast radius analysed
Controlled validation completed
Testing stopped at sufficient proof

Detection

Security telemetry identified
Logging gaps documented
Detection matrix completed
SOC visibility considered

Reporting

Evidence collected
Evidence sanitised
Findings written
Root causes identified
Business impact described
Remediation provided
Executive summary written
Final report completed

95. Questions You Should Be Able to Answer

After completing this project, you should confidently answer:

Attack Surface

How would you map a multi-cloud enterprise attack surface?

AWS

How would you assess IAM relationships and workload identities?

Azure

How do Entra ID, Azure RBAC, service principals, and managed identities relate?

GCP

Why are service accounts important during GCP assessments?

Identity

How can enterprise identity create attack paths across multiple clouds?

CI/CD

Why can deployment pipelines become high-value privilege choke points?

Kubernetes

How can a vulnerable workload become a cloud security problem?

Attack Paths

Why is an attack-path model more valuable than a vulnerability list?

Detection

How would you determine whether cloud attack activity could be detected?

Reporting

How would you communicate a complex cloud attack path to executive leadership?

96. Professional Red Team Mindset

A beginner thinks:

I found an exposed service.

An intermediate tester thinks:

Can this service be compromised?

A professional red teamer thinks:

If this service were compromised, which identity would I gain, which trust relationships would become available, which critical assets could eventually be affected, how far could the attack propagate, and would defenders detect it?

That progression is the purpose of this capstone.

97. Think in Relationships

Enterprise red teaming becomes easier when you stop viewing systems independently.

Think:

User
 |
Identity
 |
Application
 |
Workload
 |
Cloud Role
 |
Secret
 |
Pipeline
 |
Production Identity
 |
Critical Asset

Every arrow represents a trust relationship.

Every trust relationship should be justified.

98. The Most Important Multi-Cloud Questions

During every assessment keep asking:

What is exposed?

Who can authenticate?

What identity is being used?

What permissions does that identity possess?

What does this workload trust?

What trusts this workload?

Can development affect production?

Can one identity cross cloud boundaries?

Which system controls enterprise identity?

Where are the privilege choke points?

What critical assets are reachable?

How large is the blast radius?

Would security monitoring detect this?

What is the smallest safe proof?

What is the underlying root cause?

99. Common Capstone Mistakes

Avoid:

Scanning everything without understanding architecture

Treating AWS, Azure, and GCP as unrelated environments

Focusing only on vulnerabilities

Ignoring enterprise identity

Ignoring workload identities

Ignoring CI/CD

Ignoring Kubernetes-to-cloud relationships

Ignoring network trust

Reporting every permission without analysing impact

Over-testing after sufficient evidence exists

Collecting sensitive data unnecessarily

Ignoring defensive visibility

Writing findings without root-cause analysis

Producing a technical report with no business narrative

100. Definition of Success

A successful red team engagement does not mean:

obtaining maximum access.

Success means:

Understand the enterprise
      |
Identify realistic weaknesses
      |
Connect weaknesses into attack paths
      |
Safely validate the important relationships
      |
Demonstrate business impact
      |
Show defensive visibility
      |
Collect clear evidence
      |
Identify root causes
      |
Provide actionable remediation

101. Capstone Outcome

By completing this project, you have moved beyond platform-specific cloud testing.

You have practised analysing:

AWS
Azure
GCP
Enterprise Identity
Applications
APIs
Kubernetes
CI/CD
Workload Identity
Secrets
Networking
Federation
Logging
Attack Paths
Business Risk

These are the same domains that frequently intersect during real enterprise cloud security assessments and red team engagements.

102. Key Takeaways

Multi-cloud red teaming is primarily about relationships and trust.
Identity frequently becomes the bridge between cloud platforms.
Workload identities deserve the same attention as human identities.
Development environments can create unexpected paths toward production.
CI/CD infrastructure may hold extremely powerful deployment privileges.
Kubernetes workloads can inherit cloud permissions.
Individual medium-risk weaknesses can combine into critical attack paths.
Attack paths provide more context than isolated findings.
Cloud logs must be analysed as part of the security architecture.
Defensive visibility should be evaluated alongside offensive exposure.
Evidence should prove the risk without creating unnecessary impact.
Root-cause remediation is more valuable than fixing symptoms individually.
Professional red teaming ends with communication, remediation, and improvement—not exploitation.

103. Final Enterprise Red Team Workflow

AUTHORISATION
      |
      v
SCOPE
      |
      v
ENTERPRISE RECONNAISSANCE
      |
      v
ASSET DISCOVERY
      |
      v
AWS + AZURE + GCP ENUMERATION
      |
      v
IDENTITY ANALYSIS
      |
      v
APPLICATION + API REVIEW
      |
      v
WORKLOAD + KUBERNETES ANALYSIS
      |
      v
CI/CD + SECRETS REVIEW
      |
      v
NETWORK + TRUST ANALYSIS
      |
      v
CROSS-CLOUD RELATIONSHIPS
      |
      v
ATTACK PATH DEVELOPMENT
      |
      v
CONTROLLED VALIDATION
      |
      v
BLAST RADIUS ANALYSIS
      |
      v
DETECTION ASSESSMENT
      |
      v
EVIDENCE
      |
      v
FINDINGS
      |
      v
ROOT CAUSE
      |
      v
REMEDIATION ROADMAP
      |
      v
EXECUTIVE REPORTING

What’s Next?

You have now completed the Multi-Cloud Enterprise Red Team Capstone.

This project brings together the major offensive-security disciplines required to think beyond individual vulnerabilities and evaluate an enterprise as a connected system of:

Identity → Applications → Workloads → Cloud Platforms → Networks → Trust → Critical Assets

The next stage should shift from learning individual techniques toward demonstrating your capability as a professional Ethical Hacker through:

portfolio-ready assessment documentation;
attack-path explanations;
technical and executive reporting;
scenario-based interview preparation;
penetration testing methodology questions;
cloud and enterprise security interview scenarios;
communicating findings to technical and non-technical stakeholders.

➡️ Next: 10 — Interview Preparation

This works well as the **final enterprise project** because it forces the learner to combine AWS, Azure, GCP, identity, Kubernetes, applications, CI/CD, detection, and reporting into one complete engagement rather than treating each skill separately.