Cloud computing attack vectors and countermeasures: Protecting your infrastructure in 2026

When it comes to cloud threats, criminals have been abiding by a familiar adage: Follow the money. As enterprises digitally transform and migrate operations to the cloud, the number of appealing targets tucked away in data centers steadily climbs. Understanding cloud computing attack vectors — the pathways threat actors use to compromise cloud environments — is essential for building effective defenses.  

Recognizing the monetary value of successfully breaching these architectures, both cybercriminal organizations and lone wolves have been adjusting their tactics accordingly. 

To help you stay a step ahead, here are some examples of recent attacks, the methods hackers are using and ways to safeguard your cloud environments. 

Editor’s note: Are you relatively new to cloud infrastructure design? Infosec Institute’s free AWS workshop: Build and Deploy Your First Cloud Infrastructure is a great, hands-on starting point. 

View Free Course

Why cloud computing attack vectors have been expanding 

When cloud computing first took off, much of it involved relatively simple architectures, such as cloud-hosted virtual machines and desktops. Cloud providers could safeguard these relatively easily because, as long as the code was secure and there were adequate firewalls in place, there weren’t that many points of entry for attackers to exploit. 

But times have changed. In 2026, organizations utilize complex, distributed cloud systems comprising a mix of containerized and serverless functions. There are also several cloud migration security risks associated with companies shifting on-premises processes to the cloud. Additionally, it’s common for an organization to utilize a multi-cloud setup, such as a public cloud for development and a private cloud for highly sensitive internal data. Each of these components presents a new attack vector. 

Another factor that has been ballooning the attack landscape is the complex supply chain involved in building cloud-native apps and automations. Developers have to source images, APIs, libraries and a range of other pre-built components to build cloud systems that meet time-sensitive customer demands. Knowing this, threat actors execute a range of cloud supply chain attacks that focus on infiltrating the supply chain and creating dangerous vulnerabilities. 

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Recent cloud computing attacks 

Even though there are successful attacks occurring all the time, some have earned more attention than others, primarily because they impacted respected brands, including those that have already been using some form of cloud data protection for many years. 

Capital One 

The Capital One attack occurred in 2019, but its implications persist in 2025, as hackers continue to employ the same methods. Capital One utilized Amazon Web Services (AWS) for its cloud-native computing needs. In AWS, organizations can manipulate virtual servers called Amazon Elastic Compute Cloud (EC2). In the Capital One attack, one of the most significant cloud breach attack vectors was a misconfigured firewall that enabled a hacker to access EC2 metadata. Cloud misconfiguration vulnerabilities, like this, are relatively easy targets for attackers because they lower defenses against attack methods that exploit weak points. 

Using their stolen data, the attacker assumed an identity and access management role that permitted them to exfiltrate data from Amazon Simple Storage Service (S3) buckets. It would be like someone gaining access to your login credentials for your laptop and then stealing information from your hard drive. 

Uber 

The Uber breach in September 2022 is one of the most infamous cloud computing attacks, not because of any material damage, but because of the ease with which the attacker penetrated the ride-hailing company’s defenses. The attacker, who claimed to be only 18 years old, exploited a phenomenon known as multi-factor authentication (MFA) fatigue. This occurs when an attacker sends numerous MFA requests until the victim becomes tired of receiving the notifications and simply approves one. 

It appears that the attacker may have been using the hack to inflate their resume, possibly to impress other hackers or qualify for lucrative hacking opportunities in the future. After obtaining the employee’s login information, they gained access to internal communication systems, source code repositories and other engineering systems. They then sent some of the stolen information to news outlets and security researchers — two audiences that are likely to spread news of the attack to the rest of the world. 

LastPass 

The LastPass breach in 2022 featured one of the most common cloud attacks: username and password theft. LastPass provides password management services, so a successful breach could have given the hacker credentials that could have been used in other cloud infrastructure attacks, as well as for identity and account theft. 

Fortunately, the attack was only somewhat successful. The criminal was able to use social engineering to steal an engineer’s credentials and then the secret source code used to build LastPass’s solutions. 

Although the attacker successfully penetrated that region of LastPass's infrastructure, they weren't able to access the plaintext usernames and passwords of the company's customers because they were protected with strong encryption. While this was a relatively unsuccessful cloud attack from an identity theft perspective, it demonstrated how easily an attacker can gain access to other sensitive information through a combination of social engineering and cloud infrastructure vulnerabilities.

Common cloud-native threats and how to mitigate them 

Here, we will identify common cloud-native threats and cloud computing attack vectors, classifying them according to the OWASP Top Ten, and provide options for mitigating or preventing them.  

