Virtually every organisation runs critical infrastructure on AWS, Azure, or GCP in 2026. And virtually every one of them has IAM misconfigurations, overpermissive S3 buckets, or exposed metadata endpoints that an attacker can pivot from initial access to full cloud account takeover. Cloud security hacking is the highest-demand offensive skill of 2026 — and the highest-paying specialisation in bug bounty. This guide covers the attack surface, the tools, and the methodology ethical hackers use to find and prove cloud vulnerabilities in authorised engagements.

☁️
After reading this you will understand:
The top cloud misconfigurations attackers exploit · IAM privilege escalation paths in AWS · How S3 bucket attacks expose sensitive data · SSRF to cloud metadata credential theft · Cloud pentesting tools (Pacu, ScoutSuite, CloudFox) · Cloud red team methodology — authorised engagement approach

~19
min read

📊 QUICK POLL
What’s your current experience with cloud security testing?




The Cloud Attack Surface — What’s Different

Traditional network penetration testing focuses on open ports, running services, and software vulnerabilities. Cloud penetration testing shifts the focus fundamentally: the primary attack surface in cloud environments is not software vulnerabilities — it is configuration mistakes. IAM policies that grant too many permissions. Storage buckets with public access. Logging disabled so attacker actions go undetected. Security groups open to the world.

The cloud provider secures the physical infrastructure. The customer secures everything they configure on top of it — and that includes IAM, storage permissions, network access controls, logging, encryption, and dozens of other settings. Misconfiguring any of these creates an exploitable attack surface that exists nowhere in the traditional network model.

securityelites.com

TRADITIONAL PENTESTING vs CLOUD PENTESTING — ATTACK SURFACE COMPARISON
🖥️ TRADITIONAL NETWORK
Open ports and services
Software vulnerabilities (CVEs)
Default credentials
Network segmentation gaps
Kernel and OS exploits
Physical access controls

☁️ CLOUD ENVIRONMENT
IAM misconfigurations (primary)
Public storage buckets
Missing MFA on cloud accounts
Overpermissive security groups
Logging and monitoring gaps
Exposed metadata endpoints
Serverless/container misconfigs

KEY INSIGHT: In cloud environments, the attacker’s goal is not to exploit software vulnerabilities — it is to discover and abuse IAM permissions and misconfigurations. A single misconfigured IAM role can provide access to an entire cloud account’s data without exploiting a single CVE.

Traditional vs Cloud Penetration Testing attack surface comparison. The shift from software exploitation to configuration abuse is the fundamental change cloud environments introduce. This is why cloud pentesting requires a different skill set — and why professionals who develop cloud security expertise are in such high demand in 2026.

Top Cloud Misconfigurations — What Attackers Target First

Cloud security assessments consistently find the same categories of misconfigurations across organisations of all sizes. These are not exotic vulnerabilities — they are common configuration defaults left unchanged, or best practices not applied. Each one represents a high-probability finding in any cloud engagement.

#1 — OVERPERMISSIVE IAM POLICIES
Roles with "Action": "*" or "Resource": "*" grant far more access than needed. Finding: any identity that assumes this role has full access to targeted service. Real-world impact: lambda functions, EC2 instances, and developer accounts routinely found with admin-equivalent policies.
#2 — PUBLIC S3 BUCKETS
Buckets with Block Public Access disabled and public ACLs expose all objects to unauthenticated download. Often contain: database backups, API keys in config files, customer PII, source code. AWS Block Public Access setting exists — it is simply not always enabled, especially on older buckets created before the feature existed.
#3 — MISSING MFA ON PRIVILEGED ACCOUNTS
AWS root account and IAM admin users without MFA are vulnerable to credential stuffing. Root account access keys in code repositories (a common finding) + no MFA = immediate full account compromise. AWS mandates MFA for root since 2024 but enforcement at IAM admin level is inconsistent.
#4 — SECURITY GROUPS OPEN TO 0.0.0.0/0
Security groups with inbound rules permitting all IPs (0.0.0.0/0) on ports like SSH (22), RDP (3389), database ports (3306, 5432), or admin panels expose services directly to the internet. Any credential on these exposed services is brute-forceable or targetable with published exploits.
#5 — CLOUDTRAIL / LOGGING DISABLED
CloudTrail (AWS), Activity Log (Azure), and Cloud Audit Logs (GCP) provide complete records of API calls. When disabled, attacker actions — IAM changes, data access, resource creation — leave no trace. Attackers increasingly check and disable logging early in an engagement to operate without detection.

