Seth Art, principal at Bishop Fox and creator of CloudFox and CloudFoxable, joined Cloud Security Podcast for an exclusive interview, Cloud Pentest of AWS with Open Source, to talk about his extensive experience with cloud penetration testing. Hear his insights on how AWS cloud penetration testing differs from other types of penetration testing, why cloud configuration reviews aren’t enough sometimes, and tales from the trenches of cloud pen testing engagements. If your organization is thinking about getting a pen test done on your AWS account or you want to learn how to pen test in AWS, you don’t want to miss this conversation with Ashish Rajan, Cloud Security Podcast host, and Seth Art. We hope you enjoy this deep dive into AWS penetration testing!

Ashish: For those viewers that aren’t familiar with your security journey, what was your path into cloud security?

Seth: I’ve been an offensive security pen tester for 13 years. My start in offensive security was in web application pen testing. Prior to that I worked on the defensive side, but I really wanted to be an ethical hacker. I studied the OWASP top 10 and similar resources which led to my first web application security job. I kept hearing about internal pen testing and stories about simulating access to a building or network and mapping out the worst-case scenario for clients. I was fortunate enough to get a job doing web application, mobile, and internal pen testing. I loved being able to go to a client’s site, plugging into their network, and within a few days getting access to every computer, server, and piece of data in the organization. I was able to educate organizations on how to better protect their digital infrastructure. Over time, I started to get more internal pen tests requests at Bishop Fox that were based entirely in cloud environments. So, we built a cloud pen testing methodology which is essentially internal pen testing but tailored to cloud environments.

Ashish: For those that are well versed in web application testing, how do you differentiate between that and cloud pen testing?

Seth: Before I get to the difference between web app and cloud pen testing, let’s touch on the various types of cloud pen testing. It can be external only which means a pen tester is attempting to get into the cloud environment, but that only scratches the surface. In that type of engagement, the internal controls may only get tested if the external perimeter is breached. I spend a lot of time focused on assumed breach scenarios where we look at the whole cloud infrastructure with the assumption that a breach will happen. An application may be compromised, a user will fall victim to a phishing attempt, or a bad actor gains internal access, to name a few examples of potential compromise situations.

So now let’s get back to web application testing. This is the way that I like to explain it. If you’re worried about the code that you’ve written for your application that is hosted in the cloud, a web application pen test is most appropriate. You are looking for things like cross-site scripting, SQL injection, SSRF, etc. However, if you’re concerned about the application configuration in your overall cloud environment and are wondering what would happen if that application was compromised, that is the ideal framework for a cloud penetration test.

Ashish: From a scale perspective, how do you describe the scale of an AWS footprint and what does that mean for you as a pen tester?

Seth: One of my favorite parts about working at Bishop Fox is working with enterprise clients. We help protect some of the largest AWS environments that exist. To fit with the growing scale of cloud environments, we recommend segmenting workloads into different AWS accounts, based on what they are supposed to be doing. This applies to Azure and Google, as well. If your organization has more than 10-20 AWS accounts, which is extremely common these days, there are different strategies to scope cloud pen tests. For example, we may group together accounts that are related and do a pen test on those as a mechanism to support security in scaled cloud environments.

Ashish: What are some of the common findings that you discover during cloud pen tests? What do you find layered on top of cloud misconfiguration?

Seth: It is always relevant to run a configuration check against your cloud environment. There are lots of tools like Prowler, Scout Suite, or Steam Pipe with compliance modules. I don’t consider this to be the same as penetration testing, but it does help you find a lot of low hanging fruit via predefined mechanisms to hunt for misconfigurations, such as a publicly exposed bucket.

However, with cloud penetration testing we are trying to find not only the ways that you’ve misconfigured the cloud, but your organization’s information in the cloud. For example, perhaps you put an application on an EC2 instance, but maybe it’s a docker container and it has no authentication. Let’s imagine this enables you to access the most sensitive information in the company without authentication. For penetration testers this means that after gaining internal access, the only necessary step is to browse through this application to reach the sensitive data. Configuration reviews would not pick this up, so this is a big value point for implementing an offensive security approach.

Ashish: I feel there is a shift about how we have to think about adversaries in the cloud compared to other types of digital threat landscapes. Do you think there are foundational changes that pen testers must account for in cloud environments?

Seth: The goal in cloud pen testing is not to get to IAM administrative access. The goal as a consultant is to ask the client where the most sensitive data is located. If you are an in-house pen tester or Red Teamer, the goal is to work with business units across your organization to ask where the sensitive data is located. That is where you focus your time and effort to get to that data by any means necessary, such as identifying misconfigurations or performing privilege escalations.

Ashish: What are some of the first things you do to kick off a cloud pen test?

Seth: The really cool thing about the cloud is that it is all API-based. You can use the EC2 API to show the IP addresses of the EC2 instances or the IP addresses of the ECS containers. We are constantly enumerating the attack points and necessary commands.

When we are conducting cloud pen tests there are two things that we are generally looking to answer:

• If an application is compromised, what is the worst that can happen?
• If a user is compromised, what is the worst that can happen?

Both of those situations often have IAM permissions assigned to it – you can assign a role to a Lambda, an EC2, or a Kubernetes cluster. The impact of what you can do depends on the permission that the thing has access to. For example, a developer may not have IAM permissions because it isn’t necessary to have administrative access. But if the developer has SSM or SSH access to all the EC2 instances, the developer does in fact have admin access. Therefore, testing assumptions is important for cloud pen testing to be successful.

Ashish: Why should users be concerned with the different ways that permissions or lack thereof enable access into cloud environments?

Seth: Most of the time we are simulating a user that has some IAM permissions, but with restrictions. Clients we work with want to know if a user could take a path to get around the restrictions. The process of a penetration tester is to look at what permissions can lead to a privilege escalation path.

For example, SSM is a way that allows you to connect to an SSM send command or start session. This is a new way to connect to an EC2 instance without an SSH key if you have that IAM permission.

Here is another interesting example. You can attack Lambda from the front door which is the code running in the Lambda function. Let’s say you give somebody access to create a Lambda and attach an IAM role to it. If there is an IAM role that trusts the Lambda service, you can just write code in the Lambda that gives away credentials. You attach the admin role to it and now you are the administrator.

You have to be careful in the way that you design patterns in cloud environments.

Ashish: What happens after you’ve used tools like CloudFox and Prowler to map the cloud environment for a pen testing engagement? Are there common services in AWS that you look for because they are frequently misconfigured?

Seth: Prowler, Scout Suite, and Steam Pipe compliance module help you get low hanging fruit findings. CloudFox and Pacu, for example, give you leads and internal attack surface area. The next step is network scanning, application enumeration, etc. This is where things differ from a web application pen test which focuses on one component. In a cloud pen test, CloudFox gives us all the end points, so we determine the path of least resistance. My next step is the path that looks like a good lead to reach the objective.

Ashish: From a client perspective, what is usually recommended to share with the pen tester to make the most of the engagement time? What are scoping mistakes that you encounter?

Seth: Asking questions to potential clients to properly scope their cloud environments is critical. Things like how many AWS accounts they have, how many different services there are, and how many resources are all extremely important data points for a successful pen test. We generally don’t perform cloud pen tests in less than a week because the internal testing component requires time to familiarize ourselves with the environment. Then we spend time trying and failing. When we find a good attack path, it can get complicated in cloud environments, and we are constantly learning to attack different parts of the cloud. We generally test our clients' preventative controls versus defense mechanisms since that falls more into Red Teaming.

Ashish: As a pen tester, how do you view the shared security model between customers and AWS?

Seth: Both the client and AWS have responsibilities. Pen testing focuses on the client side of the shared responsibility model. There are many common ways that companies misconfigure their cloud environments. For example, a company might have tens of accounts or more. By default, those accounts should be isolated from each other, but there are ways to break that. In a production account, there is a role that trusts a principal in a development account. If I can gain admin privileges in a development, I can assume admin in production.

Ashish: What types of boundaries that AWS has set for penetration testing?

Seth: AWS used to require alerts from pen testers, but that is no longer the case. An example of something that I would never do as a pen tester is nmap an S3 bucket because that is clearly AWS’s digital property. When I look at S3 buckets, I’m looking at how the client has misconfigured things. During a pen test engagement, we are not testing AWS’s infrastructure. We are looking to use the same AWS components that are already in the client’s environment, but in a way that they were intended to be used.

Ashish: I think cloud pen testing is more complex than what we’ve previously experienced. What sort of skill sets do you need to perform cloud pen tests? What sorts of skills transitions can people expect if they want to learn cloud pen testing?

Seth: With cloud pen testing, you will never know everything, and every single engagement will be different because it depends on what AWS services the client is using. In some cases, the client will be using a service that you don’t have experience with, so part of your job is to ramp up your knowledge.

For traditional pen testers that want learn more about cloud pen testing, I recommend getting into AWS Goat, any Terraform examples, and there is nothing that beats deploying an environment or trying to build an environment. This offers invaluable learning experiences. I built a tool called IAM Vulnerable, an intentionally vulnerable terraform code that you can deploy to your own environment. You can test around 30 IAM privilege escalation paths and perform common attacks.

For a cloud security architect that wants to get into offensive security, I would recommend looking into OSCP, Hack the Box, Hacking the Cloud, and starting to transition to the offensive security mindset.