Hardening Your Cloud Against SMTP Abuse

April 05, 2021

| | Cloud & Application Security
Compromises of cloud accounts have been a hot topic in the security industry lately, but the common themes we are seeing, such as compute-resource cryptomining and storage bucket data theft, are not the only threats out there. There are underground markets where access to previously compromised accounts of cloud customers (such as through AWS, GCP, Azure, etc.) is being sold and the buyer could use them for spamming and phishing, among other attacks. CrowdStrike has a lot of data, and some of that data includes information from many underground hacking and fraud communities. Threat intelligence indicates that customer credentials to cloud providers are being sold, and occasionally come with some sort of guaranteed access. These credentials may provide access to a large storage bucket for data theft, a larger-than-default compute limit for launching cryptomining or other attacks, or, as we will discuss in this post, a high daily quota for outbound SMTP mail. The information and techniques described here apply to any cloud provider that offers an email service, but we will focus on AWS for this post. It’s important to note the Shared Responsibility Model provided by AWS before diving into this topic, in that everything discussed in this post falls under the user’s responsibility, not AWS’s. AWS is largely doing everything it can to prevent these types of attacks, but you need to be sure to take care of your own responsibilities in order to prevent this type of malicious activity, which we will discuss below.

SMTP in AWS

AWS offers a few different services for communicating with end users of your applications, such as Simple Email Service (SES) for emails, Pinpoint for SMS/push notifications and other options.

The Sandbox

When a new AWS account begins using any of these services, they are placed in what’s known as a sandbox environment, where additional restrictions are applied to prevent fraud and abuse. According to AWS documentation, the following restrictions apply:
  1. Mail can only be sent to verified identities
  2. Maximum of 200 sent messages per 24 hours
  3. Maximum of 1 sent message per second
Essentially, these restrictions are saying that you can send a small amount of emails to verified identities, and no one else. Verified identities are email addresses or domains that have been registered and confirmed in your AWS account, so it is basically restricting your sender list to yourself or your own organization. To get out of the SES sandbox, you must manually submit a request to AWS, which will be reviewed and responded to in approximately 24 hours. This is to prevent abuse of the service. In theory, if an attacker were to gain access to your account and it was still in the SES sandbox, they would not be able to abuse their access for fraudulent emails originating from your own email/domains.

Outside the Sandbox

Knowing that the blast radius of compromised credentials that belong to an account that is still in the SES sandbox is a little smaller, now imagine that you have a valid business need for SES and you request to be removed from the sandbox. As an example, you may be granted something like 50,000 daily messages and up to 150 messages per second. This is typical for a newly approved account with a valid use case. Now that your limit has increased, so has the underground value of access to your account if it were compromised and sold, due to the greatly increased blast radius of an attacker gaining access to your environment.

The Underground Trade

AWS accounts that are outside of the SES sandbox are valuable to criminals that are looking to perform mass spam campaigns or large-scale phishing attacks — this is why there is demand for them. When purchased, they will attempt to launch their campaign as soon as possible and get as much out there as they can, before Amazon catches on and bans the AWS account for malicious activity with SES. Going back to our account with 50,000 daily messages and 150 messages per second, a compromise might mean our account gets put up for trade.

Impact

The impact of credentials belonging to your account being sold can be catastrophic. There is a wide range of damage that can result from mass spamming/phishing by an attacker, including but not limited to:
  • Email-related services paused by AWS (such as SES, SNS, Pinpoint, etc.)
  • Full account shutdown by AWS
  • Damage to your company domain’s reputation
  • Large-scale blocking of your domain by email spam services
  • Large costs charged to your AWS account
All of these scenarios could spell disaster for a company of any size, but they are all due to necessary processes that defend against malicious activity like this.

 

Defenses

Let’s say you’re out of the SES sandbox and have high limits for your email sending. How can you best protect yourself against these criminals? The answer is both through preventing compromise and limiting blast radius in the event of compromise. “Preventing compromise” of an AWS account is a massive topic, so we’ll refer you to existing documentation by AWS on IAM best practices, while we focus on limiting what happens after the credentials have been breached.

Limiting Blast Radius

No one is immune to breaches, so the best thing we can do is ensure we have proper detections in place and limit the blast radius of any compromise to our environment. Here are a few things to consider when architecting your AWS environment in a secure manner.
  1. Understand the responsibilities you have on your side of the Shared Responsibility Model.
  2. Isolate workloads/projects/environments into separate AWS accounts through the use of AWS Organizations.
  3. Follow the principle of least privilege when delegating access to your environment.
  4. Utilize SES Sending Authorization Policies to ensure layered security on your email-sending identities.
  5. Consider verifying specific email addresses instead of entire domains through SES.
  6. Configure bounce, complaint and delivery notifications through SNS to be notified of potentially suspicious activity.
  7. Monitor for API calls to ses:GetSendQuota across multiple regions through CloudTrail, which may indicate an attacker is trying to identify a region that has been lifted from the SES sandbox. This has been seen in the wild, with one such case documented here.

     

  8. Monitor your SES sender reputation to ensure it is not damaged.
  9. Set up infrastructure to automatically pause email sending under certain conditions.

     

  10. Monitor the criminal underground for your AWS credentials for sale. CrowdStrike Falcon® Intelligence Recon™ was specifically designed to expose digital risk within underground markets and restricted websites.

     

These tips can help you get started in limiting the blast radius of an attacker in your environment, but they are no means all you need to take care of. Security is an ongoing process, and you should never be complacent. Threat actors are constantly evolving their techniques to account for the changing landscape in the industry. This means we cannot just rely on public breach-related data to determine what is going on in the wild — instead, we need to account for all sources of intelligence to correctly identify and monitor emerging threats.

 

Additional Resources
Breaches Stop Here
Related Content
Shift Left, Measure Right: Assessing the Efficacy of Application Security in the Age of CI/CD
Shift Left, Measure Right: Assessing the Efficacy of Application Security in the Age of CI/CD
CrowdStrike Falcon Platform Supports Google Cloud's ARM-Based Axion CPUs
CrowdStrike Falcon Platform Supports Google Cloud's ARM-Based Axion CPUs
CrowdStrike Research Challenges Containerized Application Predictability Assumptions
CrowdStrike Research Challenges Containerized Application Predictability Assumptions