AWS SES Full Access Policy Attached to IAM Entity by Unusual User

Description

Detects the first occurrence in 7 days of an AWS identity attaching the managed policy AmazonSESFullAccess to an IAM user, role, or group. AmazonSESFullAccess grants unrestricted permission to send email, manage identities and templates, manage suppression lists, and access SES account-level settings. Granting this policy to an unexpected IAM entity, particularly a newly created user or a role not previously associated with email operations, is a documented technique used by threat actors to establish phishing infrastructure on compromised AWS accounts, enabling them to send email on behalf of the victim organization's trusted sending domain. Using new terms on the calling identity suppresses recurring attachments by known email automation while surfacing identities performing this action for the first time.

Query · kuery

data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: ("AttachUserPolicy" or "AttachRolePolicy" or "AttachGroupPolicy")
    and event.outcome: "success"
    and aws.cloudtrail.flattened.request_parameters.policyArn: "arn:aws:iam::aws:policy/AmazonSESFullAccess"

Investigation fields

Pivot points the source recommends for triage.

  • @timestamp
  • aws.cloudtrail.user_identity.arn
  • aws.cloudtrail.user_identity.type
  • aws.cloudtrail.user_identity.access_key_id
  • user.name
  • user.target.name
  • event.action
  • event.outcome
  • aws.cloudtrail.request_parameters
  • source.ip
  • cloud.region
  • cloud.account.id

Implementation guide

The AWS integration must be ingesting management events into logs-aws.cloudtrail-*. No additional data event selectors are required — iam:AttachUserPolicy, iam:AttachRolePolicy, and iam:AttachGroupPolicy are management-plane APIs logged by default.

Known false positives

  • Legitimate email service automation may attach AmazonSESFullAccess to a service account. Validate the target IAM entity against known email automation roles and CI/CD pipeline identities. Because this is a new terms rule keyed on the calling identity, recurring attachments by the same automation will not re-alert within the 7-day history window; first-time attachments by administrators performing legitimate setup may still trigger and should be validated against change management records.

Analyst notes

Investigating AWS SES Full Access Policy Attached to IAM Entity by Unusual User

AWS Simple Email Service (SES) is a cost-effective bulk email platform with a reputation built on a customer's verified sending domains. Threat actors who compromise an AWS account often establish phishing infrastructure by granting SES access to a new or existing IAM identity and then using that identity's credentials to send phishing emails under the victim organization's trusted domain. Attaching the managed policy AmazonSESFullAccess is the simplest way to grant the full range of SES capabilities (send, manage identities, manage suppression lists, configure sending settings).

This is a new terms rule that alerts only when the calling identity (aws.cloudtrail.user_identity.arn) has not attached this policy within the previous 7 days, prioritizing anomalous or first-time activity over recurring automation.

Possible investigation steps

  • Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether the caller is a legitimate administrator or an anomalous identity.
  • Identify the target IAM entity in user.target.name and aws.cloudtrail.flattened.request_parameters.userName (or groupName or roleName). Is this a known email automation account, or an entity created recently?
  • Query CloudTrail for all SES API calls (event.provider: ses.amazonaws.com) from the target entity in the time window after this attachment. Look for SendEmail, SendRawEmail, VerifyEmailIdentity, SetIdentityMailFromDomain, or UpdateAccountSendingEnabled.
  • Review whether the attachment corresponds to a legitimate change management process. Check for a corresponding IAM change window ticket.
  • Verify whether SES sending is enabled for the account (ses:GetAccountSendingEnabled) and whether there are existing or recently created SES identities.

False positive analysis

  • Legitimate email automation services (transactional email, notification services) may attach AmazonSESFullAccess. Confirm the target entity is a known service role.
  • CI/CD pipelines that manage email notification infrastructure may attach this policy. Validate via pipeline execution logs and source IP.

Response and remediation

  • If unauthorized, immediately detach AmazonSESFullAccess from the target entity and review all SES calls made under that identity.
  • Review SES account sending status and disable sending if any unauthorized email was sent.
  • Check SES suppression list for any unauthorized modifications (attackers may add or remove entries to influence deliverability).
  • Rotate all credentials associated with both the calling identity and the target entity.
  • Enable SES event publishing to review any emails sent during the unauthorized period.
Raw source AWS SES Full Access Policy Attached to IAM Entity by Unusual User · Elastic TOML
Esc
Published by elastic/detection-rules ↗, licensed under Elastic License 2.0 ↗. Reproduced here unmodified. 
[metadata]
creation_date = "2026/08/31"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/31"

