How to Perform Effective Cloud Penetration Testing

You’ve moved your infrastructure to the cloud. Maybe it was a gradual migration or a full-scale "lift and shift." On paper, it’s great. You have scalability, better availability, and you don't have to worry about hardware failing in a dusty server room. But here is the reality: moving to the cloud doesn't automatically make you secure. In fact, it often just changes the way you get hacked.

Cloud security is a shared responsibility. Amazon, Google, or Microsoft handle the security of the cloud—the physical data centers and the hypervisors. But you are responsible for security in the cloud. That means your configurations, your identity management, your data encryption, and your application code. One misplaced checkmark in an S3 bucket setting or a leaked API key in a public GitHub repo can open the door to your entire environment.

This is why cloud penetration testing is different from traditional network testing. You aren't just scanning for open ports on a firewall; you're looking for identity misconfigurations, overly permissive IAM roles, and vulnerabilities in serverless functions. If you're still treating your cloud environment like a virtual data center, you're missing half the attack surface.

In this guide, we're going to walk through exactly how to perform effective cloud penetration testing. We'll cover the methodology, the tools, the common pitfalls, and how to turn a one-time test into a continuous security posture. Whether you're a security engineer or an IT manager trying to figure out if your setup is actually resilient, this is for you.

Understanding the Cloud Attack Surface

Before you start running tools, you need to understand what you're actually testing. In a traditional environment, the perimeter was clear: the firewall was the border. In the cloud, the perimeter is identity.

The Shift from Network to Identity

In the cloud, the "Identity and Access Management" (IAM) system is the new firewall. If an attacker steals a set of credentials with AdministratorAccess or even a poorly scoped developer role, they don't need to "break in" through a network vulnerability. They just log in.

Effective cloud penetration testing focuses heavily on Privilege Escalation. The goal isn't just to get a shell on a server; it's to find a way to trick the cloud provider into giving the attacker more permissions. For example, can a user with "CreateRole" permissions create a new role with full admin rights and then assign it to themselves? That is a classic cloud-native attack vector.

The Shared Responsibility Model

You can't test everything. If you try to perform a Denial of Service (DoS) attack against an AWS managed service, you'll likely just get your account banned because you're attacking the provider's infrastructure, not your own.

You need to distinguish between:

The Infrastructure Layer: Managed by the provider (AWS, Azure, GCP). You generally can't pen-test this.
The Platform Layer: Managed services like RDS, Lambda, or S3. You test the configuration and access to these.
The Application Layer: The code you wrote and deployed. This is where traditional web app pen-testing (OWASP Top 10) still applies.

Cloud-Specific Target Areas

When planning your test, break your environment into these buckets:

Storage: S3 buckets, Azure Blobs, Google Cloud Storage. Are they public? Are the permissions too broad?
Compute: EC2 instances, Kubernetes clusters (EKS/GKE), Lambda functions. Are there unpatched OS vulnerabilities or leaked environment variables?
Identity: IAM users, roles, and policies. Are there long-lived access keys? Is MFA disabled for privileged users?
Network: VPCs, Security Groups, Load Balancers. Is there "lateral movement" possible between a public-facing web server and a private database?

Phase 1: Reconnaissance and Information Gathering

Reconnaissance in the cloud is about finding "leaks." Because cloud environments are so integrated with DevOps pipelines, the biggest vulnerabilities often start outside the cloud console.

OSINT and Leaked Credentials

The most common way cloud breaches start is through leaked secrets. Attackers don't always "hack" their way in; often, they just find the keys.

GitHub/GitLab Scraping: Using tools like TruffleHog or GitLeaks to search public repositories for AWS Access Keys, Azure Secret Keys, or database passwords.
Public Bucket Scanning: Searching for open S3 buckets using keywords related to your company name. Tools like s3scanner can help identify if your internal documents are accidentally public.
DNS Enumeration: Finding subdomains that might point to "dev" or "staging" environments. These are often less secure than production but share the same identity permissions.

Mapping the Cloud Footprint

Once you have a foothold or a target, you need to map the environment. This is where you figure out what services are actually running.

Service Discovery: Are you using serverless (Lambda)? Containers (ECS/Fargate)? A mix of both?
Identifying the Provider: While usually obvious, knowing the exact version of the cloud provider's API or the specific region can help in tailoring attacks.
Publicly Exposed Endpoints: Identify every API Gateway, Load Balancer, and public IP. This creates your initial "attack map."

The "Outside-In" Approach

Start by mimicking an external attacker. Don't assume they have no credentials. Assume they found a developer's key on a forum or a public repo. This "assumed breach" mentality is far more effective than starting from a dead stop, as it tests your detection and response capabilities rather than just your perimeter.

Phase 2: Vulnerability Analysis and Configuration Review

Now that you know what's out there, you need to find the holes. In the cloud, a "vulnerability" is rarely a bug in the software and more often a mistake in the configuration.

Auditing IAM Policies

This is the meat of cloud pen-testing. You are looking for "Overprivileged Identities."

Wildcard Permissions: Look for policies that use Resource: "*" or Action: "s3:*". If a user only needs to upload files to one folder, they shouldn't have access to every bucket in the account.
Trust Relationships: Check who is allowed to assume which roles. If a development role can assume a production admin role without MFA, you have a critical vulnerability.
Long-Lived Keys: Identify users with access keys that haven't been rotated in 90+ days. These are prime targets for theft.

Misconfigured Storage and Databases

It's a cliché for a reason: people leave buckets open.

Public Read/Write: Can you upload a file to an S3 bucket without authentication? Can you read sensitive config files?
Unencrypted Data: Check if sensitive data at rest is encrypted. While not a direct "entry point," it's a major compliance failure (GDPR/HIPAA) and makes data exfiltration much more damaging.
Database Exposure: Ensure that RDS or CosmosDB instances are not assigned public IP addresses. They should always be in a private subnet.

Serverless and Container Vulnerabilities

Modern cloud apps rely on Lambda, Azure Functions, and Kubernetes. These introduce new risks.

Environment Variables: Developers often put API keys or DB passwords in Lambda environment variables. If an attacker gets execution rights (via a code injection), they can simply run env and steal everything.
Container Escape: In Kubernetes, if a pod is running as "privileged," an attacker who compromises the pod might be able to escape to the host node and gain access to the underlying cloud metadata service.
Cold Start Attacking: Investigating how state is handled between function calls to find potential data leaks between different users.

Phase 3: Exploitation and Lateral Movement

This is where you prove the risk. Finding a "misconfiguration" in a report is one thing; showing that you can steal the customer database is another.

Attacking the Metadata Service (IMDS)

One of the most powerful tools in a cloud pen-tester's arsenal is the Instance Metadata Service. If you find a Server-Side Request Forgery (SSRF) vulnerability in a web app running on an EC2 instance, you can query http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name].

This returns temporary security credentials for the role attached to the instance. You can then configure these keys on your local machine and act as that server. This is how most major cloud breaches actually happen.

Privilege Escalation Paths

Once you have a low-level set of credentials, the goal is to become an Admin. Common paths include:

iam:CreateAccessKey: If you can create a new access key for another user (like an admin), you've won.
iam:PassRole: If you can pass a high-privilege role to a new EC2 instance and then log into that instance, you've escalated.
lambda:UpdateFunctionCode: If you can change the code of a Lambda function that is triggered by an admin, you can make it send the admin's session tokens to your own server.

Lateral Movement Across Accounts

Large companies use multiple cloud accounts (Dev, Stage, Prod).

Cross-Account Roles: Check if the Dev account has a role that allows it to access the Prod account.
Shared Credentials: Often, the same SSH key or API key is used across multiple environments. Find it in Dev, use it in Prod.
VPC Peering: If two VPCs are peered, can you move from a compromised web server in one VPC to a database in another?

Phase 4: Post-Exploitation and Exfiltration

The goal of a professional pen-test isn't just to "get in," but to show what an attacker could actually steal or destroy.

Data Exfiltration Techniques

How would an attacker get the data out without triggering alarms?

