Cloud Identity Attacks

Learning Objectives

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

Understand why identity is the primary cloud attack surface.
Learn common cloud identity attack techniques.
Identify IAM misconfigurations.
Understand privilege escalation methods.
Recognise identity-based attack paths.
Learn defensive strategies used in enterprise environments.

Introduction

In traditional networks, attackers often targeted servers.

In modern cloud environments, attackers target identities.

Why?

Because identities already have permission to access cloud resources.

Instead of exploiting operating systems, attackers often:

Steal credentials
Abuse IAM permissions
Compromise service accounts
Assume privileged roles
Exploit federation
Access cloud APIs

Cloud identities are now considered the most valuable asset in enterprise cloud environments.

What is a Cloud Identity?

A cloud identity represents a user, workload or application that can authenticate to cloud resources.

Examples include:

IAM Users
IAM Roles
Service Accounts
Managed Identities
Federated Users
Applications
CI/CD Pipelines
Kubernetes Service Accounts

Every cloud request is associated with an identity.

Why Identity is the Primary Attack Surface

Cloud environments are API-driven.

Every API request requires an identity.

If an attacker compromises a privileged identity, they may gain access to:

Virtual Machines
Storage
Kubernetes
Databases
Secrets
Networking
Monitoring
Serverless services

One compromised identity can expose an entire cloud environment.

Identity Attack Lifecycle

Credential Discovery

↓

Credential Theft

↓

Authentication

↓

Enumeration

↓

Privilege Escalation

↓

Persistence

↓

Lateral Movement

↓

Data Access

Identity attacks often progress rapidly once valid credentials are obtained.

Common Identity Targets

Attackers frequently target:

IAM Users
IAM Roles
Root Accounts
Service Accounts
OAuth Tokens
API Keys
Access Keys
Session Tokens
Managed Identities
Kubernetes Service Accounts

Attack 1 — Credential Theft

Attackers attempt to steal credentials using:

Phishing
Malware
Password Managers
Keyloggers
Browser Cookies
Memory Dumps
Public Git Repositories

Example:

Developer Laptop

↓

Phishing Email

↓

AWS Credentials

↓

AWS Console Login

Attack 2 — Access Key Exposure

Cloud credentials are frequently exposed in:

GitHub repositories
Configuration files
Docker images
Backup files
CI/CD pipelines
Documentation

Example:

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

Attackers continuously scan public repositories for exposed credentials.

Attack 3 — Weak Passwords

Examples:

Password reuse
Predictable passwords
Default credentials
Shared administrator accounts

Common attacks include:

Password Spraying
Credential Stuffing
Brute Force (where applicable)

Strong authentication policies significantly reduce these risks.

Attack 4 — Missing Multi-Factor Authentication (MFA)

Without MFA:

Username

+

Password

↓

Cloud Access

With MFA:

Username

+

Password

+

Second Factor

↓

Access Granted

MFA is one of the most effective protections against credential theft.

Attack 5 — IAM Privilege Escalation

Attackers look for identities that can obtain additional permissions.

Examples:

AdministratorAccess policies
iam:PassRole abuse
Role assumption
Policy modification
Access key creation
Service account abuse

Example:

Developer Role

↓

Assume Admin Role

↓

Administrator Access

Attack 6 — Role Assumption Abuse

Cloud roles are designed for temporary access.

Attackers may abuse overly permissive trust relationships.

Example:

Compromised IAM User

↓

AssumeRole()

↓

Administrative Role

↓

Full Cloud Access

Review trust policies carefully during assessments.

Attack 7 — Service Account Compromise

Applications frequently use service accounts.

Targets include:

Kubernetes Service Accounts
AWS IAM Roles
Azure Managed Identities
Google Service Accounts

Weak permissions can allow attackers to move from workloads into cloud infrastructure.

Attack 8 — Kubernetes Service Accounts

Pods often inherit cloud permissions.

Example attack path:

Compromised Pod

↓

Service Account Token

↓

Cloud IAM

↓

S3 Bucket Access

↓

Sensitive Data

Least privilege should be applied to every service account.

Attack 9 — Metadata Service Abuse

Cloud virtual machines expose metadata services.

Examples:

AWS

169.254.169.254

Azure

169.254.169.254

Google Cloud

169.254.169.254

If a workload is compromised, attackers may attempt to access metadata to retrieve temporary credentials.

Protect workloads and limit unnecessary permissions to reduce this risk.

Attack 10 — Federation Abuse

Enterprise environments commonly integrate:

