Shared Responsibility Model (Attacker Perspective)

Learning Objectives

By the end of this lesson, you will be able to:

Understand the Shared Responsibility Model from an attacker’s perspective.
Identify which cloud components attackers commonly target.
Learn why attackers rarely target cloud providers directly.
Recognise common customer-side security weaknesses.
Apply this knowledge during enterprise cloud penetration testing engagements.

Introduction

The Shared Responsibility Model is one of the most important concepts in cloud security.

From a defensive perspective, it defines who is responsible for securing each layer of the cloud environment.

From an attacker’s perspective, however, it answers a different question:

“Which components can I realistically compromise?”

Professional Cloud Penetration Testers think like attackers to identify weaknesses while remaining within authorised Rules of Engagement.

Attacker’s View of the Cloud

Attackers generally ignore the physical infrastructure managed by the cloud provider.

Instead, they focus on customer-managed resources because these are more likely to contain security weaknesses.

Cloud Provider Infrastructure

↓

Physical Servers

Networking Hardware

Hypervisor

❌ Not Targeted

────────────────────────────

Customer Environment

↓

IAM

Applications

Virtual Machines

Containers

Kubernetes

Storage

APIs

Secrets

CI/CD

✔ Primary Targets

Why Attackers Ignore Cloud Providers

Major cloud providers invest heavily in security.

They operate:

Secure data centres
Physical access controls
Dedicated security teams
Hardware security
Infrastructure monitoring
Continuous patching

Compromising the cloud provider itself is extremely difficult.

Compromising a customer’s cloud configuration is often much easier.

Where Attackers Focus

Most attackers focus on:

Cloud identities
IAM permissions
Public storage
APIs
Kubernetes
Containers
Serverless functions
Secrets
CI/CD pipelines
Cloud workloads

These resources are controlled by customers and frequently contain misconfigurations.

Enterprise Attack Surface

Cloud Identity

↓

Management Console

↓

Cloud APIs

↓

Storage

↓

Compute

↓

Containers

↓

Kubernetes

↓

Applications

↓

Sensitive Data

Every component in the customer-managed layer can become an attack path.

Customer Responsibilities = Attack Surface

The following customer-managed resources are common penetration testing targets.

Customer Responsibility	Why Attackers Target It
IAM Users	Credential theft
IAM Roles	Privilege escalation
Security Groups	Network exposure
Object Storage	Sensitive data exposure
Virtual Machines	Initial access
Containers	Runtime compromise
Kubernetes	Cluster takeover
Secrets	Credential theft
APIs	Authentication bypass
Logging	Disable detection

Attack Scenario 1 — Public Storage

CloudNova Technologies stores customer invoices in an Amazon S3 bucket.

The bucket is accidentally configured for public access.

Attacker workflow:

Internet Search

↓

Public Bucket Discovery

↓

Download Sensitive Files

↓

Data Exfiltration

Root cause:

Customer misconfiguration.

Attack Scenario 2 — Excessive IAM Permissions

Developer account:

AdministratorAccess

Attacker workflow:

Phishing

↓

Credential Theft

↓

AWS Console Login

↓

Administrator Access

↓

Complete Cloud Control

Root cause:

Excessive permissions.

Attack Scenario 3 — Missing MFA

Administrator account:

Username
Password

No MFA.

Attacker workflow:

Credential Leak

↓

Login

↓

Administrator Access

↓

Persistence

↓

Data Theft

MFA would significantly reduce this risk.

Attack Scenario 4 — Public Kubernetes API

Cluster configuration:

Internet

↓

Kubernetes API Server

↓

Weak Authentication

↓

Cluster Access

Possible attacker actions:

Enumerate Pods
Read Secrets
Deploy malicious workloads
Escalate privileges

Attack Scenario 5 — Exposed Secrets

Developer accidentally commits:

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

to GitHub.

Attacker workflow:

GitHub Search

↓

Credential Discovery

↓

Cloud Login

↓

Resource Enumeration

↓

Privilege Escalation

This remains a common real-world issue.

Attack Scenario 6 — Weak Security Groups

Configuration:

0.0.0.0/0

↓

SSH

↓

Linux Server

Attacker workflow:

Internet Scan

↓

Open SSH

↓

Credential Attack

↓

Server Compromise

Restricting access significantly reduces exposure.

Attack Scenario 7 — Vulnerable Containers

Container image contains:

Known vulnerabilities
Outdated packages
Root user

Attacker workflow:

Exploit Vulnerability

↓

Container Access

↓

Credential Discovery

↓

Cloud Metadata Service

↓

Cloud Credential Theft

Attack Scenario 8 — CI/CD Pipeline

Pipeline contains:

Hardcoded secrets
Over-privileged service account

Attacker workflow:

Pipeline Access

↓

Secret Extraction

↓

Cloud Authentication

↓

Infrastructure Compromise

