06 — Cloud Security Testing

Cloud computing has fundamentally changed the attack surface of modern enterprises.

Traditional penetration testing often starts with:

IP Address
   ↓
Port
   ↓
Service
   ↓
Vulnerability
   ↓
System Access

Cloud security testing frequently starts somewhere very different:

Cloud Identity
      ↓
IAM Permission
      ↓
Cloud API
      ↓
Resource
      ↓
Additional Identity
      ↓
Privilege
      ↓
Cloud Control Plane

An attacker may never need to exploit a traditional server vulnerability.

A single:

Exposed credential
Overprivileged identity
Public storage bucket
Misconfigured role
Leaked API key
Workload identity
CI/CD credential
Insecure trust relationship

may create a path deep into the cloud environment.

For an Ethical Hacker, cloud security testing therefore requires a shift in mindset.

Cloud hacking is often identity, permission, configuration, and trust-path hacking.

Module Mission

Your mission is to learn how to systematically assess authorised cloud environments across AWS, Microsoft Azure, Google Cloud, and modern cloud-native workloads.

The core methodology is:

Scope
  ↓
Understand Cloud Architecture
  ↓
Identify Accounts / Subscriptions / Projects
  ↓
Establish Current Identity
  ↓
Enumerate Permissions
  ↓
Discover Resources
  ↓
Map External Exposure
  ↓
Assess IAM
  ↓
Assess Storage
  ↓
Assess Networking
  ↓
Assess Compute
  ↓
Assess Workload Identities
  ↓
Assess Secrets
  ↓
Assess Serverless / Containers / Kubernetes
  ↓
Analyse Trust Relationships
  ↓
Identify Privilege Paths
  ↓
Validate Safely
  ↓
Collect Evidence
  ↓
Report

The objective is not simply to discover misconfigurations.

The objective is to answer:

How could an attacker move from initial cloud access to meaningful business impact?

1. Cloud Security Testing

Cloud security testing evaluates the security of:

Cloud Identities

Cloud Resources

Cloud Configurations

Cloud Networks

Cloud Applications

Cloud Workloads

Cloud APIs

Trust Relationships

Management Planes

The assessment may include both:

External Attack Surface
          +
Authenticated Cloud Assessment

2. Why Cloud Pentesting Is Different

In traditional infrastructure:

Server
  ↓
Operating System
  ↓
Application

In cloud:

Cloud Control Plane
      │
      ├── Identity
      ├── Compute
      ├── Storage
      ├── Network
      ├── Database
      ├── Serverless
      ├── Containers
      └── Security Services

The management API itself becomes part of the attack surface.

3. Cloud Control Plane

The control plane allows authorised identities to create, modify, and delete cloud resources.

Examples include:

Create Virtual Machine

Modify Firewall

Create IAM User

Attach Role

Read Secret

Create Function

Modify Storage Policy

Change Logging

Control-plane access can be more powerful than access to an individual server.

4. Data Plane

The data plane represents interaction with deployed resources and their data.

Example:

User
 ↓
Web Application
 ↓
Database

while control-plane interaction may look like:

Administrator
 ↓
Cloud API
 ↓
Modify Database Configuration

Both must be considered during cloud assessments.

5. Shared Responsibility

Cloud providers secure the underlying cloud infrastructure.

Customers remain responsible for significant parts of their deployed environment.

Conceptually:

Cloud Provider
      ↓
Security OF the Cloud

Customer
      ↓
Security IN the Cloud

The exact division varies by service.

6. Shared Responsibility Changes by Service

For Infrastructure as a Service:

Provider
├── Physical Infrastructure
├── Hardware
└── Core Cloud Platform

Customer
├── Operating System
├── Applications
├── Identity
├── Data
└── Configuration

For managed services, the provider may manage more of the underlying stack.

But customers still commonly control:

Identity

Access

Data

Configuration

7. Cloud Providers

This module focuses on principles applicable across:

Amazon Web Services

Microsoft Azure

Google Cloud Platform

Do not memorise only service names.

Understand the security concepts behind them.

8. Cloud Hierarchy

Different providers organise environments differently.

A simplified comparison:

Security Concept	AWS	Azure	Google Cloud
Top-level environment	Organization	Tenant	Organization
Workload boundary	Account	Subscription	Project
Identity	IAM	Entra ID / Azure RBAC	Cloud IAM
Compute	EC2	Virtual Machines	Compute Engine
Object storage	S3	Blob Storage	Cloud Storage
Serverless	Lambda	Functions	Cloud Functions
Secrets	Secrets Manager	Key Vault	Secret Manager

The names differ.

The security questions remain similar.

9. Cloud Scope

Cloud assessments require precise scope.

Example:

Provider:
AWS

Organization:
Example Corporation

In Scope:
Account 111111111111
Account 222222222222

Regions:
eu-west-1
us-east-1

Services:
IAM
EC2
S3
Lambda

Out of Scope:
Production destructive testing
DoS
Third-party SaaS
Unapproved accounts

10. Cloud Provider Testing Policies

Cloud providers may have specific penetration-testing policies.

Before conducting an engagement:

Client Authorization
        +
Cloud Provider Rules
        +
Rules of Engagement

must all be understood.

Never assume traditional penetration-testing rules automatically apply to every managed cloud service.

11. Start With Identity

When given authorised cloud access, your first question should be:

Who am I?

Not:

Which exploit should I run?

Establish:

Identity

Account

Tenant

Subscription

Project

Roles

Permissions

Authentication Method

12. Identity Is the New Perimeter

Traditional security:

Internet
   ↓
Firewall
   ↓
Internal Network

Cloud environments increasingly operate like:

User / Workload
      ↓
Identity
      ↓
Policy
      ↓
Cloud API
      ↓
