Ashish: Seth, can you tell us a bit about yourself and how you got to where you are today?

Seth: Sure, I am currently a principal security consultant at Bishop Fox, but I started my security journey working at a help desk and then moved to Symantec on the defensive side. I loved that type of work and learned a lot, but I really had the itch to hack stuff. So, I got into web application pen testing for a while and then eventually moved to internal, external, and physical pen tests.

Once I arrived at Bishop Fox, I was assigned to a lot of internal pen tests but realized that some of those were based entirely in cloud infrastructure. All the attack methodologies about traditional network testing were tossed to the side, and I had to quickly learn how to attack cloud-native services, containers, Kubernetes, etc. I have been working on that for the last three years and leading the Cloud Penetration Testing practice at Bishop Fox.

Ashish: What is the difference between internal and external pen tests? Is the objective the same?

Seth: With external pen tests, you are testing whether somebody without any credentials or social engineering can get into an organization’s network. The ways that we do that are:

• Vulnerability scanning for vulnerable software;
• Manual testing to identify any vulnerability that isn’t found by a vulnerability scanner; anything publicly-facing that is missing authentication or that has default credentials.

Password spraying is an example of manual testing. Let’s suppose that I find an employee list (or try different probable naming conventions), make my best guess at a potential password, and try it against every employee login. That may be my way into the network. Manual testing is much more comprehensive than simply running vulnerability scanners. It is true that with external pen tests, you sometimes get to dabble in internal pen testing, if I find a way into the network. Essentially, you follow the thread that you pulled in the external test and keep going with the client’s approval.

With an internal pen test, you don’t have to find your way in. We simulate a scenario where somebody will gain a foothold in the network; for example, a malicious employee that may intend to cause harm to the company or an employee that is compromised by social engineering. Or an evil maid attack where someone walks into the building and plugs into the network jack. The objective for all these scenarios is identifying what the worst thing that can happen is, where the most sensitive data is located, and what the attack paths are to get to it.

Ashish: What is the difference between assumed breach and objective-based cloud pen testing?

Seth: Internal pen tests are essentially an assumed breach where you already have a foothold in the environment. You’ve taken the position of an assumed breach by using the given foothold.

Objective-based pen tests focus on attack paths that map to an identified objective. The first step of a good objective-based pen test is talking to your client to discover what they are concerned about and where the sensitive data is stored. That is what becomes your objective, or trophy target, as we call it at Bishop Fox. The pen test is designed around getting to the objective.

Cloud pen testing is a combination of internal and external pen testing techniques; however, the internal pen testing should always be assumed breach and objective-based. Unlike attackers, pen testers work under time constraints during engagements, so spending the allotted time looking for attack paths instead of black box hunting for where the sensitive data is located is always a better use of resources for clients. Use your time wisely with pen testers!

Ashish: People are starting to say that network pen tests are dead. What is your opinion on that?

Seth: Internal pen testing is by no means dead; it is simply on the decline. There are still AS400s around, and I believe Active Directory pen tests will be relevant for another ten to 20 years. Cloud pen testing is just growing at a much faster rate, in my opinion.

One of the things that attracted me to network pen tests was Active Directory internal pen tests. However, more organizations are moving to the cloud for their infrastructure and we're finally seeing an uptick in organizations moving to Azure Active Directory. I’ve learned to refocus my traditional network pen testing skills to be applicable to cloud environments.

Ashish: There is a general understanding that the next generation of network pen testing is essentially cloud pen testing. The weakest spot seems to be cloud misconfigurations these days. How would you approach a network and cloud pen test at the moment? Are they the same in your opinion, or do you recommend doing a cloud penetration test in addition to a network pen test?

Seth: This is an issue that frequently comes up while scoping work for clients and I can give insights to how we solve it at Bishop Fox.

It depends on the objective and where the infrastructure is in the environment. I’ve done lots of work for newer companies that don’t have a data center or Active Directory. All their employee identities are in Google Workspace or Azure Active Directory. All their workloads and things that would traditionally be in the data center are instead in Azure, GCP, or AWS. So, there is no corporate infrastructure, and the recommended offensive security solution would be a cloud penetration test. Then we can focus on internal and external testing.

However, many companies are migrating, so they have data in different types of locations. They still have a data center and a corporate network, but they are moving infrastructure – like services, databases, and data – into the cloud. In this case, a company may benefit from an internal pen test and a cloud pen test.

Ashish: Are there any examples of findings or attacks that you can share on the cloud pen test side? What about attack methods that you like to use during engagements?

Seth: I would love to share a story. This is an example of something that could be caught in a cloud configuration review, but I’ll share what happened next and why you would want to enlist the help of a trusty cloud pen tester.

