Find out what's involved in cloud penetration testing, including best practices for your test.
back to BLOG

Cloud penetration testing: a beginner’s guide 

James Harrison

There are many advantages of moving to the cloud, from flexibility to cost savings. But migrating your apps and services off premises into the cloud is not without challenges too. With almost half of all data breaches already occurring in the cloud, security is one of them.

As a tried and tested security assessment, penetration tests are often the first port of call for business leaders looking to secure their cloud environment. But are they the best way to assess your cloud security? Here we look at what’s involved, what you can expect, and their advantages and limitations.

Cloud penetration test or configuration review?

When customers or clients ask for a cloud penetration test, it’s important to check if they really want a pentest or are they actually looking for a cloud configuration review. While similar, there are some subtle but key differences.

A cloud configuration review is a low-level and collaborative assessment where the tester will typically be given read access to the entire cloud account, or the parts they’ve been asked to audit. They’ll then use this to pull the configurations of various services and review them to make sure they’re strong and robust. When we talk about services here, we mean cloud services such as S3, IAM, Cloud SQL, etc. This provides great visibility into your cloud environment, and can really help you configure it securely.

In a cloud penetration test, the tester will start with no access to the cloud environment or limited access if they’re testing an assumed breach scenario – for example assuming an attacker has compromised a server in the cloud environment, or a specific user. They’ll then try to escalate their privileges to reach other parts of the cloud environment, trying to access sensitive data.  

They won’t have the same oversight of the cloud environment, and while they’ll probably be trying to enumerate cloud configurations, they're not auditing them in the same way. They’ll often be trying to chain weaknesses they've found, or pull in other information from outside the environment that might help. This approach provides a better idea of what an attacker might be able to do from a particular perspective. The pentest will likely leave you with a few headaches to fix, and guidance to do so painlessly. 

So which one is best? Well, it depends what you want to achieve, but there are a number of advantages to taking a hybrid approach. Giving a tester ‘read access’ and letting them focus on exploiting weaknesses and escalating a particular path can provide better coverage than a pentest, while more focus on exploitable issues with better context is better than just a running a config review.

When do you need a cloud penetration test?

Once you’re sure you want a cloud penetration test, it’s important to know what it can and can’t do. For example, cloud penetration testing is designed to find security issues in your cloud service before hackers do. Different manual methods, methodology, and cloud pentesting tools may be used, depending on the type of cloud service and the provider. However, since you don’t actually own the cloud infrastructure, platform or software as an entity but rather as a service, there are strict legal restrictions and technical challenges to cloud penetration tests.

Certain aspects of cloud security are controlled and handled by the cloud provider and the customer is responsible for the others, based on the Service Level Agreement (SLA) between you and your cloud service provider (CSP). For instance, the cloud provider is not responsible for custom policies you’ve configured in your cloud account. Similarly, the client is not responsible for patching the underlying infrastructure used by serverless functions, or the physical security of the data centers managed by the cloud providers. As a cloud user, your focus is on ‘security in the cloud’ and not ‘security of the cloud’. What you are responsible for, and therefore what can be included in the scope of a pentest, is dictated by the shared responsibility model.

Why is cloud penetration testing important? 

Now you know what cloud pentesting is, let’s look at why you should care. In the same way you should be concerned about the security of your network and infrastructure, your cloud assets should be equally relevant.

The big difference is that a business often won’t have cloud or security experts when they start their shift to the cloud. It’s also faster and easier to deploy assets in the cloud with just a small team. But this means that they can quickly and unknowingly open and close security holes that are hard to monitor and fix.

As a result, while there are many reasons for getting a proactive pentest such as suppliers to satisfy, contractual obligations and compliance requirements, more often than not it’s reacting to the consequences of a breach – downtime, compliance violations, reputational risk, loss of business and all the associated financial ramifications.

Cloud penetration testing helps you get ahead of all these. Not just in terms of finding and fixing key vulnerabilities, but also by learning from mistakes and incorporating best practices earlier in the development cycle. And at Intruder, we see a lot of customers who simply want to check, maintain or improve their cyber hygiene.