Resource

Therefore:

Identity configuration often determines the effective cloud perimeter.

13. Human and Machine Identities

Cloud identities include:

Human Users

Administrators

Applications

Virtual Machines

Containers

Serverless Functions

CI/CD Systems

Automation Platforms

Machine identities deserve the same scrutiny as human identities.

14. Authentication vs Authorization

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Example:

Alice
  ↓
Authenticated
  ↓
Cloud Environment
  ↓
Read Storage
  ↓
Cannot Modify IAM

Both controls matter.

15. AWS Identity Model

Important AWS IAM concepts include:

IAM Users

IAM Groups

IAM Roles

Policies

Resource Policies

Temporary Credentials

Service Roles

A simplified model:

Identity
   ↓
Policy
   ↓
Permission
   ↓
AWS Resource

16. Azure Identity Model

Azure commonly combines:

Microsoft Entra ID
       +
Azure RBAC

Conceptually:

User / Service Principal
          ↓
Role Assignment
          ↓
Scope
          ↓
Azure Resource

Scope may exist at:

Management Group

Subscription

Resource Group

Resource

17. Google Cloud IAM

Google Cloud IAM uses principals, roles, and resource hierarchy.

Conceptually:

Principal
    ↓
Role
    ↓
Organization / Folder / Project / Resource

Inherited permissions can create broad access.

18. IAM Assessment

For each identity determine:

Who Is It?

Why Does It Exist?

How Does It Authenticate?

Which Roles?

Which Permissions?

Which Resources?

Can It Assume Another Identity?

Can It Modify IAM?

Can It Access Secrets?

Is MFA Required?

Is It Still Needed?

19. Least Privilege

Cloud identities should receive only the permissions required.

Example:

Application
    ↓
Needs:
Read Object A

But receives:

Storage Administrator

This creates unnecessary attack capability.

20. Effective Permissions

Do not evaluate only directly assigned roles.

Effective privilege may result from:

Direct Permissions
        +
Group Membership
        +
Inherited Permissions
        +
Resource Policies
        +
Role Assumption
        +
Trust Relationships

This makes cloud permission analysis complex.

21. Cloud Privilege Escalation

Cloud privilege escalation often occurs when an identity can use apparently limited permissions to obtain greater control.

Conceptually:

Low-Privilege Identity
        ↓
Cloud Permission
        ↓
Modify Resource / Identity
        ↓
Assume Stronger Privilege
        ↓
Administrative Access

The key question is:

What can this permission indirectly allow the identity to become?

22. IAM Privilege Paths

Example:

Developer
   ↓
Can Modify Application
   ↓
Application Uses Privileged Role
   ↓
Developer Influences Workload
   ↓
Privileged Cloud Access

The developer did not need direct administrative permission.

The workload created the path.

23. Permission Chaining

Cloud risk frequently comes from combinations.

Suppose an identity can:

Create Workload
      +
Assign Existing Role

Neither permission should be assessed in isolation.

Together they may produce:

Create Workload
      ↓
Attach Privileged Identity
      ↓
Workload Runs
      ↓
Higher Privilege

This is permission chaining.

24. Cloud Reconnaissance

Cloud reconnaissance attempts to understand the environment before deeper testing.

Information may include:

Domains

Cloud Providers

Public IP Addresses

Storage Names

Applications

APIs

CDNs

Authentication Portals

Public Repositories

Cloud Service References

Only actively interact with systems included in scope.

25. External Cloud Attack Surface

A cloud environment may expose:

Web Applications

APIs

Storage

Load Balancers

Virtual Machines

Serverless Endpoints

Container Services

Kubernetes APIs

Management Interfaces

Create an external inventory before testing individual components.

26. Cloud Asset Inventory

Example:

Asset	Provider	Exposure	Identity	Purpose
Web App	AWS	Public	App Role	Customer portal
Storage	AWS	Restricted	Storage Role	Documents
VM	Azure	Internal	Managed Identity	Application
Function	GCP	Public API	Service Account	Processing

Asset context is essential.

27. Public Does Not Automatically Mean Vulnerable

Some resources must be public.

Examples:

Public Website

Public API

Static Website Content

The question is whether:

Intended Exposure
        =
Actual Exposure

28. Cloud Storage

Object storage is widely used for:

Documents

Backups

Application Data

Logs

Media

Deployment Files

Static Websites

Examples include:

Amazon S3

Azure Blob Storage

Google Cloud Storage

29. Storage Security Questions

For every storage resource ask:

Is It Public?

Who Can Read?

Who Can Write?

Who Can Delete?

Is Encryption Enabled?

Is Versioning Used?

Is Logging Enabled?

Does It Contain Secrets?

Is Access Cross-Account?

30. Public Storage Exposure

A risky configuration may look like:

Internet
   ↓
Public Storage
   ↓
Sensitive Data

But not every publicly accessible object is sensitive.

Validate the intended business use.

31. Storage Write Access

Unauthorised write access can sometimes be more dangerous than read access.

Potential impact includes:

Content Modification

Malware Distribution

Application Manipulation

Data Destruction

Supply-Chain Risk

Always evaluate permissions beyond simple public readability.

32. Cloud Networking

Cloud networking commonly includes:

Virtual Networks

Subnets

Routes

Security Groups

Firewall Rules

Load Balancers

Gateways

Private Endpoints

VPNs

Peering

Understand the architecture before assessing exposure.

33. Security Groups and Firewalls

A simplified rule:

Source
  ↓
Protocol
  ↓
Port
  ↓
Destination

Review whether sensitive services are exposed more broadly than required.

34. Common Network Exposure

Examples requiring investigation include:

Administrative Services → Internet

Database Services → Internet

Kubernetes Management → Internet

Internal Applications → Internet

Exposure alone does not establish exploitability, but it expands attack surface.

35. Network Segmentation

Cloud environments should separate workloads according to trust.

Example:

Internet
   ↓
Public Load Balancer
   ↓
Application Tier
   ↓
Database Tier

Not:

Internet
   ↓
Everything

36. Cloud Peering

Cloud networks may connect through peering or similar mechanisms.

Example:

Development Network
        ↓
Peering
        ↓
Production Network

Review:

Routing

Firewall Rules

Trust Direction

DNS

Identity

Shared Services

37. Hybrid Connectivity

Cloud environments may connect to on-premises networks through:

VPN

Private Connectivity

SD-WAN

Dedicated Links

Conceptually:

Cloud
  ↓
Private Connection
  ↓
Corporate Network
  ↓
Active Directory

This can create cloud-to-on-premises attack paths.

38. Compute Security

Cloud compute includes:

Virtual Machines

Managed Instances

Container Hosts

Autoscaling Workloads

Assess both:

Operating System Security
          +
Cloud Configuration

39. Compute Security Questions

For every cloud VM ask:

Is It Public?

Which Ports?

Which Identity Is Attached?

What Can That Identity Access?

How Is Administration Performed?

Are Patches Current?

Are Secrets Stored Locally?

Is Logging Enabled?

40. Public IP Exposure

A VM with a public IP may be intentionally exposed.

Determine:

Why Public?

Which Services?

Which Source Networks?

Is a Load Balancer Better?

Is Administration Restricted?

Do not automatically report every public IP.

41. Cloud Metadata Services

Cloud workloads may access metadata services providing information about the workload and, depending on architecture, temporary credentials.

Conceptually:

Cloud Workload
      ↓
Metadata Service
      ↓
Workload Information
      ↓
Temporary Identity Credentials

This makes metadata access security-sensitive.

42. Why Metadata Matters

Consider:

Application Vulnerability
        ↓
Application Can Reach Metadata
        ↓
Workload Identity
        ↓
Cloud API

A web application issue may therefore become a cloud IAM issue.

43. SSRF-to-Cloud Concept

Server-Side Request Forgery can sometimes allow an application to make unintended requests.

In cloud environments, a dangerous conceptual chain is:

SSRF
 ↓
Metadata Access
 ↓
Temporary Credential
 ↓
Cloud Permission
 ↓
Cloud Resource

Modern cloud protections and secure application design should be used to break this path.

44. Metadata Defensive Controls

Controls may include:

Modern Metadata Protections

Least-Privilege Workload Identity

Application Egress Restrictions

SSRF Prevention

Network Controls

Monitoring

Do not depend on a single control.

45. Workload Identities

Modern cloud systems often avoid storing long-lived static credentials.

Instead:

Workload
   ↓
Assigned Identity
   ↓
Temporary Credential
   ↓
Cloud API

This is generally stronger than embedding permanent API keys.

But the identity still requires least privilege.

46. Secrets Management

Cloud applications need secrets such as:

API Keys

Database Credentials

Certificates

Tokens

Encryption Keys

These should not be scattered through application code and configuration.

47. Secret Exposure

Common locations worth reviewing include:

Source Code

Configuration Files

Environment Variables

Build Pipelines

Container Images

Deployment Templates

Logs

Backups

Only inspect authorised repositories and resources.

48. Cloud Secret Managers

Cloud platforms provide managed secret storage services.

Examples include:

AWS Secrets Manager

Azure Key Vault

Google Secret Manager

The presence of a secret manager does not automatically mean secrets are secure.

Review who can access it.

49. Secret Access Paths

Example:

Developer
   ↓
Can Read Secret
   ↓
Database Credential
   ↓
Production Database

The real permission may be hidden behind secret access.

50. Encryption Keys

Cloud Key Management Services control encryption keys.

Key access may permit:

Encrypt

Decrypt

Sign

Verify

Key Administration

Cryptographic permissions should be reviewed separately from resource permissions.

51. Serverless Security

Serverless platforms include:

AWS Lambda

Azure Functions

Google Cloud Functions

Architecture:

Event
 ↓
Function
 ↓
Workload Identity
 ↓
Cloud Resources

The function’s identity becomes particularly important.

52. Serverless Attack Surface

Review:

Trigger

Input Validation

Authentication

Function Code

Environment Variables

Secrets

IAM Role

Network Access

Logging

A vulnerable function may provide a bridge into cloud resources.

53. Serverless Privilege Path

Example:

Public Function
      ↓
Application Weakness
      ↓
Function Execution Context
      ↓
Overprivileged Role
      ↓
Sensitive Storage

The application issue and IAM misconfiguration combine into one attack path.

54. Containers in Cloud Environments

Cloud environments frequently run containers through:

Managed Container Platforms

Kubernetes

Serverless Containers

Virtual Machines

Container security involves both:

Container Security
        +
Cloud Identity Security

55. Container Image Security

Review images for:

Outdated Components

Embedded Secrets

Unnecessary Tools

Unsafe Configuration

Excessive Privilege

Container images should be treated as software supply-chain artifacts.

56. Container Registry Security

Registries may contain proprietary application images.

Review:

Public Exposure

Push Permissions

Pull Permissions

Administrative Rights

Image Signing

Vulnerability Scanning

Unauthorised write access can create supply-chain risk.

57. Kubernetes Security

Cloud Kubernetes environments combine several security layers:

Cloud IAM
   ↓
Kubernetes Authentication
   ↓
Kubernetes RBAC
   ↓
Workloads
   ↓
Service Accounts
   ↓
Cloud Resources

This creates complex cross-layer attack paths.

58. Kubernetes Security Questions

Assess:

API Server Exposure

Authentication

RBAC

Namespaces

Service Accounts

Secrets

Pod Security

Network Policies

Container Privileges

Cloud Identity Integration

59. Kubernetes Privilege Path

Example:

Developer
   ↓
Can Create Pod
   ↓
Pod Uses Powerful Service Account
   ↓
Service Account
   ↓
Sensitive Kubernetes Resources

Again, permissions must be analysed in combination.

60. Kubernetes-to-Cloud Attack Path

Modern Kubernetes clusters may provide workloads with cloud identities.

Conceptually:

Pod
 ↓
Kubernetes Service Account
 ↓
Cloud Workload Identity
 ↓
Cloud IAM
 ↓
Storage / Database / Secrets

A Kubernetes compromise can therefore become a cloud compromise.

61. CI/CD Security

Cloud environments depend heavily on deployment pipelines.

Typical flow:

Developer
   ↓
Source Repository
   ↓
CI/CD
   ↓
Cloud Credential
   ↓
Production Deployment

The pipeline is part of the cloud attack surface.

62. CI/CD Questions

Review:

Who Can Modify Pipeline?

Which Credentials Exist?

Which Cloud Roles?

Can Developers Trigger Production?

Are Secrets Protected?

Are Branch Controls Enforced?

Are Actions Logged?

63. CI/CD Privilege Path

Example:

Repository Contributor
        ↓
Modify Pipeline
        ↓
Pipeline Uses Deployment Identity
        ↓
Production Cloud

A source-code permission may therefore become a production cloud privilege.

64. Infrastructure as Code

Cloud infrastructure is often deployed through:

Terraform

CloudFormation

Bicep

ARM Templates

Other IaC Platforms

IaC repositories can reveal the intended cloud architecture.

65. IaC Security

Review for:

Public Resources

Weak IAM

Open Firewall Rules

Embedded Secrets

Missing Encryption

Unsafe Defaults

Overprivileged Workloads

Finding weaknesses before deployment is preferable to discovering them in production.

66. Cloud API Keys

Long-lived access keys create significant risk when poorly managed.

Review:

Age

Owner

Purpose

Last Use

Permissions

Storage Location

Rotation

Whether Still Required

Prefer temporary credentials where supported.

67. Exposed Credentials

Potential exposure locations include:

Public Repository

Developer Laptop

CI/CD Log

Container Image

Backup

Configuration File

Support Ticket

An exposed credential should immediately trigger permission and blast-radius analysis.

68. Credential Blast Radius

Do not stop at:

We found a cloud key.

Determine:

Credential
   ↓
Identity
   ↓
Permissions
   ↓
Resources
   ↓
Assumable Roles
   ↓
Critical Assets

This determines actual severity.

69. Temporary Credentials

Temporary credentials generally reduce long-term exposure.

But they can still be abused while valid.

Security therefore requires:

Short Lifetime
     +
Least Privilege
     +
Secure Delivery
     +
Monitoring

70. Role Assumption

Cloud platforms support mechanisms for identities to obtain other roles.

Conceptually:

Identity A
    ↓
Trusted by Role B
    ↓
Assume Role B
    ↓
New Permissions

Trust configuration must be carefully reviewed.

71. Cross-Account Trust

Large enterprises often connect cloud accounts.

Example:

Security Account
      ↓
Trust
      ↓
Production Account

Cross-account access is not inherently dangerous.

The question is whether trust is appropriately constrained.

72. Cross-Account Attack Path

Example:

Development Identity
        ↓
Assumable Role
        ↓
Shared Services
        ↓
Production Role
        ↓
Production Resources

The attack path may cross several account boundaries.

73. Azure Cross-Scope Privilege

Azure permissions may inherit through:

Management Group
      ↓
Subscription
      ↓
Resource Group
      ↓
Resource

A role assigned high in the hierarchy can have a much larger blast radius than expected.

74. Google Cloud Inheritance

Google Cloud IAM can similarly inherit through its resource hierarchy.

Always determine:

Where Was Permission Assigned?

Where Does It Apply?

What Inherits It?

Scope is fundamental to cloud privilege analysis.

75. Multi-Cloud Environments

Enterprises may operate:

AWS
 +
Azure
 +
Google Cloud
 +
SaaS

These environments may share:

Identity

CI/CD

Secrets

Networking

Monitoring

A compromise in one platform may create paths into another.

76. Multi-Cloud Attack Path

Example:

Corporate Identity
       ↓
CI/CD Platform
       ↓
AWS Deployment Role
       ↓
Shared Secret
       ↓
Azure Application

Cloud boundaries do not necessarily equal security boundaries.

77. Cloud SSO

Enterprises often use central identity providers.

Conceptually:

Corporate Identity
        ↓
SSO
        ↓
AWS
Azure
GCP
SaaS

Compromise of the central identity system can create a very large blast radius.

78. MFA

Privileged cloud identities should generally use strong authentication.

MFA can reduce account takeover risk.

But MFA does not fix:

Excessive Permissions

Weak Workload Identities

Exposed API Keys

Unsafe Trust Policies

Misconfigured Resources

Identity security requires multiple layers.

79. Break-Glass Accounts

Organisations may maintain emergency administrative accounts.

Review:

Purpose

Credential Protection

Monitoring

Testing

Access Restrictions

Usage History

Emergency access should not become an unmonitored permanent backdoor.

80. Root Accounts and Equivalent Identities

Some platforms provide extremely powerful top-level identities.

These should receive exceptional protection.

Ask:

Is Daily Use Prevented?

Is MFA Enabled?

Are Credentials Protected?

Is Activity Monitored?

Are Access Keys Disabled Where Possible?

81. Cloud Logging

Cloud security depends heavily on control-plane logging.

Important events may include:

Authentication

