״Defenders think in lists, attackers think in graphs,” said John Lambert from Microsoft, distilling the fundamental difference in mindset between those who defend IT systems and those who try to compromise them.
The traditional approach for defenders is to list security gaps directly related to their assets in the network and eliminate as many as possible, starting with the most critical. Adversaries, in contrast, start with the end goal in mind and focus on charting the path toward a breach. They will generally look for the weakest link in the security chain to break in and progress the attack from there all the way to the crown jewels.
Security teams must embrace the attacker’s perspective to ensure their organization’s cybersecurity defenses are adequate. Drawing an analogy to a daily life example, the standard way to defend our house from intrusion is to ensure all the doors are locked. But to validate that your house is protected requires testing your security like a burglar: attempting to pick the locks, climb through windows, and looking for places where house keys might be “safely” stored.
Penetration testing serves this need precisely: it provides an attacker’s view into what can be compromised. The practice of penetration testing has been around for decades, helping to reveal how resilient our networks are against malicious attacks. However, with modern enterprises increasing their usage of cloud services, it is just as necessary to apply the concept of traditional penetration testing to the cloud.
Cloud architectures comprise resources, identities, and configurations that are defined programmatically and change at a rapid pace. As a result, the cloud can be a pandora’s box of added cybersecurity complexity. While the leading cloud service providers implement rigorous security practices, this may generate a false sense of security for organizations, who may not be aware of their responsibility for securing their cloud assets, as defined by the cloud shared responsibility model. For these reasons, pentesting in the cloud is just as important as traditional network penetration testing – in some cases, even more so.
In this blog post, we explore the basic cloud pentesting building blocks, focusing on how attackers look for and exploit security gaps in your cloud.
Depending on your chosen cloud services’ delivery model, the bounds of your responsibility for security may vary. In general terms, the cloud service providers’ responsibility ends where your responsibility starts. The cloud provider is responsible for securing the hardware and the underlying software that enables its services. You are responsible for protecting everything you create in the cloud – your data, keys, assets, services, applications, and configurations. Consider an example of using Lambda functions to develop cloud-native applications in Amazon Web Services (AWS). While AWS addresses security for the compute and storage infrastructure and the Lambda service itself, it is your responsibility to ensure that access to your organization’s code and resources is secure. So it’s up to you to ensure that your developers are not storing credentials in the functions’ code or environment variables that could be used to compromise sensitive data or laterally move in the network if intercepted by malicious actors.
To prepare for various breach scenarios, penetration tests should use different starting points:
For organizations with hybrid cloud and on-premises networks, a complete and accurate understanding of risk exposure can only be achieved with the ability to test attack paths that cross between these environments. For example, an On-Prem machine is compromised, and the attacker runs an RCE to harvest credentials from the machine. Using browser password extraction, the attacker gains the credentials of a developer with privileges on an Azure VM. From there, the road to breach the cloud is paved, and this process is repeated on different machines until the attacker gets a hold of the highest privileges in the environment and can leverage any resource at will. Therefore, cloud penetration tests should cover scenarios where initial access on-premises could lead an attacker to compromise cloud resources and vice-versa.
Here are five key building blocks for cloud penetration testing:
This first step entails mapping all the assets within your organization’s cloud environment; workloads, storage, databases, and identities. The information gathered in this phase provides the scope of assets that can be used or targeted within a test and a baseline for initiating attack actions.
In traditional network pentesting, the test scope is typically defined by the IP addresses of the endpoints to be included in the test. Cloud resources, in contrast, are identified by unique identifiers, and access to them is enabled via APIs. Therefore, the typical approach for reconnaissance in cloud pentests is to gather the asset information at the beginning of a test by connecting to the organization’s cloud API.
Cloud configuration reviews and vulnerability scans should be performed to uncover misconfigurations and known software vulnerabilities across your cloud assets. For instance, cloud network security should be evaluated by assessing the configuration of controls like firewalls, virtual private networks (VPNs), access, and network segmentation settings. This process is needed to identify weaknesses such as publicly accessible resources or insecure Virtual Private Cloud (VPC) peering connections, which could allow unauthorized access, lateral movement, privilege escalation, and data exfiltration.
Another resource at high risk is web applications, which are commonly targeted by hackers as, by design, they are open to the Internet. To validate that the security controls and software security implementations don’t allow unauthorized access to services and sensitive data, penetration testing should cover cloud-hosted web applications. Testing should include OWASP Top 10 security risks, such as input validation, SQL injection, cross-site scripting (XSS), and Server-Side Request Forgery (SSRF).
However, vulnerability scans are just the beginning. Detected misconfigurations and vulnerabilities need to be tested for exploitability, aiming to propagate an attack exactly like an adversary would. For example, if a publicly accessible cloud storage bucket is detected, it can then be tested by scanning its content for valuable secrets or attempting to exfiltrate data.
Privilege escalation methods can grant adversaries access to more sensitive data, applications, and services. Attackers attempt to gain higher privileges by:
While privilege escalation is a common attack technique used in traditional networks, the challenge of securing identities and access to prevent such attacks in the cloud is exponentially greater.
First, the complexity of cloud IAM architectures is much greater. The abundance of human and machine identities and intricate access control policies put in place to support automated orchestration of cloud resources are likely to introduce risks that attackers can easily exploit. Not only that, but the combination of Cloud and On-Prem Access controls can lead to a very complex rule system, and attackers thrive on complexity.
Second, developers using cloud infrastructure to create their applications often place hardcoded secrets in their code and may forget or neglect to remove them, exposing them to malicious actors.
Testing should identify possible paths between cloud resources, which adversaries can leverage to gather additional sensitive data or secrets and advance their attacks.
In hybrid environment testing scenarios, lateral movement techniques can be attempted as a means to pivot from on-premises to cloud or vice versa. Therefore protecting the cloud environment as a silo won’t work. Organizations may be impacted by attacks propagating across the entire attack surface – the internal network, external-facing assets, and cloud environments. Adversaries don’t view the organizational attack surfaces as disconnected entities but rather as one surface, so defenders need to take a similar approach, working across domains to intercept attacks. To secure the cloud, one must validate all the inroads that lead to it.
Data collection in cloud computing refers to the gathering of data from multiple resources, mainly sensitive in nature, such as credit cards, personal information, passwords etc. This is the main reason attackers break into a network, to get a hold of sensitive information. Sometimes the adversaries will store the data in a centralized location, as a preliminary step to concentrate the data they would like to exfiltrate.
A cloud pentest should assess the ability to collect and then exfiltrate data to an external location and validate the network security controls to test whether they prevent exfiltration to known IOCs.
As you begin the cloud penetration testing journey, it is crucial that you spend some time understanding the scope of your cloud services and assets, and what parts of the attack surface are in your hands to protect according to the shared responsibility model. It is then possible to make informed decisions on cloud-pentesting investments within the context of your organization’s risk exposure.
As a final note, the effectiveness of a cloud pentesting program is not only determined by the depth and breadth of testing, but also by the testing frequency. The pace of change in on-premises networks is serving as a blow to the effectiveness of lengthy manual penetration testing cycles. In the cloud, it’s a knockout. Just like cloud and R&D teams are automating their cloud operations and deployments, security teams must shift gears to automating their cloud penetration testing activities and, ultimately, complement the Continuous Integration/Continuous Deployment loop with Continuous Validation.
To confidently validate your company’s resilience to cloud-native attacks, learn more about Pentera Cloud, and listen to the On-demand recording about Putting Cloud Security to the Stress Test.
