Tools Resources

The 2022 Top 7 Cloud Attack Paths

author_profile
Dana Tsymberg
Monday, Aug 8th, 2022

Introduction

At Panoptica, our graph-based technology views cloud environments from the perspective of the potential attacker to provide a comprehensive view of imposed risks and assets. By connecting the dots between environments and asking specific context-related questions to understand the criticality of the possible exploitable vulnerabilities, Panoptica empowers organizations with the focus and prioritization they need to remediate the critical attack paths that matter most in their environments.

Based on Panoptica proprietary data, research, and our tracking of cloud security trends in the market, our research team has compiled a list of the 2022 Top 7 Cloud Attack Paths across AWS, Azure, GCP, and Kubernetes as seen on the Panoptica Cloud Native Application Protection Platform. The attack paths were selected based on frequency, criticality, and impact. Our attack paths are based on Panoptica’s cloud attack path taxonomy and tie to the MITRE ATT&CK Cloud Matrix for Enterprise. Check out this GitHub report which includes the applicable MITRE ATT&CK TTPs with formatting in .xls, .json, and .svg vended from the MITRE ATT&CK Navigator (https://mitre-attack.github.io/attack-navigator/) for easy reference and utility in reproduction, table-top exercises, threat modeling, etc.

1. Exploitable public workload

Exploitable Public Workload

Definition

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. In both cases, if not mitigated, this kind of initial access into the cloud environment can increase the risk of the attack vector. One of the more common implications of this kind of attack method is leveraging this into running crypto miners or ransomware attacks. In other cases, advanced techniques are used to pivot in the environment using attached or stored cloud credentials to gain data access or perform privilege escalation within the cloud environment.

Description

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.

Business Impact

An exploitable public workload leading to privilege escalation attack path can impose the following impacts:

  • 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.
  • Reputational damage. Customers want to know their data is stored in a secure manner and therefore are also expecting the company to follow regulations and use best practices in their security assessments. Data breaches and temporary downtime can indicate that these practices are not followed which leads to customers being skeptical or having less trust in particular brands or organizations to hold or store their data.
  • Financial damages. Recovering from cloud attacks can be expensive. Often these attacks require rehabilitating the damaged environment which may cost more than expected, and additionally compensating customers impacted by the attacks or breach. It is important to note that some malware can also create direct financial damage. Malware such as crypto mining can generate extra charges and often these risks fly under the radar.

Recommendations

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 to 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 discovery of unknown risks as well.
  • Identity – Follow the principle of least privileges and provide the minimum required permissions to the workloads that allows them to perform their designated task.

Use Cases

https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/

Applicable MITRE ATT&CK for Enterprise TTP

https://github.com/lightspin-tech/lightspin-2022-top-7-attack-paths/tree/main/exploitable-public-workload-priv-esc

2. Private workload with admin permissions

Private workload with admin permissions

Definition

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.

Description

Just because the workload has been configured as private, does not mean that it is secure. This attack path emphasizes the potential of insider risks. Access to a private workload makes it possible for an attacker who already has an initial foothold in the cloud environment or for authorized employees to become administrators in the cloud environment, which is not necessarily the desired role (both for the attacker), but also for the employee. Workloads are generally created to run several jobs or tasks, with different access patterns and authentication complexities, requiring different permissions for multiple services. This complexity creates challenges in managing access to specific services and resources, leading to bad security practices such as granting excessive permissions.

Business Impact

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

  • Takeover and control of 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.

Recommendations

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. Follow the principle of least privileges and provide the minimum required permissions to the workloads that allows them to perform their designated task.

Use Cases

https://krebsonsecurity.com/2019/08/cybersecurity-firm-imperva-discloses-breach/

Applicable MITRE ATT&CK for Enterprise TTPs

https://github.com/lightspin-tech/lightspin-2022-top-7-attack-paths/tree/main/private-workload-admin

3. Cleartext cloud credentials discovered on workload

Cleartext Cloud credentials discovered on workload

Definition

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.

Description

Permissions are usually required to provide a cloud asset access to other cloud services to operate. For example, a known use case is when an EC2 needs access to an S3 bucket to store or retrieve data from it. The recommended way to grant this access to the workload is by attaching it to an identity with the required permissions. 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.

Business Impact

Credentials and secrets are often the most protected assets in every company and companies invest a lot to ensure they are safely stored. When credentials are stored in an unsecured manner, it allows an attacker to leverage and use them to access other resources inside the cloud environment, furthering their attack.

Recommendations

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

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

Use Cases

https://brew.sh/2018/08/05/security-incident-disclosure/

https://techcrunch.com/2019/05/08/samsung-source-code-leak/

Applicable MITRE ATT&CK for Enterprise TTPs

https://github.com/lightspin-tech/lightspin-2022-top-7-attack-paths/tree/main/cleartext-creds-on-workload

4. Identity with bad hygiene

Identity with bad hygiene

Definition

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 which compromises this identity.

Description

It is crucial to maintain a healthy security environment, and although this is not an easy task, it is important to pay attention to IAM best practices, as it is usually the first thing attackers will examine and try to exploit.

Bad hygiene comes in many forms:

  • Not using MFA. Multi-factor Authentication (MFA) provides an additional protection layer for IAM users. When MFA is not enabled, and the authentication is done with a username and password only, the environment can be easily compromised by attackers once they gain access to those credentials.
  • Weak password policies. Without defining a strong password policy, attackers can easily guess passwords using well-known techniques (dictionary attacks, brute force, etc.) and gain access to the target user’s identity to log in to its cloud environment.
  • Empty groups. Groups are aggregated entities usually created for users. In the cloud environment permissions can be assigned to the group itself and these permissions are also granted to any users contained in the group. New users that are added to the group will also be granted the existing permissions of this group. Therefore, having a group without assigned users imposes a risk on the environment because there is no active usage for this group.
  • Inactive identities. Identities activity such as users or roles can be tracked using audit logs and last login records. These identities are considered neglected identities that can pose a risk to the environment.
  • Unused access keys. Access keys are long-term credentials for IAM users. These keys can be neglected and overseen which gives an attacker the option to avoid detection while using these keys to gain access to the environment.

Business Impact

Poor maintenance of the security environment’s health can lead to an identity with 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, making it particularly risky for organizations.

Recommendations

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

  • Enable MFA. MFA should be mandatory for all IAM users.
  • Create strong password policies. Ensure IAM user's 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.

 Use Cases

https://medium.com/@gchib/naturesbasket-aws-root-account-takeover-e4aa5c5e95e1

https://threatpost.com/hacker-puts-hosting-service-code-spaces-out-of-business/106761/

Applicable MITRE ATT&CK for Enterprise TTPs

https://github.com/lightspin-tech/lightspin-2022-top-7-attack-paths/tree/main/private-workload-admin

5. Unauthenticated public access to data store

Unauthenticated public access to data store

Definition

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.

Description

Cloud storage and database services are a key factor in any company, outside of specific use cases most applications need some form of storage. This storage can include PII (personally identifiable information), or company internal trade secrets.

If these various cloud datastores are misconfigured to be publicly reachable without additional authentication, attackers can use readily available utilities to compromise the datastore and/or the data within with a high likelihood of carrying out the attack without being detected.

There are several main security configurations on which storage components are built:

  • Public/Private. When discussing public cloud datastores the differentiation between public and private refers to both network access (via an endpoint or a hostname) and additional identity controls such as allowing anonymous users to read and / or write from the datastores. When creating a storage component, the user can choose if the storage will be public or private. This configuration controls the access settings of the storage. When access is public, this means the storage is open to the world and any entity can access it without special restrictions.
  • Encryption. Post-incident response reports show that many cloud storage components were not only public but also unencrypted. Cloud-native encryption typically requires additional permissions to use the encryption keys which can prevent the data itself from being compromised in some cases.
  • Authentication. Some public cloud datastores offer multiple configuration options for authentication to the resource. For the most part, there are options for no authentication or basic authentication (username and password). Others offer advanced options such as SAML, OIDC, Kerberos, or cloud native IAM-based authentication. The latter authentication methods are more hardened against external attacks than the former.

Business Impact

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 customer’s sensitive data can cause reputational damage to the company and impact current and future customers.

Recommendations

To proactively secure the cloud environment from an unauthenticated public access to datastore attack path the organization can:

  • 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, 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.

Use Cases

https://www.upguard.com/breaches/data-leak-hipaa-medico-s3

https://pf-media.co.uk/news/pfizer-suffers-huge-data-breach-on-unsecured-cloud-storage/

Applicable MITRE ATT&CK for Enterprise TTPs

https://github.com/lightspin-tech/lightspin-2022-top-7-attack-paths/tree/main/unauthenticated-public-datastore

6. 3rd party cross environment / account access leading to privilege escalation

account access leading to privilege escalation

Definition

This attack path details the trust given to a 3rd 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 3rd party company.

Description

Many organizations rely on 3rd party vendors and managed service providers to support, monitor, or secure their environment. If the access granted to those 3rd party accounts is configured incorrectly, it exposes the company to unnecessary risks, especially if there are no restrictions on access to specific resources inside the environment.

Business Impact

Any breach of the trusted 3rd 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 the actions from the trusted 3rd party company, which is considered to be safe.

Recommendations

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

  • 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.

Use Cases

https://blog.lightspin.io/risks-of-misconfigured-s3-buckets

Applicable MITRE ATT&CK for Enterprise TTPs

https://github.com/lightspin-tech/lightspin-2022-top-7-attack-paths/tree/main/3rd-party-cross-env-priv-esc

7. SSH keys discovered on workload leading to lateral movement

SSH keys discovered on workload leading to lateral movement

Definition

This attack path details the ability to perform a lateral movement in the cloud environment based on SSH keys. This movement ("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.

Description

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.

Business Impact

Sharing the same SSH key pair between many compute instances creates a single point of high risk to the cloud environment. It makes it easier for an attacker to move between environments such as Dev and Prod and reach sensitive assets.

Recommendations

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.

Use Cases

https://resources.lightspin.io/detect-same-key-pairs-ec2-instances-to-prevent-hacks

https://attack.mitre.org/techniques/T1021/004/

Applicable MITRE ATT&CK for Enterprise TTPs

https://github.com/lightspin-tech/lightspin-2022-top-7-attack-paths/tree/main/ssh-keys-lateral-movement

Key Takeaways

  1. Simple is deadly. It’s not the exotic attack paths that are seen the most and drive the most damage to the business. It’s the combination of simpler mistakes (leaving clear text credentials exposed, over permissive roles, bad IAM hygiene, public exposure etc.). Developers want to build and deploy quickly to fulfill business objectives, without support from the security teams in the form of easy-to-use secure-by-default templates or available documentation, the least secure options may be selected.
  2. Everyone makes mistakes. There’s no such thing as a perfectly secure cloud environment. Across every cloud provider, the complexity is exploding, the difficulty astronomic, the work force, short-handed. The top 7 cloud attack paths exist because attackers exploit combinations of the lack of basic security hygiene practices.
  3. Connecting the dots. Attack paths provide data and visualization to help show development and security teams the true impact of mistakes, providing the context of how small mistakes combined with 1 or 2 other points of context can result in a critical issue with potentially major business impact. Giving plenty of context drives good action. Security is just one form of quality in code. Developers care about quality; therefore, they need the context. Nothing better than a cloud attack path to elegantly provide that.
  4. Remediation is key. 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.

Panoptica’s attack path expertise and deep dive technology provides organizations of all sizes visualization, prioritization, and remediation for SecOps and DevOps teams. To see attack paths in action, sign up for a free trial and get access to a demo environment and other learning materials. If you’d like a personalized demo and deep dive with our technical solutions team, book a demo today.

Popup Image