IAM Attacks — The #1 Cloud Attack Vector

Identity and Access Management (IAM) is the central nervous system of every cloud environment — it controls who can do what to which resources. Misconfigurations in IAM are the primary attack vector in 2026 cloud breaches, accounting for the majority of significant cloud security incidents. Understanding IAM is to cloud security what understanding TCP/IP is to network security.

AWS IAM Enumeration — Authorised Engagement Commands
# Determine current identity
aws sts get-caller-identity

# List all IAM users
aws iam list-users

# List attached policies for a user
aws iam list-attached-user-policies --user-name [username]

# Get all permissions in the account (requires iam:GetAccountAuthorizationDetails)
aws iam get-account-authorization-details

# List IAM roles (potential privilege escalation via role assumption)
aws iam list-roles

# Check if current identity can assume a role
aws sts assume-role --role-arn arn:aws:iam::[ACCOUNT]:role/[ROLENAME] --role-session-name test

# Check access keys (looking for unused/old keys)
aws iam list-access-keys --user-name [username]
aws iam get-access-key-last-used --access-key-id [KEY_ID]

# Automated IAM enumeration and privilege escalation detection
pacu                               # launch Pacu framework
Pacu> run iam__enum_permissions     # enumerate all permissions
Pacu> run iam__privesc_scan         # scan for privilege escalation paths

S3 Bucket Attacks — Finding Exposed Data

S3 bucket misconfigurations consistently produce some of the most impactful findings in cloud security assessments — and some of the highest bug bounty payouts for researchers who find them on in-scope programmes. The challenge is that bucket exposure is often invisible to the organisation: files are accessible to anyone with the URL, but without active scanning, the organisation may have no idea their data is publicly readable.

S3 Enumeration & Public Access Testing — Authorised Only
# List all S3 buckets in the account (requires s3:ListAllMyBuckets)
aws s3 ls

# Check public access block settings for a bucket
aws s3api get-public-access-block --bucket [BUCKET-NAME]
# All 4 settings should be "true" — if any are "false", public access possible

# Check bucket ACL
aws s3api get-bucket-acl --bucket [BUCKET-NAME]
# Look for "AllUsers" or "AuthenticatedUsers" grantees = public access

# Check bucket policy
aws s3api get-bucket-policy --bucket [BUCKET-NAME]
# Look for "Principal": "*" = any identity can perform allowed actions

# List objects in bucket (if public)
aws s3 ls s3://[BUCKET-NAME] --no-sign-request
# --no-sign-request = test unauthenticated access

# ScoutSuite for complete S3 audit across the account
scout aws --no-browser -r [REGION]
# Generates HTML report with all S3 misconfigurations flagged

⚡ KNOWLEDGE CHECK — Part 1
You run aws s3 ls s3://target-backup-bucket --no-sign-request and receive a list of objects including database_backup_2026.sql. What does this confirm?




SSRF to Cloud Metadata — The Critical Path

The combination of an SSRF vulnerability in a web application and a cloud-hosted EC2 instance creates a Critical attack chain: SSRF → AWS metadata endpoint → IAM credentials → full AWS service access. This chain was the root cause of the Capital One breach and remains one of the most impactful findings in cloud security assessments in 2026. We covered SSRF hunting in detail in Bug Bounty Day 10 — this section covers the cloud escalation phase specifically.

Cloud Metadata Endpoints — Reference (In-Scope Targets Only)
# AWS IMDSv1 (via SSRF on EC2-hosted application)
http://169.254.169.254/latest/meta-data/                 # root metadata
http://169.254.169.254/latest/meta-data/iam/security-credentials/  # IAM role name
http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE]  # CRITICAL: creds

# GCP — requires Metadata-Flavor: Google header
http://metadata.google.internal/computeMetadata/v1/
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Azure — requires Metadata: true header
http://169.254.169.254/metadata/instance?api-version=2021-02-01
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/

# STOP AT ROLE NAME — do NOT exfiltrate/use actual credentials
# Confirming metadata endpoint = accessible → Critical severity → report immediately
⚠️ RESPONSIBLE DISCLOSURE — METADATA CREDENTIALS

