Cloud Penetration Testing from the field

Breaking the Cloud via “some service” is every pentester or red reamer mission. While the Blue team, SecOps, and other security teams struggle to minimize the attack surface area, create friction with attackers, and gain more visibility. The other teams, like Red and Penetration Testing, have many winning situations.

Everyone wants to break the Cloud in some manner, if it’s the Microsoft Cloud (Azure, Office 365), AWS, Google Workspace, etc. But what is breaking the Cloud? to abuse some service, find a vulnerability in a specific component, or utilize a misconfiguration? What about applying Red-Team operations or performing penetration testing on the Cloud? It depends on the purpose of each scenario.

As an offensive and investigative person, I could say that I’m always willing to be the one on the hill with the flag without anyone recognizing me. I can say that misconfiguration is often my best friend because it’s straightforward to find and even not use manipulation in my ‘abusing bag.’ sometimes it’s easy, and others are challenging. At the same time, I’m running Red-Team operations and security testing on various Cloud environments.

This post isn’t technical and focuses on Cloud Penetration Testing and little things in between.

After doing a lot of security testing, penetration testing, and investigation in the cloud, I might say that there is no one method for all to run security testing. It can be changed between environments, focus, scope, etc.

Cloud Penetration Testing vs. Penetration-Testing

Penetration testing is a cyberattack simulation launched on a system to discover points of exploitation and test IT breach security. It helps businesses to obtain expert, unbiased third-party feedback on their security processes and improve their defenses against real attacks.

Cloud penetration testing is a specific type that evaluates security and discovers vulnerabilities in cloud environments, services, and dynamic components. It helps to identify risks, gaps, and impacts of exploitable vulnerabilities in cloud services such as AWS, Azure, or Google Cloud Platform. It also helps to determine how to leverage any access obtained via exploitation and how to mitigate the risks.

The main difference between cloud penetration testing and penetration testing is that cloud penetration testing focuses on the cloud-specific aspects of security, such as:

• The configuration and management of cloud resources.
• The access control policies and permissions for cloud users.
• The data protection mechanisms and encryption standards for cloud storage.
• The network security and firewall rules for cloud traffic.
• Compliance with cloud-specific regulations and standards.

Penetration testing, on the other hand, can cover a broader range of security domains, such as:

• The application logic and functionality of web or mobile apps.
• The authentication and authorization mechanisms for users.
• The input validation and output encoding for preventing injection attacks.
• The session management and cookie security for maintaining state.
• The error handling and logging for detecting anomalies.

Both types of testing are essential for ensuring the security of your systems. However, they require different skills, tools, and techniques. Cloud penetration testing requires more knowledge about the service provider’s features, settings, and best practices. Penetration testing requires more knowledge about the application’s code, design, and architecture.

Therefore, it is advisable to hire professional testers who have experience in both types of testing. They can help you perform a comprehensive assessment of your system’s security posture and provide you with actionable recommendations for improvement.

How should you run security testing or attack the cloud?

Cloud computing is a popular and convenient way of storing and accessing data and applications over the internet. However, it also comes with its own set of security challenges and risks. How can you ensure your cloud infrastructure is secure and resilient against cyber attacks? How can you test your cloud security posture and identify vulnerabilities or weaknesses?

What is cloud security testing? Cloud security testing is a type of security testing method in which cloud infrastructure is tested for security risks and loopholes that hackers can exploit. Cloud security testing is mainly performed to ensure that cloud infrastructure can protect an organization’s confidential information.

Cloud security testing differs from traditional application security testing in a few ways. Traditional application security testing requires on-premises tools that scan the code or binaries of an application for vulnerabilities. Cloud security testing, on the other hand, requires tools that can access and test the cloud environment remotely. Moreover, cloud security testing has to consider various aspects of cloud architecture, such as multi-tenancy, scalability, elasticity, shared responsibility model, etc.

Why is cloud security testing important? Cloud security testing is important for several reasons:

• It helps you comply with regulatory standards and industry best practices for data protection and privacy.
• It helps you avoid data breaches, financial losses, reputational damage, legal liabilities, etc., that may result from a successful cyber attack on your cloud infrastructure.
• It helps you improve customer trust and satisfaction by demonstrating your commitment to secure their data and applications.
• It helps you gain a competitive edge by offering your clients secure and reliable cloud services.

How to perform cloud security testing? There are different types of cloud security testing methods that you can use depending on your goals and needs. Some of the common ones are:

• Cloud penetration testing is detecting and exploiting security vulnerabilities in your cloud infrastructure by simulating a controlled cyber attack. Cloud pentest is performed under strict guidelines from the cloud service providers like AWS, GCP, Azure, etc., who may have specific rules and limitations for conducting such tests on their platforms. You need to obtain their permission before launching any pentest on their resources. Cloud pentest can help you uncover hidden flaws in your configuration settings, access controls, encryption mechanisms, network protocols, etc., that may allow an attacker to compromise your data or applications.
• Cloud vulnerability scanning is scanning your cloud environment for known vulnerabilities using automated tools or scanners hosted in the cloud. Cloud vulnerability scanning can help you identify common issues, such as outdated software versions, misconfigured firewalls, exposed ports, weak passwords, etc., that may pose a risk to your security posture. You must regularly update your scanners with the latest vulnerability signatures and patch any detected issues immediately.
• Cloud compliance auditing: This is the process of verifying whether your cloud infrastructure meets the required standards and regulations for data protection and privacy. Cloud compliance auditing can help you ensure that you follow best practices such as encrypting sensitive data at rest and in transit, implementing strong authentication and authorization mechanisms, logging user activities, etc. You need to check with your relevant authorities or industry bodies for what kind of compliance requirements apply to your business domain.

Here are some tips that can help you run successful cloud security tests:

• Define clear objectives and scope for your tests. What are you trying to achieve? What are the assets or resources that you want to test? What are the threats or scenarios that you want to simulate?
• Choose appropriate tools and techniques for your tests. What kind of tools do you need? Do they support your chosen platform? Do they have enough features and functionalities? Do they have good documentation and support?
• Plan ahead and coordinate with stakeholders. When do you want to conduct your tests? How long will they take? Who will be involved or affected by them? How will you communicate with them?
• Document everything carefully. What did you find during your tests? How did you exploit them? What are the impacts or risks associated with them? How did you remediate them?
• Review and improve continuously. What did you learn from your tests? How can you improve them next time? What are some new challenges or opportunities that emerged?

Scenario: Attacking Kubernetes from inside a Pod

One scenario from many others that provide actions – this time attacking Kubernetes.

Kubernetes is a popular platform for managing containerized applications. However, it also introduces new security challenges and attack vectors. In this blog post, I will show you how an attacker can compromise a Kubernetes cluster from inside a pod.

A pod is the smallest unit of deployment in Kubernetes. It consists of one or more containers that share the same network namespace and storage volumes. Pods are usually isolated from each other by network policies and security contexts. However, there are some ways that an attacker can break out of this isolation and gain access to other pods or even the cluster itself.

One way is to exploit the service account token mounted to every pod by default. This token allows the pod to communicate with the Kubernetes API server and perform various actions on behalf of the service account. Depending on the role bindings of the service account, this could include reading secrets, creating pods, deleting resources, etc.

Another way is to perform a DNS spoofing attack on the pod’s network interface. This involves intercepting DNS queries sent by other pods on the same node and returning malicious answers that point to an attacker-controlled server. This could allow an attacker to hijack the traffic, steal credentials, inject malware, etc.

A third way is to perform a BGP hijacking attack on the node’s network interface. This involves sending fake BGP updates to neighboring routers and announcing routes that redirect traffic destined for other nodes or external services to an attacker-controlled server. This could allow an attacker to perform a man-in-the-middle (MiTM) attack on any communication between pods or between pods and external services.

Usually, the pods run with a service account token inside of them. This service account may have some privileges that you could abuse to move to other pods or escape to the nodes configured inside the cluster. To escape from the pod, you might need to escalate privileges first – some techniques to abusing priv with enumeration.

Search for vuln network services – Sniffing. Suppose the compromised pod is running some sensitive service where other pods need to authenticate. In that case, you might be able to obtain the creds sent from the other pods sniffing local communications. From there, you can exploit and pivot the cloud.

image: HackTricks

Common Cloud Security Threats

Some of the most common cloud security threats businesses face today are:

Unauthorized access

One of the main cloud security threats is unauthorized access to cloud resources by malicious actors or unauthorized users. This can happen due to weak or compromised credentials, phishing attacks, brute force attacks, or insufficient identity and access management policies.

Unauthorized access can result in data breaches, data loss, data corruption, ransomware attacks, denial of service attacks, or other malicious activities that can harm the business and its reputation.

Businesses should implement strong authentication and authorization mechanisms for their cloud users and administrators to prevent unauthorized access. This includes using multi-factor authentication (MFA), encryption keys, role-based access control (RBAC), identity federation, etc.

Additionally, businesses should regularly monitor their cloud activity logs to detect suspicious or anomalous behavior and respond quickly to incidents.

