The Amazon SES Threat: How Cybercriminals Exploit Trusted Infrastructure for Phishing Attacks

Introduction

Phishing attacks continue to evolve as attackers seek new ways to bypass email security measures and trick recipients into revealing sensitive data. While many scams rely on suspicious domains or malicious attachments, a growing trend involves weaponizing legitimate email services. One such service under increasing abuse is Amazon Simple Email Service (SES), a cloud-based platform designed for reliable transactional and marketing message delivery. By leveraging Amazon's trusted infrastructure, cybercriminals can craft emails that pass all standard security checks, making them extremely dangerous. This article explores how Amazon SES is being misused, how attackers gain access to it, and what real-world phishing campaigns look like.

How Attackers Abuse Amazon SES

Amazon SES is part of the AWS cloud ecosystem and is intended for legitimate bulk email sending. However, its features make it an attractive tool for phishing. Attackers exploit the service in several key ways.

Leveraging Trusted Domains and Authentication

One of the most insidious aspects of Amazon SES abuse is that emails sent through the service appear completely legitimate from a technical standpoint. They include proper SPF, DKIM, and DMARC authentication protocols, which means they pass all standard provider checks. Additionally, the Message-ID headers often contain .amazonses.com, further reinforcing trust. Because the emails originate from a reputable cloud provider, security systems and users alike are less likely to flag them as suspicious. Blocking all emails from Amazon SES would cause massive false positives, disrupting workflows for many organizations, so IT teams rarely take that step.

The Danger of Redirect Links

Phishing URLs can be masked using redirects within Amazon's own infrastructure. A recipient might see a link like amazonaws.com in the email and click it with confidence, only to be redirected to a phishing site instead of a legitimate one. This technique exploits the trust users place in Amazon's domains, making it harder for both automated filters and human judgment to detect the attack.

Custom HTML Templates

Amazon SES supports custom HTML templates, which attackers use to craft highly convincing emails that mimic well-known brands. They can replicate the look and feel of notifications from services like DocuSign, Dropbox, or financial institutions. Because the template is hosted on legitimate infrastructure, even users who inspect the email source may not notice anything amiss.

How Compromise Occurs

Attackers rarely have direct access to an Amazon SES account. Instead, they gain entry through leaked credentials, particularly AWS Identity and Access Management (IAM) access keys. These keys are often inadvertently exposed by developers.

Leaked IAM Access Keys

Developers frequently leave IAM keys in publicly accessible locations, such as:

• Public GitHub repositories (including commit history)
• .env files in codebases
• Docker images pushed to public registries
• Configuration backups stored in unsecured S3 buckets
• CI/CD pipeline logs

Once a key is exposed, it can be discovered and exploited within minutes.

Automated Secret Scanning

To find these leaked keys, phishers deploy automated tools like TruffleHog, an open-source utility that scans for secrets in code repositories and other sources. After verifying that a discovered key has the necessary permissions for Amazon SES (such as ses:SendEmail or ses:SendRawEmail) and checking the account's sending limits, attackers can begin blasting out phishing emails at scale. The key's permissions may also allow the attacker to use custom Return-Path addresses, further masking the email's origin.

Examples of Phishing Campaigns

Attackers using Amazon SES have launched various campaigns, often themed around urgent notifications. One common example is fake alerts from electronic signature services.

Fake DocuSign Notifications

In early 2026, a wave of phishing emails impersonated DocuSign. The emails claimed that a document required the recipient's signature, using urgency to prompt action. The technical headers confirmed delivery via Amazon SES, and the email appeared legitimate at first glance—complete with proper logos, formatting, and a link that initially seemed to point to an Amazon domain. However, clicking the link led to a phishing page designed to steal credentials or deploy malware.

Similar campaigns have also targeted users of Adobe Sign, Dropbox, and various financial institutions, always relying on Amazon SES's trusted infrastructure to evade detection.

Conclusion

The abuse of Amazon SES represents a sophisticated evolution in phishing tactics. By hiding behind a trusted cloud provider, attackers bypass traditional email security measures and exploit user trust. Organizations must adopt proactive defenses, including monitoring for leaked IAM keys, implementing behavior-based email filters, and training users to scrutinize even seemingly legitimate emails. Understanding how attackers weaponize legitimate services is a critical step in building resilience against modern phishing threats.