Cloud attacks

Surveying the skies

Before we can fully get into what the cloud threat landscape looks like, we need to understand a few key points. First, cloud technologies depend heavily on identity. For more information on how identities are compromised, see the Identity attacks section of this report. As identity technology is heavily intertwined with cloud technologies, most cloud attacks begin with a compromised identity.

Second, many cloud attack techniques are enabled by a misconfiguration by a well-meaning developer, security engineer, or IT administrator. It can be very difficult to distinguish between “normal” behavior of a legitimate user and an adversary trying to perform some operation in an environment. Thus, it is important to monitor for anomalous behavior and configuration changes in your environment as it could indicate the presence of a malicious actor.

Third and last of all, each major cloud provider may have slight variations in what techniques show up most frequently. We’ll highlight and generalize the most common patterns of behavior that apply across cloud providers to help paint a broad picture of what the current cloud threat landscape looks like.

What we saw in 2024

Throughout the year Red Canary continued to ramp up our cloud detection capabilities. We support cloud detection for Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP). We also have detection capabilities for related areas such as identity and business email compromise (BEC). After looking over threats we published and research from others, we have seen only minor changes in how adversaries are attacking cloud environments.

To start, let’s consider how adversaries gain access to cloud environments. Three of the most common ways they do this are:

• misconfigurations
• credential theft
• application errors

This seems to indicate that when configured and managed correctly, the authentication mechanisms provided by cloud service providers (CSP) provide good security. Along with identifying misconfigurations or bugs, adversaries have also gone after the human element by attempting to get credentials from a user or finding exposed credentials elsewhere. Once an adversary has access to an environment, there are myriad techniques they can employ to perform reconnaissance, gather sensitive data, compromise more privileged accounts, and more.

We’ll identify the most prolific threats we have seen once an adversary has some level of access to a cloud environment and highlight some emerging trends.

Cloud attack techniques

In general we saw a rise in cloud-related threat actor activity in 2024. The techniques employed, however, did not change substantially. Let’s focus on a few high-level MITRE ATT&CK techniques seen across the major cloud providers.

Impair Defenses (T1562)

Across our customer base we saw a clear trend of adversaries attempting to impair defenses inside of a cloud environment. The two most common approaches we observed were disabling or modifying firewall rules and disabling or modifying logging in the cloud environment.

Disabling or modifying firewall rules

Adversaries attempt to access cloud environments to take advantage of the services that are running inside them. This can allow them to set up a Secure Shell (SSH) into a compute instance or Remote Desktop Protocol (RDP) into a virtual machine. They may also gain access to internal applications hosted in the cloud environment. Having direct network access to certain services allows the adversary to maintain access to the environment even if they lose access to the compromised account they used for initial access.

Disabling or modifying logging

Our ability to detect adversary behavior in a cloud environment depends heavily on our ability to review audit logs generated by the cloud provider. Knowing this, adversaries attempt to disrupt the ability to view or receive these logs. This would allow them to operate in the cloud environment virtually undetected.

Account Manipulation (T1098)

Adversaries are constantly looking for ways to gain more privileges, often by compromising an identity and then attempting to grant more roles to the identity. This then allows them to potentially expand their operations to other services or even completely take over a cloud environment.

If an organization has granted its users overly permissive roles, adversaries can escalate privileges with just one set of compromised credentials. Each major cloud provider has different defaults for assigning privileges to identities. The identities may be human users or they could be service accounts that are tied to a specific service, such as Kubernetes, virtual machines, serverless functions, etc.

Credential Theft (TA0006)

While a stolen username and password can grant an adversary access to a victim’s cloud environment, credentials such as API keys, certificates, and various tokens enable the adversary to maintain that access over a longer period of time.

Common ways adversaries steal credentials include:

• finding publicly exposed credentials
• using adversary-in-the-middle technologies such as Evilginx
• phishing users for their login credentials
• leveraging stealer malware

Regardless of how the adversaries gain access to the credentials, the end goal is the same: They want to gain access to a cloud environment as a legitimate user. They can then leverage that access to understand the user’s permissions and what tradecraft they can execute as that user.

AI enters the cloud

Many of the major CSPs offer artificial intelligence (AI) services as part of their suite of products, and adversaries have taken notice. If an adversary is able to gain access to AI models or their access tokens, they can perform a wide variety of actions, including:

• incurring high costs through malicious token usage
• reputational damage through the submission of illicit, illegal, or otherwise unwanted content
• theft of intellectual property

For more examples of how an adversary might abuse AI in the cloud, read our blog Understanding and observing Azure OpenAI abuse and visit the Cloud Service Hijacking section of this report.

We’re confident that this trend will continue throughout the next few years as both businesses and adversaries take more advantage of AI services.

Understanding the latest trends in cloud security is an important first step to developing an effective mitigation strategy. The next step is understanding what you can do to defend your environments against these types of attacks. Let’s explore some strategies.

Best practices for cloud security