What gets checked in a cloud penetration test? 

Misconfigurations are common in the cloud and frequently lead to the exposure of sensitive data: IBM attributes cloud misconfigurations to 15% of breaches seen in 2022. Gartner goes further to suggest that in just two years’ time, 99% of cloud security failures will be the result of user error. Two of the most common types of misconfigurations are Identity Access Management weaknesses and data leakage.

Identity and Access Management (IAM) weaknesses 

Who is the user and what are they allowed to do? These are the main tenants governing IAM. To remain secure, cloud infrastructure needs MFA (multi-factor authentication), strong authenticators, and defined user roles with the principle of least privilege. Logging, monitoring and revoking access when no longer needed are also key. These safeguards will particularly protect against attackers leveraging stolen credentials from past breaches. 

Data leakage 

News headlines are littered with examples of large companies leaking large amounts of data, so cloud pentesting aims to identify improper storage and handling of data in the cloud. Databases, object stores, logs and repositories can all be made public inadvertently, and attackers are continually scanning the entire internet for these sorts of exposures. Our research has shown how quickly data exposed to the internet gets accessed.

Using passwords that are weak or reused frequently can make cloud accounts vulnerable to password-guessing attacks, so pentesters will also check for weak credentials. Unpatched vulnerabilities are an easy point of entry for hackers and many use automated tools to find them, so penetration testers will also check for any out-of-date, third-party software.

Can you automate cloud penetration testing?  

There are elements of cloud penetration testing that can only be carried out manually because even the best scanners struggle with the contextual understanding required to identify business logic flaws, nuanced access control weaknesses, or to determine which data is commercially sensitive. Manual testing can also discover chained exploitation paths which are more severe than the sum of each vulnerability.

Conversely, given the increasing complexity and size of cloud deployments, there are also elements of cloud penetration testing which can and should be automated. For some pentests, the sheer number of assets to review would be impossible to carry out manually. Automation is quick, reduces the chance of human error, and checks services, parameters and configuration settings which may otherwise be missed. Plus, automation enables continuous testing of cloud targets.

But without the manual review and attempts at exploitation, any test will be a vulnerability scan. Cloud penetration testing just can’t be fully automated yet.

Find your weaknesses,
before the hackers do

Try Intruder for free

What is cloud penetration testing best practice?

There are some simple steps to make sure your cloud penetration test delivers the best possible outcomes:

What does Intruder bring to the table? 

One of the biggest problems in vulnerability management is tracking what assets you have, what’s in use, and what isn’t. You can’t secure anything, if you don’t know it’s there. Cloud platforms can make this worse, because it’s so easy now to spin up new services in AWS, Google Cloud or Azure. Keeping on top of any new systems that are exposed to the internet and ensuring they are continuously monitored for weaknesses can be a challenge.

Intruder is a powerful vulnerability scanner designed to work seamlessly with the three major cloud service providers. Our integrations make securing cloud systems a breeze, providing a single transparent view into the services and security exposures across all your cloud accounts, removing any IPs no longer in use so you can’t scan someone else’s infrastructure. And when you activate CloudBot for your connected AWS, Google Cloud or Azure accounts, it’ll perform an hourly check for new IP addresses or hostnames.

Beyond your cloud assets, we also scan web apps, networks, internal systems and APIs! Get started with a free trial today. 

Release Date
Level of Ideal
Before CVE details are published
Limited public information is available about the vulnerability.

Red teamers, security researchers, detection engineers, threat actors have to actively research type of vulnerability, location in vulnerable software and build an associated exploit.

Tenable release checks for 47.43% of the CVEs they cover in this window, and Greenbone release 32.96%.
Day of CVE publish
Vulnerability information is publicly accessible.

Red teamers, security researchers, detection engineers and threat actors now have access to some of the information they were previously having to hunt themselves, speeding up potential exploit creation.

Tenable release checks for 17.12% of the CVEs they cover in this window, and Greenbone release 17.69%.
First week since CVE publish
Vulnerability information has been publicly available for up to 1 week.