In addition to the mitigation tips described below, a good way to identify vulnerabilities, regardless of the types of threats you’re trying to avoid, is to employ cloud penetration testing techniques, whether you use an external provider or in-house personnel. 

Identity and access-based attacks 

OWASP Web Application Top 10 classifications: A01:2021 and A07:2021 

These typically consist of: 

• Credential theft cloud: Attackers focus on individual or group user accounts. They can also steal API keys, which may be present in the source code of an organization’s app. 

• Abusing IAM roles: After an attacker steals credentials, they gain persistent access to sensitive areas of the network or resources they want to steal. 

• Privilege escalation: Attackers gain access to a system and then move laterally, accessing a range of user accounts and services. 

How to combat identity and access-based attacks 

To fight these assaults, you should: 

• Never store API keys in publicly accessible source code, such as on an open GitHub account. 

• Encrypt access credentials at rest to prevent an attacker from gaining access to them. As mentioned above, taking this precaution prevented the LastPass breach from exposing customer login information. 

• Strictly enforce policies designed around the principle of least privilege. This can be an effective way to prevent lateral movement through a system because the attacker will quickly hit an account without the privileges the hacker is after. 

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Misconfiguration and resource exploits 

OWASP Cloud-Native Application Security Top 10 (CNAS) classifications: CNAS-1, CNAS-3, CNAS-5, CNAS-6 and CNAS-8 

Misconfiguration and resource-based attacks tend to involve: 

• Targeting misconfigured policies: Sometimes, an organization has relatively weak security policies, inadequate cloud workload protection or loose constraints, and attackers often target these first. For instance, a company may not be using least privilege, so compromising an account can open the door to a broad attack without any privilege escalation being necessary. 

• Insecure storage buckets: In AWS, Azure and Google Cloud Services (GCS), there may be storage buckets that are publicly accessible. 

• Misconfigured network security groups or virtual private clouds (VPCs): This is one of the more popular cloud breach attack vectors because it enables criminals to exploit weak firewalls or VPCs with lax security configurations, exposing many attractive targets. 

How to combat misconfiguration and resource exploits 

Staying a step ahead of attackers who focus on misconfiguration vulnerabilities is pretty straightforward: 

• Regularly audit your security and VPC configurations, viewing them from the perspective of an attacker seeking to either gain access to each area or move laterally. 

• Don’t make any of your storage buckets publicly available. If a previously unauthorized person needs access, a security team member should carefully examine the reasons why and the individual’s identification credentials. 

• Don’t use default VPC configurations. Default VPC configurations may assign public IP addresses to new resources, which increases the risk of exposure. 

• Use network segmentation. Put sensitive resources, like databases and application servers, in private subnets that don’t have direct internet access. 

API attacks 

OWASP Cloud-Native Application Security Top 10 (CNAS) classifications: CNAS-1, CNAS-3, CNAS-5, CNAS-8 and CNAS-9 

There are many ways to use APIs in attacks, but cloud API security threats often involve: 

• Exploitation of overly permissive API access controls: A microservice, for instance, may not shield the access keys for the API it uses, so an attacker who gains access to the microservice’s source code can easily grab the plaintext API. 

• Taking advantage of permissive cloud IAM roles: An organization may grant too many people access to an area that contains the APIs used in its web applications, for instance. Once the attacker steals or self-assigns an IAM role, they can then access all the API keys to which they are entitled. 

How to combat API attacks 

To prevent API attacks, you can: 

• Use your cloud provider’s vault service to store API keys. Some standard tools include AWS Secrets Manager, HashiCorp Vault and Azure Key Vault. With these tools, your API keys are secured and you can still refer to and use them in your programming. 

• Use API gateways. You can think of an API gateway as the main entrance to an apartment building. No entity can perform an API request without presenting credentials and being allowed in the “building.” 

• Regularly generate new API keys. By decommissioning old API keys, you close the door on attackers who’ve stolen them. This is a good practice even if you use a vault service or API gateway. 

• Encrypt APIs while at rest and in transit. You can encrypt the area that stores your APIs using your cloud provider’s protocol. When sending APIs to someone else, ensure that you use Transport Layer Security (TLS) encryption to prevent interception or tampering. 

Container and orchestration attacks 

OWASP Cloud-Native Application Security Top 10 (CNAS) classifications: All CNAS classifications, from 1 to 10 

Container and orchestration attacks encompass a wide range of methods, including both attacks on containers and orchestrations themselves, as well as container orchestration attacks, which involve compromising the automation that controls containers within a system. Some of the most common vectors include: 

• Insecure infrastructure-as-code attacks: A hacker who gains access to your infrastructure-as-code functions can introduce serverless security risks by changing them and altering your system’s behavior. 

