Cloud Penetration Testing: AWS Attack Techniques Explained

AWS penetration testing is authorised security testing that simulates how a real attacker would compromise an AWS environment — starting with IAM enumeration, moving through misconfiguration discovery and privilege escalation, and ending in data access or lateral movement. Unlike a misconfiguration checklist, it follows actual attacker methodology: enumerate identities, abuse SSRF to steal instance credentials from the metadata service, exploit permissive policies, and pivot through Lambda or EC2 roles. For Indian cloud teams running production on AWS, understanding this attack chain — not just the settings to fix — separates a real security assessment from a compliance checkbox.

What Cloud Penetration Testing Actually Tests

Cloud penetration testing differs fundamentally from testing an on-premises network. There's no perimeter firewall to breach — the attack surface is IAM, API permissions, and the trust relationships between services. A misconfigured IAM policy, an SSRF-vulnerable web application, or an overly permissive Lambda role can hand an attacker the same access a stolen root password once did, without touching a traditional network boundary.

This matters because the shared responsibility model puts configuration security on the customer. AWS secures the infrastructure; the customer secures everything built on top of it — identities, policies, network configuration, application code. Most real-world AWS compromises exploit exactly this layer, not a flaw in AWS's own infrastructure.

AWS Penetration Testing Rules: What's Actually Authorised

Before any technique below is used, scope has to be nailed down. AWS's self-service pentest policy authorises testing resources you own across a defined set of in-scope services — EC2, RDS, CloudFront, Lambda, API Gateway, and more — but prohibits certain activities regardless of ownership: DNS zone walking via Route 53, denial-of-service testing, and anything affecting other customers' resources. A multi-account organisation also requires each account owner's authorisation, not just the payer account's.

1. Confirm the account tested is one you own, with written authorisation if performed for a client.
2. Cross-reference AWS's current permitted-services list — testing an unlisted service can trigger AWS's abuse response process.
3. Never test shared or multi-tenant resources without isolating scope first.
4. Log every action taken — this becomes remediation evidence and your defence if AWS's monitoring flags it.

Phase 1: IAM Enumeration and Reconnaissance

Every real-world AWS attack chain starts with identity enumeration, because IAM is the control plane for everything else. An attacker who gains even low-privilege credentials — via a leaked access key in a public GitHub repo, a phished developer, or a compromised CI/CD pipeline — begins by mapping what that identity can actually do.

Tools built for this, such as Pacu and ScoutSuite, automate calls like iam:ListUsers, iam:ListRoles, and iam:ListPolicies to build the account's identity graph: which users exist, which roles trust which principals, and which policies attach where. Many of these calls succeed even for low-privilege identities, so this phase is often near-silent. The output is a permissions graph that turns the next phase, privilege escalation, into pattern-matching rather than guesswork.

Privilege Escalation Through Misconfigured IAM Policies

Once an attacker holds a permissions graph, they search it for known IAM privilege-escalation patterns — documented, repeatable paths where a low-privilege identity can grant itself higher privilege through a policy the account owner didn't intend to be exploitable. These patterns are consistently found in real environments, particularly where policies were written broadly at setup and never tightened.

Every one of these paths is exploitable without any AWS vulnerability — they're consequences of policy design. That's why cloud pentesting has to test the permission logic, not just scan for public resources.

SSRF to IMDS: Stealing Instance Credentials

Server-side request forgery (SSRF) is one of the most consequential web vulnerabilities in an AWS context, because of what sits behind it: the Instance Metadata Service (IMDS). Every EC2 instance can query a well-known internal address for metadata about itself — including the temporary credentials attached to its IAM instance role.

If a web application on that instance has an SSRF flaw — say, a "fetch URL for preview" feature that doesn't validate the target — an attacker can direct that request at the metadata endpoint instead of an external URL. The application, running with the instance's network access, fetches the role's temporary access key, secret key, and session token and returns them in the response. The attacker now has valid AWS credentials with whatever permissions that role holds, usable from outside the network.

IMDSv2 closes this hole by requiring a session token — a PUT request first, then a GET that includes it in a header — rather than the original simple GET-only IMDSv1 protocol. Most SSRF payloads can trivially perform a GET but not the two-step sequence, which is why enforcing IMDSv2 account-wide meaningfully reduces this attack path.

S3 Bucket Exposure and Overly Permissive Policies

S3 misconfiguration remains one of the most consistently exploited AWS weaknesses, largely because bucket policies, ACLs, and account-level Block Public Access settings interact in ways that are easy to get wrong. A bucket policy granting s3:GetObject to Principal: "*" makes every object world-readable regardless of what the console UI implies, and older buckets can carry forward public settings nobody remembers configuring.

This phase is largely enumeration-driven: tools brute-force likely bucket names, check s3:GetBucketAcl and s3:GetBucketPolicy where credentials are already held, and attempt anonymous reads against discovered buckets. What's exposed varies enormously — from harmless static assets to customer data exports, database backups, or source code with embedded credentials.

Lambda and Role Abuse

Lambda functions frequently run with execution roles broader than the function needs, because it's easier to attach one wide role than to scope permissions per-function. An attacker who compromises a function — via a vulnerable dependency, an injection flaw, or a leaked deployment package — inherits its execution role's full permission set, including cross-service access the function itself never uses.

A related risk sits in environment variables: database credentials and API keys are commonly stored there in plaintext rather than Secrets Manager, and any principal with lambda:GetFunctionConfiguration permission can read them directly, without compromising the function's code at all.

Defence in Depth: The Controls That Actually Close These Paths

Every technique above has a specific, well-documented control. The gap between "known best practice" and "actually enforced" is where most real breaches happen — these controls are rarely secret, just inconsistently applied across fast-growing environments.

This figure is drawn from IBM's Cost of a Data Breach Report. CERT-In advisories have separately and repeatedly flagged misconfigured cloud identity and access controls as a recurring root cause in incidents reported by Indian organisations, per periodic advisories published by CERT-In, India's national computer emergency response team.

Where This Fits Into a Broader Cloud Security Programme

Cloud environments change faster than most annual audit cycles can track — a new IAM role, Lambda function, or S3 bucket can introduce an exploitable path the same week it's created. A structured AWS penetration test, run against a properly scoped account under AWS's own testing policy, verifies whether the attack chains above are actually exploitable, not just whether individual settings look correct in isolation. Where regulatory submission requires it, this is typically delivered with a CERT-In empanelled partner. Bachao.AI, built by Dhisattva AI Pvt Ltd, gives Indian cloud teams continuous visibility into exactly these misconfiguration classes between audit cycles. Organisations processing personal data in AWS should also map findings against obligations under India's DPDP Act, since an exposed S3 bucket or over-privileged role can itself constitute a reportable incident.

Want to know whether your AWS account has an exploitable privilege-escalation path right now? Get a free VAPT scan, or browse the Bachao.AI blog for more technique-level security guides.