AWS SES Account Email Sending Enabled
editAWS SES Account Email Sending Enabled
editDetects 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-*
Severity: medium
Risk score: 47
Runs every: 5m
Searches indices from: now-6m (Date Math format, see also Additional look-back time)
Maximum alerts per execution: 100
References:
- https://docs.aws.amazon.com/ses/latest/APIReference/API_UpdateAccountSendingEnabled.html
- https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutAccountSendingAttributes.html
- https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/
- https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/
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
Investigation guide
editTriage and analysis
Investigating AWS SES Account Email Sending Enabled
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.
Possible investigation steps
- 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.
False positive analysis
- Legitimate SES operations teams re-enabling sending after a planned suspension will trigger this rule. These events are rare; validate against change records.
Response and remediation
- 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.
Setup
editThe 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.
Rule query
editdata_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&CKTM
-
Tactic:
- Name: Resource Development
- ID: TA0042
- Reference URL: https://attack.mitre.org/tactics/TA0042/
-
Technique:
- Name: Stage Capabilities
- ID: T1608
- Reference URL: https://attack.mitre.org/techniques/T1608/