The Seven Scariest Cloud Attack Paths

This attack path details the ability of an attacker to exploit vulnerabilities in a public workload and gain initial footholds into the cloud environment. The vulnerability can be either a well-known one or a zero-day.

Public workloads refer to any workload that is accessible to an external attacker due to network configuration of the cloud assets. The exploitable asset can be vulnerable to different vulnerability categories such as misconfigurations, known CVEs, application vulnerabilities, and more. Using the combination of both, an attacker can successfully obtain access, control, or leverage the cloud asset to further their attack. Since, in this attack path, the compromised asset can lead to persistency, data access or privilege escalation in the cloud environment, the attacker can leverage it and may even take over the whole environment.

To harden the cloud environment, security should take place across all points of the attack path.

• • • Network – Limit network access as much as possible. Use IP restrictions to specifically designated CIDR ranges and open access to selected ports instead of wide ranges. Whenever possible, configure the cloud assets as private and not public.
    • Vulnerabilities – Scan all workloads regularly to detect known vulnerabilities and fix them through suggested remediation. It is recommended to conduct a security assessment dedicated to the organization’s cloud environment to ensure the discovery of unknown risks as well.
    • Identity – Follow the principle of least privileges and provide the minimum required permissions to the workloads that allow them to perform their designated task.

This attack path details the existence of a privately configured workload with admin permissions in the cloud environment. Often, these workloads are accessible using CI/CD tools for build and deployment processes that are accessible to most engineers within the organization. This path enables anyone with access to the workload to leverage permissions and become the environment administrator. Just because the workload has been configured as private does not mean that it is secure.

A compromised private workload with admin permissions attack path can lead to the following impacts:

• • • Takeover and control of the entire cloud environment. Through this attack path, a user can gain complete control of the entire cloud environment and can perform any and all actions they desire.
    • Access to sensitive data. After compromising the cloud asset, the attacker can leverage its over-permissive permissions to access sensitive data stored in the cloud environment.

The best practice to ensure that this attack path can be proactively prevented is to verify that only the real and required individual has administrator access to the cloud environment. These permissions should be given out sparingly. Organizations should follow the principle of least privileges and provide the minimum required permissions to the workloads that allow them to perform their designated task.

This attack path details the existence of cleartext cloud credentials such as IAM access keys on a cloud workload. The credentials can be found inside the running workload, in its code, or in its configuration, such as environment variables.

This attack path discovers the risky way to apply this access where the identity credentials are stored directly on the cloud workload. The cleartext credentials can be stored in the asset environment variables, which is a key/value pair used to describe the environment in which the application is running, or in the code itself.

To better protect against the attack path where cleartext cloud credentials are discovered on a workload, organizations should:

• • • Regularly scan cloud workload configuration and code to search for cleartext credentials and secrets.
    • Most security incidents are caused due to human errors, so ensuring ongoing education and training for employees is key.

This attack path details the bad hygiene of an entity such as user, role, group, etc. Each identity should have security controls and be properly maintained. A neglected identity can lead to an undetected breach that compromises this identity.

Poor maintenance of the security environment’s health can lead to an identity with a bad hygiene attack path. This ultimately can compromise the security of specific identities such as users or roles within a cloud environment. These will look like legitimate users at the time of the breach, circumventing any detection or alarms that the system may have in place, and making it particularly risky for organizations.

To proactively prevent this kind of attack path, organizations should:

• • • Make MFA mandatory for all IAM users.
    • Create strong password policies. Ensure IAM users’ passwords won’t be compromised easily. In addition to the standard password policies complexity (length, uppercase, and lowercase alphabet, numerical and non-alphanumeric characters), administrators should also set password expirations and configure the settings, so that expired passwords require administrator resets and prevent password reuse.
    • Empty groups. If there are groups without users, delete the group.
    • Inactive identities. Monitor identities activity using audit logs and last login records. In case there is an identity that looks inactive for a defined period of time (as determined by the organization), it is recommended to delete this identity.
    • Ensure access keys are up to date. Make sure there are no unused or expired access keys. It is also recommended to rotate your access keys every 90 days.

This attack path details the existence of cloud-hosted storage, databases, or other datastores that are public. When there is no authentication, attackers can exploit it to read and/or write data using common tools to compromise the availability, integrity, or confidentiality of the data stored within.

An attacker with access to the datastore can expose sensitive data that will allow them to further their attack. Downloaded sensitive data can be used for a variety of purposes, such as selling it online for any entity or using it to extort the company. Exposing customers’ sensitive data can cause reputational damage to the company and impact current and future customers.

To proactively secure the cloud environment from unauthenticated public access to datastore attack path, organizations should:

• • • Change the public settings. If the storage asset is not intended to be public or it contains any data that is not supposed to be public, the best practice is to change the settings of the storage asset to be private.
    • Network security controls. Cloud datastores such as caches or databases typically require network access controls to be applied. Ensure these allow minimal access and preferably only allow access within an internal network segment versus allowing the entire internet (‘0.0.0.0/0’) to connect.
    • Use encryption keys. Make sure all storage assets are encrypted and that a minimum number of identities is authorized to encrypt/decrypt with the key.
    • Avoid using basic or no-authentication. While additional resources and services may be required, it is recommended to use a cloud-native IAM-based authentication or another open standard such as SAML, OIDC, Kerberos, etc.

This attack path details the trust given to a third-party company or resource to access the customer’s cloud environment. Cross environment/account access is usually granted through a middle identity that is also given a set of permissions. In this attack path, the permissions that are given are overly permissive and can lead to privilege escalation from the third-party company. 

Any breach of the trusted third-party company can directly impact the customer’s cloud environment. When the granted permissions are over-permissive, it allows the attackers to access sensitive resources such as datastores or widely move within the cloud environment. These attacks are particularly difficult to detect because they perform actions from a trusted third-party company, which is considered to be safe.

To proactively protect the cloud environment against this type of attack path, organizations should:

• • • Follow the principle of least privileges and ensure external accounts have as minimum permissions as possible. Provide only the necessary permissions needed for specific resources.
    • Perform a periodic review of the third-party accounts. If the account is no longer in use, delete it and any related assets.
    • Ensure MFA and external IDs are configured for an extra security level.

This attack path details the ability to perform a lateral movement in the cloud environment based on SSH keys. This “jump” can be between public and private virtual machines with permissive network access based on poorly stored private SSH keys or sharing the same SSH keys between many virtual machines in one environment.

As organizations scale, the number of compute instances in use increases in cloud environments, leading to challenges in managing SSH key pairs. Due to the complexity of managing access keys, organizations use the same keys for multiple compute instances. As a result, an attacker that compromises one server can access all servers that use the same SSH key pair. This is an easy way to move inside the cloud environment and gather more information and search for higher permissions.

To proactively protect the cloud environment against such an attack path, use hardened access patterns for the publicly exposed virtual machines via SSH. For instance, secured bastion hosts (“jump box”) with a one-time SSH key or an IAM-based auth solution (AWS Session Manager) can be used to maximize security. Some enterprise solutions also support MFA alongside the SSH authentication mechanism.

As for the inter-cloud lateral movement risks, it is recommended to use different SSH keys for both the public and private virtual machines. Keep the private keys off the virtual machines and consider using a secure credential management solution (password/credential vaults) for the private keys for end-users access.

Without dynamic and customizable remediation, organizations are missing a key element in the power of attack path technology. It is essential for organizations to source platforms and partner with vendors who provide the full depth – root cause analysis and remediation.