Amazon SES Increasingly Abused in Phishing Attacks That Bypass Security Filters

Attackers are stealing exposed AWS IAM (Identity and Access Management) access keys and using them to send phishing emails through Amazon SES (Simple Email Service — Amazon's legitimate cloud email platform), allowing the messages to pass SPF, DKIM, and DMARC authentication checks and slip past reputation-based blocklists. Research published by Kaspersky's Securelist and independently documented by BleepingComputer shows the campaign is accelerating in 2026, with victims receiving convincingly formatted emails that appear to originate from a trusted, high-reputation sending infrastructure.

Amazon SES Phishing: Why Legitimate Cloud Email Is the Perfect Cover

Amazon SES is one of the world's most widely used transactional email services, processing billions of messages per month for businesses of all sizes. Because it sits inside Amazon's vast infrastructure, SES-sourced email carries strong sender reputation scores with every major inbox provider — Gmail, Outlook, Yahoo — and its sending IPs are whitelisted by virtually every corporate email gateway.

This is precisely why threat actors want access to it. When a phishing email arrives from a legitimate Amazon SES sending address, the receiving mail server sees:

• A valid SPF (Sender Policy Framework) record — Amazon's IP is authorized to send for the domain
• A valid DKIM (DomainKeys Identified Mail) signature — the message hasn't been tampered with
• Potentially a passing DMARC (Domain-based Message Authentication, Reporting, and Conformance) check

All three green lights mean the message sails straight into the inbox. Reputation-based blocklists — which flag known spam sources — are useless against a fresh or legitimate Amazon IP. The result is a phishing campaign that neutralizes the primary layer of enterprise email defense before the message even reaches a human.

How Attackers Gain Access: The IAM Key Theft Pipeline

Attackers do not breach Amazon directly. Instead, they exploit a well-documented but persistently common problem: developers accidentally expose AWS IAM access keys in public locations.

IAM access keys are credential pairs (an access key ID and a secret access key) that grant programmatic access to AWS services — including the ability to send unlimited email through SES. Developers routinely leave these keys embedded in:

• Public GitHub repositories — committed directly in source code, .env files, or configuration YAML
• Docker images — baked into container layers pushed to Docker Hub or ECR
• S3 buckets with public read access — in backup files, deployment packages, or CI/CD artifacts
• Environment variable files — .env files accidentally included in open repos

To harvest these at scale, threat actors use automated tooling built on top of TruffleHog — an open-source secret-scanning utility designed to detect leaked credentials in git history and repository files. Attackers have built bot pipelines that continuously monitor GitHub's public commit stream, run TruffleHog against any new code, validate discovered keys against the AWS API, and immediately queue confirmed SES-capable keys for phishing campaigns.

The pipeline is fast. A key exposed in a public commit can be harvested and sending phishing emails within minutes of publication.

Phishing Lure Tactics and Evasion Techniques

Kaspersky's Securelist research documents the lure themes in detail. The most prevalent in early 2026 are fake notifications from electronic document signing services — emails that mimic DocuSign, Adobe Sign, and similar platforms, instructing the recipient to review or sign an urgent document.

The phishing quality is high. Attackers use custom HTML email templates that closely replicate the visual design of legitimate services, including correct logos, color schemes, and footer text. Linked landing pages are hosted on AWS infrastructure itself — redirecting through S3-hosted pages or CloudFront distributions — further reinforcing the appearance of legitimacy.

To complicate detection further, attackers route victim clicks through commercial traffic analysis services (similar to Bitly or UTM redirect services), which serve dual purposes: they obfuscate the final malicious destination from security scanners that follow redirect chains, and they provide the attacker with real-time click analytics and victim geolocation data.

Wiz's cloud security research documented a parallel SES abuse campaign that sent over 50,000 phishing emails per day at peak volume using a single compromised set of IAM credentials with generous SES sending limits.

Why Standard Defenses Fail

Most enterprise email security stacks are built on two pillars: authentication (SPF/DKIM/DMARC) and reputation (IP and domain blocklists). Amazon SES abuse defeats both simultaneously.

Authentication: Because attackers send through Amazon's own infrastructure using legitimately authenticated keys, every authentication header passes. The email is not spoofed — it is genuinely sent from SES.

Reputation: Amazon SES IPs rotate across thousands of addresses. Fresh IPs carry no negative history. Even blocklist feeds updated hourly cannot keep pace with Amazon's IP space. Additionally, if attackers configure SES to send from a custom domain subdomain they control, they can further customize the apparent sender.

Content filters: High-quality HTML templates with minimal suspicious text and no traditional spam-trigger phrases (no "click here to claim your prize") are increasingly effective at evading signature-based content scanners.

The result is a threat category that Datadog's security team classifies as a "trusted infrastructure abuse" attack — one where the attacker's strength is borrowed legitimacy from a reputable platform.

Who Is Affected

Any organization whose employees receive email is a potential target. The campaign is broadly untargeted at the recipient level — the attackers are using Amazon SES's scale to cast a wide net. However, industries handling sensitive document workflows (legal, finance, healthcare, real estate) are disproportionately targeted because DocuSign-style lures are plausible in those contexts.

On the sender side, any AWS account holder whose IAM credentials are exposed is at risk of being weaponized — making developers, DevOps teams, and any organization with AWS infrastructure a liability vector if key hygiene is poor.

What You Should Do Right Now

For security and DevOps teams at AWS-using organizations:

• Audit IAM keys immediately using AWS IAM Access Analyzer to identify unused, over-permissioned, or long-lived access keys. Rotate or revoke any key older than 90 days.
• Eliminate long-lived access keys where possible. Migrate workloads to IAM roles with temporary credentials (AWS STS — Security Token Service) instead of static key pairs. Roles issue short-lived tokens that automatically expire.
• Enable AWS CloudTrail logging for all SES API calls (ses:SendEmail, ses:SendRawMessage). Alert on any SES send volume spike or sends from unrecognized IAM principals.
• Apply least-privilege IAM policies. If a service account only needs to read from S3, it should not have ses:* permissions. Review all policies granting SES access and restrict them to specific identities that genuinely need email-sending capability.
• Configure IP-based access restrictions on IAM policies using aws:SourceIp conditions, limiting which IP ranges can use SES credentials — blocking attackers calling the API from overseas infrastructure.
• Run secret scanning on your repositories. Integrate TruffleHog or GitHub's built-in secret scanning as a pre-commit hook and CI/CD gate. Treat any IAM key committed to source control as compromised and rotate it immediately, regardless of whether the repo was public.

For email security defenders:

• Consider behavioral email analysis — tools that flag unusual send-rate patterns on SES-originating mail or detect domain mismatches between the "From" display name and the authenticated sending domain.
• Train users to verify document-signing requests through a second channel (phone or internal Slack) before clicking any link in an unexpected DocuSign-style email.

Background: Understanding the Risk

The Amazon SES abuse pattern is part of a broader shift in phishing strategy toward trusted infrastructure abuse — using legitimate, reputable cloud services as attack infrastructure. The same technique has been observed with Google Forms, Microsoft SharePoint, Dropbox, and OneDrive — platforms whose domains appear trustworthy to both humans and security tools.

The underlying driver is the ever-growing exposure of cloud credentials. AWS IAM keys have appeared in public GitHub repositories since GitHub's early days, and despite years of warnings, the problem persists. The 2024 exposure documented by The Register found thousands of AWS credentials stolen from misconfigured sites in a single research sweep, and the 2026 campaign documented by Wiz demonstrates that attackers are industrializing the collection and exploitation of these keys at scale.

SES's built-in abuse controls — sending limits, reputation monitoring, and account suspension — are reactive rather than preventive. Amazon will suspend accounts identified as sending spam, but this happens after the phishing emails have already reached inboxes. Attackers mitigate this by spreading sends across multiple compromised accounts simultaneously, making it difficult for Amazon to throttle the campaign before it completes a send run.

The shift toward using legitimate cloud email infrastructure also has BEC (Business Email Compromise — a fraud scheme where attackers impersonate executives or vendors to redirect payments or steal credentials) implications. A BEC email sent from a real SES address with a custom domain looks more convincing than one sent from a VPS-hosted server, and sophisticated actors are beginning to layer the two techniques.

Conclusion

The Amazon SES phishing wave represents a maturation in attacker tradecraft: rather than building their own sending infrastructure, threat actors are borrowing Amazon's. The fix is not an email security product — it is IAM hygiene. Organizations running workloads on AWS should treat SES-capable IAM keys with the same sensitivity as production database passwords: rotated regularly, scoped precisely, and never committed to any repository under any circumstances.