Amazon SES Increasingly Abused in Phishing to Evade Detection

What happened

Threat actors are exploiting Amazon Simple Email Service at increasing scale to send phishing emails that pass standard authentication checks and bypass reputation-based blocking, according to Kaspersky researchers. The primary driver of the abuse is the widespread exposure of AWS Identity and Access Management access keys in public assets including GitHub repositories, .ENV files, Docker images, backups, and publicly accessible S3 buckets.

Attackers use automated tools built on the open-source TruffleHog utility to scan for leaked credentials, validate key permissions and email sending limits, and then distribute phishing messages at volume through legitimate Amazon SES infrastructure. Because Amazon SES is a trusted platform, emails sent through it pass SPF, DKIM, and DMARC authentication checks automatically. Blocking the sending IP addresses is not a viable defense because doing so would block all Amazon SES traffic.

Observed campaigns include fake document-signing notifications impersonating DocuSign that lead to AWS-hosted phishing pages, and more sophisticated business email compromise attacks involving fabricated email threads and fake invoices targeting finance departments. The phishing quality is high, with custom HTML templates mimicking real services and realistic login flows. Kaspersky notes the abuse is not limited to Amazon SES, with threat actors continuously seeking to exploit other legitimate email platforms using the same approach. Amazon directed organizations to report suspected abuse to AWS Trust and Safety and pointed to its guidance on protecting against unauthorized account access.

Who is affected

Any organization that uses Amazon SES legitimately faces reputational risk if its credentials are compromised and used for phishing campaigns. Finance teams are specifically targeted through BEC attacks involving fabricated invoice threads. Recipients of Amazon SES-delivered phishing have no reliable technical signal to distinguish malicious emails from legitimate ones, as both pass authentication checks identically.

Why CISOs should care

Amazon SES abuse removes the foundational email security assumption that authentication checks provide meaningful protection. SPF, DKIM, and DMARC passing is the signal most email security tools use to establish trust. When attackers send through a legitimate, trusted platform, those checks become a liability rather than a protection, actively increasing the credibility of phishing messages. The automation of credential scanning, permission validation, and email distribution means this attack pattern scales without significant attacker effort once a valid key is found.

The BEC component is particularly relevant for security leaders. Fabricated email threads that appear to come from legitimate Amazon SES infrastructure are substantially harder for finance teams to identify as fraudulent than generic phishing attempts.

3 practical actions

1. Audit AWS IAM access keys for Amazon SES across all environments and rotate any that have been exposed in public repositories, environment files, or container images: TruffleHog and similar tools are actively being used to automate discovery of exposed credentials. Run the same scanning tools against your own public and internal repositories to identify leaked SES keys before attackers do, and rotate any that cannot be confirmed as unexposed.
2. Apply least-privilege IAM policies to all SES-enabled accounts and restrict sending permissions to specific verified identities: SES access keys that have broad sending permissions represent a higher-value target. Restrict IAM permissions to the minimum required sending scope, enable MFA on accounts with SES access, and apply IP-based access restrictions to limit key usage to known authorized environments.
3. Update email security awareness training to address trusted-platform phishing: Standard advice to check authentication headers and sender domains is ineffective against Amazon SES abuse. Brief employees, particularly in finance, on the pattern of fabricated invoice threads and document-signing lures delivered through trusted cloud email infrastructure, and reinforce that payment requests require out-of-band verification regardless of how convincing the email chain appears.