[New Rule] AWS SES Identity Verified Then Deleted

[bryans3c]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/1066

Summary - What I changed

Added an eql sequence rule that detects an SES email identity verified and then deleted by the same AWS identity within one hour — the verify-use-delete pattern used by adversaries to send phishing email from a victim account's SES capacity and then remove evidence of the sending domain.

Why it matters

Amazon SES requires email addresses and domains to be verified before use as senders. An adversary who obtains SES write credentials can verify a domain they control, send bulk phishing email under the victim organization's SES reputation and sending quota, then delete the identity to remove it from ListIdentities output — making post-incident attribution harder. The verify-then-delete sequence within a short window is a recognized attacker technique documented in SES abuse research, and has no common legitimate equivalent since test cleanup workflows typically operate on sandbox addresses over longer timeframes.

• https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/

How To Test

Query to verify in our TRaDE stack:

sequence by aws.cloudtrail.user_identity.arn with maxspan=1h
  [any where event.provider == "ses.amazonaws.com"
   and event.action in ("VerifyEmailIdentity", "VerifyDomainIdentity", "VerifyEmailAddress", "VerifyDomainDkim")
   and event.outcome == "success"]
  [any where event.provider == "ses.amazonaws.com"
   and event.action == "DeleteIdentity"
   and event.outcome == "success"]

Checklist

• Added a label for the type of pr: Rule: New
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[Copilot]

Pull request overview

Adds a new AWS CloudTrail EQL sequence detection rule to identify a suspicious “verify SES identity → delete identity” pattern within 1 hour by the same AWS principal, aimed at catching SES abuse used for phishing/spam operations and subsequent cleanup.

Changes:

• Introduced a new EQL sequence rule for SES identity verification followed by deletion (maxspan 1h).
• Added investigation guide content, references, tags, and ATT&CK mappings for triage and classification.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[imays11]

Suggested change

	one hour, performed by the same AWS identity. Amazon SES requires email addresses and domains
	30 minutes, performed by the same AWS identity. Amazon SES requires email addresses and domains

[terrancedejesus]

maxspan of 30m is long for EQL. Consider changing to ESQL for performance.

[imays11]

++

[terrancedejesus]

Suggested change

	risk_score = 73
	risk_score = 47

Would reduce here. Its plausible maintenance may be going on in which users are verified and deleted. Less likely, but not inherently malicious.

[terrancedejesus]

Suggested change

	severity = "high"
	severity = "medium"

[terrancedejesus]

LGTM. Agreed on dropping this to medium, verify-then-delete can be maintenance. Also +1 on the 30m maxspan being long for EQL.