Correctly executing penetration tests against AWS environments is a difficult, complicated task that requires knowledge and practice in a variety of different areas. It requires both AWS knowledge and red-team-like knowledge to perform a worthwhile test.

A problem that shows up here is that there is currently not any easy way to test and learn these skills. As an example: for web applications, there are all kinds of resources for directly testing your knowledge, skills, and techniques repeatedly. These resources include things like bug bounty programs, CTFs, and vulnerable-by-design virtual machines/web applications that you can setup on your personal computer for all kinds of testing (Like OWASP’s WebGoat).

There aren’t these kinds of resources for learning penetration testing and attack techniques against AWS environments. AWS, and the cloud in general, is being adopted more and more by companies all over the world every day, which means that attackers are getting pulled in as well. No one wants to test new attack techniques against their own professional environment, regardless if it is a dev, test, or prod environment and no one wants to setup a vulnerable environment to attack manually either, as it may open the account to external risks that they are unaware of.

To address these needs, we created CloudGoat – an inexpensive, simple, vulnerable-by-design AWS environment that can be deployed and shutdown at will.

CloudGoat on GitHub: https://github.com/RhinoSecurityLabs/cloudgoat

CloudGoat is used to deploy (and shutdown) a vulnerable set of AWS resources, designed to teach AWS security risks.  We ensure that all vulnerabilities we include are only exploitable by someone with access to the given AWS account. This includes white listing access to sensitive resources to a personal IP address you supply where possible.

In its default state, CloudGoat can safely be launched into your AWS account and left running, without having to worry about threats from external actors.

Note: This can change if you make configuration changes to the environment while attacking it. To avoid this, as part of your attack, do not allow inbound security group rules to unknown IP addresses for the vulnerable instances or upload personal/private information to the vulnerable resources that CloudGoat deployed. It is suggested that CloudGoat is deployed into either its own account, separate from any real AWS resources, or at least a separate region, so that you can feel secure in your testing.

Messed something up, worried about some changes you made, or you just are done for the day? Run the shutdown script and CloudGoat will be wiped from your account.

One of the primary drivers for developing CloudGoat was to support research and development of Pacu, the open-source AWS attack framework mentioned here in a previous post.

Pacu will be released at BSidesLV on Wednesday, August 8th, where Spencer Gietzen will be doing a talk on AWS security research and how that research played into us building Pacu. Pacu will be released at that event completely open source.

EDIT (8/9/18): Pacu is now live on GitHub: https://github.com/RhinoSecurityLabs/pacu

CloudGoat and Pacu currently are, and will continue to be, closely tied together in that our goal is for CloudGoat to support the attack modules available in Pacu. This will allow Pacu users to test attacks against an AWS environment without needing to target real systems or having to spin up their own resources.

The CloudGoat deployment script uses Terraform and some customization in Python to launch the required resources into your account. It will generate passwords and key pairs that are used within the environment and output them to a file in the CloudGoat working directory. These credentials stand as a starting place when attacking the environment. There are multiple IAM users, so a good starting point would be taking the access keys or password belonging to one of those users and acting as if you just compromised that info and have no more info than that.

CloudGoat launches the following resources into your AWS account (currently into us-west-2 where possible):

• 1 CloudTrail trail
• 1 GuardDuty detector
• 1 Lambda function
• 2 S3 buckets
• 1 Elastic Load Balancer
• 1 EC2 instance
• 3 EC2 security groups
• 3 IAM users
• 3 IAM roles
• 1 IAM group
• 1 IAM instance profile
• 1 Lightsail instance
• 1 CodeBuild project
• 1 Glue Development Endpoint (Disabled by default)

The EC2 security groups are setup to only allow inbound access from a specific IP address range that you supply upon deployment. All these resources will be removed from your AWS account when running the shutdown script as well.

No! With CloudGoat running in an account without the AWS Free Tier enabled, it is estimated to cost roughly $1-3 per day, depending on your usage. We suggest deploying the environment, performing your testing and attacks, then shutting down the environment when you are done for the day to ensure you don’t encounter any large unexpected charges. The environment can be created and destroyed quick enough to make this the ideal solution.

CloudGoat was built with Pacu, Rhino Security Labs AWS post-exploitation attack tool, in mind, which means that we are aiming for all Pacu modules to be usable against the CloudGoat environment. As Pacu continues to develop, so will CloudGoat and we will follow up with other posts detailing how to use Pacu to attack this environment.

The following list is the different places in the environment that would make sense in a real scenario of compromise. Use that initial access to learn more about the environment and expand throughout it.

• SSH access to the EC2 instance
• The access keys for the IAM user “Joe” (Database administrator)
• The access keys for the IAM user “Bob” (EC2 manager)
• The password for the IAM user “Administrator” (Account administrator)
• SSH access to the Glue development endpoint (If you have enabled it)