The likelihood that exploitation in the wild is going to be happening is steadily increasing.

Tenable release checks for 10.9% of the CVEs they cover in this window, and Greenbone release 20.69%.
Between 1 week and 1 month since CVE publish
Vulnerability information has been publicly available for up to 1 month, and some very clever people have had time to craft an exploit.

We’re starting to lose some of the benefit of rapid, automated vulnerability detection.

Tenable release checks for 9.58% of the CVEs they cover in this window, and Greenbone release 12.43%.
After 1 month since CVE publish
Information has been publicly available for more than 31 days.

Any detection released a month after the details are publicly available is decreasing in value for me.

Tenable release checks for 14.97% of the CVEs they cover over a month after the CVE details have been published, and Greenbone release 16.23%.

With this information in mind, I wanted to check what is the delay for both Tenable and Greenbone to release a detection for their scanners. The following section will focus on vulnerabilities which:

These are the ones where an attacker can point their exploit code at your vulnerable system and gain unauthorised access.

We’ve seen previously that Tenable have remote checks for 643 critical vulnerabilities, and OpenVAS have remote checks for 450 critical vulnerabilities. Tenable release remote checks for critical vulnerabilities within 1 month of the details being made public 58.4% of the time, but Greenbone release their checks within 1 month 76.8% of the time. So, even though OpenVAS has fewer checks for those critical vulnerabilities, you are more likely to get them within 1 month of the details being made public. Let’s break that down further.

In Figure 10 we can see the absolute number of remote checks released on a given day after a CVE for a critical vulnerability has been published. What you can immediately see is that both Tenable and OpenVAS release the majority of their checks on or before the CVE details are made public; Tenable have released checks for 247 CVEs, and OpenVAS have released checks for 144 CVEs. Then since 2010 Tenable have remote released checks for 147 critical CVEs and OpenVAS 79 critical CVEs on the same day as the vulnerability details were published. The number of vulnerabilities then drops off across the first week and drops further after 1 week, as we would hope for in an efficient time-to-release scenario.

Figure 10: Absolute numbers of critical CVEs with a remote check release date from the date a CVE is published

While raw numbers are good, Tenable have a larger number of checks available so it could be unfair to go on raw numbers alone. It’s potentially more important to understand the likelihood that OpenVAS or Tenable will release a check of a vulnerability on any given day after a CVE for a critical vulnerability is released. In Figure 11 we can see that Tenable release 61% their checks on or before the date that a CVE is published, and OpenVAS release a shade under 50% of their checks on or before the day that a CVE is published.

Figure 11: Percentage chance of delay for critical vulnerabilities

So, since 2010 Tenable has more frequently released their checks before or on the same day as the CVE details have been published for critical vulnerabilities. While Tenable is leading at this point, Greenbone’s community feed still gets a considerable percentage of their checks out on or before day 0.

I thought I’d go another step further and try and see if I could identify any trend in each organisations release delay, are they getting better year-on-year or are their releases getting later? In Figure 12 I’ve taken the mean delay for critical vulnerabilities per year and plotted them. The mean as a metric is particularly influenced by outliers in a data set, so I expected some wackiness and limited the mean to only checks released 180 days prior to a CVE being published and 31 days after a CVE being published. These seem to me like reasonable limits, as anything greater than 6 months prior to CVE details being released is potentially a quirk of the check details and anything after a 1-month delay is less important for us.

What can we take away from Figure 12?

Figure 12: Release delay year-on-year (lower is better)

With the larger number of checks, and still being able to release a greater percentage of their remote checks for critical vulnerabilities Tenable could win this category. However, the delay time from 2019 and 2020 going to OpenVAS, and the trend lines being so close, I am going to declare this one a tie. It’s a tie.

The takeaway from this is that both vendors are getting their checks out the majority of the time either before the CVE details are published or on the day the details are published. This is overwhelmingly positive for both scanning solutions. Over time both also appear to be releasing remote checks for critical vulnerabilities more quickly.

Written by

James Harrison

Recommended articles

Ready to get started with your 14-day trial?

try for free