SES‑Abuse Detection Playbook



SES‑Abuse Detection Playbook
(Enterprise SOC Edition)

Focus: Amazon SES abuse using stolen IAM keys to send fully authenticated phishing that bypasses SPF/DKIM/DMARC.


1. Log Sources Required (High‑Fidelity Detection)

AWS Logs

  • CloudTrail

    • SendEmail, SendRawEmail

    • CreateEmailIdentity, VerifyEmailIdentity

    • GetSendStatistics, GetSendQuota

    • ListIdentities, DeleteIdentity

    • GetCallerIdentity (first action attackers run)

  • IAM Access Analyzer

    • External access findings

  • VPC Flow Logs

    • Outbound SMTP/HTTPS anomalies

  • GuardDuty

    • IAM credential exfiltration

    • Anomalous API usage

Email Security Logs

  • Message trace (Exchange Online / M365)

  • Header analysis

  • URL rewrite logs

  • Transport rule hits

Threat Intel / Enrichment

  • Domain age (WHOIS)

  • SES IP reputation

  • URL redirect chain analysis


2. High‑Value SIEM Queries (KQL Examples)

These are tuned for Microsoft Sentinel but easily portable.

A. SES API calls from unusual IPs

AWSCloudTrail
| where EventName in ("SendEmail","SendRawEmail","CreateEmailIdentity","VerifyEmailIdentity")
| where not(SourceIpAddress in ("your-approved-CIDRs"))
| project TimeGenerated, UserIdentityArn, EventName, SourceIpAddress, AWSRegion

B. SES activity from newly created IAM users

AWSCloudTrail
| where EventName in ("SendEmail","SendRawEmail")
| join kind=inner (
    AWSCloudTrail
    | where EventName == "CreateUser"
    | project UserIdentityArn, UserCreationTime = TimeGenerated
) on UserIdentityArn
| where TimeGenerated < UserCreationTime + 1h

C. SES sending spikes (possible compromised key)

AWSCloudTrail
| where EventName == "SendEmail"
| summarize count() by bin(TimeGenerated, 5m), UserIdentityArn
| where count_ > 50

D. Inbound email with SES headers + suspicious domains

EmailEvents
| where SenderIPv4 in ("SES IP ranges") 
| where SenderDomainAge < 30
| where AuthenticationDetails has "SPF=pass" and AuthenticationDetails has "DKIM=pass"

E. SES‑originated mail with mismatched display names

EmailEvents
| where SenderDisplayName !contains SenderFromAddress
| where SenderIPv4 in ("SES IP ranges")

3. IAM Hardening (Prevention)

Mandatory

  • Enforce MFA on all IAM users

  • Rotate access keys every 90 days

  • Block SES usage unless explicitly required

  • Use IAM service‑control policies to restrict SES to specific roles

  • Enable Access Analyzer organization‑wide

  • Disable SMTP credentials unless absolutely required

Key Policies

  • Deny SES actions unless from approved VPC endpoints

  • Deny SES actions unless using approved identities

  • Deny IAM users from creating new SES identities

Example SCP (deny SES unless from approved IPs)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ses:*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": ["YOUR-CIDR-RANGES"]
        }
      },
      "Resource": "*"
    }
  ]
}

4. Conditional Access‑Style Controls (Email Security)

Inbound

  • Flag external emails where:

    • Domain age < 30 days

    • SES is the sending infrastructure

    • Display name mismatch

    • URL redirect chain > 2 hops

    • HTML contains brand impersonation indicators

Outbound

  • Block or quarantine outbound mail that:

    • Uses SES domains unexpectedly

    • Contains AWS‑style Message‑IDs

    • Has mismatched envelope vs. header sender

User‑Facing Controls

  • External sender banners

  • Browser isolation for finance/HR workflows

  • QR‑code phishing detection


5. Incident Response Workflow (SES Abuse)

Step 1 — Confirm SES Abuse

  • CloudTrail shows SES API calls from unknown IPs

  • IAM user shows unusual activity

  • SES sending spikes

  • New SES identities created

Step 2 — Contain

  • Disable IAM access keys

  • Rotate all IAM credentials

  • Revoke SMTP credentials

  • Block SES sending in the region

Step 3 — Investigate

  • Review CloudTrail for:

    • Identity creation

    • Policy changes

    • SES identity verification

  • Review email logs for:

    • Volume

    • Targets

    • Payloads

Step 4 — Remediate

  • Delete unauthorized SES identities

  • Implement SCPs

  • Enforce MFA

  • Rotate all secrets in the environment

Step 5 — Recover

  • Re-enable legitimate SES usage

  • Validate IAM least privilege

  • Add SIEM detections permanently


6. High‑Signal Indicators of SES Abuse

Strong Indicators

  • GetCallerIdentity immediately followed by SES API calls

  • SES sending from IAM users that never used SES

  • SES identities created without change‑control

  • SES sending from regions you don’t operate in

Moderate Indicators

  • SES mail from domains < 30 days old

  • SES mail with mismatched display names

  • SES mail with multi‑hop redirect chains


7. Executive Summary (for leadership)

Attackers increasingly weaponize Amazon SES using stolen IAM keys. Because SES automatically passes SPF, DKIM, and DMARC, these phishing emails appear cryptographically legitimate and bypass most email security controls. Detection requires behavioral analysis, IAM hardening, and SIEM‑level correlation — not traditional sender‑reputation filtering.

Comments

Popular posts from this blog

Entire List Leaked for Canvas Ransomware Attack

WSUS CVE-2025-59287 Mitigation

Cloud Infrastructures are Having a Bad Week

CVE-2025-58034 Fortinet Warnings and Mitigation

Broadcom is dismantling of VMware Cloud Service Providers (VCSPs)

FBI Seizes RAMP Cybercrime Forum

Instagram Data Leak Update

CodeRED emergency alert system is currently down across many regions!

SitusAMC Breached!

Notepad++ update service was compromised