CompTIA PenTest+ Certification: A Simple Guide To Attacking the Cloud

Key topics:
- Account and Privilege Attacks
- Credential Harvesting
- Privesc
- Account Takeover
- Password Spraying
- Misconfigured Cloud Assets
- Identity and Access Management
- Federation
- Object Storage
- Containerization Technologies
- Cloud-Centric Attacks
- Denial of Service
- Cloud Malware Injection
- Side-Channel Attacks
- Software Development Kits


- Performing attacks against cloud technologies, such as credential harvesting, privilege escalation, and account takeover
- Identifying misconfigured cloud assets
- Using cloud-specialized attack tools for cloud attacks

Like network, mobile, and application penetration testing, cloud pentesting is quickly becoming its own unique discipline. The CompTIA PenTest+ exam acknowledges this and may have questions to test your knowledge of the subject area. In this guide, we will attempt to cover enough of this discipline to aid you during your certification attempt, but we encourage you to do additional research in this area to truly build your expertise.

We talked about special environmental considerations applying to cloud penetration testing. Let’s take a deeper look at what this means.

It’s been said that there is no cloud, there is only someone else’s computer. This is a humorous but not altogether inaccurate description of Software as a Service (SaaS) models, where the end user does not own the environment being tested. Since the end user can only provide permission to test the content they own, this means traditional pentesting methods can’t be used. In Amazon Web Services (AWS), for instance, legal and technological constraints for SaaS environments forbid testing of physical hardware, underlying operating systems, and EC2 environments belonging to other organizations—even if they are leveraged by the target, or Amazon’s small Relational Database Service (RDS).

Note: : The rules of engagement for Microsoft Cloud are at https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement, AWS rules are at https://aws.amazon.com/security/penetration-testing/, and Google Cloud rules are at https://support.google.com/cloud/answer/6262505?hl=en.
As a result, cloud pentesting—for SaaS environments at least—will focus on the evaluation of assets owned by the user. This includes credentials and other authorization keys, user-supplied configurations governing management and permissions, API usage, and other functionality created by the application owner rather than the cloud provider. Misconfiguration can expose data hosted within the cloud environment and allow side-channel attacks, takeovers, and exploitation of assets that exist in or rely upon the environment. Insecurely implemented services may be prone to attacks that allow the target to be vulnerable to—or even used in—denial of service (DoS) attacks. This is a small survey of the possible attack landscape for cloud pentests.
Keep in mind that there are many cloud providers, and each has its own approach to implementing cloud services. These differences in approaches will affect the tooling you use and how you apply the concepts covered in this guide. In most cases, talking about the cloud means we’re talking about three main providers (Amazon, Microsoft, and Google), so we’ll stick to these three to cover cloud pentest concepts to prepare you for basic scenario analysis during the CompTIA PenTest+ exam.

Account and Privilege Attacks
Many organizations move to the cloud for the simplicity of securing their environments. However, it turns out that most cloud providers have a large number of roles to allow users to perform tasks. When things don’t work, users often end up with more privileges than are necessary in order to make an easy fix. Additionally, cloud accounts have some of the same weaknesses as corporate accounts because they still use credentials. While cloud providers may offer multifactor authentication for web interfaces, those are not necessarily the most common attack vector.
Most of the time, compromised API-based credential material is to blame for successful cloud attacks.

For AWS, this can be SSH keys, access keys, and secrets. For Azure, this can be credentials, keys, or certificates. Google even offers custom authentication methods. But all of these credentials tend to be stored somewhere. Because they are used programmatically, they may not be stored securely, and frequently they end up in places where they shouldn’t. Once these are compromised, misconfigurations in identity and access management (IAM) schemes can lead to privilege escalation or account takeover, enabling attackers to gain full administrative access to a cloud account.

Credential Harvesting
Credential harvesting is therefore one of the primary attack vectors for cloud environments. There are different approaches, but one of the most common is to mine source code repositories. 

