Cloud computing is the delivery of IT resources over the Internet with the pay-as-you-go principle. We can access lots of technology services such as computing power, storage, and databases instead of buying, owning, maintaining physical data centers and servers.
As we know, there are lots of popular cloud computing providers such as AWS, Google, Microsoft Azure, that we use every day for our workloads. As the popularity of cloud services increases, attackers focus on cloud services and cloud vulnerabilities.
Attackers use lots of sustained attacks against managed cloud service providers and their customers. If companies are using cloud technologies, they need to make sure it is secure. At this point, they need cloud penetration testing.
Cloud penetration testing is an attack simulation performed to find vulnerabilities that can be exploited or to find any misconfigurations in a cloud-based system. With cloud penetration testing, companies learn about the strengths and weaknesses of their cloud system to improve its overall security posture.
Today, we will summarize what you need to know about cloud penetration testing. We will also share some open source tools that help you in cloud pentesting.
CloudBrute: AWS S3 is a cloud storage service. CloudBrute is an open-source tool that can help you enumerate the customer’s AWS S3 buckets. The tool is modular and customizable and is generally preferred because it is relatively fast. Features of the tool are:
CloudSplaining: open-source tool that helps you to find out the violation of least privilege on AWS IAM policies by scanning all the policies in the AWS account and giving you an HTML report. It can scan all the policies in an AWS account or a single policy file. It helps prioritize the remediation process by flagging IAM policies that present risks. Cloudsplainig also can identify the IAM roles that can be assumed by AWS. Flagging these roles is particularly useful to penetration testers or attackers under various scenarios.
Enumerate-iam: If AWS credentials of customers are ever stolen or captured, it would take a lot of time to find which services those credentials are authorized for. To ease up this process, an open-source tool called enumerate-iam can be used. It tries to brute force all API calls allowed by the IAM policy, in a non-destructive manner. Another good part of this tool is that it can be easily integrated with other tools if needed.
WeirdAAL: An AWS attack library. Why We Like It: One thing I love about infosec is the names people come up with for tools and talks, this being an example. That aside, Gates describes one of WeirdAAL’s two overarching goals to be a repo of useful defensive and offensive security functions for AWS, making it a resource you’ll want to bookmark. And if you find yourself in a more black-box testing scenario, WeirdAAL is a perfect choice.
ScoutSuite: A multi-cloud security-auditing tool. It supports the major cloud computing providers: AWS, Azure, Google Cloud, Alibaba Cloud, and Oracle Cloud. That means this is one extremely versatile tool. Plus, ScoutSuite was designed to make assessing cloud environments much easier, providing the user “a clear view of the attack surface automatically,” saving significant time.
GitOops: All paths lead to clouds. As teams scale, it becomes more difficult for security departments to monitor GitHub repos. This is where GitOops comes in, as the tool leverages the literal GitHub “oops.” Another well-named tool, you can use GitOops to find privilege escalation paths as well as for lateral movement in GitHub.
Pacu: An AWS exploitation framework. This automated tool has many modules that allow enumeration of permissions, listing of internal AWS resources in all AWS regions, and privilege escalation attacks. Think of it like a Metasploit for the cloud. Check out the modules for more information. And a note: We recommend testing an automated tool like this in a lab environment before using it during testing.
S3Scanner: Scan for open AWS S3 buckets. You can use this tool during a black-box assessment to dump AWS S3 buckets, which are bound to contain valuable information. S3Scanner allows the user to automate the search for public resources available in different clouds and dump the information, not just in AWS but in other cloud services like DigitalOcean, too.
Microburst: Assorted scripts for Azure security. This is your one-stop shop for everything Azure related. You can use it for Azure services discovery, configuration auditing, and post-exploitation. This handy toolkit was created by Karl Fosaaen, an expert in cloud pen testing and an excellent resource when it comes to testing Azure environments.
SkyArk: Discover the most privileged cloud users. Available for Azure and AWS, this is a useful tool for identifying additional attack surface. Specifically, the tool is designed to detect the presence of cloud shadow admins, a very real threat to cloud environments (making it worthwhile for defenders to keep around, too.)
ROADTools: Framework for interacting with Azure Active Directory (AD). This entry is both a library and an exploitation tool. The library is meant to authenticate with AD; alternatively, you can use it to build tools that integrate with a database containing ROADrecon data. The tool meanwhile is for deeper exploration of AD; there’s a lot of data to sift through in AD, and ROADTools can help you make sense of it. Other similar tools you can check out are PMapper, which is designed for AWS environments, and this Google Cloud privilege escalation toolkit by Rhino Security Labs.
PowerZure: PowerShell framework for Azure security. It’s multifaceted: It can be used for reconnaissance and post-exploitation. So, you can use it to kick off an engagement and bring things to a close. Couple this with AzureHound and your testing should go seamlessly!
These aren’t pen testing tools per se, but they are incredibly useful and robust resources. The shared purpose of all three of these interfaces is to act as a “mission control” for their specific cloud platform, providing all kinds of tools for interacting with the platform.
This is a volunteer-run encyclopedia for helping security professionals learn various cloud security attacks, techniques, and tactics.
Not only does this website contain a vast array of information (like cheat sheets) on cloud security technologies, but it’s also solid for resources related to security culture and leadership.
Finally, this site aims to be the place to go for all things cloud security. So, we couldn’t do a proper cloud security blog without giving a shoutout!
Every cloud provider has a pentesting policy that includes permitted and prohibited services and activities to test. Before we start, we need to be sure which cloud services are used in the customer’s environment, and which services can be tested by cloud pentesters. For more information, check out the Microsoft Azure cloud pentest approach.
When we start cloud penetration testing, we need to check a couple of things:
Talking with the customer: The first thing we want to do is to communicate with the customer to determine the start and end dates of the pentest. We should ask for a preview of the cloud platform, and gain information on topics such as which URLs will be tested, what is the cloud architecture of this platform, and the functions.
Check the customer’s system: After getting the information, pentesters need time to analyze the system. Gain more information about the system; check the potential access points for any data to send or receive, check the source code, software versions, or if any leaked keys exist. The more data we gather, the more easily we identify the flaws.
Cloud pentesting tools should simulate an actual attack. Many hackers use automated processes to find vulnerabilities, such as guessing passwords repeatedly or looking for APIs that provide access directly to the data. What we should do is to try and simulate those types of procedures. If our cloud pentesting tools can’t meet our requirements for attack scenarios, we could write our own systems, tools, or scripts for cloud pentesting.
Without analyzing the findings and responses, cloud pentesting would be meaningless. After using the automated tools and performing manual tests, we need to analyze the responses. All responses should be documented. We should decide whether these results are false positives, or expected cloud responses. If not, those findings should be reported. This step is one of those where our information and experience on the cloud are important.
This is the last step of the cloud pentesting process. After all cloud tests and checks are done, the severity and impact of vulnerabilities should be discussed and investigated with the cloud pentesting team. A final cloud vulnerability report should be prepared with recommendations and remediations.
Cloud service providers have to stick to a shared security responsibility model. We are responsible for security in the cloud, such as security for our operating environment, including our applications, servers, user controls. The cloud service provider is responsible for the security of the cloud. In the AWS shared responsibility model, AWS takes responsibility for protecting the infrastructure that runs all the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.
The diagram that explains the general structure of the shared responsibility model.
We should always check the cloud providers’ service policies. The tables below visualize AWS’s policy on what we can and can’t test:
Cookie | Duração | Descrição |
---|---|---|
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |