Phishing Through Trusted Channels: A Deep Dive into Amazon SES Abuse and Defense

Overview

Attackers constantly seek ways to bypass email security filters. One increasingly effective method involves abusing legitimate cloud services that organizations already trust. Amazon Simple Email Service (Amazon SES) – a cloud-based platform for sending transactional and marketing emails – has become a prime target. By leveraging SES, attackers send phishing emails that pass SPF, DKIM, and DMARC checks, include legitimate-looking amazonses.com headers, and originate from trusted IP addresses. This tutorial breaks down how these attacks work, from credential theft to final delivery, and offers practical steps to defend your organization.

Prerequisites

To get the most from this guide, you should be familiar with:

• Basic email security concepts (SPF, DKIM, DMARC)
• AWS Identity and Access Management (IAM) fundamentals
• Common phishing techniques (URL redirection, social engineering)
• Ability to read email headers

No advanced programming skills required, but examples include command-line snippets for validation.

Step-by-Step Anatomy of an Amazon SES Phishing Attack

1. Reconnaissance and Key Harvesting

Attackers start by searching for leaked IAM access keys. These keys are often accidentally exposed in:

• Public GitHub repositories (e.g., in code commits or configuration files)
• .env files or Docker images
• Publicly readable S3 buckets
• Configuration backups shared inadvertently

To automate discovery, phishers use tools like TruffleHog, an open-source scanner that detects secrets in Git repositories. Once a candidate key pair is found, they test it against AWS APIs.

# Example: Testing credentials with AWS CLI (attacker's perspective)
aws sts get-caller-identity --profile stolen_profile
# If successful, they see the account ID and user ARN.

Next, they verify that the key has ses:SendEmail or ses:SendRawEmail permissions, ideally with sending limits sufficient for bulk phishing.

2. Key Verification and Setup

After confirming the key works, attackers check SES sending limits and verify the sending domain (if already configured). They may also use the key to request a sending quota increase from AWS – often automated if the stolen account has billing history.

If the victim’s AWS account already has SES verified domains, the attacker can immediately send emails that appear to come from that domain. Otherwise, they might attempt to verify a new domain – but this is riskier because it triggers notifications to the account owner.

3. Crafting the Phishing Email

Using the IAM key, attackers call the SES API to send emails with custom HTML templates. Typical phishing themes include:

• Fake DocuSign notifications (e.g., “Document ready for signature”)
• Account security alerts (“Unusual login detected – verify now”)
• Shipping or payment confirmations

The HTML is carefully designed to match legitimate services. A critical element is the phishing URL, which is masked using AWS infrastructure itself – for example, a link pointing to https://amazonaws.com/something that actually redirects to a malicious site. Because the domain amazonaws.com is legitimate, users and many security filters trust it.

Example: Sending via AWS CLI (attacker)

aws ses send-email \
    --from 'noreply@docusign.com' \
    --destination 'ToAddresses=target@victim.com' \
    --message 'Subject={Data=DocuSign Document Ready,Charset=utf8},Body={Html={Data=...View Document...}}'

4. Bypassing Email Security

Amazon SES automatically signs outgoing emails with DKIM and configures SPF records. The Message-ID header contains .amazonses.com, which pass all standard authentication checks. The sending IP addresses are from AWS’s large pool, so they are not blocklisted. Email security gateways that rely on reputation alone will likely allow these messages through. The attacker’s email appears technically legitimate from an infrastructure standpoint.

Additionally, attackers can use AWS’s rate limits to send thousands of emails before being throttled, maximizing their reach before any anomaly detection kicks in.

5. The Attack in Action

Once the email lands in the target’s inbox, the victim sees a convincing brand interface. Clicking the link (e.g., https://amazonaws.com/...?redirect=malicious.com) leads to a phishing page that steals credentials or sensitive data. Because the initial domain is Amazon’s, the user may not suspect anything until it’s too late.

Real-world example: In early 2026, attackers sent fake DocuSign notifications via SES. Email headers showed amazonses.com, and the links pointed to Amazon’s domain with a redirect. The attack bypassed many standard filters.

Common Mistakes (and How to Avoid Them)

For Organizations:

• Exposing IAM keys publicly – Never commit keys to code repositories. Use AWS Secrets Manager or environment variables with restricted access. Regularly scan with tools like TruffleHog on your own repos.
• Overly permissive IAM policies – Follow the least-privilege principle. If SES is not needed, do not grant ses:SendEmail to anyone. For users who need it, restrict to specific source ARNs.
• No monitoring of SES usage – Enable AWS CloudTrail and Amazon GuardDuty to detect unusual SES sending patterns. Set up alerts for sudden spikes in email volume or repeated failures.

For Security Teams:

• Blocking all Amazon SES traffic – This is impractical as it would break legitimate services. Instead, implement URL inspection and known phishing redirect patterns.
• Relying solely on SPF/DKIM/DMARC passing – These only verify the sending domain, not the content. Add content filtering and link reputation checks.
• Ignoring email headers – Train users to check the actual link destination (hover over links). For automated systems, scan for amazonses.com in headers combined with suspicious URLs.

Summary

Amazon SES abuse represents a sophisticated phishing vector that exploits trust in legitimate cloud infrastructure. Attackers steal IAM keys, send authenticated emails that bypass security, and use redirects to fool victims. Defending requires proactive key hygiene, least-privilege IAM policies, monitoring SES usage, and supplementing email authentication with content analysis. By understanding the attack lifecycle, organizations can better protect their users and data.