API Calls

IAM Changes

Resource Creation

Network Changes

Storage Changes

Key Access

Secret Access

Logging Changes

82. AWS Logging

AWS environments commonly use services such as:

CloudTrail

CloudWatch

AWS Config

Security Hub

GuardDuty

An Ethical Hacker should understand whether relevant security activity becomes visible.

83. Azure Logging

Azure environments may use:

Azure Activity Logs

Microsoft Entra Logs

Azure Monitor

Defender for Cloud

Microsoft Sentinel

Identity and control-plane telemetry should be considered together.

84. Google Cloud Logging

Google Cloud environments provide services such as:

Cloud Audit Logs

Cloud Logging

Security Command Center

The exact tooling matters less than the question:

Can the organisation reconstruct important cloud security activity?

85. Logging Is a Security Control

Suppose:

Compromised Identity
      ↓
Reads Secret
      ↓
Creates New Credential
      ↓
Modifies Firewall

A mature environment should have telemetry for these high-risk activities.

86. Logging Tampering

Attackers with sufficient privilege may attempt to:

Disable Logging

Delete Logs

Modify Retention

Change Destinations

Therefore logging infrastructure itself must be protected.

87. Centralised Logging

A stronger architecture may use:

Workload Accounts
      ↓
Central Security Account
      ↓
Protected Logs

Separating security telemetry from workloads makes tampering more difficult.

88. Cloud Detection Engineering

Potential detections include:

Unusual Authentication

New Access Keys

Privilege Changes

Public Storage Changes

Firewall Changes

Secret Access

Cross-Account Role Assumption

Logging Disabled

During testing ask:

Would the security team detect this activity?

89. Cloud Security Posture Management

Organisations may use posture-management capabilities to identify:

Misconfigurations

Policy Violations

Public Exposure

Weak IAM

Compliance Issues

Automated posture tools are useful but should not replace attack-path analysis.

90. Scanner Finding vs Attack Path

A scanner might report:

Storage Logging Disabled

Another finding:

Role Is Overprivileged

Another:

Application Is Public

Attack-path analysis may reveal:

Public Application
       ↓
Application Weakness
       ↓
Workload Role
       ↓
Sensitive Storage
       ↓
Logging Gap

The combined story is much more valuable.

91. Cloud Attack Path Analysis

For each initial foothold ask:

What Identity?

What Permissions?

What Resources?

What Secrets?

What Trust?

What Networks?

What Other Identities?

What Can Be Modified?

What Can Be Assumed?

What Is the Final Impact?

92. Attack Path Example — Exposed Credential

Public Repository
      ↓
Cloud Credential
      ↓
Developer Identity
      ↓
Read Secret
      ↓
Database Credential
      ↓
Production Database

The exposed key is only the beginning.

93. Attack Path Example — Workload Identity

Web Application
      ↓
Application Vulnerability
      ↓
Workload Context
      ↓
Overprivileged Role
      ↓
Secret Manager
      ↓
Production Credential

This combines application and cloud security.

94. Attack Path Example — CI/CD

Developer Account
      ↓
Repository Write
      ↓
Pipeline Modification
      ↓
Deployment Identity
      ↓
Production Cloud

Software supply-chain permissions become cloud permissions.

95. Attack Path Example — Hybrid Identity

Cloud Workload
      ↓
Hybrid Connectivity
      ↓
On-Premises Server
      ↓
Active Directory
      ↓
Privileged Identity

Cloud testing can connect directly to the Active Directory techniques studied earlier.

96. Attack Path Example — Kubernetes

Application
   ↓
Container
   ↓
Kubernetes Service Account
   ↓
Cloud Workload Identity
   ↓
Cloud Secrets
   ↓
Production Resource

Modern attack paths cross technology layers.

97. Think in Security Boundaries

Map:

Internet

Cloud Edge

Account

Subscription

Project

Virtual Network

Subnet

Workload

Identity

Management Plane

Data

Then ask:

What controls movement between these boundaries?

98. Cloud Privilege Is Often Indirect

An identity may not have:

Administrator

but may have:

Modify Function

Pass Role

Create Deployment

Modify Policy

Read Secret

One or more of these permissions may indirectly provide greater privilege.

99. Read vs Write Permissions

Do not assume write permissions are the only dangerous permissions.

Read access may expose:

Secrets

Credentials

Private Keys

Source Code

Backups

Sensitive Data

These can create new attack paths.

100. Resource Creation Permissions

The ability to create resources can also matter.

Ask:

Can Identity Create Compute?

Can It Attach an Identity?

Can It Create Credentials?

Can It Modify Networking?

Can It Trigger Automation?

Cloud permissions should always be analysed for downstream effects.

101. Destructive Cloud Operations

Cloud APIs can perform destructive actions very quickly.

Examples include:

Delete Storage

Terminate Compute

Delete Database

Modify IAM

Disable Logging

Do not perform destructive validation unless explicitly authorised and safely planned.

102. Minimum Necessary Validation

Suppose you prove an identity has permission to delete a production database.

You generally do not need to:

Delete the database.

Instead document:

Identity

Permission

Resource

Policy Evidence

Potential Impact

The evidence may already establish the risk.

103. Cloud Evidence Collection

For each finding capture:

Evidence ID

Cloud Provider

Account / Subscription / Project

Identity

Resource

Region

Permission

Configuration

Relevant Output

Timestamp

Cloud environments can change quickly, so timestamps matter.

104. Avoid Sensitive Data Collection

If storage access is being validated:

Confirm Access
      ↓
Collect Minimum Evidence
      ↓
Stop

Do not download large quantities of customer or production data merely to demonstrate access.

105. Example Evidence

Evidence ID:
CLOUD-EV-017

Provider:
AWS