Identity is the Primary Target

Modern cloud attacks rarely begin by exploiting operating systems.

Instead, attackers focus on identity.

Common objectives:

Steal credentials
Assume IAM roles
Abuse OAuth tokens
Compromise service accounts
Bypass authentication
Escalate privileges

Identity is often the shortest path to cloud resources.

Cloud Attack Path Example

Developer Laptop

↓

Phishing

↓

Cloud Credentials

↓

AWS IAM

↓

Administrator Role

↓

Amazon EKS

↓

Secrets

↓

Database

↓

Sensitive Data

One compromised identity can expose multiple services.

Customer Misconfigurations Attackers Love

Attackers actively search for:

Public storage buckets
Disabled MFA
Excessive IAM permissions
Public databases
Public Kubernetes APIs
Weak RBAC
Unencrypted secrets
Hardcoded credentials
Disabled logging
Open Security Groups

Most of these issues require no software exploit—only insecure configuration.

What Cloud Penetration Testers Assess

Professional assessments typically include:

IAM review
Storage security
Security Group analysis
Kubernetes RBAC
Network segmentation
Secret management
API security
Logging configuration
Cloud monitoring
Infrastructure as Code review

These areas align with the customer’s security responsibilities.

Enterprise Assessment Workflow

Review Architecture

↓

Review IAM

↓

Review Networking

↓

Review Storage

↓

Review Compute

↓

Review Containers

↓

Review Kubernetes

↓

Review Logging

↓

Identify Attack Paths

↓

Prioritise Risks

The goal is to identify realistic attacker paths.

Red Team vs Cloud Penetration Tester

Cloud Penetration Tester	Red Team
Focuses on authorised security assessments	Simulates full adversary campaigns
Identifies vulnerabilities	Tests detection and response
Produces remediation reports	Evaluates organisational resilience
Limited by agreed scope	May simulate advanced persistent threats (within approved objectives)

Both approaches provide valuable security insights.

Defensive Lessons

Every attack path teaches defenders something.

For example:

Weakness	Defensive Control
Public bucket	Block public access
Excessive IAM	Least privilege
Missing MFA	Enable MFA
Public Kubernetes API	Private endpoint
Hardcoded secrets	Secret Manager
Weak Security Groups	Restrictive inbound rules
Unpatched containers	Image scanning
Missing logging	Enable CloudTrail and audit logging

Understanding both attack and defence strengthens security assessments.

Best Practices

To reduce attacker opportunities:

Apply least privilege.
Enable Multi-Factor Authentication (MFA).
Remove public access where unnecessary.
Rotate credentials regularly.
Store secrets securely.
Enable continuous monitoring.
Review IAM permissions frequently.
Scan container images before deployment.
Secure Kubernetes clusters.
Conduct regular cloud penetration tests.

Common Mistakes

Avoid:

Assuming the cloud provider secures customer configurations.
Granting administrator permissions by default.
Storing credentials in source code.
Ignoring Kubernetes security.
Leaving storage publicly accessible.
Disabling security logging.
Failing to review IAM permissions regularly.

Knowledge Check

1. Why do attackers primarily target the customer-managed layer of cloud environments?

Answer: Customer-managed resources such as IAM, storage, Kubernetes and applications are configurable and therefore more likely to contain exploitable misconfigurations than the cloud provider’s underlying infrastructure.

2. Why is IAM considered one of the highest-value attack targets?

Answer: IAM controls access to cloud resources. Compromising identities or abusing excessive permissions can provide attackers with broad access across an organisation’s cloud environment.

3. Why are cloud misconfigurations often easier to exploit than software vulnerabilities?

Answer: Misconfigurations such as public storage or excessive permissions often require no sophisticated exploit. Attackers can simply take advantage of insecure settings.

4. What is the role of a Cloud Penetration Tester when assessing the Shared Responsibility Model?

Answer: A Cloud Penetration Tester evaluates customer-managed resources to identify security weaknesses, validate controls and recommend improvements based on realistic attack paths.

5. Why should organisations regularly review their cloud configurations?

Answer: Cloud environments change frequently. Regular reviews help identify newly introduced misconfigurations, reduce attack surfaces and strengthen the overall security posture.

Key Takeaways

Attackers rarely target the cloud provider’s physical infrastructure.
The customer-managed layer is the primary cloud attack surface.
Identity is the most valuable target in modern cloud attacks.
Most cloud breaches result from customer misconfigurations rather than provider failures.
Understanding the attacker’s perspective helps penetration testers identify realistic attack paths and recommend effective defensive controls.

What’s Next?

In the next lesson, we will explore the Cloud Attack Lifecycle, following the stages attackers use to compromise cloud environments—from initial access and reconnaissance through privilege escalation, persistence and data exfiltration.

➡️ Next Lesson: Lesson 04 — Cloud Attack Lifecycle