So, in an AWS test we found a role that looked like it was accidentally configured, so anybody could assume the role. That isn’t great news, but to assume a role, you need to know the name of a role. Therefore, it is unlikely to be discovered by just anyone on the internet. This is a great exercise to enumerate who would know the name of that role – most likely any current employee or previous employee who had access to the AWS account. We discovered that this role could invoke Lambdas, but it could not edit or change them. As a pen tester, my job was to figure out how to get the existing Lambdas to do something malicious. In this engagement, we had read-only access, so we were able to read all the Lambda functions. We combed through all the Lambda functions and found one with a remote code execution vulnerability (RCE). We then were able to invoke the Lambda and do a callback to our hacker attack box.

Essentially, we had a situation where somebody could assume the role, get a call back from the Lambda, and, Ashish, guess what permissions the Lambda has access to? It could read all the secrets from secrets manager. Then, we determined that the coolest secret was an admin API token for their backend service with all their most sensitive data in the secrets manager and used that for our demonstration.

This is an interesting process to examine because a configuration review might flag it, but without any context. This is a situation where you want an experienced pen tester to walk through the multi-step approach that demonstrates how a former employee can gain unauthorized access to the production API.

I’ll share one more story before we move on. Recently, one of our pen testers found a bastion host during an Azure assumed-breach pen test. We were given the credentials of an employee within Azure Active Directory. The pen tester was able to log into SSH with Azure Active Directory credentials. So, he got onto the bastion host, which was a Linux box. One of the users on that box made their home directory world readable for everyone. He rifled through that user’s directory and found credentials for Snowflake, a third-party database service. He used those credentials to connect to the third-party provider and gained access to production data.

Ashish: How would you describe a cloud pen test these days, and how is it more than a configuration review?

Seth: Let’s use a crawl, walk, run analogy. Configuration review is equivalent to crawl. Objective-based cloud pen testing is walk, and Red Teaming is run. Configuration review is an important first step, but only scratches the surface and leaves it exploitable. Once you have configuration review in place, objective-based pen testing is the next important step in your journey. This is what helps you find the types of attack paths people really exploit and can improve an organization's maturity leading to eventual Red Teaming exercises. Now, once you are at a place where you have defenders or a full-fledged Blue Team and you want to test that team’s preventative, detective, and reactive controls, then you are ready Red Teaming, the most realistic type of offensive security testing there is.

Ashish: How do you scale cloud pen testing? Is there a way to scale cloud pen testing the same way that organizations scale deployments in the cloud?

Seth: I’ll give you two answers. For my first answer, prioritization is key. Let’s consider a traditional situation where an organization has 100 applications, but not enough budget for 100 application pen tests. They might prioritize an external penetration test so they can look at only the public-facing applications and then pick a subset of applications to perform a full-scale application penetration test on.

I would take a similar approach for organizations that have a lot of cloud accounts, subscriptions, or projects. Cloud configuration review and cloud security posture management (CSPM) are likely the most pragmatic solutions to start with. That will help determine which accounts are important to focus on for subsequent cloud pen testing. For example, there may be large production and development environments along with a shared area with buckets and images and those would be good to nominate for cloud pen tests above other areas of the cloud environment.

The second approach is for a large enterprise that has more resources and budget than the previous examples. Conducting cloud pen tests on the infrastructure that supports every single application is often a better option, leading to a more robust security posture. This is a trend we are seeing at Bishop Fox.

Ashish: Are the skillsets used in traditional pen testing different from those used in cloud pen testing?

Seth: So, the skillsets are definitely different. There are a lot of cloud-specific skills, and they vary between different cloud environments. I started with AWS and only some of those skills transferred to Azure and GCP. One of the biggest differences is that in the cloud there are APIs for everything. In traditional network pen testing, the first step is to run Nmap or vulnerability scanning, but in cloud environments, these things don’t apply. Learning shortcuts is a big part of changing your mindset to work in cloud environments.

Ashish: Can you tell us more about CloudFox and CloudFoxable, the open-source tools that you’ve developed?

Seth: We created CloudFox because we wanted to teach people how to find things more quickly and exploit them. But then I realized that I needed to teach people how to use CloudFox more efficiently. For the last six months, I've been working on CloudFoxable, an intentionally vulnerable environment. I built CloudFoxable in a way that offers a middle ground for cloud pen testers. It is Terraform, so you create the Terraform environment in your own AWS account, but all the gamification, the flags, the hints, and the scoreboard happens at CloudFoxable.

The first challenge is as simple as deploying Terraform. As the starting user, you have permission to access a single secret and you get a flag. In the next challenge, the starting user can assume a different role. And then that role has access to the second flag. It works up from simple complexity to quite complex. Thus far, I’ve received great feedback that it helps practitioners that have very little cloud offensive security knowledge to get to the point where they can start to understand attack paths and the things that cloud pen testers encounter on engagements.