How Cloud Penetration Testing Defends Against Common Attacks

If your organization has recently migrated to the cloud or is in the process of migrating, you probably know that this major transition has the potential to introduce new vulnerabilities that can leave you exposed to cyberattacks.

Cloud penetration testing (pentesting) is a great way to proactively identify vulnerabilities in your cloud environment, enabling you to fix them before they can be exploited by attackers to compromise your valuable systems and data.

In this blog, we’ll review three of the most common vectors used for attacking cloud environments. We’ll also provide real-world examples of how Tevora’s cloud penetration testing methodology is used to identify aspects of our clients’ cloud environments that were vulnerable to these types of attacks.

On-Prem vs. Cloud Vulnerabilities

Before diving into the attack vectors, it’s worth considering some of the ways in which cloud environments differ from on-prem environments and how these differences can affect vulnerabilities to attack.

Unlike on-prem environments—which often have hosts, servers, and sub-nets dedicated to specific applications—cloud environments use “serverless” cloud-native applications that can be spread across multiple external servers and Cloud Service Providers (CSPs). While they still run on servers, serverless applications are developed in a way that abstracts the server infrastructure away from the application layer. This allows developers to focus on application logic while CSPs handle the work of provisioning and scaling the server infrastructure.

The traditional approach of defending the on-prem corporate network perimeter doesn’t work well for cloud environments in which applications run on multiple external servers and CSPs. Organizations need to work in concert with their CSPs to develop new approaches (e.g., Zero Trust architectures) to harden their cloud environment defenses.

One of the significant benefits of cloud environments is that automated tools can be used to rapidly deploy code and allocate infrastructure resources across multiple servers and CSPs while minimizing or eliminating deployment errors. However, if attackers are able to obtain the credentials required to execute these powerful tools, they can wreak havoc by rapidly deploying malware across an organization’s cloud environment. In many cases, automated cloud deployment tool administrators use generic ids and passwords and are given overly broad privileges, both of which can leave organizations vulnerable to attack.

Attack Vector 1 – Application

One potential pitfall when pentesting cloud applications is to focus on the application software alone without testing all of the supporting infrastructure tools and services that interact with the application. For example, you may have an application that performs a specific business function but relies on infrastructure tools such as S3 for storage buckets or Okta for identity management. In this case, it’s important to enumerate and test all business application functions as well as the supporting storage and identity management functions performed by S3 and OKTA. Failing to perform this type of comprehensive testing can cause you to miss key vulnerabilities.

In one of our pentesting engagements, our client had a business application that used S3 storage buckets to support an application that allowed users to request uploads of files to a cloud server. By testing both the application and the supporting S3 tools, we determined that there was insufficient input checking on the cloud server side when performing S3 uploads. This weak input checking would have enabled an attacker with access to a typical employee’s credentials to arbitrarily overwrite uploaded files. For example, it would have been possible for an attacker to overwrite the static content of an uploaded HTML file, opening the door for significant attacks within our client’s cloud environment.

Attack Vector 2 – Compromised Compute

This attack vector refers to an approach in which attackers gain access to a specific cloud compute instance and either compromise multiple applications within that instance, or pivot to gain access to other compute instances within the target organization’s cloud environment. This is often done by first gaining access to credentials on a specific compute instance, then leveraging that access to launch a broader attack. For example, in an AWS environment, an attacker might compromise a workload to gain access to temporary security credentials that allow that instance to interact with AWS.

In one engagement, we were able to compromise a client application that had remote code execution capabilities. This application leveraged agent-based configurations that were querying a global registry of information. With this access, we were able to use AWS configuration information in agent interactions to disclose other tenant configurations (including passwords). This allowed us to compromise other tenants within the client’s cloud environment.

Attack Vector 3 – Pivoting From On-Prem

Security weaknesses in on-prem environments are often exploited to compromise cloud environments. On-prem developer workstations present a target-rich environment for attackers because they frequently contain sensitive information that can be used to gain access to cloud environments. For example, developer workstations may have:

• Poorly protected Secure Shell Protocol (SSH) keys, which can be used to create proxy pivots that enable access to cloud environments.
• DevOps/automation infrastructure that, when compromised, can be used to deploy malware to cloud environments.
• Accounts/passwords that are the same as those used for a user’s cloud accounts. While this practice is strongly discouraged by most organizations, it happens.

In a recent pentesting engagement, we exploited the client’s legacy LLMNR protocol to gain remote access to their on-prem environment. With that access, we were able to upload and execute a payload that enabled us to enumerate the client’s Azure domains and targets and obtain access to on-prem domain admin and user credentials. Next, we discovered that some service and domain passwords were replicated in the client’s cloud environment, which enabled us to gain access that would have allowed an attacker to compromise a broad range of the client’s cloud applications.

Check Out Our Cloud Pentesting Webinar

For a much deeper dive into the ways cloud penetration testing can help your organization defend against common attack vectors, check out the recording of Tevora’s recent webinar on this topic.

We Can Help

If you have questions about cloud pentesting or would like help using this valuable testing approach to identify vulnerabilities in your cloud environment, Tevora’s team of security specialists can help. Just give us a call at (833) 292-1609 or email us at sales@tevora.com.

About the Author

Kevin Dick is the Manager of Threat Services at Tevora.