Amazon Web Services (AWS) is the most popular cloud provider in the world, with the largest market share of 34%. As of 2022, 94% of enterprises use cloud services, and over 60% of all corporate data is stored in the cloud, making it a prime target for malicious actors.
Attacks against organizations in the cloud are on the rise. The latest “state of cloud” reports highlight the biggest security threats, including misconfiguration and a need for more staff expertise.
Source: Cybersecurity Insiders Cloud Security Report 2022
To help you protect against these threats, we’ve identified the top ten attacker techniques in 2023 and created a collection of labs to help you defend against them.
This collection covers the most common and novel techniques that attackers use to exploit AWS environments in the wild. It demonstrates what the methods are and how they’re often carried out – as well as how cloud security engineers (or anyone who works in a defensive security capacity) can identify and remediate the misconfigurations that lead to these vulnerabilities.
So what are the top ten AWS attacker techniques?
Subdomain takeovers are a common, high-severity threat. Attackers can perform them against a range of cloud services that provision domain names on customers’ behalf. S3 is vulnerable as it provides the feature to host static websites using the bucket name within the domain name. As bucket names are global, this presents attackers with the opportunity to take over your domain.
In September 2021, security Engineer Ian Carroll discovered that over 60,000 subdomains using S3 were vulnerable to takeover due to a misconfiguration by domain registrar MarkMonitor, which serves more than half of the Fortune 100.
Subdomain takeover can lead to reputational damage, as the brand associated with the domain could be used in phishing campaigns or to collect user credentials. Protect your organization’s reputation by taking our latest lab on subdomain takeover using S3.
Lambda is one of the most popular serverless services in the world because of its low cost and ability to scale. As Lambda runs using an execution role, any code vulnerability could allow attackers access to your AWS environment by stealing the credentials Lambda uses when running.
It’s often forgotten that the credentials Lambda uses can outlast the runtime of the function, as temporary credentials created by AWS Security Token Service have a minimum lifetime of 15 minutes. Most Lambda functions complete within that, giving plenty of time for attackers to establish persistence.
The second lab in this collection will demonstrate how to exploit a vulnerable Lambda function and the actions you can take to prevent this from happening in your organization.
AWS’s Simple Queue Service (SQS) and Simple Notification Service (SNS) are commonly used to send data between applications or notify users. Datadog recently revealed that at least 15% of participating organizations using the service have publicly exposed topics or queues.
Malicious actors could subscribe to an unintentionally public SNS topic or pull from an SQS queue to obtain sensitive data, which they could use to attack your organization. As applications use SQS queues, it’s possible for attackers to manipulate your applications by sending malicious payloads.
Try this lab to find out the common misconfigurations that cause public SQS queues and SNS topics and how to prevent them from being created in your organization.
Simplified, IAM:PassRole is a permission that allows a principal to pass a role to an AWS service. It’s useful for enabling AWS services to do things on your behalf. But due to the complexity of IAM and unclear documentation, this permission is often misconfigured.
A misconfigured IAM:PassRole allows attackers to escalate their privileges. There are currently five well-known privilege escalation paths that use IAM:PassRole, but this could increase as AWS releases more services.
Learn how to prevent, detect, and perform privilege escalation using this misconfiguration in this lab.
Elastic Cloud Compute (EC2)’s user data service is a convenient way to run scripts when creating a new instance. Attackers can abuse this feature of EC2 to run malicious scripts at startup. This can allow them to gain a foothold in your AWS environment and, in some cases, escalate their privileges. The EC2 user data tool can also contain vital information about your environment, such as internal services and resource names. Worst case scenario? Attackers could find hardcoded credentials.
This lab will teach you how to exploit the EC2 user data service in an account, and how to detect when it’s being abused in your environment.
Elastic Block Storage (EBS) is the storage behind EC2. To back up data stored on EBS volumes, you can easily create a point-in-time copy known as a snapshot, which can be private or public. As EC2 is one of the most popular compute services in AWS used for anything and everything, the data held on public snapshots can be an attractive target for attackers.
In 2019, the security researcher Ben Morris discovered that hundreds of organizations were exposing thousands of public EBS snapshots. These snapshots revealed source code, personal identifying information, and credentials. Accidentally-exposed snapshots can have significant consequences for your organization, resulting in fines or further breaches.
Check out the lab on public EBS snapshots and learn how to detect and prevent this misconfiguration from happening in your account.
Version 1 of the Instance Metadata Service (IMDSv1) allows EC2 instances to obtain user data, IAM credentials, and other metadata associated with an instance. IMDSv1 is useful for a developer – but it also aids attackers. Malicious actors with access to the service can get valid IAM credentials, which they could use to proceed further down the cyber kill chain.
The most common way to abuse the IMDSv1 is by server-side request forgery (SSRF), which should come as no surprise as it’s in the OWASP Top Ten too. This attack happened to Capital One in 2019. Attackers used SSRF and IMDSv1 to gain credentials that gave them access to the data of 106 million individuals, resulting in a $190 million lawsuit.
Try out this to learn more about IMDSv1 and how to protect yourself against this misconfiguration.
IAM policies can be complicated, so it’s common for organizations to have broad policies that cover a large range of permissions to ease the administrative burden. However, multiple reports have revealed that many IAM policies are overly permissive and 90% go unused.
When a user is compromised, the damage an attacker can do is limited to the affected user’s permissions. The risk here is that the more permissions the user has, the more damage the attacker can do to an organization.
Take on this lab to explore how attackers take advantage of misconfigured, overly-permissive IAM policies to escalate privileges.
S3 is a well-known and popular service, but it can be tricky to configure securely. Between ACLS, IAM permissions, and resource policies, it can be easy for an administrator to make a mistake. Attackers reportedly start accessing the data within a few hours when a bucket name is publicly exposed.
A public S3 bucket can expose a range of sensitive data, including personally identifying information (PII), proprietary technology, and – worst of all – credentials. The consequences can be severe. Not only could you face significant fines, but attackers could also carry out more sophisticated attacks using the data they uncover.
Data breaches due to misconfigured S3 buckets are a common news headline, and big-name companies such as Twilio, Accenture, and Verizon have all been victims.
Try this lab to equip yourself and prevent your organization from becoming the next name in the headlines.
Access keys allow users to access and perform actions on AWS resources, but they need to be stored and accessed securely. 61% of data breaches reportedly result from leaked credentials, costing industries millions. If an access key is revealed and a user’s credentials are exposed, it only takes attackers one minute to find and abuse these credentials leaked to GitHub. From there, they can wreak havoc on an organization.
Don’t be one of those orgs that accidentally leaks credentials; check out our blog on the true cost of Git security and how to avoid committing your keys to git. Then, try out the lab to detect and prevent this attack within your account.
Want to find out more?
The new collection covers each of these misconfigurations in depth. Each lab will provide hands-on practical experience, where you’ll take on the role of an attacker trying to exploit these misconfigurations.
Along the way, you’ll learn about real-life incidents and actions you can take to prevent each misconfiguration from happening in your organization. To access the collection, click here.