[rule]
author = ["Elastic"]
description = """
Detects the first occurrence in 7 days of an AWS identity attaching the managed policy
AmazonSESFullAccess to an IAM user, role, or group. AmazonSESFullAccess grants unrestricted
permission to send email, manage identities and templates, manage suppression lists, and access
SES account-level settings. Granting this policy to an unexpected IAM entity, particularly a newly
created user or a role not previously associated with email operations, is a documented technique
used by threat actors to establish phishing infrastructure on compromised AWS accounts, enabling
them to send email on behalf of the victim organization's trusted sending domain. Using new terms
on the calling identity suppresses recurring attachments by known email automation while
surfacing identities performing this action for the first time.
"""
false_positives = [
    """
    Legitimate email service automation may attach AmazonSESFullAccess to a service account.
    Validate the target IAM entity against known email automation roles and CI/CD pipeline identities.
    Because this is a new terms rule keyed on the calling identity, recurring attachments by the
    same automation will not re-alert within the 7-day history window; first-time attachments by
    administrators performing legitimate setup may still trigger and should be validated against
    change management records.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS SES Full Access Policy Attached to IAM Entity by Unusual User"
note = """## Triage and analysis

### Investigating AWS SES Full Access Policy Attached to IAM Entity by Unusual User

AWS Simple Email Service (SES) is a cost-effective bulk email platform with a reputation built on a customer's verified sending domains. Threat actors who compromise an AWS account often establish phishing infrastructure by granting SES access to a new or existing IAM identity and then using that identity's credentials to send phishing emails under the victim organization's trusted domain. Attaching the managed policy `AmazonSESFullAccess` is the simplest way to grant the full range of SES capabilities (send, manage identities, manage suppression lists, configure sending settings).

This is a new terms rule that alerts only when the calling identity (`aws.cloudtrail.user_identity.arn`) has not attached this policy within the previous 7 days, prioritizing anomalous or first-time activity over recurring automation.

### Possible investigation steps

- Identify the caller in `aws.cloudtrail.user_identity.arn` and `user.name`. Determine whether the caller is a legitimate administrator or an anomalous identity.
- Identify the target IAM entity in `user.target.name` and `aws.cloudtrail.flattened.request_parameters.userName` (or `groupName` or `roleName`). Is this a known email automation account, or an entity created recently?
- Query CloudTrail for all SES API calls (`event.provider: ses.amazonaws.com`) from the target entity in the time window after this attachment. Look for `SendEmail`, `SendRawEmail`, `VerifyEmailIdentity`, `SetIdentityMailFromDomain`, or `UpdateAccountSendingEnabled`.
- Review whether the attachment corresponds to a legitimate change management process. Check for a corresponding IAM change window ticket.
- Verify whether SES sending is enabled for the account (`ses:GetAccountSendingEnabled`) and whether there are existing or recently created SES identities.

### False positive analysis

- Legitimate email automation services (transactional email, notification services) may attach AmazonSESFullAccess. Confirm the target entity is a known service role.
- CI/CD pipelines that manage email notification infrastructure may attach this policy. Validate via pipeline execution logs and source IP.

### Response and remediation

- If unauthorized, immediately detach AmazonSESFullAccess from the target entity and review all SES calls made under that identity.
- Review SES account sending status and disable sending if any unauthorized email was sent.
- Check SES suppression list for any unauthorized modifications (attackers may add or remove entries to influence deliverability).
- Rotate all credentials associated with both the calling identity and the target entity.
- Enable SES event publishing to review any emails sent during the unauthorized period.
"""
references = [
    "https://docs.aws.amazon.com/ses/latest/dg/control-user-access.html"
]
risk_score = 47
rule_id = "d2e3f4a5-b6c7-8901-bcde-f23456789012"
setup = "The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional data event selectors are required — `iam:AttachUserPolicy`, `iam:AttachRolePolicy`, and `iam:AttachGroupPolicy` are management-plane APIs logged by default."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Service: AWS IAM",
    "Service: AWS SES",
    "Rule Type: New Terms",
    "Tactic: Persistence",
    "Tactic: Resource Development",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: ("AttachUserPolicy" or "AttachRolePolicy" or "AttachGroupPolicy")
    and event.outcome: "success"
    and aws.cloudtrail.flattened.request_parameters.policyArn: "arn:aws:iam::aws:policy/AmazonSESFullAccess"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"


[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1608"
name = "Stage Capabilities"
reference = "https://attack.mitre.org/techniques/T1608/"


[rule.threat.tactic]
id = "TA0042"
name = "Resource Development"
reference = "https://attack.mitre.org/tactics/TA0042/"

[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "user.name",
    "user.target.name",
    "event.action",
    "event.outcome",
    "aws.cloudtrail.request_parameters",
    "source.ip",
    "cloud.region",
    "cloud.account.id",
]

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.