Cloud Penetration: Not Your Typical Internal Testing

This blog originally appeared on SethSec: https://sethsec.blogspot.com.

There seems to be a common path for experienced penetration testers who are thrown into the world of cloud penetration testing. I'm talking about internal (aka assumed breach) tests, where the goal is to demonstrate the impact of a compromised user with access to the cloud or a compromised application in the cloud.

The path usually starts with ignorance, is followed by total confusion and questioning everything you know about penetration testing, and ends with… well, it never ends. Why? Because the cloud providers and the cloud native technologies running in these clouds keep evolving at a remarkable rate. There's always more to learn and more attack paths waiting to be found.

I hope walking through my own path and defining the stages of ignorance and awareness I encountered in a playful way might help others progress through the early stages more quickly than I did. 

Level 1: This is just like any other Internal Penetration Test, right?

You connect to your assumed breach starting point within the internal cloud network: something like Kali running on an EC2 instance. You run nmap against the VPC’s internal /16 and hope for the best. You quickly realize there might be a better way to do this.

Level 2: You get your first spark of harnessing cloud magic

You realize if you ask for and receive IAM credentials for the target environment, you can use those cloud credentials and the AWS API to enumerate the IP addresses of all the EC2 instances in the account, and then nmap only those IP addresses. You pat yourself on the back and think you might actually be a cloud security expert now. Unfortunately, you still think that the scope of the cloud attack surface is limited to the services running on EC2. Such a level 2 move. 

Level 3: Woah. There is more than just EC2!?!

You realize if you have Route53 access, you can enumerate all of the A records in AWS managed DNS zones, and this makes you very happy. Lots of new attack surface area. You start to find things hosted by other services, like Kubernetes, ECS, API Gateway, ELB, etc. You might not yet realize what Kubernetes, ECS, API Gateway, and ELB do yet, but that's OK at level 3. The important thing is that you have more things to hack. Go find those services with default credentials, SSRF vulns, missing authentication, etc., and have some fun!

Level 4: You become woke to IAM PrivEsc

You start to learn about what IAM is and how it can be misconfigured. You learn about IAM privilege escalation. You exploit the ec2:RunInstance + iam:PassRole attack path and gain administrative access to the AWS account. Or, you pop a service and realize that service has an IAM role that can assume other IAM roles. You realize, like all of those before you, that Spencer Gietzen was a really smart dude who shared a ton of amazing info with the community, and you get hungry to learn more about IAM privesc. You should probably check out IAM Vulnerable at this point.

Level 5: A secret in the wrong place can be pretty bad

You start to look at other key AWS services like S3, Lambda, ECR, EKS, CloudFormation and you start to see patterns that lead to other (non-IAM) types of privilege escalation: A secret stored in the wrong place (S3 bucket object, Kubernetes secret, Lambda environment variable, EC2 user-data, etc.) can provide unintended privilege escalation opportunities. It reminds you of finding passwords in powershell scripts accessible via SMB shares and you get nostalgic.

Level 6: You start to think in graphs, and even work backwards

You are now always looking for secrets, vulnerable software, and misconfigured IAM policies in the environment. But when you find these, you now work backward and focus on who has access to that secret/vuln software/IAM policy, and you build and execute attack paths that demonstrate that user X has paths to the penetration test trophy targets. You also realize there can be relationships between AWS accounts, like how multiple Active Directory domains can be connected in a single forest. You look for ways that access from a lower-trust account can be used to gain access to the higher-trust accounts (e.g., role trusts) and your attack chains become even more impactful.

Level 7: CI/CD Tooling is a freaking gold mine

You're testing ACME corp, an organization that is fairly mature from a security perspective. Nobody has write permissions to the production cloud environments except for the Ops team and the automated deployment tooling. But, you realize all of the developers DO have access to the continuous deployment tooling, and as it turns out RBAC is not enforced here. You realize this means all developers have access to all of the secrets in the CI/CD tooling software, so you grab the admin creds to the production cloud environment, complete the assessment objectives, and do a victory dance. You file this in the "things I always need to look for" category. It rarely disappoints.

Level 8: You start to think tech monopolies are a good thing

You're feeling really good about cloud security these days. (You can tell that I personally have spent the most time on AWS, but your journey might start with GCP, Azure, or even one of the others.) But eventually, you'll need to run a penetration test in another one of the public clouds, and you very quickly notice there are really big differences between them. You start to pine for the ubiquity of Active Directory. You take solace in the fact that at least half of your cloud penetration testing methodology is cloud agnostic and applies to all cloud providers. But you get sad every time you have to start over and learn the ins and outs of a new cloud provider. On that note, you also get a little sad when you have to context switch to a cloud provider you have not seen in awhile.

Level 9: I know nothing about the cloud

The more you learn about cloud penetration testing, the more confident you are that you don’t know anything about the cloud. You've learned that the attack surface area of each organization depends entirely on the specific services that the target organization uses, how the org deploys those services, how all of the services interact with each other, and how they interact with third-party services. In other words, you know the general approaches you need to take, but are resigned to the fact that you will be learning new cloud services and new cloud native technologies for the foreseeable future.

Honorable mentions:

• Why isn't Responder working as expected in the cloud?
• Hey Google: "What is cloud native?", "What is serverless?", and "What is Kubernetes?"
• Azure Active Directory is Azure's managed Active Directory, right? RIGHT!?

What were some of the "ah-ha" moments in your cloud penetration testing journey? 

Wrap Up

If you are interested in learning more about cloud hacking in general, but in an easy to read format, check out this excellent book by Sparc Flow: How to Hack like a Ghost.

If you want an idea of how we perform objective based Cloud Penetration Testing at Bishop Fox, check out this page, or the talk I gave called Penetrating the Cloud: Uncovering Unknown Vulnerabilities.

Also, check out CloudFox, a tool Carlos Vendramini and I created at Bishop Fox to help automate the process of gaining situational awareness in cloud environments.

Lastly, there are some amazing open source knowledge bases available as well:

• https://hackingthe.cloud/
• https://cloudsecdocs.com/
• https://www.secwiki.cloud/
• https://cloudsecwiki.com/

Happy cloud hacking! If you'd like to chat about cloud security, hit me up on the Cloud Security Forum Slack (sethsec) or on Mastodon @ https://infosec.exchange/@sethsec.