Misconfiguration – Another common cloud security threat is the misconfiguration of cloud resources or settings. Misconfiguration can occur due to human error, lack of knowledge, lack of visibility, or lack of automation. Misconfiguration can expose cloud resources to public access or unwanted traffic, create security gaps or vulnerabilities, violate compliance requirements, or cause performance issues.

To avoid misconfiguration, businesses should follow best practices for configuring their cloud resources and settings. This includes using secure defaults, applying security patches regularly, enforcing policies through automation tools, conducting regular audits and reviews, etc.

Furthermore, businesses should use tools that can help them identify and remediate any misconfigurations in their cloud environment automatically or with minimal intervention.

Insecure interfaces – Another common cloud security threat is insecure interfaces between cloud services or applications. Insecure interfaces can occur due to poorly designed APIs (application programming interfaces), SDKs (software development kits), UIs (user interfaces), and CLI (command-line interface) tools.

Insecure interfaces can allow attackers to exploit vulnerabilities in the communication channels between cloud services or applications. This can lead to data interception, modification,
injection, spoofing, replay attacks, etc.

To secure their interfaces, businesses should use encryption protocols such as SSL/TLS (Secure Sockets Layer/Transport Layer Security) for data transmission over the internet. They should also use digital signatures or certificates to verify the identity and integrity of the parties involved in the communication.

Moreover, businesses should use reputable vendors that provide secure APIs, SDKs, UIs, and CLI tools for interacting with their cloud services or applications.

External data sharing – Another common cloud security threat is external data sharing with third parties such as partners,  customers, suppliers, contractors, etc.

External data sharing can pose a risk if the third parties do not have adequate security measures in place or if they misuse or mishandle the shared data. External data sharing can lead to data leakage or exposure to unauthorized parties or malicious actors.

They should also use encryption techniques such as homomorphic or differential privacy to protect sensitive data while allowing computation. Furthermore, they should regularly monitor and audit external data-sharing activities and revoke access when necessary.

Insecure APIs enable companies to share their application’s data and functions with third-party companies. API keys are used for identifying and authenticating between companies and third parties. Someone can gain access if we don’t protect our API keys. API services are commonly used, and insecure APIs can lead to severe data leaks.

Credentials may leak in some way or can be hardcoded in the application. This may cause our credentials to be stolen. In the codebase, we should not share our credentials, such as the access key, secret access key, or API keys. That’s basically like giving our master key to a stranger.

Access privileges – There is a concept in the cloud called the least privilege principle. That means giving the user the least amount of privileges to do their job. If we give them excessive privilege and the account gets hacked or stolen, this may lead to severe problems—from service principle to highest privilege.

Do you know if someone is reconning your Azure AD? or any other resource on the cloud?

Is someone scanning your Azure AD? https://t.co/xafCsDIrmc

— Elli Shlomo (IR) (@ellishlomo) January 15, 2023

The Purpose of Cloud Penetration-Testing

The purpose of cloud penetration testing is to assess the security of a cloud-based system or service by attempting to identify and exploit vulnerabilities. This type of testing is conducted to ensure that the cloud infrastructure is secure and to identify any system weaknesses that attackers could exploit.

Cloud penetration testing involves simulating real-world attacks on a cloud-based system or service to identify potential security vulnerabilities. The testing typically involves several steps, including reconnaissance, scanning, and exploitation. It may also include social engineering techniques to trick users or gain access to sensitive information.

The goal of cloud penetration testing is to identify potential security risks and provide recommendations for remediation. By identifying vulnerabilities and weaknesses in the cloud infrastructure, organizations can strengthen their security posture and protect their data from unauthorized access or theft.

Overall, cloud penetration testing aims to ensure the cloud-based system or service is secure and provides insights into how it can be further secured to protect against potential attacks. Cloud penetration testing helps to:

• Identify default config, misconfiguration, etc.
• Provide best practices in maintaining visibility.
• Identify security risks, vulnerabilities, and other gaps.
• Deliver clear and actionable remediation information.
• Determine how to leverage any access obtained via exploitation.

The Shared Responsibility Model

Cloud penetration testing is an essential part of the shared responsibility model in cloud computing. The shared responsibility model defines the responsibilities of the cloud service provider (CSP) and the customer for securing the cloud environment.

In this model, the CSP is responsible for the security of the underlying infrastructure, such as the physical data center, networking, and storage. However, the customer is responsible for securing their data and applications hosted on the cloud infrastructure.

Cloud penetration testing falls under the customer’s responsibility for securing their data and applications. The customer is responsible for testing their applications and data for vulnerabilities and ensuring they are secure.