If SSRF returns AWS IAM credentials (AccessKeyId, SecretAccessKey, Token): stop immediately. Screenshot the response showing the credential structure only — blur/redact actual key values. Do NOT use the credentials to access any AWS service. Do NOT attempt to enumerate their permissions. Report immediately at Critical severity. Using exfiltrated cloud credentials — even “to demonstrate impact” — violates programme safe harbour and potentially computer fraud law.


Cloud Privilege Escalation — From User to Admin

Cloud privilege escalation differs fundamentally from traditional OS privilege escalation. Instead of kernel exploits and SUID binaries, cloud privesc exploits IAM policy misconfigurations — finding a sequence of allowed IAM actions that cumulatively grant admin access from a low-privilege starting point. Rhinosecurity Labs documented over 20 distinct AWS privilege escalation paths, all of which remain valid in 2026.

securityelites.com

AWS IAM PRIVILEGE ESCALATION PATHS — COMMON EXAMPLES
iam:AttachUserPolicy → Admin
aws iam attach-user-policy –user-name [self] –policy-arn arn:aws:iam::aws:policy/AdministratorAccess
If allowed: attaches AdministratorAccess managed policy to your own account → instant admin.

iam:CreateAccessKey on another user
aws iam create-access-key –user-name [admin-user]
Creates API keys for another user (e.g., an admin) → use those keys to access account as them.

iam:PassRole + ec2:RunInstances → RCE with Admin Role
aws ec2 run-instances –iam-instance-profile Name=[admin-role] –user-data [reverse-shell]
Launch EC2 instance with admin IAM role + reverse shell payload → shell with admin permissions.

TOOL: Pacu > run iam__privesc_scan automatically checks all known privilege escalation paths for your current identity. Reports which paths are exploitable given your current permissions.

AWS IAM Privilege Escalation Paths — three examples of how low-privilege IAM identities escalate to admin access through misconfigured policies. All three require only specific IAM permissions, not software exploits. Pacu’s iam__privesc_scan module checks all 20+ known escalation paths automatically during authorised assessments.

Cloud Pentesting Tools — Pacu, ScoutSuite & CloudFox

🦜 PACU — AWS Exploitation Framework
The “Metasploit for AWS” — modular framework for post-compromise AWS exploitation. Modules include IAM enumeration, privilege escalation scanning, S3 data discovery, Lambda backdooring, and more. Requires valid AWS credentials for the target environment. Authorised engagements only.
pip3 install pacu –break-system-packages
pacu
Pacu> set_keys                     # configure AWS creds
Pacu> run iam__enum_permissions     # enumerate current identity
Pacu> run iam__privesc_scan          # find escalation paths

🔍 SCOUTSUITE — Multi-Cloud Security Auditing
Audits AWS, Azure, and GCP configurations against security best practices. Generates a detailed HTML report flagging misconfigurations across IAM, storage, networking, logging, and encryption. The fastest way to get a complete picture of a cloud environment’s security posture on an authorised assessment.
pip3 install scoutsuite –break-system-packages
scout aws –no-browser              # AWS audit
scout azure –no-browser            # Azure audit
scout gcp –no-browser              # GCP audit

🦊 CLOUDFOX — Attack Path Automation
Identifies actionable attack paths in cloud environments — similar to BloodHound for Active Directory but for cloud. Maps attack paths visually from current identity to high-value targets (admin, sensitive S3, databases). Supports AWS with Azure in development.
cloudfox aws –profile [profile] all-checks
cloudfox aws –profile [profile] permissions
cloudfox aws –profile [profile] instances


Cloud Red Team Methodology — Authorised Engagement Approach

⚡ KNOWLEDGE CHECK — Part 2
During an authorised AWS assessment you discover your IAM identity has the permission iam:AttachUserPolicy. What should you do next?



Cloud Red Team Engagement — 5-Phase Methodology
1
Scope Definition — Define authorised accounts, regions, services. Confirm rules of engagement (production impact limits, escalation permission). Get explicit written authorisation.
2
Reconnaissance & Enumeration — ScoutSuite full audit, IAM enumeration (Pacu), S3 bucket discovery, EC2/network mapping, CloudTrail status check.
3
Exploitation (Authorised) — Test and confirm public S3 access, SSRF to metadata (stop at role name), IAM privilege escalation paths (confirm before executing).
4
Impact Demonstration — Document each finding with evidence (screenshots, CLI output). Map impact chain from initial finding to maximum possible impact. Assign CVSS scores.
5
Reporting & Remediation — AWS/Azure/GCP-specific remediation steps for each finding. Prioritise by CVSS and exploitability. Include architectural recommendations for cloud security hardening.