Microsoft Entra ID
Active Directory
Okta
Ping Identity

Attackers may target:

SAML assertions
OAuth tokens
Federation trust relationships
Identity providers

Compromising federation can provide broad access across multiple cloud services.

Attack 11 — OAuth Token Theft

Modern cloud applications rely heavily on OAuth.

Potential attack vectors include:

Stolen browser tokens
Refresh token theft
Token replay
Excessive application permissions

Review OAuth application permissions regularly.

Attack 12 — API Key Exposure

Developers sometimes expose API keys in:

Source code
Mobile applications
JavaScript files
Configuration files

Examples include:

AWS API Keys
Azure API Keys
Google API Keys
Third-party SaaS tokens

Secrets should always be stored in dedicated secrets management services.

Identity Attack Path Example

Developer

↓

Phishing

↓

IAM Credentials

↓

AWS Console

↓

IAM Enumeration

↓

Role Assumption

↓

Amazon EKS

↓

Secrets Manager

↓

Customer Database

One compromised identity can enable access to multiple services.

Cloud Identity Enumeration

Cloud Penetration Testers review:

AWS

IAM Users
Roles
Policies
Access Keys
MFA
Trust Policies

Azure

Users
Groups
Managed Identities
Role Assignments
Conditional Access

Google Cloud

Service Accounts
IAM Bindings
Roles
Organization Policies

The goal is to identify excessive permissions and weak identity controls.

Enterprise Scenario

CloudNova Technologies has:

320 IAM users
91 IAM roles
15 Kubernetes service accounts
Microsoft Entra ID federation
AWS IAM Identity Center integration

Assessment findings:

Five administrator accounts without MFA.
Two IAM roles trusted by all authenticated users.
One Kubernetes service account with cluster-admin privileges.
Long-lived access keys older than 365 days.
Hardcoded API keys in a CI/CD pipeline.

These issues create multiple identity-based attack paths.

Defensive Controls

Organizations should implement:

Multi-Factor Authentication (MFA)
Least Privilege Access
Role-Based Access Control (RBAC)
Conditional Access Policies
Short-lived Credentials
Identity Monitoring
Privileged Access Management (PAM)
Identity Federation Controls
Secret Rotation
Continuous IAM Reviews

Identity security should be treated as a continuous process.

Identity Assessment Checklist

During a cloud penetration test, verify:

Best Practices

Prefer temporary credentials over long-lived access keys.
Enable MFA for all users, especially privileged accounts.
Apply least privilege to users, roles and service accounts.
Rotate credentials regularly.
Review IAM permissions frequently.
Monitor authentication events.
Secure workload identities.
Audit federation relationships.

Common Mistakes

Avoid:

Granting AdministratorAccess by default.
Using long-lived credentials.
Disabling MFA.
Hardcoding credentials in source code.
Sharing privileged accounts.
Over-privileging service accounts.
Ignoring workload identities.

Knowledge Check

1. Why are cloud identities considered the primary attack surface?

Answer: Cloud identities control access to cloud services and APIs. Compromising an identity often provides attackers with authorised access to resources without needing to exploit software vulnerabilities.

2. Why is Multi-Factor Authentication (MFA) important?

Answer: MFA adds an additional layer of authentication, making it significantly more difficult for attackers to use stolen credentials to access cloud resources.

3. How can attackers abuse IAM roles?

Answer: Attackers may exploit overly permissive trust relationships or excessive permissions to assume privileged roles and gain broader access within the cloud environment.

4. Why are Kubernetes service accounts important during cloud security assessments?

Answer: Service accounts may be associated with cloud permissions. If they are over-privileged, compromising a workload can allow attackers to access cloud resources beyond the Kubernetes cluster.

5. What is the most effective way to reduce identity-based attack risk?

Answer: Apply least privilege, enable MFA, use short-lived credentials, secure service accounts, monitor authentication events and regularly review IAM permissions.

Key Takeaways

Identity is the foundation of cloud security.
Most modern cloud attacks begin with compromised identities.
IAM, service accounts and federation require regular security reviews.
Privilege escalation and role abuse are common attack techniques.
Strong identity governance significantly reduces the cloud attack surface.

What’s Next?

In the next lesson, we will explore Cloud Storage Attacks, including attacks against Amazon S3, Azure Blob Storage and Google Cloud Storage, public bucket exposure, access control weaknesses, encryption issues and data exfiltration techniques.

➡️ Next Lesson: Lesson 08 — Cloud Storage Attacks