Therefore, the customer must conduct cloud penetration testing to ensure their data and applications are secure in the cloud environment. This testing is crucial because it helps identify any security weaknesses attackers can exploit.

The results of cloud penetration testing can help the customer make informed decisions about further securing their cloud environment. It can also help the CSP to identify areas where they need to improve their security measures.

Cloud penetration testing within the context of the shared responsibility model involves the examination of security in the cloud instead of the security of the cloud. The security of specific cloud components remains within the control and management of the cloud service provider (CSP), and the security of other components falls within the scope of the customer. A customer’s Service Level Agreement (SLA) defines the type and scope of cloud penetration testing allowed and how frequently cloud pen testing can be done.

The following diagram shows the Cloud Penetration Testing within the Shared Responsibility Model.

Policy Restrictions

Each cloud service provider has its policy regarding conducting cloud penetration testing. This defines the types of tests that can be conducted. Also, some require you to submit an advance notice before conducting the tests. This policy disparity poses a significant challenge and limits the scope of conducting cloud penetration testing.

Microsoft’s Azure and Amazon Web Services (AWS) are two standard cloud-based services organizations use to support business activities in the cloud. Azure and AWS permit penetration testing relative to any infrastructure the business is hosting on the AWS or Azure platform as long as those tests fall within the list of permitted services. The Rules of Engagement for penetration testing on Azure and AWS can be found at these links:

• Azure Penetration Testing
• AWS Penetration Testing
• Google Cloud Platform Penetration Testing

Policy restrictions may limit the scope of cloud penetration testing. For example, some cloud service providers may have policies prohibiting customers from performing certain tests, such as denial-of-service attacks, that could disrupt other customers on the same shared infrastructure.

Additionally, the Shared Responsibility Model may limit the scope of cloud penetration testing, as the cloud service provider is responsible for specific security aspects, such as physical security and network infrastructure. Therefore, any testing conducted by the customer must not interfere with the provider’s security controls or compromise the security of other customers on the shared infrastructure.

To ensure that cloud penetration testing complies with the Shared Responsibility Model and any policy restrictions, it is essential to work closely with the cloud service provider to understand their policies and limitations. The testing should be conducted, controlled, and measured, with clear communication between the customer and provider, to ensure that any potential security risks are identified and addressed appropriately.

Types & Methods of Cloud Penetration Testing

There are primary types and methods to run security testing on the Cloud – from familiar BOX testing or by permissions. Some of them are known by classic penetration testing. One of the best descriptions for Azure AD and Office 365 comes from AADInternals, and how it can be done from Outsider, Guest, and Admin.

TIP: Guest in Azure AD is one of the differences from On-Premises and provides an external attack surface.

Image source: AADInternals

Note: While the AADInternals provides many ways to attack the cloud, other tools can provide additional methods. 

The Cloud penetration testing will examine attack, breach, operability, and recovery issues within a cloud environment. The Cloud penetration testing will be based on familiar BOX and Permissions and the new objects in the Cloud. Different types of cloud penetration testing include:

• Black Box Penetration Testing – Attack simulation in which the testers have no prior knowledge of or access to your cloud resources.
• Grey Box Penetration Testing – testers have limited knowledge of users and resources and may be granted limited administration privileges.
• White Box Penetration Testing – testers are granted admin or root-level access to cloud resources.

There are additional types of cloud pen testing. All three involve testers poking the resources as an attacker would identify natural and exploitable weaknesses. They determine which testing type depends on the specific events of the systems under security testing.

• Transparent box testing – Testers have admin-level access to the cloud environment, allowing them to complete access and knowledge about the resources they are attempting to compromise.
• Semitransparent box testing – Testers have some knowledge about the resources they are attempting to hack.
• Opaque box testing – Testers must learn about or access cloud resources before beginning their testing activities.

Note: Both types can look the same, but the difference can be in the Cloud objects. The ones that we don’t have on the On-Premise environments.

The Cloud attack timeline is around 150 to 180 days, and the security testing can be done quietly without interruptions in the Research Preparation and attack stages.

Cloud Penetration Testing Best Practices

There are a few tips that can help ensure your cloud penetration testing activities provide the best possible security outcomes:

• Understand the Shared Responsibility Model – Cloud systems are governed by the Shared Responsibility Model, which defines the areas of responsibility owned by the customer and the CSP.
• Rules of Engagement – Your cloud service provider’s SLA will provide details on the “rules of engagement” related to any penetration testing involving their cloud services.
• Define the scope – Understand what components are included in your cloud assets to determine the full scope of the cloud penetration testing that will be needed.
• Determine the Method – Know which cloud penetration testing your business would like conducted.
• Establish a protocol – Have a plan if the cloud penetration testing company determines that your company has already been breached or if they happen upon an ongoing attack.