Cloud systems are reasonably secure, when configured correctly. We’ve written about the benefits that cloud security offers over endpoint security. That said, cloud security is only as good as its configuration. According to Gartner, 80 percent of data breaches can be attributed to a misconfiguration, and almost all cloud environment failures can be attributed to some human error.

It seems the problem is not the cloud technology itself but rather our understanding of how to properly secure cloud applications. So what can we do about it?

For starters, we need to make sure we are properly educated on the best practices recommended by the various CSPs:

• AWS
• Azure
• GCP 

When applied correctly, these best practices make it very difficult for adversaries to take control of your cloud environment. You will need to ensure that all users with access to a cloud environment are aware of the risks and know how to properly protect their accounts and the services to which they have access.

Next, you’ll need to secure the human element. Human error accounts for an overwhelming majority of cloud breaches. This may be due to a user providing credentials during a phishing attack, or a developer accidentally exposing API keys. Whatever the case, ensure that all reasonable efforts have been made to protect people from adversaries and from themselves. Here are some recommendations and best practices:

1. Ensure all users have strong MFA enabled
2. Use short-lived tokens whenever possible
3. Use identity federation when possible/applicable
4. Make sure users are educated on how to spot phishing attempts
5. Narrowly scope users’ roles inside of a cloud environment
6. Keep services private unless absolutely necessary
7. Use limits and quotas to reduce the potential cost impact of adversary behavior

For more in-depth guidance on how to protect your environment from these risks, check out this Cloud Security Alliance article on managing misconfiguration risks.

When considering how to effectively detect threats in the cloud, understand first what kind of visibility you have into your cloud environment. Your primary source of information is audit logs. All major cloud service providers (CSP) provide audit logs of some sort. They all contain some level of logging that is on by default and that they provide free of charge. There are also options to configure more detailed logging that will incur extra cost. Audit logs provide information about what is occurring inside of a cloud environment. They answer the who, what, where, when, and how of each action that is logged. Using this information, security teams can reason about what is going on in their environment and determine if something seems unusual.

The difficulty with cloud detection is that it can be very hard to determine the why. Looking at a single audit log entry, for example one that corresponds to making a storage bucket public, will almost never provide enough context to determine why something occurred and if that should be allowed. We can see who performed the action but we may not know if that user’s account has been compromised or not. The audit log will also not tell us if that user is supposed to be making storage buckets public. To paint the whole picture, you often need to combine multiple audit log entries and then enrich that data with other sources such as IP enrichment, identity enrichment, endpoint data, and whatever else may be relevant to a given log type.

Building effective detection coverage for cloud threats is a difficult task. It requires a different mindset than traditional endpoint security practices. It also requires that security teams be familiar with many different technologies as the cloud has many components to it and there are multiple cloud providers.

Here are some tips for trying to build out detection capabilities for cloud environments:

Start by asking questions

For each cloud technique you want to detect, start by asking yourself the question “What data do I need to be able to fully answer the who, what, where, when, how, and even the why?” Trying to identify, up front, the various pieces of data that are required to effectively detect a given technique will simplify the actual implementation of the detection. Begin discussions with members from various teams that have a stake in cloud security such as developers, security teams, IT, and others. To get started some pieces of information that are almost always relevant are:

1. User information. This could include, but is not limited to, usernames, groups, roles, email addresses, etc
2. IP address information. This could include IPv4 and/or IPv6 addresses as well as any IP enrichment such as geolocation or other metadata around the address.
3. Timestamps
4. User agent strings
5. Resources information. This could include data such as application IDs, resource names, resource metadata, etc.

Focus on the services you use

Each major cloud provider offers 200+ services. It is unreasonable to try and provide full detection coverage of every technique for every service. Make sure to scope down your detection coverage to the services you are actually using. Take the time to understand those services at a deep level. Attempt to identify the threat landscape of that service and discuss plans for how to defend it. Then, discuss how visibility into that service will lead to detecting threats.

Cut down on the noise

Sometimes coming up with the detector idea is the easy part and tuning the detector to reduce the number of false positives is the difficult part. Once a detector concept is created, be sure to first test it in your environment to determine how common the event is. If it turns out the event occurs frequently then extra filtering will need to be applied to the detector in order to make it usable by a security team. These extra filters can be created in a number of different ways.

1. Use more of the existing data you already have. For example, in Azure you might have an allow list or block list of Application IDs that could help narrow down a detector idea.
2. Enrich your data. Most audit logs for the cloud will have an IP address. If you can enrich the IP address to include information such as whether or not the IP is a Tor node, VPN, or is otherwise suspicious, that can help filter down the results and reduce the noise.
3. Correlate data. Sometimes bringing together multiple pieces of data to create a new data field can help better target a detector idea.

Verify your hypothesis

Spend time simulating and testing your detection capabilities. Make sure that this happens regularly. It should be easily repeatable. It is not uncommon to come up with a detector idea, put it into production and then never see it trigger due to the underlying assumptions being incorrect. Despite our best efforts to understand the data and what actions will generate that data, the only way to truly know if your detector works or not is to simulate the behavior, capture the data, and analyze it with your detector logic. See the section below on some guidance on how to get started simulating various attack scenarios.