📋 CLOUD PENTEST QUICK REFERENCE — ARTICLE 4
AWS / Azure / GCP Security Testing 2026

# ── AWS IDENTITY & IAM ──────────────────────────────────────────
aws sts get-caller-identity           # who am I?
aws iam list-users                    # list IAM users
aws iam list-roles                    # list IAM roles
aws iam get-account-authorization-details # full IAM config

# ── S3 BUCKET TESTING ───────────────────────────────────────────
aws s3 ls                             # list all buckets
aws s3 ls s3://[bucket] --no-sign-request # anon access test
aws s3api get-public-access-block --bucket [bucket]
aws s3api get-bucket-policy --bucket [bucket]

# ── CLOUD METADATA (SSRF TARGET, IN-SCOPE ONLY) ─────────────────
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://metadata.google.internal/computeMetadata/v1/

# ── AUTOMATED TOOLS ─────────────────────────────────────────────
scout aws --no-browser                # full AWS security audit
pacu                                  # AWS exploitation framework
Pacu> run iam__privesc_scan           # escalation paths
cloudfox aws --profile [p] all-checks # attack path mapping

Finished reading? Track your progress.

☁️
Every client in 2026 is in the cloud.
The ethical hacker who tests cloud finds the most critical vulnerabilities.

Start with our free ethical hacking course to build the web and network fundamentals, then extend into cloud security testing with Pacu, ScoutSuite, and CloudFox.

Free 100-Day Ethical Hacking Course →

Frequently Asked Questions – Cloud Security Hacking

What are the most common cloud security misconfigurations in 2026?
Top cloud misconfigurations: overly permissive IAM policies with wildcard actions, publicly accessible S3 buckets, missing MFA on privileged accounts, security groups open to 0.0.0.0/0 on sensitive ports, and logging (CloudTrail/Activity Log) disabled. IAM misconfigurations are the #1 cause of significant cloud security incidents.
What is IAM privilege escalation in cloud security?
IAM privilege escalation exploits overly permissive IAM policies to gain higher privileges — typically full account admin from a low-privilege starting point. Examples: iam:AttachUserPolicy (attach admin policy to yourself), iam:CreateAccessKey on another user’s account, iam:PassRole + ec2:RunInstances (launch EC2 with admin role). Pacu’s iam__privesc_scan module checks all known paths automatically.
How do attackers exploit misconfigured S3 buckets?
Public read S3 buckets expose all objects for unauthenticated download — commonly containing database backups, source code, API keys, and customer data. Test with aws s3 ls s3://[bucket] --no-sign-request. AWS Block Public Access settings prevent this when all four settings are enabled.
What is the AWS metadata service and why is it a risk?
The EC2 IMDS at 169.254.169.254 returns IAM credentials for the instance’s role when accessed. Via SSRF on a cloud-hosted application, an attacker makes the server fetch its own credentials. Obtaining IAM keys via SSRF is consistently Critical — stop testing at role name confirmation and report immediately without using the credentials.
What tools do ethical hackers use for cloud pentesting?
Key cloud pentesting tools 2026: Pacu (AWS exploitation framework — like Metasploit for AWS), ScoutSuite (multi-cloud security auditing for AWS/Azure/GCP), CloudFox (attack path automation), Prowler (compliance checks), Trivy (IaC misconfiguration scanning). All require authorised credentials for the target environment.
Is cloud pentesting different from traditional network pentesting?
Yes — the attack surface shifts from network ports and CVEs to IAM permissions and configuration mistakes. Privilege escalation happens through IAM policy manipulation not kernel exploits. Most cloud providers have penetration testing policies (AWS Penetration Testing Policy) specifying what testing is permitted. Cloud pentesting requires understanding IAM, VPC, storage services, serverless, and container platforms.

ME
Mr Elite
Founder, SecurityElites.com | Cloud Security Specialist | Educator

The first cloud assessment I ran took me two hours to find a publicly accessible S3 bucket containing the company’s entire user database — complete with hashed passwords and PII for 2.3 million customers. The misconfiguration had been in place for 14 months. No one had noticed. ScoutSuite flagged it in 12 minutes. Cloud security is where a single configuration check produces findings that traditional pentesting takes days of manual work to uncover. It is the most ROI-positive skill investment in offensive security in 2026.

LEAVE A REPLY

Please enter your comment!
Please enter your name here