Tools such as Gitleaks (https://github.com/zricethezav/gitleaks) and truffleHog (https://github.com/trufflesecurity/truffleHog) probably won’t appear on the exam, but they are purpose-built for finding secrets, such as passwords and keys, in Git repositories. Using these secrets to gain initial access to cloud environments or to escalate privileges may be the easiest point of compromise when attacking cloud environments.
Since these credentials are typically used in automated scripts, they aren’t always cleaned up as part of commits to repositories. They may be accidentally included and may live in the repository history even if they are caught. Some continuous integration/continuous deployment (CI/CD) pipelines may integrate these search tools into their process out of an awareness of these issues.
In addition to cloud authentication, federated authentication is becoming more common. Federated authentication takes organizational authentication and uses Security Assertion Markup Language (SAML) to create an authentication token, which is fed to the cloud service. This token can then be decrypted and assessed for authentication information by the cloud provider. The information shared from the organization is part of a signed SAML assertion (http://saml.xml.org/assertions).
With federated authentication, corporate credentials become more valuable. There has been an increase in password spraying attacks on Microsoft Azure authentication in 2021 (https://www.secureworks.com/research/undetected-azure-active-directory-brute-force-attacks). These spraying attacks are beneficial because they can get an attacker some level of access within an organization to make privesc, phishing, and other attacks easier.

Privesc
Much as with typical environments, the next step for cloud environments after gaining an initial foothold is to elevate privileges. First, you need to figure out what privileges and roles you have. This is one of the main goals of Pacu (https://github.com/RhinoSecurityLabs/pacu) by Rhino Security Labs. Pacu can help identify cloud resources, misconfigurations, and more. In this example, we’ll import some keys that we may have found in an internal repository. We will attempt to use them for privilege escalation.
If Pacu is not installed, the instructions for installing it are in the Pacu GitHub. To begin, we will need to launch Pacu and create a new session to store our data. Each session maintains a database about the information that you uncover. This data can be queried and used to help make decisions for the modules inside Pacu. Pacu is written in Python and only supports AWS for cloud infrastructure. If you have Python version 3.6 or higher and you have pip installed, you can run the command pip install pacu to install the tool.

Tip: Pacu is an open-source Python exploitation framework for AWS cloud environments. You can use it to conduct reconnaissance, privilege escalation, lateral movement, exploitation, and evasion in the cloud. Pacu implements modules to do things like enumerate users, roles, resources, lambda data, and s3 buckets; identify privilege paths and misconfigurations; perform injection; and gain persistence within the cloud.

With Pacu installed, change to the pacu directory and create a new session. In our case, we will make one called ptplus.

Next, import keys. This might be from your AWS credentials file stored in your profile. In Kali, this is in ~/.aws under the credentials file. The name of the credential set is what you import. In this case, we import ptplus keys.

Pacu lists the modules it supports by category. This includes
- Enumeration
- Escalation
- Exfiltration
- Evasion
- Reconnaissance (Recon)
- Exploitation
- Persistence

To list the supported modules, you can use the ls command.

Let’s list some basic information about the AWS account so that we can verify the keys are working and we are set up correctly. Modules are run with the run or execute command. If you get stuck, you can use help. Run the aws__enum_account module.

We have verified that our keys work for access to the instance, and we’ve completed some basic enumeration. Let’s try out some privesc. First, we’ll find out what permissions we have by populating the database with the iam__enum_permissions command. This will list permissions from the IAM service with AWS.

Our ptplus user does have roles. But we only asked Pacu to list information relating to our user—not specific roles. We could have asked it to list roles as well. The iam__privesc_scan module will run additional checks as required. We don’t have to do this here, but running the previous module did tell us that we can list our own privileges. This tells us that we can better identify possible escalation vectors.

Without this ability, we would have to resort to other reconnaissance or attack activities to find privesc opportunities.

At this point, we have used Pacu to identify policies that it thinks it can use for privesc. It identifies these as either POTENTIAL or CONFIRMED. Once this identification is complete, Pacu will ask specific questions about the attack option it has identified. In this case, the CreateNewPolicyVersion attack will ask which policy to use.

You can simply press ENTER to allow it to choose an ideal one for you.

Now we can enumerate other users and policies to determine what access they have. This information lets us determine additional users, roles, persistence opportunities, and strategies for account takeover.

With enumeration complete, we can use the data command to query information about services, configurations, and more from the Pacu database. In this case, we’ll list information about users we were able to discover from the IAM database.



We want to leverage the access we have into IAM and other services to move into some of the compute resources. AWS’s Infrastructure as a Service (IaaS) offering is called Elastic Compute Cloud (EC2). EC2 resources may use a resource-specific userdata blob for initial configuration when they are launched. Pacu can query this data and save it to a file for us.

In this case, Pacu has identified one instance that has user data in a blob. But Pacu doesn’t have enough information to pull it automatically. It will use the ec2__enum module to gather the data it needs to be able to pull the requested blob.

Now that we have downloaded the data, we can exit Pacu and resume the session later. The data we need will be stored in our local user’s directory under ~/.local/share/pacu/<SessionName>.

Let’s run cat on the file and view the user data.

We also have the code the target is using for setting local administrator passwords when systems are booted. Pacu has helped us not only get elevated access in IAM but access to EC2 resources as well. With access to a system, we have additional attack opportunities like getting data from the Metadata service.

The Metadata service (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) provides information about systems to the systems themselves. When you have access to a system using an attack like the preceding userdata attack, you can query the metadata service in AWS. From an AWS system, you can query the URI http://169.254.169.254/latest/meta-data to see the various options. This is an Amazon-specific IP address. One of the things we can do is get the tokens from the instance. These tokens allow us to take advantage of the rights of the system or service we have compromised.

Tip: AWS user keys typically begin with AKIA, and services begin with ASIA. When you see AKIA, it is a long-term credential, and ASIA is a short-term credential for the service (https://docs.aws.amazon.com/STS/latest/APIReference/API_GetAccessKeyInfo.html).




Tip: If you would like to experiment more with this kind of attack, the flAWS CTF challenge at http://flaws.cloud/ allows you to test this with real AWS configurations.

Account Takeover
Account takeover is a term used to describe someone gaining pervasive access to an account. In essence, the attacker has privileges that are equivalent to the account owner. Typically, this is the result of spear phishing, misconfigured access, or privilege escalation from domain privileges into the cloud. One high-profile incident involving account takeover was the SolarWinds breach at the end of 2020. Attackers added further OAuth certificates into cloud applications, which allowed them to forge credentials in order to maintain elevated privileges (https://www.bankinfosecurity.com/solarwinds-attackers-manipulated-oauth-app-certificates-a-16253).

In addition to attacking OAuth and federation, attacks can create permissive policies that look benign, add certificates or access keys to a user that is controlled by an attacker, or add persistence to applications that have elevated privileges within the account. Malicious policies can be assigned to users or systems, or additional permissions can be added to existing policies. But all of these attacks serve to grant persistent access within the environment, resulting in pervasive access to data and commands. This may go beyond the cloud account itself and into federated applications, cloud assets, hosted data, and network boundaries.

Password Spraying
As with other exposed login interfaces, password spraying attacks will work in the cloud. In many cases, multifactor authentication will be in place and will mitigate these attacks. However, in the case vulnerable cloud interfaces are exposed, password spraying tools designed for common login services may not work. Instead, you may need to use cloud-specific tools for password spraying, such as the Microsoft Online MSOLSpray tool (https://github.com/dafthack/MSOLSpray).

Here’s an example:

For the exam, it’s unlikely you will be asked to have an encyclopedic knowledge of all tools capable of doing this. However, you should be aware that this attack still applies when you are testing assets hosted in the cloud and that you may have to customize your tools to do it during a pentest. Additionally, you should be aware of the impact a spray will have on the service and whether that is allowed according to the hosting provider’s pentest policies. But keep in mind that attacking an asset that is hosted in the cloud is not the same as attacking the cloud itself, even though you might ultimately be able to gain access to a cloud-hosted system or even elevate your privileges to the point where you can gain access to attack the cloud infrastructure.

Misconfigured Cloud Assets
Whether it’s Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS), securing cloud asset configurations can be underwhelmingly simple or overwhelmingly complex. The more sophisticated the platform, the more difficult it may be to secure the platform, and when moving into PaaS or IaaS, complexities can be huge.

Identity and Access Management
IAM consists of the users, groups, roles, and permissions of users and assets within a cloud environment. Permissions are explicit grants of access given to a user, group, or asset. This could be something like being able to access a specific bucket in AWS or the ability to update Blob Storage in Azure.
Roles are designed to roll up permissions so that they can be used across different users, groups, or assets. They are built so that a specific task can be performed. For example, in order to create a new image in the cloud using a tool like Packer, you would need to be able to spin up a machine image, update the image, snapshot the image, and promote it to a new image. This would require a series of permissions. Roles may nest other roles under them to perform that task.
A best practice is to have roles assigned to groups and to place users in the groups. This helps with role-based access control (RBAC). This allows administrators to give people the permissions they need to do their job while being able to update those permissions across all job holders should the requirements for the job change. This is less administratively intensive than having to update each individual user, especially in larger organizations.
Keep in mind that applications and systems may also have permissions. This includes permissions to access other services, to create and destroy files within a data store, and even to update certain cloud configurations. Because this can become very complicated quickly, it’s handy to have tooling to help identify problems.
Scout Suite by NCCGroup (https://github.com/nccgroup/ScoutSuite) is one such tool. It can audit accounts in AWS, Azure, Google Cloud, Alibaba, and Oracle Cloud. Scout Suite is written in Python and can be installed by running pip install scoutsuite or by downloading and installing the tool from GitHub. Once installed, typing scout -h will allow you to view options. Let’s take a look at our AWS configuration by running scout aws. The output will save to a directory and create an HTML file.

Tip: Scout Suite is a Python tool that can audit accounts in AWS, Azure, Google Cloud, Alibaba, and Oracle Cloud. Scout Suite automatically gathers configuration data and highlights potential risk areas for manual inspection.

The figure above shows an example of how the resulting HTML file looks when opened in a browser. The main page shows all of the services, while the dashboard shows overall issues pertaining to all the services evaluated.

The figure below shows what happens if we click on the Security pulldown and select IAM to view IAM issues.



Figure:   Scout Suite results, main page



Figure:   Scout Suite IAM dashboard

Our IAM dashboard flags several issues for our attention. Clicking on any of the findings will allow us to view further details so that we can remediate the issues. As an attacker, this is an easy way to dig into areas that may be exploitable to identify potential attack vectors. As a cloud account owner, it’s a good practice to run tools like this regularly for proactive efforts at security remediation.

Federation
Federation takes an identity provider and uses it as the authentication source for an environment. This could be something like Okta (https://www.okta.com/identity-101/what-is-federated-identity), which acts as an authentication source of its own, or it could be integrated into AWS (https://aws.amazon.com/identity/federation), Azure (https://docs.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed), or Google Cloud (https://cloud.google.com/architecture/identity/federating-gcp-with-active-directory-introduction).

Federation uses technologies like OAuth (https://oauth.net/2/), SAML (https://auth0.com/blog/how-saml-authentication-works/), or OpenID (https://openid.net/) to act as identity providers that can perform authentication outside of an environment, then return data about the authenticated party so the platform itself can handle authorization. This is typically secured with shared secrets, such as certificates. If those secrets are compromised, then the security of the federation is compromised (https://www.zdnet.com/article/nsa-warns-of-federated-login-abuse-for-local-to-cloud-attacks/). As such, protecting these keys is fundamental to the security of the environment.

Some services allow more than one federated authentication source or multiple keys. Auditing changes to keys, federation sources, or external authentication sources will help protect an environment. As a tester, this is something you should look for but handle carefully. Modifying these settings means protecting the secrets you add and making sure you clean up when you are finished so that you don’t degrade the security of your target environment as a result of your testing.

Object Storage
Object storage is one of the most abused cloud components. Frequently, breaches of storage like Amazon S3 are due to misconfigurations. In one case, hundreds of gigabytes of municipal data was accidentally disclosed due to poor S3 hygiene (https://www.securitymagazine.com/articles/95704-us-municipalities-suffer-data-breach-due-to-misconfigured-amazon-s3-buckets). As pentesters, we approach object storage in one of two ways. We can identify storage that is accessible from an unauthenticated point of view, or we can identify storage that is accessible from an authenticated view. Tools like CloudCustodian (https://cloudcustodian.io/) can be used for cloud governance and discovery.

Tip: CloudCustodian is an open-source tool that uses YAML policy files for auditing and enforcing cloud configuration policies in multiple cloud environments, including Azure, AWS, and Google Cloud Platform.
CloudCustodian takes policies in YAML and runs them against an account in order to identify misconfigurations, fix them, and report on potential policy violations. Policies have a name, a resource, and a series of applicable filters. CloudCustodian has sample configurations for AWS, Azure, and Google Cloud. These range from account checks and remediation to VPC checks (https://cloudcustodian.io/docs/aws/examples/index.html). Let’s say we want to identify buckets that are not blocking public access.

This sample policy will check this.

To run this policy, we can use the run command and the --dry-run option to run the custodian binary. The --dry-run option makes sure that no changes take place. We also use the -s flag to supply an output directory.

In this case, we see two resources. Looking in the output directory, we will see each policy in its own directory based on name, with identified resources inside a resources.json file.



We can see that the test-web bucket has a public access block that does not prevent public access. The policy has PublicReadGetObject allowed for * to get objects. This means anyone can grab a file from this bucket via the Web. Let’s verify that with curl.

We see that we can access the bucket using the naming scheme for web-enabled buckets (<bucket>.s3.amazonaws.com). If you know the organization name, you may also be able to use the format: s3-<region>.amazonaws.com/<Org Name>. We also can verify using the CloudScout output for S3 buckets. When we click on our derp-web bucket, we see the same information we saw in the JSON response, as shown below.



Figure:   CloudScout results for S3 buckets

What if we didn’t have access? There are many tools designed to guess S3 bucket names. You could use this command in Pacu:
Pacu > run s3__bucket_finder -d <doamain>

Pacu’s s3__bucket_finder module guesses bucket names based on domain names, subdomains, given affixes, and more. There are other tools that guess buckets based on dictionaries and wordlist manipulation.

One of those tools is CloudBrute (https://github.com/0xsha/CloudBrute). CloudBrute supports AWS, Azure, Google Cloud, Digital Ocean, Vultr, Alibaba, and Linode providers. It will attempt to guess buckets based on a key (specified by -k), a wordlist (specified by -w), and a domain or other keywords. Let’s try searching for derp.pro.

The figure below shows the output.



Figure:   CloudBrute results for ./CloudBrute -d derp.pro -k derp -c amazon -w data/storage_small.txt

Derp-web doesn’t show up. This directory isn’t publicly listable. It will only show up if you request the page explicitly, such as with index.html. Storage has access lists and public settings that typically make up the combined access rules. These can be complex if you aren’t familiar with them. This is why there have been so many leaks of cloud storage data (https://github.com/nagwww/s3-leaks).

Tip: CloudBrute is a multicloud (Azure, Amazon, Google, etc.) tool that helps identify target infrastructure, files, and applications using wordlists, domains, and common cloud naming conventions.

Containerization Technologies
Containers allow you to take an image and run it anywhere. A number of different technologies let us run containers, such as containerd, Windows containers, Docker, Kubernetes, and cloud implementations of these technologies. Most pentesters will need to understand how to recognize, access, and break out of containerized systems. How you leverage container resources to further your access to other systems, or to the hosting system, will be influenced by whether you are able to map local disks on the system from within the container, for example. If directories are mapped that include a Docker socket file, for example, you may be able to issue commands to the container using that file.

Additional Docker breakout methods can be found at https://blog.nody.cc/posts/container-breakouts-part1/.
Docker is typically only used for small numbers of containers on a specific host. Docker Swarm is used for orchestration when there are a small number of systems with a small number of services.

Kubernetes is better for systems that require orchestration across many nodes, and it offers enterprise-level scalability and resiliency.

Docker and Kubernetes share some common attack patterns (such as kernel exploits: https://snyk.io/blog/kernel-privilege-escalation/), but Kubernetes works off of kubelets, users, pods, secrets, and more, which have unique attack vectors.

Microsoft has created a list of potential attack, escalation, discovery, and evasion techniques as part of their Threat Matrix for Kubernetes (https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/). Jay Beale of Inguardians has written a walkthrough of some techniques that can be used in a Kubernetes attack on their blog: https://www.inguardians.com/attacking-and-defending-kubernetes-bust-a-kube-episode-1/blog/

Cloud-Centric Attacks
Some attacks, such as DoS, have specialized context when applied to the cloud. Other attacks focus on the nuances of services available only within cloud environments, such as with malware injection and side-channel attacks for cloud resources. Attackers may use these attacks to gain further access within a cloud environment or to use the cloud environment as an attack tool to accomplish goals against other Internet-facing targets.

Denial of Service
Attackers use DoS attacks to increase costs, disrupt quality of service, or cause inconvenience for organizations owning the resources or attempting to use them. Motivations may range from monetary (ransom), political or moral activism, or revenge, to using them to mask other attacks. As a pentester, you may also be asked to evaluate whether a cloud environment has weaknesses that allow attackers to use cloud resources for DoS attacks.

Volumetric DDoS
Volumetric attacks try to take up bandwidth or connections on their targets. Cloud resources are an attractive way to amplify an attack or to mask the true source of the attack. The amplification of a reflected attack is the ratio of what is sent to the intermediary versus what is sent to the victim. For example, Memcached is used to store data that can be shared between applications, like web session data. A small request to Memcached can turn into a huge return volume. But as there are fewer Memcached systems on the Internet compared to NTP or SNMP, it may be less attractive as a target. UDP reflection attacks can use protocols like Apple Remote Management Service, Web Services Dynamic Discovery (WS-DD), Constrained Application Protocol (CoAP), LDAP, and Memcached, all of which can be exposed by cloud resources.

Direct-to-Origin Attacks
One of the benefits of cloud-based distributed denial of service (DDoS) prevention is cloud front-ends can massively scale in order to deal with an attack. Only the traffic that has to be passed to back-end systems lands on the origin server itself. With this type of mitigation, there are ideally firewall rules to prevent anyone other than the cloud provider from communicating directly with the origin server. If these rules don’t properly protect origin servers, attackers may be able to issue requests that reveal back-end IP addresses for the systems being protected (https://cdn.net/how-to-protect-your-cdn-origin-server/).
If real IPs are revealed, attackers can bypass protections and attack IP addresses directly. This is a direct-to-origin attack. Content delivery networks (CDNs) are designed to shoulder the bulk of the load. Massive amounts of traffic can therefore be serviced by relatively few systems. Attacking those few directly can quickly overload the target. The cached content in the CDN will still be serviced, but dynamic content can’t be generated and distributed. This would be things like logins, searches, and more (https://www.red-button.net/ddos-glossary/direct-to-origin-ddos-attacks/).

Look up the website by name to get its IP. Look up the IP and see who owns it in ARIN. If it’s a cloud provider, it could be a cloud-fronted site. You could instead make requests to a bogus virtual host address—let’s say, “doesnotexist.derp.pro”—and see if you get a response from a different IP range. You could even look up the IP range your target organization owns and request the domain name. For example, send this request to the IP address target in Burp (https://<company owned IP address from ARIN>):

If the response comes back as a valid web response with a base page, you know you’ve made a direct request. You can also examine SSL certificates to identify IP addresses that may be vhosts in use. Some tools exist to help automate this process, but may not show up on the exam:
- https://github.com/jobertabma/virtual-host-discovery
- https://github.com/gwen001/vhost-brute
- https://github.com/m0rtem/CloudFail

Tip: For further reading about some of the research into these types of attacks, check out these articles at ZDnet (https://www.zdnet.com/article/fbi-warns-of-new-ddos-attack-vectors-coap-ws-dd-arms-and-jenkins/) and Team Cymru’s blog (https://team-cymru.com/blog/2020/05/15/dissecting-ddos-attacks/).

Cloud Malware Injection
XSS and SQLi attacks  also work in the cloud. However, there are additional vectors of attack for malware injection in the cloud. In the cloud, attackers may be able to use the access acquired through other attacks to inject malicious content into served images or cloud services.

For example, if an attacker is able to manipulate a copy of a legitimate cloud-hosted service or machine image and then convince the cloud provider that copy should be served, they could gain additional access to the cloud environment or even intercept service requests meant for the legitimate service. In a SaaS or PaaS model, this means using a service. In an IaaS model, this means affecting served images. In both cases, this involves having some level of privileged access to the cloud account. But this may be acquired as a result of other attacks. Let’s look at a plausible example.

Assume during our testing that we identify an abandoned GitHub repository maintained by the target organization. It looks like a number of scripts within the repository are used either as examples of how to manage the services the organization offers or to perform the management. Using a tool like truffleHog, we can look for keys. Let’s say we find a key in a commit from more than a year ago. It’s since been removed from the repository, but the history file has not been cleaned. Testing the key, we find out that it works, and the key grants access to the organization, but without enough permissions to do what we want. We have EC2:* privileges, though. This lets us enumerate the EC2 instances and find the AMI that was used to create them.

To take a closer look, we can spin up a new instance with that AMI using our own keys, connect to it, and find that it is using AWS Secrets Manager to get credentials for communication to other services. Since we don’t have enough privileges to grant permissions to the new instance, it can’t access these secrets. Bummer, right? We need to get creative. We look and find that the AMIs use a naming scheme: WebService-Master-MM-YY. It’s possible that services pull the latest image based on this naming scheme. So, we modify our AMI to add a hidden webshell for remote access and throw in a privilege escalation binary so that we can take over the system. Then we save it to a new AMI using the same naming scheme. We wait, and eventually we see that the service has launched our malicious AMI. We can use our webshell to get into it, elevate privileges, and sift through the running processes to access the credentials from AWS Secrets Manager. Those secrets allow us to access the RDS instance and get access to sensitive data that we could not use before.

Attackers could use this to exploit users of the cloud service with something like a drive-by attack, intercept other sensitive data sent to the service, or plant additional malware to abuse resources hosted in the cloud environment. This type of attack can be difficult to spot, because it relies heavily on integrity management of images and services, as well as protecting cloud secrets. While there’s a lot of attention on the latter, good controls for integrity management are less often considered.

Side-Channel Attacks
One of the reasons the cloud is popular is because of its scalability. Affordable scalability is the result of multitenancy. That means many customers may be running isolated images using the same physical hardware. Since the CPUs are still the same and some of the hardware is shared, side-channel attacks may take advantages of weaknesses in hardware to capture information from other instances. Two prominent examples of this are Spectre and Meltdown (https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html). Using these weaknesses, attackers may be able to read kernel memory and system caches and perhaps access information of other instances. Keys, certificates, credentials, processed data, and other information may be leaked from shared systems. There are numerous scholarly papers about side-channel attacks (http://dx.doi.org/10.1145/2660267.2660356 for example); however, these attacks are difficult to execute, and the data returned is not always predictable.

Software Development Kits
Cloud-based software development kits (SDKs) include command-line interfaces (CLIs) to interact with the cloud. Amazon implements awscli. Google Cloud Platform (GCP) implements the gcloud tool. Azure has the az tool. These may also include various other libraries to help interact with services. Most cloud infrastructures can be accessed programmatically.

Here’s an example of using PowerShell to look up automation accounts and runbooks and export them in Azure:

This can also be done using an Azure SDK written for Python (https://github.com/Azure/azure-sdk-for-python).

In addition, many organizations are going the route of using Infrastructure as Code (IaC). IaC allows organizations to programmatically define how to build instances and architectures in the cloud so that they can be consistent, scalable, reusable, and well defined. Some of the tools that make up IaC include Chef, Puppet, Ansible, SaltStack, Terraform, CloudFormation, Packer, Vagrant, Docker, and Kubernetes. We could probably dedicate the entire space of a book to these technologies, and you should certainly use the opportunity to research these independently in order to become a great pentester, if you choose to focus on cloud technologies. What you need to know is that using these tools provides a programmatic way to use cloud SDKs from within other tooling.

Using code to set up configuration files to build a cloud-based infrastructure and then perform prebuild, deployment, and post-deployment tasks to customize the resulting images has three advantages. As tooling is updated, this makes it much easier to upgrade, redeploy, scale, and destroy environments as necessary. It becomes easier for DevOps methodologies to use these tools to better include cloud in CI/CD pipelines, where code can be constantly updated as new features are added so that environments can be scaled, upgraded, and rolled back as needed. And these tools make it easier to transform environments from one provider to another, since the actual infrastructure is abstracted.

What does this mean to a pentester or an attacker? These are all powerful tools, but they must be run from somewhere. This means that keys, secrets, configurations, and the data these tools use must also reside somewhere. This makes targeting this information a potential operational goal. Confirm that this information is adequately protected by looking in internal and external code repositories to minimize unintentional exposures. Target systems that handle CI/CD pipelines and make sure they do not grant access to all of the cloud repositories, including the ability to spin up new instances, capture keys for privilege escalation, or gain persistence.

Tools like CyberArk, HashiCorp Vault, AWS Secrets Manager, and GCP Secrets Manager all help manage secrets.

Google has some good recommendations for secrets management (https://cloud.google.com/secret-manager/docs/best-practices), but users who fail to follow this guidance or leak additional keys may also leave secrets management vulnerable.

Therefore, pentesting will focus on finding weaknesses in the implementation of policies and practices designed to protect this information throughout the provisioning and management process, especially when cloud SDKs and CI/CD are involved.

Review
- The cloud is its own specialty area for pentesting. It requires its own set of tools and knowledge to perform pentests against it successfully.

- In this guide, we’ve reviewed cloud-centric considerations for account and privilege attacks, giving an overview of where common pentest concepts have specific application within the cloud.

- We looked at cloud configuration concepts to give a context for cloud management, reconnaissance, and exploitation during pentests, and we discussed attack permutations that are specific to cloud environments.

- Cloud pentesting often requires custom tooling, so we have provided a few scenarios to familiarize you with some of these, such as Pacu, CloudBrute, Cloud Custodian, and Scout Suite.