Snapshot Sharing: Instead of downloading a 1TB database (which triggers network alerts), an attacker might create a snapshot of the EBS volume and share it with an external AWS account they control.
S3 Sync: Using aws s3 sync to mirror a bucket to an external location.
DNS Tunneling: Sending small bits of data out via DNS queries to avoid detection by standard firewalls.

Persistence Mechanisms

How does an attacker stay in the system even after you rotate the password?

Creating Backdoor Users: Adding a new IAM user with a vague name like cloud-support-service.
Modifying Trust Policies: Adding an external account's ID to a trust relationship so they can assume a role whenever they want.
Scheduling Tasks: Creating a Cron job or a CloudWatch event that re-creates an access key every 24 hours.

Impact Assessment

At this stage, you document exactly what was accessed.

Could you access PII (Personally Identifiable Information)?
Could you shut down the entire production environment?
Could you modify the application's source code in the deployment pipeline?

Comparing Traditional Pen-Testing vs. Cloud Pen-Testing

It's common for teams to think they can just use their old pen-testing checklist for the cloud. That is a mistake. Here is why.

Feature	Traditional Pen-Testing	Cloud Pen-Testing
Primary Goal	Breach the perimeter/network	Breach the Identity (IAM)
Entry Point	Open ports, unpatched software	Leaked keys, SSRF, Misconfigs
Movement	Network pivoting (SSH, SMB)	API calls, Role Assumption
Persistence	Rootkits, Web shells	IAM backdoors, Shadow Admins
Tooling	Nmap, Metasploit, Burp Suite	Pacu, ScoutSuite, CloudEnum
Scope	Physical/Virtual Servers	Managed Services & Serverless

Traditional testing is about "breaking" things. Cloud testing is more about "misusing" things. You aren't fighting a firewall; you're fighting a complex set of permissions.

Common Mistakes in Cloud Pen-Testing

Even experienced security pros trip up when they move to the cloud. Avoid these common traps.

1. Forgetting the "Human" Element (CI/CD)

Many testers focus only on the running environment. But the cloud is deployed via code (Terraform, CloudFormation, Jenkins). If the Terraform script has a hardcoded password, the "secure" environment it creates is actually compromised from the second it is deployed. Always include the CI/CD pipeline in your scope.

2. Over-Reliance on Automated Scanners

Automated tools are great for finding an open S3 bucket, but they are terrible at finding complex IAM escalation paths. A scanner can tell you that a user has iam:PutUserPolicy, but it won't necessarily explain that this allows the user to give themselves AdministratorAccess. Manual analysis of the policy logic is where the real value is.

3. Ignoring the "Quiet" Services

Everyone tests the EC2 instances and the S3 buckets. Few people test the Glue jobs, the SQS queues, or the Secret Manager. Attackers love these "quiet" services because they are often overlooked by security teams and usually have overly permissive roles.

4. Failing to Test the "Blast Radius"

A common mistake is stopping after the first a successful exploit. "I got into the dev server, so the system is vulnerable." No. The real question is: "Once I'm in the dev server, can I reach the production database?" Testing the limits of your segmentation (the blast radius) is what provides actual business value.

5. Testing Without a "Cloud-Aware" Legal Agreement

Testing in the cloud can be risky. If you accidentally trigger a security alarm at AWS or Azure, they might suspend your account. Always ensure you are operating within the provider's "Permitted Services" policy and that you have clear written consent from the account owner.

A Step-by-Step Walkthrough: Simulating a Cloud Attack

To make this concrete, let's walk through a hypothetical scenario.

The Target: A mid-sized e-commerce company using AWS. The Goal: Access the customer database.

Step 1: Discovery

The tester starts with OSINT. They find a public GitHub repository belonging to one of the company's developers. In a commit from six months ago, there is a .env file containing an AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.

Step 2: Initial Access

The tester configures these keys locally. They run aws sts get-caller-identity and find out the keys belong to a user called dev-automation-user. They check the permissions and realize the user has very limited access—mostly just reading from a few S3 buckets.

Step 3: Finding the Pivot

The tester lists the S3 buckets and finds one called company-deployment-scripts. Inside, they find a script used to deploy a Lambda function. The script contains a hardcoded reference to a role: lambda-executor-role.

