AWS SES Account Email Sending Enabled

  1[metadata]
  2creation_date = "2026/08/24"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2026/08/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects when account-level email sending is explicitly enabled in Amazon SES, via the v1
 11UpdateAccountSendingEnabled API with Enabled: true or the v2 PutAccountSendingAttributes API with
 12SendingEnabled: true. Account-level sending is commonly paused by an administrator, or by automation
 13wired to CloudWatch reputation alarms when bounce or complaint rates rise. An attacker who
 14compromises an AWS account may re-enable sending to restore a paused capability as part of phishing
 15infrastructure setup, allowing bulk email under the victim organization's trusted sending domain.
 16Neither API can resume sending that AWS itself has paused.
 17"""
 18false_positives = [
 19    """
 20    SES account sending may be legitimately re-enabled by an administrator after a sending pause
 21    for bounce/complaint rate investigation or maintenance. Validate against a change management
 22    record or scheduled maintenance window. This API is rarely called in normal operations.
 23    """,
 24]
 25from = "now-6m"
 26index = ["logs-aws.cloudtrail-*"]
 27language = "kuery"
 28license = "Elastic License v2"
 29name = "AWS SES Account Email Sending Enabled"
 30note = """## Triage and analysis
 31
 32### Investigating AWS SES Account Email Sending Enabled
 33
 34ses: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.
 35
 36### Possible investigation steps
 37
 38- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether this is a known SES administrator or an anomalous identity.
 39- 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.
 40- 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.
 41- Check the account's SES sending statistics for any unusual spike in sent email volume following this event.
 42- Determine whether this corresponds to a legitimate remediation of a bounce/complaint rate issue with a change management ticket.
 43
 44### False positive analysis
 45
 46- Legitimate SES operations teams re-enabling sending after a planned suspension will trigger this rule. These events are rare; validate against change records.
 47
 48### Response and remediation
 49
 50- If unauthorized, disable account-level sending immediately via ses:UpdateAccountSendingEnabled with Enabled: false, or ses:PutAccountSendingAttributes with SendingEnabled: false.
 51- Revoke active sessions for the calling identity.
 52- Review SES send statistics for unauthorized email activity during the enabled window.
 53- Check all SES email identities and sending authorization policies for unauthorized entries.
 54"""
 55references = [
 56    "https://docs.aws.amazon.com/ses/latest/APIReference/API_UpdateAccountSendingEnabled.html",
 57    "https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutAccountSendingAttributes.html",
 58    "https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/",
 59    "https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns/",
 60]
 61risk_score = 47
 62rule_id = "e3f4a5b6-c7d8-9012-cdef-34567890abcd"
 63setup = "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."
 64severity = "medium"
 65tags = [
 66    "Domain: Cloud",
 67    "Platform: AWS",
 68    "Data Source: AWS CloudTrail",
 69    "Service: AWS SES",
 70    "Rule Type: Custom Query (KQL)",
 71    "Tactic: Resource Development",
 72    "Resources: Investigation Guide",
 73]
 74timestamp_override = "event.ingested"
 75type = "query"
 76
 77query = '''
 78data_stream.dataset: "aws.cloudtrail"
 79    and event.provider: "ses.amazonaws.com"
 80    and event.action: ("UpdateAccountSendingEnabled" or "PutAccountSendingAttributes")
 81    and event.outcome: "success"
 82    and aws.cloudtrail.request_parameters: (*enabled=true* or *Enabled=true*)
 83    and not user_agent.original: (*Terraform* or *terraform* or *Pulumi* or *pulumi* or *Ansible* or "batch.amazonaws.com" or "cloudformation.amazonaws.com")
 84'''
 85
 86
 87[[rule.threat]]
 88framework = "MITRE ATT&CK"
 89[[rule.threat.technique]]
 90id = "T1608"
 91name = "Stage Capabilities"
 92reference = "https://attack.mitre.org/techniques/T1608/"
 93
 94
 95[rule.threat.tactic]
 96id = "TA0042"
 97name = "Resource Development"
 98reference = "https://attack.mitre.org/tactics/TA0042/"
 99
100[rule.investigation_fields]
101field_names = [
102    "@timestamp",
103    "aws.cloudtrail.user_identity.arn",
104    "aws.cloudtrail.user_identity.type",
105    "aws.cloudtrail.user_identity.access_key_id",
106    "user.name",
107    "event.action",
108    "event.outcome",
109    "aws.cloudtrail.request_parameters",
110    "source.ip",
111    "cloud.region",
112    "cloud.account.id",
113]