Account:
Production

Identity:
ApplicationRole

Resource:
CustomerDataBucket

Observation:
The application workload identity possesses read access to the production customer-data storage resource beyond its documented operational requirement.

Validation:
Permission relationship confirmed without downloading customer records.

106. Example Finding — Excessive Workload Privilege

CLOUD-001 — Application Workload Identity Has Excessive Access to Production Resources

Observation

The application workload identity possessed permissions to access cloud resources beyond those required for its documented function.

Attack Scenario

An attacker compromising the application could inherit the workload identity and use its cloud permissions to access additional production resources.

Impact

Successful exploitation could expand an application compromise into broader cloud data or infrastructure compromise.

Recommendation

Reduce the workload identity to the minimum required permissions and continuously review effective permissions.

107. Example Finding — Public Storage

CLOUD-002 — Sensitive Cloud Storage Is Publicly Accessible

Observation

A cloud storage resource containing non-public organisational information was accessible without the intended authenticated access controls.

Impact

Unauthorised parties could potentially access sensitive information.

Recommendation

Remove unintended public access, enforce centrally managed public-access restrictions, review historical access logs, and classify affected data.

108. Example Finding — Overly Broad Administrative Exposure

CLOUD-003 — Cloud Administrative Service Is Exposed to Untrusted Networks

Observation

Administrative connectivity to a cloud-hosted workload was permitted from broad internet address ranges.

Risk

Broad network exposure increases the attack surface of administrative services and may enable credential-based or vulnerability-based attacks.

Recommendation

Restrict administrative access to approved management networks, VPN infrastructure, private access mechanisms, or identity-aware administrative services.

109. Example Finding — Long-Lived Access Key

CLOUD-004 — Long-Lived Cloud Credential Remains Active

Observation

A long-lived access credential associated with a human or automation identity remained active beyond the organisation’s expected credential lifecycle.

Risk

Long-lived credentials increase the window in which accidental exposure can lead to unauthorised cloud access.

Recommendation

Remove unnecessary static credentials and prefer temporary, identity-based authentication mechanisms.

110. Example Finding — Excessive Cross-Account Trust

CLOUD-005 — Production Role Trusts a Broad External Identity Scope

Observation

A privileged production role could be assumed by a broader set of identities from another cloud account than required.

Attack Scenario

Compromise of an authorised identity in the trusted account could provide a path into production resources.

Recommendation

Restrict trust to explicitly required identities and conditions and periodically review cross-account trust relationships.

111. Example Finding — Inadequate Cloud Logging

CLOUD-006 — Critical Control-Plane Activity Is Not Centrally Retained

Observation

Security-relevant cloud management events were not consistently forwarded to a protected central logging environment.

Risk

An attacker obtaining sufficient cloud privilege could perform high-impact actions while reducing the organisation’s ability to investigate the incident.

Recommendation

Enable comprehensive control-plane logging, centralise telemetry in a protected security environment, restrict log modification, and monitor logging configuration changes.

112. Root Cause Analysis

Suppose you discover:

Overprivileged Users

Overprivileged Workloads

Broad Cross-Account Trust

Excessive Service Roles

The root cause may be:

Weak cloud IAM governance and insufficient least-privilege engineering.

This is more useful than reporting dozens of unrelated IAM observations.

113. Cloud Security Themes

Common themes include:

Identity Governance

Who has cloud access?

Privileged Access

Who can control the environment?

Workload Identity

What can applications become?

Network Exposure

Which resources are reachable?

Data Security

Who can access sensitive data?

Secret Management

Where are credentials stored?

Trust

Which accounts, tenants, projects, and systems trust one another?

Monitoring

Can suspicious cloud activity be detected?

114. Cloud Attack Surface Workbook

Create:

Resource	Exposure	Identity	Data	Trust	Risk
Web App	Public	AppRole	Customer	Internal API	Review
VM01	Private	VMRole	None	AD	Review
Bucket01	Restricted	StorageRole	Sensitive	Cross-account	High
Function01	Public	FunctionRole	API	Database	Review

This becomes the foundation of your attack-path analysis.

115. Cloud Identity Workbook

Create:

Identity	Type	Role	Scope	Privilege	MFA
Alice	Human	Developer	Dev	Medium	Yes
AppRole	Workload	Custom	Production	High	N/A
CICD	Automation	Deployment	Production	Critical	N/A

Pay particular attention to machine identities.

116. Cloud Trust Register

Document:

Account A
   ↓
Trusts Role
   ↓
Account B

or:

Azure Tenant
    ↓
Federated Identity
    ↓
CI/CD Platform

or:

Kubernetes
    ↓
Workload Identity
    ↓
Cloud IAM

Trust mapping often reveals hidden paths.

117. Practical Lab Scenario

Assume an isolated training AWS environment:

Training Account
│
├── Web Application
├── EC2 Instance
├── S3 Bucket
├── IAM Role
├── Lambda Function
└── CloudTrail

You are provided an authorised low-privilege training identity:

lab-developer

Your mission:

Determine whether the identity or workloads possess unnecessary paths to sensitive cloud resources.

118. Step 1 — Confirm Scope

Document:

Account:
Training Account

Identity:
lab-developer

Allowed:
IAM Enumeration
Resource Enumeration
Configuration Review
Controlled Permission Validation

Not Allowed:
DoS
Resource Deletion
Production Access
Unapproved Accounts

119. Step 2 — Establish Identity

Determine:

Who Am I?

Which Account?

Which Roles?

Which Policies?

Which Session?

This establishes your initial position.

120. Step 3 — Enumerate Resources

Build:

Training Account
│
├── WEB01
├── AppBucket
├── ApplicationRole
├── ProcessorFunction
└── Audit Logging

