How Attackers Exploit Amazon SES for Phishing Campaigns: A Step-by-Step Breakdown

Introduction

Phishing attackers are constantly refining their methods to slip past email security filters. One of their most cunning tactics involves abusing trusted services like Amazon Simple Email Service (SES). By weaponizing legitimate cloud infrastructure, they craft emails that look authentic to both users and security systems. This guide dissects the exact process attackers use—from stealing credentials to sending convincing phishing messages—so you can understand the threat and protect your organization.

How Attackers Exploit Amazon SES for Phishing Campaigns: A Step-by-Step Breakdown — Source: securelist.com

What You Need (Prerequisites for Understanding)

To follow along, you should be familiar with:

Amazon SES: A cloud-based email service for sending transactional and marketing messages.
AWS IAM: Identity and Access Management, used to control permissions for AWS resources.
Email authentication: Basics of SPF, DKIM, and DMARC protocols.
Phishing techniques: How attackers trick users into revealing sensitive data.

No technical setup required—this is a conceptual guide.

Step-by-Step Process

Step 1: Sourcing Leaked AWS Credentials

Attackers begin by hunting for exposed IAM access keys. These keys are often carelessly left in public places:

Public GitHub repositories (committed by mistake)
Environment (.env) files in shared codebases
Docker images pushed to public registries
Configuration backups stored in publicly accessible S3 buckets

Tools like TruffleHog (an open-source scanner) automate the search for these secrets. Once a key is found, the attacker verifies its permissions and email sending limits.

Step 2: Verifying and Preparing the SES Account

With valid IAM keys, the attacker logs into AWS or uses the SES API to check:

If the account is in the SES sandbox (limits sending to verified addresses only). If so, they may need to request production access using other stolen credentials.
The daily sending quota – higher limits allow bigger campaigns.
Whether the account has DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) already configured. Many AWS accounts have these set up, giving the attacker a ready-to-use trusted infrastructure.

At this point, the attacker has full control to send email from a legitimate SES endpoint.

Step 3: Crafting the Phishing Email

Attackers exploit SES’s features to build convincing messages:

Custom HTML templates: They design emails that mimic services like DocuSign, Microsoft 365, or bank notifications.
Safe redirects: Phishing URLs are masked using legitimate AWS domains (e.g., amazonaws.com or amazonses.com). When a user clicks, a redirect sends them to a fake login page.
Impersonation: The “From” address and display name are set to something familiar, like “noreply@docusign.com” (using a spoofed domain).

The email is then queued for sending through SES.

Step 4: Sending the Phishing Campaign

Using the SES API or AWS console, the attacker sends thousands of emails. Each message automatically passes authentication checks because:

SPF: SES’s mail servers are included in the SPF record of amazonses.com.
DKIM: SES signs emails with its own DKIM key, so the signature is valid.
DMARC: The alignment passes because the sending domain is Amazon’s.

The email headers show amazonses.com in the Message-ID, and the IP addresses are on Amazon’s clean IP range—not blacklisted.

Step 5: Bypassing Security Filters

Because SES is a trusted sender, most email security solutions (Secure Email Gateways, Microsoft Defender, etc.) let the message through. The attacker’s IP isn’t on any reputation blocklist. Blocking all SES traffic would cause massive false positives, so organizations rarely do it. This gives the attacker a reliable channel.

Step 6: Harvesting Credentials

The email contains a call to action (e.g., “Review Document” or “Verify Account Now”). Clicking the link takes the user to a fake login page hosted on a compromised or malicious server. The attacker captures entered credentials and may redirect to the real site to avoid suspicion.

Example of a Real-World Attack

In early 2026, security researchers observed a wave of phishing emails imitating DocuSign notifications. The emails had valid SES headers, passed all authentication checks, and used AWS redirect links. The fake DocuSign landing page looked identical to the real one. Only a careful examination of the URL revealed the scam.

Tips for Defense

Monitor your AWS environment: Regularly check for unused IAM keys and use tools like AWS CloudTrail to detect unusual SES activity.
Educate users: Train staff to verify unexpected email links, even if the sender looks legitimate. Hover over links and check the actual domain.
Implement strict IAM policies: Grant least privilege—don’t give SES permissions unless absolutely necessary. Regularly rotate keys.
Use anomaly detection: Watch for sudden spikes in email volume from your SES accounts.
Scan code repositories: Run secret scanners (like TruffleHog) on your own repositories to prevent leaks.
Consider email authentication beyond DMARC: While SES emails pass DMARC, you can still filter based on content patterns (e.g., common phishing keywords or unusual redirects).

Tags: