9.1 Cloud Shared Responsibility, Threat Landscape, and IAM Attacks

Cloud Shared Responsibility, Threat Landscape, and IAM Attacks

The transition from on-premises data centers to cloud computing fundamentally alters incident handling. Defenders no longer possess physical custody, hypervisor visibility, or raw network tap access. Instead, responders navigate multi-tenant environments governed by application programming interfaces (APIs), virtualization layers, and strict service agreements. Mastering the Shared Responsibility Model, common cloud threat vectors, Identity and Access Management (IAM) abuse primitives, and the distinction between control plane and data plane compromises is vital for certified incident handlers.

The Shared Responsibility Model in Incident Response

The Shared Responsibility Model establishes security obligations between the Cloud Service Provider (CSP) and customer organizations across delivery models:

• Infrastructure as a Service (IaaS): The CSP secures physical facilities, hardware, and hypervisor virtualization. The customer is responsible for guest operating systems, virtual networking, access control lists, middleware, applications, identity policies, and data security. During an IaaS compromise, the customer conducts host-level triage, memory acquisition, disk snapshotting, and OS remediation.
• Platform as a Service (PaaS): The CSP manages physical hardware, hypervisors, operating systems, runtime engines, and platform patching. The customer maintains application code, configuration settings, user access, and data. During an incident, the customer lacks host OS access and relies on application logs, database connection telemetry, and platform diagnostics.
• Software as a Service (SaaS): The CSP manages the entire technology stack from hardware to software. The customer responsibility narrows to identity governance, user authentication, role assignment, data classification, and monitoring user behavior. Response is constrained to auditing SaaS activity logs, revoking compromised sessions, and managing resource sharing permissions.

Incident Response and Forensic Boundaries

Cloud investigations encounter strict boundaries separating customer access from CSP infrastructure. In multi-tenant environments, physical servers host workloads belonging to multiple unrelated organizations. Consequently, CSPs prohibit customers from capturing hypervisor memory, tapping physical switches, or inspecting physical disks, as doing so would violate neighbor confidentiality. Responders must investigate exclusively through CSP-provided APIs, guest operating system agents, virtual network flow logs, and storage snapshots. Furthermore, organizations cannot independently launch invasive vulnerability scans or penetration tests against shared infrastructure without adhering to CSP testing rules.

Cloud Threat Taxonomy: Misconfigurations and Leaks

Misconfigurations and exposed credentials are common cloud intrusion paths, but responders should evaluate them alongside vulnerable workloads, supply-chain compromise, and provider advisories:

• Misconfigured Object Storage: Storage repositories like Amazon S3 and Azure Blobs are frequently exposed due to faulty access control lists (ACLs) or overly permissive policies granting global access to AllUsers or AuthenticatedUsers. Threat actors scan public IP ranges to exfiltrate sensitive databases, customer personally identifiable information (PII), and unencrypted backups.
• Exposed Management Consoles: Administrative web consoles (AWS Management Console, Azure Portal, Google Cloud Console) protected solely by single-factor authentication fall victim to credential stuffing and password spraying. Gaining console access grants adversaries immediate graphical control over resource provisioning, billing, and identity governance.
• Leaked API Keys in Public Repositories: Developers inadvertently commit code containing hardcoded credentials (such as AWS keys beginning with AKIA, Azure service principal secrets, or GCP service account keys) to public repositories like GitHub. Automated adversary scrapers detect leaked keys within seconds, triggering scripts that provision high-compute instances for cryptocurrency mining or pivot into enterprise subscriptions.

Cloud Identity and Access Management (IAM) Attack Vectors

In cloud architectures, identity serves as the primary security perimeter, governing authentication and authorization across users and workloads:

• Privilege Escalation Primitives: Attackers with limited initial permissions leverage specific APIs to escalate to administrative levels. The iam:PassRole permission allows passing an existing administrative role to compute services (EC2, ECS, Lambda), allowing code execution under that elevated role. Similarly, iam:CreateAccessKey generates new keys for dormant administrative accounts, while iam:CreatePolicyVersion enables an attacker to define a permissive policy granting administrative wildcard actions as the default version.
• Role Assumption and Lateral Movement: Threat actors exploit sts:AssumeRole to pivot across accounts and subscriptions. Overly permissive trust policies lacking external ID checks allow adversaries to assume cross-account roles and exfiltrate data from secondary production environments.
• Compromised Service Principals: Non-human service accounts (Azure Service Principals, GCP Service Accounts) often hold extensive privileges for CI/CD automation. Attackers harvest client secrets or exploit Server-Side Request Forgery (SSRF) against the Instance Metadata Service (IMDSv1) to steal temporary credentials.
• Static Keys vs. Temporary STS Tokens: Long-lived access keys lack built-in expiration, are rarely rotated, and remain valid until manually revoked. Conversely, temporary tokens issued via AWS Security Token Service (STS) expire automatically within minutes to hours, require continuous renewal, and can enforce multi-factor authentication, substantially limiting attacker dwell time.

Control Plane vs. Data Plane Compromises

Incident handlers must distinguish between control plane and data plane compromises:

• Control Plane (Management Plane): Encompasses administrative APIs and orchestration services that create, modify, configure, and delete cloud resources. Operations include launching instances, modifying security groups, and altering IAM policies. A control plane compromise occurs when attackers manipulate cloud APIs directly—such as disabling audit trails, creating backdoor accounts, or launching illicit workloads.
• Data Plane: Involves direct interactions with workloads, services, and data stored in cloud resources, such as querying an RDS database, transferring files via SSH, or invoking s3:GetObject.

A data plane compromise accesses or alters hosted assets without necessarily changing cloud configurations. Handlers must analyze both control plane telemetry and data plane logs to establish the full attack path and accurately assess exfiltration scope.