Hacking the Cloud: AWS Pentesting in Action Sena Yakut, 2025 

About me Cloud Security Architect All links about me 

YES! You really do. We are still not secure in the cloud 100%. Never. Question 1: Do we really need a pentest process for cloud environments? Remember shared responsibility model. 

Question 1: Do we really need a pentest process for cloud environments? Cloud pentesting is complex. Lack of knowledge Lots of different new services / features every day Lots of resources in your environments Traditional tactics → New techniques Even if you know a cloud provider (mostly), you need to know more as a pentester. AWS → Region, Azure → Subscription, GCP → Project 

Configuration review – CSPM is not a pentesting activity. If you’re using a CSPM tool for a pentest and reporting these, you’re probably going the wrong way. It’s a good start. But it’s not the whole point. Question 2: So, what is cloud pentesting? The goal is not to get administrative access or break the whole system mostly. We focus the data → Where is the all data? What are the critical ports that we can use? Exposed Key or Secrets Misconfigured Permissions Unsecure API endpoints / configurations 

Question 2: So, what is cloud pentesting? Enumeration is a really good start. You can find lots of different things more than you expected. DNS Enumeration Find services like CloudFront, Amazon SES, Azure Website, Workmail, Google Workspace Discover keys in public AMIs Enumerate Root User Email Address from the AWS Console → for your phishing campaigns 

We do never know everything! Every service that your customer use, or your developer team use is a fresh start. Question 3: What should we know? We still need to know OWASP Top 10. Web app attack techniques 

How cloud services work, what are the concepts? Based on the environments that you’re testing, you need to focus on different cloud services. Question 3: What should we know? Read the documentation, as always. 

Example 1: Domain TakeOver with CloudFront + AWS S3 

Example 1: Domain TakeOver with CloudFront + AWS S3 The website admin deletes the S3 bucket but forgets the CNAME record deletion. The attacker checks the website and sees the error message. 

Example 1: Domain TakeOver with AWS S3 + CloudFront When you use the static website hosting feature from S3, the URL is like .s3-website- .amazonaws.com. So, getting the bucket name and region is enough to create the same bucket in the attacker’s AWS account with dangerous content. 

Example 2: AWS Lambda SSRF Lambda Function URL from Web App 

Example 2: AWS Lambda SSRF In AWS Lambda, AWS credentials are stored in environment variables. To get them, you need to access a path like file:///proc/self/environ 

Example 2: AWS Lambda SSRF In AWS Lambda, AWS credentials are stored in environment variables. To get them, you need to access a path like file:///proc/self/environ 

Example 2: AWS Lambda SSRF 

Example 2: AWS Lambda SSRF 

Example 2: AWS Lambda SSRF 🫨 

Example 3: Abusing Elastic Container Registry for Lateral Movement An attacker’s initial access can be through vulnerable applications (e.g SSRF), misconfiguration, leaked access keys, developer laptops, and more. 

Volkswagen massive data leak caused by a failure to secure AWS credentials 800,000 Electric Car Owners’ Data Leaked Some critical news that can get your attention Hijacked S3 buckets used in attacks on npm packages www.breaches.cloud 

THANK YOU