Do not immediately attempt privilege escalation.

Understand the environment first.

121. Step 4 — Analyse Current Permissions

Suppose:

lab-developer
     ↓
Can Modify
     ↓
ProcessorFunction

At first glance this appears to be application-development access.

Continue analysing.

122. Step 5 — Inspect Workload Identity

Suppose:

ProcessorFunction
       ↓
Uses
       ↓
ApplicationRole

Now determine what the role can access.

123. Step 6 — Identify Sensitive Permission

Suppose:

ApplicationRole
       ↓
Can Read
       ↓
Sensitive Application Secret

Your emerging path becomes:

lab-developer
      ↓
Modify Function
      ↓
Function Uses ApplicationRole
      ↓
ApplicationRole
      ↓
Sensitive Secret

124. Step 7 — Validate Without Extracting the Secret

You may already have enough evidence from:

Developer Permission

Function Configuration

Role Assignment

Role Policy

Secret Permission

Do not retrieve the production-like secret simply because you can.

Use minimum necessary validation.

125. Step 8 — Build the Attack Path

Document:

Developer Identity
      ↓
Function Modification Permission
      ↓
Privileged Workload Context
      ↓
ApplicationRole
      ↓
Secret Access
      ↓
Potential Production Resource Access

This explains the security impact.

126. Step 9 — Determine Root Cause

Potential root causes:

Excessive Developer Permission

Overprivileged Workload Role

Insufficient Separation of Duties

Multiple controls contributed to the path.

Potential remediation:

Restrict who can modify the function.
Reduce ApplicationRole permissions.
Separate development and production administration.
Scope secret access to required resources.
Monitor function and IAM modifications.
Use automated IAM policy analysis.
Periodically review cloud attack paths.

128. Step 11 — Retest

After remediation verify:

Developer
   ↓
Required Development Actions
   ✓

Developer
   ↓
Privileged Workload Path
   X

Security fixes should remove the attack path without unnecessarily breaking legitimate workflows.

129. Cloud + Active Directory

Cloud environments often connect to enterprise identity.

Example:

Active Directory
      ↓
Identity Federation
      ↓
Cloud SSO
      ↓
Cloud Roles

A compromised enterprise identity may therefore provide cloud access.

130. Active Directory + Cloud Attack Path

Example:

Standard Domain User
        ↓
AD Privilege Path
        ↓
Cloud Administrator
        ↓
SSO
        ↓
Cloud Management

The previous Active Directory module directly connects to cloud security.

131. Wireless + Cloud Attack Path

Consider:

Corporate Wireless
       ↓
Managed Endpoint
       ↓
Enterprise Identity
       ↓
Cloud SSO
       ↓
Cloud Resources

Security domains connect together.

132. Web + Cloud Attack Path

Example:

Public Web Application
       ↓
Application Weakness
       ↓
Cloud Workload
       ↓
Workload Identity
       ↓
Cloud API
       ↓
Sensitive Resource

This is one of the most important cloud attack-path patterns to understand.

133. Cloud + CI/CD Attack Path

Example:

Developer
   ↓
Source Repository
   ↓
Pipeline
   ↓
Deployment Identity
   ↓
Cloud Production

Cloud security increasingly includes software supply-chain security.

134. Cloud + Kubernetes Attack Path

Example:

Application
   ↓
Pod
   ↓
Kubernetes Identity
   ↓
Cloud Identity
   ↓
Cloud Control Plane

Modern attackers follow identities across platforms.

135. Think Like an Ethical Hacker

When you discover:

Cloud Credential

do not stop at:

Credential found.

Think:

Which Identity?
      ↓
Which Permissions?
      ↓
Which Roles?
      ↓
Which Resources?
      ↓
Which Secrets?
      ↓
Which Trusts?
      ↓
Which Final Impact?

When you discover:

Public Storage

think:

What Data?
   ↓
Read or Write?
   ↓
Intentional?
   ↓
Authentication?
   ↓
Business Impact?

When you discover:

Workload Identity

think:

Which Workload?
      ↓
Who Controls Workload?
      ↓
Which Permissions?
      ↓
Which Secrets?
      ↓
Can Privilege Expand?

136. Think Like the Defender

For every attack path ask:

Which Control Prevents It?

Which Control Detects It?

Who Owns the Control?

How Is It Tested?

How Is It Continuously Monitored?

Example:

Compromised Application
        ↓
Overprivileged Role
        ↓
Sensitive Storage

Preventive controls:

Least Privilege

Workload Isolation

Scoped Storage Policy

Detective controls:

Cloud API Logging

Anomalous Access Detection

Storage Access Monitoring

137. Common Cloud Testing Mistakes

Treating Cloud Like a Traditional Network

Cloud APIs and identities are part of the attack surface.

Running Tools Before Understanding Identity

Always establish your current security context first.

Reporting Every Public Resource

Public exposure may be intentional.

Ignoring Workload Identities

Applications can possess powerful cloud privileges.

Ignoring Permission Combinations

Two low-risk permissions may combine into a critical path.

Ignoring CI/CD

Deployment systems frequently hold production privilege.

Ignoring Cross-Account Trust

Attack paths may cross account boundaries.

Ignoring Hybrid Identity

Cloud and Active Directory may share the same identity plane.

Ignoring Kubernetes

Cloud-native workloads can bridge Kubernetes and cloud IAM.

Downloading Sensitive Data as Proof

Use minimum necessary validation.

Performing Destructive Actions

Cloud APIs can create irreversible impact very quickly.

Trusting Scanner Severity

Always determine the real business attack path.

138. Cloud Security Testing Checklist