The credentials (IAM key pairs and passwords) for the different users and servers and IP addresses for the servers will be output to a “credentials.txt” file in CloudGoat’s root directory and any keys (SSH/GPG) will be stored in the “./keys” folder.

There are many goals to aim for when attacks any AWS environment. This list is just to show some of what you should keep in mind as you move throughout an AWS environment.

• Privilege escalation
• Logging/monitoring evasion
• Data and information enumeration
• Data exfiltration
• Persistent access

Not necessarily directly relevant to CloudGoat, but it’s important to make the point that malicious actors don’t follow the rules that us penetration testers and security professionals do, so don’t think that these are the only kinds of attacks that might be used against an environment in the real world. The following list includes some examples of these kinds of attacks.

• Destruction (deletion of resources)
• Ransom (holding your resources/data hostage)
• Money/resource exhaustion (like denial of service attacks)
• Cryptomining (launching cryptocurrency miners in your account)
• Customer-targeted attacks (targeting the users of the services you offer publicly, AKA your customers)

Warning:  The following section contains spoilers for the different attack vectors and vulnerabilities in the environment.

If you want to begin targeting CloudGoat without internal details, skip to the conclusion below.

The following list details many weaknesses in the CloudGoat environment after being deployed into an account (as of writing this blog, for the latest list, checkout the CloudGoat GitHub).

1. The EC2 instance is running a web server that allows you to send arbitrary HTTP requests and read their responses. Can you gain further access with that?
2. The EC2 instance has an IAM instance profile attached to it, could that be helpful that for privilege escalation?
3. The EC2 instance has something stored in its User Data, can you leverage it to gain further access?
4. The Lambda function has different IAM privileges than you, can you abuse them to escalate privileges or establish backdoors? You might not be able to directly invoke the function, so what can you do? (Hint: DynamoDB)
5. The Lightsail instance is setup using the default settings, can you gain access to it?
6. CloudTrail is logging everything, can you evade, disrupt, or otherwise cause problems for it or the people who might review those later?
7. You might be able to restart the EC2 instance, can you gain remote access to it using that knowledge?
8. The EC2 instance is running Amazon Linux 2, can you use the default software installed on it to gain remote access to it?
9. The IAM permission “CreatePolicyVersion” accepts the “–set-as-default” flag, but the “SetDefaultPolicyVersion” permission is not required to use it, how can that help you?
10. GuardDuty is running, how can you evade detection or make it trust you?
11. Some users don’t have a password setup, can you take advantage of that to access their account?
12. Some users only have access keys, can you take advantage of that to access their account?
13. There are multiple EC2 security groups, can you discover/gain access to new services with the different rules?
14. Can you discover the minor misconfigurations in the Elastic Load Balancer and EC2 instance?
15. The developers using CodeBuild aren’t following best practices, can you gain access to secrets they have in their projects?
16. The S3 buckets do not have versioning or MFA-delete enabled, can you hide your tracks?
17. There is an unused group, can you add your user to it to gain privileges?
18. There are unused roles, how can you assume them to gain their privileges?
19. One S3 bucket allows write access, can you overwrite any files to gain further access?
20. The Glue development endpoint has a role attached to it, can you gain SSH access to it to escalate privileges? (If you have enabled it)

There might even be undocumented attack vectors. See what you can find!

CloudGoat is open source and any contributions are welcome. The more this environment can be expanded, the more security-aware the AWS community can become.

CloudGoat was built with the AWS Acceptable Use Policy (https://aws.amazon.com/aup/) in mind. What this means for you is that we have ensured that the attacks that CloudGoat opens in your environment still fall within our interpretation of the AWS Acceptable Use Policy and that you do not need to request a penetration test in your account. When attacking your environment, be sure to keep their rules in mind, as violating them can result in harsh consequences. If you think that the only way for you to gain further access to the CloudGoat environment is to do something that explicitly breaks the AWS Acceptable Use Policy, then you are wrong, and you should not do what you are thinking.

If you have any questions or concerns around CloudGoat and the AWS Acceptable Use Policy, feel free to open an issue on GitHub.

AWS security, especially while in the role of an attacker, can be difficult to get a grip on. CloudGoat aims to fill a gap in the industry and to provide a great learning experience for people of all skill levels who want to learn more about AWS security and penetration testing.

We plan to release another post as we get closer to Pacu’s release that will explain how to attack the CloudGoat environment with the various available Pacu modules. This should help users get an understanding of basic Pacu usage, as well as help them identify and exploit misconfigurations in an AWS environment.

CloudGoat is now open source on GitHub: https://github.com/RhinoSecurityLabs/cloudgoat
A supporting OWASP Talk can be found on YouTube here.

Installation and deployment instructions can be found in the README.md file in the repo.