Step 4: Exploitation (SSRF)

The tester finds a public-facing "Image Upload" feature on the company's website. By manipulating the URL, they discover a Server-Side Request Forgery (SSRF) vulnerability. They use this to query the EC2 metadata service: http://169.254.169.254/latest/meta-data/iam/security-credentials/web-server-role.

Step 5: Escalation

They now have the keys for the web-server-role. They check the permissions and find that this role has the iam:PassRole permission. They use this to create a new, small Lambda function, assign the lambda-executor-role (which they saw in the S3 bucket) to it, and write a simple script to list all secrets in AWS Secrets Manager.

Step 6: Final Goal

The Lambda function returns the database password. The tester uses the SSRF vulnerability again to tunnel into the private VPC and connect to the database using the stolen password.

Result: Complete data breach. The Lesson: The breach didn't happen because of a "hack" in the traditional sense. It happened because of a leaked key, a poorly secured S3 bucket, an SSRF flaw, and an overprivileged IAM role.

How to Build a Continuous Testing Program

A once-a-year penetration test is just a snapshot. In a cloud environment where developers push code ten times a day, that snapshot is obsolete by Tuesday. You need a continuous approach.

Implementing "Security as Code"

The best way to prevent cloud vulnerabilities is to catch them before they are deployed.

Infrastructure as Code (IaC) Scanning: Use tools like Checkov or Tfsec to scan Terraform/CloudFormation templates. If a template defines a public S3 bucket, the build should fail automatically.
Policy as Code: Use Open Policy Agent (OPA) or AWS Config to enforce rules in real-time. For example, a rule that says "No IAM user shall have AdministratorAccess without MFA."

Automating the "Low Hanging Fruit"

You don't need a human to tell you that a bucket is public. Use automated Cloud Security Posture Management (CSPM) tools to monitor your environment 24/7. These tools provide a baseline of security and alert you the moment a configuration changes.

Scheduled Red Teaming

While automation handles the basics, you still need humans to find the complex logic flaws and escalation paths. Schedule "deep dive" pen-tests every quarter or after every major architectural change.

Integrating with Your Workflow

The biggest failure in security is a report that sits in a PDF for three months. Your pen-testing results should feed directly into your engineering team's Jira or GitHub Issues. Security is a feature, not a separate project.

How Penetrify Simplifies Cloud Security

Doing all of the above manually is exhausting. It requires a massive amount of specialized knowledge and a suite of expensive tools. This is exactly why we built Penetrify.

Penetrify is a cloud-native cybersecurity platform designed to take the guesswork out of security assessments. Instead of trying to piece together twenty different open-source tools, Penetrify provides a unified environment to identify, assess, and remediate vulnerabilities.

Here is how Penetrify helps you implement everything we've discussed:

Eliminate Infrastructure Barriers: You don't need to set up "attack boxes" or complex VPNs. Penetrify's cloud-native architecture lets you launch assessments on-demand.
Automated Vulnerability Scanning: We handle the "low hanging fruit." Penetrify automatically scans for misconfigurations, open buckets, and common cloud flaws, so your human testers can focus on the hard stuff—like privilege escalation.
Seamless Integration: We don't believe in static PDF reports. Penetrify integrates with your existing security workflows and SIEM systems, feeding results directly into your remediation pipeline.
Scalability for Growing Teams: Whether you're a mid-market company or a large enterprise, Penetrify scales with you. You can test multiple environments and systems simultaneously without needing to hire a massive internal security staff.
Continuous Monitoring: Move beyond the "snapshot" mentality. Penetrify helps you maintain a strong security posture by providing ongoing visibility into your cloud resilience.

By combining automated scanning with manual penetration testing capabilities, Penetrify ensures that you aren't just "checking a box" for compliance, but actually hardening your infrastructure against real-world attacks.

Checklist for Your Next Cloud Pen-Test

If you're planning a test tomorrow, use this checklist to make sure you've covered the essentials.

$\square$ Scope & Legal

