Amazon SES Abuse: Bypassing Reputation Filters with High-Trust Infrastructure
Has anyone else noticed the sharp uptick in phishing campaigns leveraging Amazon Simple Email Service (SES)? It’s becoming a significant detection gap in our stack. Attackers aren't just spoofing headers; they are compromising verified accounts or abusing the SES sandbox to send mail that passes SPF/DKIM/DMARC checks automatically.
Because SES sits on AWS's massive, high-reputation IP space, traditional reputation-based firewalls just wave these messages through. Blocking *.amazonaws.com or AWS ASNs (like AS16509) isn't feasible for most of us given the volume of legitimate SaaS notifications.
Detection Strategies
We've had to pivot from reputation checks to deep content inspection and header analysis. One TTP we see is attackers using a "From" address that matches the victim's organization (display name spoofing) while the actual envelope sender is an SES instance.
Here is a KQL query we are running in Sentinel to flag SES-sourced mail for analysis:
EmailEvents
| where SenderFromDomain matches regex @".+\.amazonaws\.com$" or HeaderFrom contains "amazonses.com"
| extend ConfigSet = tostring(parse_(Headers)["X-SES-Configuration-Set"])
| where isnotempty(Subject)
| project Timestamp, Subject, SenderFromAddress, RecipientEmailAddress, ConfigSet
| order by Timestamp desc
We also check raw logs for the `X-SES-Outgoing` header to identify the sending region, which can correlate with other threat intel.
How is everyone else handling the "allow-list" dilemma? Are you strictly quarantining all SES-sourced mail, or have you found a reliable heuristic to separate legitimate receipts from credential phishing?
We’ve implemented a strict 'link-rewriting' policy for any email originating from major cloud providers (AWS, Azure, GCP). If the mail comes from SES, the Secure Email Gateway (SEG) strips the original URL and replaces it with a 'safe' version that forces a user-verification landing page. It catches a lot of the credential harvesting attempts that rely on the user trusting the 'aws' link context.
Good catch on the headers. I've found that a lot of these automated SES spam scripts forget to customize the mail_from attribute correctly. In Postfix logs, you can sometimes spot them by looking for a discrepancy between the From: header and the envelope sender.
grep 'X-SES-Outgoing' /var/log/maillog | awk '{print $NF}' | sort | uniq -c
If you see a high volume from a single Configuration Set in a short window, that's usually a dead giveaway of an abused API key rather than a legitimate corporate broadcast.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access