The Anatomy of an Amazon SES Phishing Attack: A Step-by-Step Breakdown

Introduction

Phishing attacks have evolved beyond simple spoofed emails. Cybercriminals now hijack trusted cloud services to bypass email security filters. One rising threat is the abuse of Amazon Simple Email Service (Amazon SES), a legitimate email platform from AWS designed for transactional and marketing messages. When attackers weaponize Amazon SES, every message passes SPF, DKIM, and DMARC checks—making the phishing email look entirely legitimate. In this guide, we’ll walk through the exact steps attackers use to exploit Amazon SES, from stealing credentials to launching convincing phishing campaigns. Understanding these tactics helps you defend against them.

What You Need (From an Attacker’s Perspective)

• Leaked AWS IAM Access Keys – Usually found in public GitHub repositories, .env files, Docker images, configuration backups, or exposed S3 buckets.
• TruffleHog (or similar secret-scanning tool) – Automated bot that scans code repositories to detect hard-coded secrets like AWS keys.
• Amazon SES Sending Limits Verified – The stolen keys must have permissions to use SES and sufficient sending quotas.
• Custom HTML Email Template – Attackers craft deceptive emails (e.g., fake DocuSign notifications) using Amazon SES’s HTML support.
• Redirect URLs – Amazon SES allows embedding links that point to amazonaws.com domains, masking malicious destinations.
• Basic Knowledge of Email Headers – To confirm amazonses.com appears in Message-ID headers, lending credibility.

Step-by-Step Breakdown of the Attack

Step 1: Harvest Leaked IAM Access Keys

Attackers begin by scanning public sources for exposed AWS Identity and Access Management (IAM) credentials. They deploy automated bots that use tools like TruffleHog to search GitHub repositories, Docker images, environment files (.env), and even misconfigured S3 buckets. These bots look for strings such as AKIA (AWS Access Key prefix) and associated secret keys. Once found, the keys are tested against AWS APIs to confirm they are still active and have SES permissions.

Step 2: Verify Permissions and Sending Limits

Not every leaked key is useful. The attacker checks whether the IAM user or role has the ses:SendEmail and ses:SendRawEmail actions allowed. They also test sending quotas (e.g., 10,000 emails per day). If permissions are low, they may chain multiple stolen keys to scale the attack. Tools like aws-cli or custom scripts automate this verification.

Step 3: Craft a Deceptive Phishing Email

With access confirmed, the attacker designs a convincing email. They exploit Amazon SES’s ability to use custom HTML templates. Common ruses include fake notifications from electronic signature services (like DocuSign), shipping updates, or account verification requests. The email includes a call-to-action button or link that appears to lead to a legitimate site but actually redirects to a phishing page. To increase credibility, the link may point to an amazonaws.com subdomain, which users and security scanners trust.

Step 4: Send the Email via Amazon SES

The attacker uses the stolen IAM keys to send the crafted email through Amazon SES. Because SES is a legitimate AWS service, the email is signed with valid SPF, DKIM, and DMARC records. The Message-ID header contains .amazonses.com. Consequently, standard email security checks see nothing suspicious—the message originates from an authenticated, reputable source. The sender’s IP address is not on any blocklist because it belongs to AWS’s trusted infrastructure.

Step 5: Evade Security Filters and Harvest Credentials

The phishing email lands in the victim’s inbox. Because it passes all authentication protocols and uses a trusted domain, it is unlikely to be quarantined. Clicking the link redirects to a fake login page or data collection form, often hosted on another compromised AWS resource. The attacker collects credentials, personal data, or even session tokens. Since the email looks legitimate, victims are more likely to comply. Moreover, blocking all SES traffic would cause massive false positives for legitimate services, so organizations rarely take that drastic step—giving attackers a persistent channel.

Tips for Defenders

• Monitor for exposed keys – Use automated secret scanning tools (like TruffleHog or GitGuardian) on your own repositories to detect AWS credentials before attackers do.
• Implement IAM best practices – Rotate keys regularly, use roles instead of long-term keys when possible, and enforce least privilege (e.g., restrict SES permissions to only needed actions).
• Train users to spot subtle clues – Even legitimate-looking emails should be inspected. Encourage reporting of unsolicited requests for login or personal info.
• Deploy advanced email security – Use solutions that analyze content and behavior (e.g., unusual redirect patterns) rather than relying solely on authentication headers.
• Audit SES usage – Regularly review AWS CloudTrail logs for unknown API calls to ses:SendEmail. Set up alerts for unusual sending volumes or new sending identities.
• Consider DMARC reporting – Even though SES emails pass DMARC, aggregate reports can help identify unexpected sources of authenticated email.

By understanding the attacker’s playbook, security teams can better anticipate and block these “legitimate” phishing attempts. Stay vigilant—because the most dangerous emails are those that look perfectly safe.