• Injection: In an injection attack, a cybercriminal injects their own data into a container, such as by changing a command or cloud event. 

• Continuous integration/continuous delivery (CI/CD) pipeline attacks: This involves an attacker introducing a vulnerability while a container or orchestration is being built. This can happen when the dev team uses a corrupted container image or when the CI/CD pipeline lacks adequate authentication. 

• Attacks using known security flaws: An attacker can penetrate a system by exploiting a known vulnerability, such as one in an outdated container image or an application component that hackers have already compromised. 

• Compute resource attacks: A container may have a relatively low quota, and hackers can exploit this by sending it numerous requests, resulting in a denial-of-service condition that either prevents the app or process from running or significantly slows it down. 

How to combat container and orchestration attacks 

Some of the principles for preventing other attacks, such as using encryption and securely storing API keys, can also prevent container and orchestration attacks, as a container or orchestration component can be compromised using these methods as well. At the same time, here are some additional ways of keeping containers and orchestrations secure: 

• Introduce security early in the development lifecycle. This is sometimes referred to as a “shift-left” strategy, where you check for runtime issues even before completing the build or deployment of a container. 

• Scan all images you use for vulnerabilities. Image scanning should be part of your CI/CD pipeline because it can detect malicious code or vulnerabilities early in the development lifecycle. 

• Only use container images from trusted sources. This means you may have to eliminate the use of images and code from public, open-source repositories. 

• Monitor orchestrations and containers for suspicious behavior. Runtime security tools can continuously monitor container and orchestration behavior, detecting anomalous activity such as unexpected network connections that may indicate container manipulation. 

Platform-specific attack vectors 

While there are many cloud breach attack vectors, some are more specific to certain cloud environments. Keeping the following attack methods top of mind is especially important if you’re trying to shrink your multi-cloud attack surface, which is crucial when using multiple cloud providers. It’s also important to remember that any of the below attacks can be used as elements of more serious digital assaults, such as cloud ransomware attacks. 

AWS 

• Exploiting EC2 metadata, as in the Capital One attack outlined above, to steal IAM role credentials 

• Exploiting open S3 buckets and stealing their data 

• Taking advantage of misconfigured S3 permissions to gain access and exfiltrate data 

• Using existing, over-privileged IAM roles to move abuse an EC2 or Lambda function 

Azure 

• Abusing Azure AD misconfigurations, such as weak multi-factor authentication or stale accounts 

• Taking advantage of publicly exposed storage containers 

• Exploiting misconfigured permissions, such as when a function has the “contributor” role when it doesn’t need to 

• Taking advantage of misconfigured role-based access controls (RBAC) in Azure Kubernetes Service (AKS), such as an API server that’s exposed to the public internet 

Google Cloud (GCP) 

• Targeting GCP service accounts that are over-privileged 

• Exploiting API keys stored insecurely, such as inside source code in GCP 

• Exploiting IAM controls in GCP with overprivileged permissions, such as the “allUsers” designation 

• Taking advantage of weak VPC Service Controls to exfiltrate data 

What are the signs of an attack on your cloud infrastructure? 

Some of the below signs can be easy to dismiss as stemming from another, more innocuous issue, such as a general, non-targeted phishing attack or over-stressed cloud resources. But suppose you notice any of the following red flags. In that case, it’s important to investigate your cloud tools right away, at least to eliminate the possibility of an attack on your infrastructure. 

• Abnormal user or access activity, such as excessive login attempts, changes in permissions or a login from a suspicious IP address 

• Performance issues, such as sudden drops in performance, crashing apps or the excess use of resources 

• Data flow and networking issues, such as spikes in outbound traffic to unknown destinations 

• Inexplicable changes to data, including modified, deleted or copied files 

• Large amounts of data being transferred out of your cloud storage 

• Suspicious emails, such as requests for password resets from accounts you haven’t accessed or people in your contacts getting messages that you didn’t send 

• Phishing emails with suspicious links or attachments 

• Unauthorized financial transactions, including activity in your bank accounts or unexpected invoices 

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Start preventing cloud attacks now 

General cloud development hygiene can go a long way towards shrinking your attack surface. Encrypt all sensitive data and adhere to the principle of least privilege when building your cloud infrastructure. Avoid over-permissioning resources, so if an attacker does manage to get inside your system, it’s difficult for them to move east to west. 

To ensure you and your staff have the most up-to-date certifications for cloud computing, check out Infosec Institute’s emerging trends infographic, which outlines the latest certification developments for cloud and other skills. 

Interested in switching careers to focus on defending cloud environments? Infosec’s Cybersecurity certifications and skills roadmap can point you in the right direction.