Cloud Penetration Testing Scope

Security testers engaged in cloud penetration testing programs will typically examine three areas of scope:

• The external resource cloud.
• The internal cloud environments.
• Hybrid environment.

Cloud penetration testing occurs in three main stages – Evaluation, Exploitation, and Remediation.

• Evaluation – Cloud penetration testing experts engage in cloud security discovery activities, such as cloud security needs, existing cloud SLAs, risks, and potential vulnerability exposures.
• Exploitation – Using the information from the previous stage, testers combine information obtained during evaluation with relevant penetration testing methodologies focusing on exploitable vulnerabilities. This focus will assess your cloud environment’s resiliency to attack, the coverage of your security monitoring, and your detection capabilities’ efficacy.
• Remediation Verification – testers perform a follow-up assessment to ensure that the exploitation phase’s remediation and mitigation steps have been accurately implemented. This also enables the testers to confirm that the customer’s security posture is aligned with industry best practices.

Performing Cloud Penetration Testing

Here is a general and primary way to perform cloud penetration testing:

Know the CSP policies

Before beginning the tests, it is essential to formulate a testing plan based on the policy of the cloud service provider. This is because each CSP has its policy regarding the following:

• Types of cloud pentest that can be performed.
• Endpoints that can be tested.
• Permission to perform the tests.
• Scope of the tests.

So, the cloud provider can penalize you if your testing plan is not by that. For example, if you try to test your account for DDOS and the CSP does not allow that, automatic systems can detect that. After that, the CSP can lock your account for some time, and you will have a lot of explanations to do before you get your account back.

Create Testing Plan

The second part is creating a plan for performing cloud penetration testing. There is no set formula for creating a plan, as it varies from auditor to auditor. But some of the steps you can take to formulate a plan are:

• Map out all the cloud services, components, and endpoints for which testing is to be done.
• Decide which resources to exclude based on policy restrictions.
• Decide the route for performing the pentest, i.e., from Guest to Global Admon or Cloud-Native application to a database.
• How load testing can be part of the security testing against an application, VMs, etc.
• Figure out which tools performed on which resources.
• Get the customer’s approval for your plan and tell them the starting time.

Note: Generally, security testing must be part of your primary plan. Tight it into the cloud penetration testing. Remember that the testing plan changes between each service and environment.  

Execute the plan

Now, it is time to go ahead and execute your plan. Tools like Nmap, Sqlmap, etc., are well-known, but there are many other attack tools that you can add to your plan. You can run the tools as you wish and observe the responses for default configuration, misconfiguration, vulnerability, etc. Some of the tools that you can include in your plan for cloud penetration testing are as follows:

• AADInternal – The ultimate Azure AD / Microsoft 365 hacking toolkit.
• MicroBurst – A collection of PowerShell scripts to scan Azure services for security issues. So, to use them, you need to have PowerShell installed, which is present by default on Windows OS.
• Azucar is another popular Azure scanning tool built using PowerShell, just like MicroBurst.
• S3Scanner – An open-source tool to scan S3 buckets for misconfigurations and dump their data.
• AWS Inspector – A customized security solution for AWS. It can be used as a bare minimum or preliminary testing tool.
• Cloudsploit – This is a popular open-source tool that can scan multiple types of cloud service providers.

Findings and Remediation

Next comes the most underrated activity of cloud penetration testing, report generation. Cloud penetration testers need to present the findings to the client understandably. The reports need to be organized and categorized based on the type and level of threat.

After the findings have been found, could you contact your match? What was the use of cloud penetration testing in the first place if you ignored the bugs? Some findings can be fixed while minor code changes, while others may require a significant overhaul. However, if your tests cannot detect any findings, you may need to change your plan and perform more elaborate security tests.

Summary – Cloud Penetration Testing is one of many security tests we need to run against the cloud environment and must be part of the offensive maturity model. Remember to run security testing wisely. Else there are no benefits to showing how the cloud environment is vulnerable.

in conclusion, Cloud penetration testing is assessing the security of a cloud-based system or service by attempting to identify and exploit vulnerabilities. The testing involves simulating real-world attacks on the system to identify potential security risks and provide recommendations for remediation. The goal is to secure the cloud infrastructure and identify any weaknesses attackers could exploit. Organizations can strengthen their security posture by conducting cloud penetration testing and protecting their data from unauthorized access or theft.