Attackers Abuse Amazon SES for Authenticated Ph Send Phishing

Threat actors are increasingly abusing Amazon’s cloud email infrastructure to send highly deceptive phishing messages. These emails appear entirely genuine, successfully bypassing all standard security checks.

Phishing has always been about deception. Attackers craft emails designed to look real, hoping recipients will trust what they see and hand over their credentials or money.

For years, security tools have gotten better at spotting suspicious senders, unknown domains, and failed email authentication checks.

So attackers adapted. Instead of building fake infrastructure, they are now hijacking real, trusted services to do the dirty work.

The latest target of this strategy is Amazon Simple Email Service, widely known as Amazon SES, a cloud-based platform used by businesses around the world to send transactional and marketing emails reliably.

Amazon SES is deeply embedded in the AWS ecosystem, which makes it a trusted name for both users and security filters alike.

Emails sent through this service carry valid SPF, DKIM, and DMARC authentication headers, meaning they pass every technical check that most email security systems run.

The Message-ID headers in these messages almost always include “.amazonses.com,” further reinforcing the appearance of legitimacy.

From a purely technical standpoint, a phishing email sent through Amazon SES looks no different from a legitimate business communication. This is precisely what makes the abuse of this platform so dangerous.

Securelist researchers identified a clear and growing uptick in phishing campaigns abusing Amazon SES in early 2026.

The team noted that attackers are exploiting this platform not because it is vulnerable in the traditional sense, but because it is legitimate.

By routing phishing emails through trusted infrastructure, threat actors effectively sidestep reputation-based blocklists.

Blocking the sender’s IP address is not a viable solution either, because doing so would cut off all legitimate emails sent through Amazon SES for any organization, generating an unmanageable volume of false positives.

The most common lure observed in early 2026 involved fake notifications from electronic signature services, such as emails impersonating Docusign.

Victims received messages asking them to click a link to review and sign a document. The link appeared to point to amazonaws.com, which most users would consider safe.

Clicking it redirected victims to a credential-harvesting form hosted on AWS infrastructure, making the deception even harder to detect.

Beyond credential theft, attackers have also been using Amazon SES to conduct Business Email Compromise (BEC) campaigns, where they impersonate employees and send fabricated invoice threads to finance departments, requesting urgent wire transfers.

The PDF attachments in these BEC emails contained no malicious URLs or QR codes, only forged payment details and supporting documents designed to appear as a legitimate business exchange.

How Attackers Gain Access

The entry point for these campaigns is almost always leaked IAM (AWS Identity and Access Management) access keys.

Developers routinely expose these keys by leaving them in public GitHub repositories, ENV configuration files, Docker images, or unsecured S3 buckets.

Attackers use automated scanning tools, including bots built on the open-source utility TruffleHog, specifically designed to hunt for exposed secrets across public code repositories.

Once a key is found, the attacker verifies its sending permissions and email limits, then begins blasting out phishing messages at scale.

The entire operation takes advantage of someone else’s legitimate account, meaning the sending IP carries a clean reputation and the emails arrive with full authentication stamps intact.

This makes detection at the gateway level extremely difficult, because the email is technically doing everything right.

Securelist researchers recommend that organizations treat IAM access key security as a top priority. Applying the principle of least privilege ensures that keys carry only the permissions required for specific tasks, reducing the damage potential if a key is exposed.

Transitioning from static IAM access keys to AWS IAM roles is a stronger approach, as roles provide scoped, temporary permissions.

Enabling multi-factor authentication, configuring IP-based access restrictions, setting up automated key rotation, and running regular security audits all help reduce exposure.

Using the AWS Key Management Service to manage encryption keys centrally also adds an important layer of control.

On the user side, emails should never be trusted based solely on the sender name or domain.

Unexpected documents should be verified through a separate communication channel before any action is taken, and every link in an email body should be inspected carefully before clicking.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.