Mallory Mooney
Amazon Simple Email Service (Amazon SES) is a cloud-based provider for sending transactional, marketing, and newsletter emails. Because of its role as a source of communication for organizations, Amazon SES has become a primary tool for phishing campaigns. Our latest threat roundup includes a key finding that Amazon SES is a common target in the initial stages of a cloud control plane attack. As part of their discovery techniques, attackers use compromised access keys to make GetAccount, ListIdentities, and GetSendQuota API calls to determine the availability of an SES account.
If an attacker finds and accesses an account, they may attempt to use it for phishing campaigns, which can significantly harm the reputation of your organization. Understanding how attackers try to exploit Amazon SES—and what malicious activity within an account looks like—can strengthen your ability to identify and prevent phishing and other email-based attacks before they become serious issues. To help you become more familiar with identifying phishing campaigns in Amazon SES, we’ll look at common configuration risks in Amazon SES as well as signs of phishing activity.
Before we talk about what SES abuse looks like, it’s important to understand how the service can become vulnerable to an attack in the first place. In many cases, simple misconfigurations give attackers enough of an opening to take over the service. In this post, we’ll look at common configuration risks for SES logging, email authentication, and IAM permissions.
Your logs are one of the primary sources of information for monitoring SES activity and identifying signs of phishing campaigns. AWS CloudTrail captures calls from the Amazon SES console and its API, including admin-level operations like creating a new identity. However, there are two data categories that are not logged by default: data events and sending activity.
For Amazon SES, you can configure CloudTrail to also log SendEmail data events. These events include detailed information about the contents of an email sent by the API, such as the recipient, body, and attachments. This data provides a better understanding of your SES account’s sending patterns and email contents, making it a valuable source of information for incident response and audits.
Sending activity, such as the outcomes for a sent email, is also not captured by default, but AWS offers several configuration options based on the level of detail you need to monitor. Without this information, you miss critical insights into email performance and engagement, such as bounces, complaints, and delivery status. For example, you may want to configure an Amazon Simple Notification Service (Amazon SNS) topic that notifies you when recipients mark email as spam. This real-time feedback on SES activity can help you surface potential phishing operations more efficiently.
It’s important to note that there are additional costs associated with logging data events and publishing email events. Refer to AWS documentation for more information about managing costs.
Amazon SES does not provide any email authentication by default, making it easier for unsuspecting users to fall victim to phishing attempts disguised as legitimate emails. Authentication also affects your SES account’s sender reputation. AWS recommends enabling authentication for your SES account by using the DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) security and validation standards. DKIM and SPF ensure that emails come from an authorized sender. Protocols like Domain-based Message Authentication, Reporting, and Conformance (DMARC) use these standards to surface spoofing and phishing activity from your SES account.
Overly permissive IAM policies are common misconfigurations in cloud environments, and they can weaken the security of your Amazon SES accounts. For example, a user with the ses:* permission has the ability to perform all SES actions. If the user’s account is compromised, an attacker can take advantage of those permissions to initiate a phishing campaign. Limiting access through IAM policies can restrict which SES API calls a user, group, or role can execute, including the SendEmail action. You can also limit which addresses a particular user can send emails from.
Depending on the size of your customer base, your applications may generate large volumes of emails at any given time, so detecting phishing attacks can be challenging without the right data. AWS offers several options for monitoring SES activity and performance, but we’ll focus on specific reputation metrics and events that can serve as a starting point for distinguishing malicious SES activity from legitimate SES activity.
Send events give you insight into any anomalies in your SES account. This information is valuable for detecting when an attacker launches a phishing campaign within your environment. As an example, let’s say your support system typically sends around 2,000 confirmation emails per day, but you discover that over 8,000 emails were sent in a short period of time. The sudden, significant change in the volume of sent emails, as seen in the following Datadog threshold monitor example, is worth investigating.
In addition to tracking email volume, you can also monitor the status of your emails via bounce and complaint rate reputation metrics. The bounce rate measures the percentage of emails sent from your Amazon SES account that generated a hard bounce, which is the result of a persistent email delivery issue. The complaint rate is the percentage of sent emails that recipients marked as spam. Using our previous example, let’s say your support system’s send volume looks typical, but you find that your sending account’s complaint rate tripled overnight. If the complaint rate is typically low, you should look into whether your account has suddenly started sending different types of emails. You can review this information via CloudTrail logs that capture SendEmail data events.
To avoid having AWS place your account under review, AWS recommends that you maintain a bounce rate below 5% and a complaint rate below 0.1% of the total email volume that represents your account’s typical sending practices.
In many cases, you can trace phishing activity back to common misconfigurations in cloud environments. Datadog researchers recently discovered Amazon SES enumeration attempts that were the result of an exposed long-term access key associated with an IAM user, as seen in the following Datadog Cloud SIEM signal example:
Enumeration attempts allow attackers to systematically probe a target for availability or information and often serve as a starting point for phishing campaigns. To confirm that the compromised user account has access to SES, you can monitor for specific account changes, such as VerifyEmailIdentity, CreateEmailIdentity, DeleteIdentity, and DeleteEmailIdentity API calls. You can review all of these actions in CloudTrail logs, as seen in the following example Datadog log:
After an attacker has access to an SES account, they often launch their phishing campaigns from newly created and verified accounts and then promptly delete them to avoid detection.
In this post, we looked at common configuration risks that can lead to an attacker taking advantage of your Amazon SES accounts, as well as signs of phishing activity. To get started protecting your accounts, you can monitor key Amazon SES metrics like aws.ses.send and aws.ses.reputation_complaint_rate from your Datadog dashboards when you enable the integration. Datadog Cloud SIEM’s built-in detection rules help you catch user and Amazon SES account changes that may indicate abuse. You can then correlate this activity with other AWS events—such as newly created IAM users, security groups, or credentials—for clearer visibility into an attacker’s full attack path.
If you don’t already have a Datadog account, you can sign up for a free 14-day trial.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。