AWS SES Account Email Sending Enabled

Detects when account-level email sending is explicitly enabled in Amazon SES, via the v1 UpdateAccountSendingEnabled API with Enabled: true or the v2 PutAccountSendingAttributes API with SendingEnabled: true. Account-level sending is commonly paused by an administrator, or by automation wired to CloudWatch reputation alarms when bounce or complaint rates rise. An attacker who compromises an AWS account may re-enable sending to restore a paused capability as part of phishing infrastructure setup, allowing bulk email under the victim organization's trusted sending domain. Neither API can resume sending that AWS itself has paused.

Rule type: query
Rule indices:

  • logs-aws.cloudtrail-*

Rule Severity: medium
Risk Score: 47
Runs every:
Searches indices from: now-6m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Cloud
  • Platform: AWS
  • Data Source: AWS CloudTrail
  • Service: AWS SES
  • Rule Type: Custom Query (KQL)
  • Tactic: Resource Development
  • Resources: Investigation Guide

Version: 1
Rule authors:

  • Elastic

Rule license: Elastic License v2
The AWS integration must be ingesting management events into logs-aws.cloudtrail-*. No additional data event selectors are required — ses:UpdateAccountSendingEnabled and ses:PutAccountSendingAttributes are management-plane APIs logged by default.

ses:UpdateAccountSendingEnabled (v1) and ses:PutAccountSendingAttributes (v2) both control whether the entire AWS account can send email in the current region, and both log under event.provider ses.amazonaws.com, so a caller can reach the same outcome through either API version. Enabling account-level sending is a one-step action that lifts a pause set by an administrator or by CloudWatch-driven automation. Per the v2 documentation neither API can resume sending that AWS has paused, so this is not a path out of an AWS enforcement action. In normal operations these APIs are rarely called. An attacker with SES permissions may call either one to restore paused sending capability, or to enable sending in a region where it was not previously active.

  • Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether this is a known SES administrator or an anomalous identity.
  • Verify whether account-level sending was previously disabled (ses:GetAccountSendingEnabled in v1, or ses:GetAccount returning SendingEnabled false in v2) and cross-reference prior CloudTrail events for both APIs.
  • Query CloudTrail for co-occurring events from the same identity: IAM privilege escalation (AttachUserPolicy, AttachRolePolicy), SES identity creation (VerifyEmailIdentity, CreateEmailIdentity), or SES template/suppression-list manipulation.
  • Check the account's SES sending statistics for any unusual spike in sent email volume following this event.
  • Determine whether this corresponds to a legitimate remediation of a bounce/complaint rate issue with a change management ticket.
  • Legitimate SES operations teams re-enabling sending after a planned suspension will trigger this rule. These events are rare; validate against change records.
  • If unauthorized, disable account-level sending immediately via ses:UpdateAccountSendingEnabled with Enabled: false, or ses:PutAccountSendingAttributes with SendingEnabled: false.
  • Revoke active sessions for the calling identity.
  • Review SES send statistics for unauthorized email activity during the enabled window.
  • Check all SES email identities and sending authorization policies for unauthorized entries.
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "ses.amazonaws.com"
    and event.action: ("UpdateAccountSendingEnabled" or "PutAccountSendingAttributes")
    and event.outcome: "success"
    and aws.cloudtrail.request_parameters: (*enabled=true* or *Enabled=true*)
    and not user_agent.original: (*Terraform* or *terraform* or *Pulumi* or *pulumi* or *Ansible* or "batch.amazonaws.com" or "cloudformation.amazonaws.com")

Framework: MITRE ATT&CK