[ ] Authorization confirmed
[ ] Provider rules reviewed
[ ] Accounts / subscriptions / projects scoped
[ ] Regions scoped
[ ] Current identity established
[ ] Human identities reviewed
[ ] Machine identities reviewed
[ ] MFA reviewed
[ ] Privileged identities identified
[ ] Effective permissions analysed
[ ] Role assumption reviewed
[ ] Cross-account trust reviewed
[ ] External attack surface mapped
[ ] Public resources reviewed
[ ] Storage reviewed
[ ] Network exposure reviewed
[ ] Segmentation reviewed
[ ] Peering reviewed
[ ] Hybrid connectivity reviewed
[ ] Compute reviewed
[ ] Workload identities reviewed
[ ] Metadata protections reviewed
[ ] Secrets reviewed
[ ] Encryption keys reviewed
[ ] Serverless reviewed
[ ] Containers reviewed
[ ] Registries reviewed
[ ] Kubernetes reviewed
[ ] CI/CD reviewed
[ ] Infrastructure as Code reviewed
[ ] Long-lived credentials reviewed
[ ] Logging reviewed
[ ] Detection reviewed
[ ] Attack paths developed
[ ] Sensitive data minimised
[ ] Evidence collected
[ ] Findings validated
[ ] Root causes identified
[ ] Recommendations developed
[ ] Retesting completed
[ ] Cleanup completed

139. Build Your Cloud Security Testing Toolkit

Create:

Cloud Security Testing Toolkit/
│
├── 01 Cloud Scope Template
├── 02 Provider Testing Rules
├── 03 Account Inventory
├── 04 Identity Inventory
├── 05 IAM Review
├── 06 Privilege Path Analysis
├── 07 Storage Review
├── 08 Network Review
├── 09 Compute Review
├── 10 Workload Identity Review
├── 11 Metadata Security Review
├── 12 Secrets Review
├── 13 Key Management Review
├── 14 Serverless Review
├── 15 Container Review
├── 16 Kubernetes Review
├── 17 CI-CD Review
├── 18 Infrastructure as Code Review
├── 19 Cross-Account Trust Review
├── 20 Hybrid Identity Review
├── 21 Logging Review
├── 22 Attack Path Register
├── 23 Evidence Log
├── 24 Finding Template
└── 25 Cloud Security Report Template

140. The Most Important Cloud Questions

For every identity ask:

Who or what owns it?

How does it authenticate?

What can it access?

What can it modify?

What identities can it assume?

Can it modify IAM?

Can it access secrets?

For every workload ask:

Who can modify it?

Which identity does it use?

What permissions does that identity have?

What network access exists?

What secrets are available?

For every resource ask:

Is it externally exposed?

Who can read it?

Who can modify it?

Which identities trust it?

What sensitive data exists?

For every cloud environment ask:

If the initial identity is compromised, how far can an attacker go?

That is the central cloud security testing question.

141. Definition of Success

A successful cloud security assessment is not:

I found 100 misconfigurations.

It is not:

I ran a cloud scanner.

It is not:

I obtained administrator access.

Success means understanding:

Initial Exposure
      ↓
Identity
      ↓
Permission
      ↓
Cloud Resource
      ↓
Workload
      ↓
Secret / Trust
      ↓
Privilege
      ↓
Control Plane
      ↓
Sensitive Asset
      ↓
Business Impact

and identifying where the organisation should break the path.

Key Takeaways

Cloud security testing is fundamentally different from traditional infrastructure testing.

Remember:

Identity is one of the most important cloud security boundaries.

Cloud permissions must be analysed for indirect privilege, not merely direct privilege.

Human and machine identities both matter.

A workload compromise may become a cloud control-plane compromise.

Metadata services and workload identities require careful protection.

Public resources must be evaluated in business context.

Strong storage security requires both access control and data governance.

Cloud network segmentation still matters.

Secrets should not be embedded in code, images, pipelines, or configuration.

Serverless functions carry identities and permissions.

Kubernetes can create paths into cloud IAM.

CI/CD systems are part of the cloud security boundary.

Cross-account and cross-project trust can create hidden attack paths.

Hybrid identity connects cloud security with Active Directory security.

Logging and detection must protect the cloud control plane.

Do not perform destructive actions merely to prove permission.

The attack path matters more than the individual misconfiguration.

Your core methodology is:

Scope
  ↓
Establish Identity
  ↓
Discover Resources
  ↓
Map Exposure
  ↓
Analyse IAM
  ↓
Analyse Network
  ↓
Analyse Data
  ↓
Analyse Workloads
  ↓
Analyse Secrets
  ↓
Analyse Trust
  ↓
Identify Privilege Paths
  ↓
Build Attack Paths
  ↓
Validate Safely
  ↓
Collect Evidence
  ↓
Report
  ↓
Remediate
  ↓
Retest

The strongest Cloud Ethical Hackers understand:

identity, permissions, APIs, resources, workloads, secrets, networking, trust relationships, attack paths, detection, and business impact.

What’s Next?

➡️ 07 — Red Team Fundamentals

In the next module, you will move from testing individual security domains into understanding how adversary behaviour is simulated across an enterprise.

You will learn:

Red team fundamentals
Red team vs penetration testing
Adversary emulation
Threat intelligence
Rules of engagement
Operational security
Attack infrastructure concepts
Initial access
Execution
Persistence concepts
Privilege escalation
Credential access
Discovery
Lateral movement
Command-and-control concepts
Defense evasion
Collection
Exfiltration concepts
MITRE ATT&CK
Attack chains
Detection validation
Purple teaming
Evidence collection
Red team reporting

You will move from asking:

Can this cloud environment be compromised through identity, configuration, workload, or trust weaknesses?

to asking:

Can we safely simulate a realistic adversary across multiple enterprise security controls and determine whether the organisation can prevent, detect, and respond to the attack?