Written permission from the asset owner.
Verification of cloud provider's pen-testing policy (e.g., AWS's "Permitted Services").
Defined "Out of Bounds" targets (to avoid crashing production).

$\square$ Reconnaissance

Scanned public GitHub/GitLab for leaked keys.
Enumerate all public DNS records and subdomains.
Identified all public-facing API endpoints and Load Balancers.

$\square$ Identity & Access (IAM)

Checked for wildcard (*) permissions in policies.
Audited trust relationships for cross-account access.
Identified users without MFA on privileged accounts.
Tested for common privilege escalation paths (e.g., iam:PassRole).

$\square$ Infrastructure & Storage

Verified all S3/Blob storage buckets are private.
Checked for unencrypted sensitive data at rest.
Ensured databases are in private subnets with no public IPs.
Tested for SSRF vulnerabilities targeting the Metadata Service (IMDS).

$\square$ Compute & Containers

Checked Lambda environment variables for secrets.
Scanned container images for known vulnerabilities.
Attempted container escape in Kubernetes pods.
Inspected VPC peering and Security Group rules for lateral movement.

$\square$ Post-Exploitation & Reporting

Attempted data exfiltration via snapshots or sync.
Checked for persistence mechanisms (backdoor IAM users).
Documented the "Blast Radius" of every successful exploit.
Provided clear, actionable remediation steps for every finding.

Frequently Asked Questions

Do I need to notify AWS, Azure, or GCP before I start pen-testing?

In the past, you had to submit a request form for almost everything. Nowadays, most major providers have a "Permitted Services" list. As long as you are testing your own resources and not performing DoS attacks or attacking the provider's underlying infrastructure, you generally don't need a formal request. However, always double-check the latest policy for your specific cloud provider to avoid having your account flagged.

How often should I perform cloud penetration testing?

Because cloud environments change so quickly, a yearly test isn't enough. A better approach is a hybrid model:

Continuous Scanning: Use a tool like Penetrify daily for misconfigurations.
Quarterly Deep-Dives: Perform manual pen-tests every 3 months.
Event-Driven Testing: Run a targeted test whenever you make a major change to your IAM roles or migrate a core service.

What is the difference between a Vulnerability Scan and a Pen-Test?

A vulnerability scan is like a home security system that tells you the front door is unlocked. It finds a known flaw and reports it. A penetration test is like a professional thief who sees the unlocked door, walks in, finds the key to the safe in the kitchen, and then steals the jewelry. One finds the hole; the other proves how much damage can be done through that hole.

Can't I just use a CSPM tool instead of pen-testing?

CSPM (Cloud Security Posture Management) tools are great for finding "known-bad" configurations (e.g., "This bucket is public"). But they can't find "logical" flaws. For example, a CSPM won't tell you that a combination of three different low-privilege roles allows a user to eventually become an admin. That requires the creative, adversarial thinking of a human pen-tester.

Should I do "White Box" or "Black Box" testing?

For cloud environments, I almost always recommend "Gray Box" or "White Box" testing. Black box testing (zero knowledge) spends too much time on the "guessing" phase. If you give the tester a list of your assets and a low-level IAM user, they can spend their time finding the deep, structural flaws that actually matter, rather than spending three days trying to find your dev server's IP address.

Final Thoughts: Security is a Process, Not a Project

If you take one thing away from this guide, let it be this: Cloud security is a moving target.

The moment you finish a pen-test and fix the vulnerabilities, a developer will push a new update, a new cloud service will be enabled, or a new zero-day will be discovered. You cannot "solve" security; you can only manage the risk.

The goal of effective cloud penetration testing isn't to reach a state of "perfect security" (which doesn't exist). The goal is to build a system that is resilient—where a single mistake in a config file doesn't lead to a headline-making data breach.

By focusing on identity, limiting your blast radius, and moving toward a continuous testing model, you put yourself ahead of most attackers. And if you want to stop managing a dozen different security tools and start getting a clear picture of your risk, check out Penetrify. We've built the platform to handle the heavy lifting of cloud assessments so you can focus on building your business securely.

Stop guessing if you're secure. Start testing it.

Back to Blog