Attackers abuse Amazon SES to send phishing emails that pass security checks

Attackers are abusing Amazon Simple Email Service to send phishing and business email compromise messages that look technically legitimate.

The emails can pass standard SPF, DKIM, and DMARC authentication checks because they come through real Amazon SES infrastructure, not a suspicious mail server built by criminals.

Kaspersky researchers said this tactic is becoming a steady trend, with attackers using leaked AWS IAM access keys to send large volumes of phishing emails through trusted cloud accounts.

Why Amazon SES abuse is hard to block

Amazon SES is a legitimate cloud email service used by businesses to send transactional, marketing, and notification emails. That trust is exactly what attackers are trying to exploit.

A phishing message sent through SES can carry valid authentication headers and may include “amazonses.com” in the Message-ID field. To many filters, the message looks like normal business email traffic.

Blocking the sending IP address is also risky. Many legitimate companies use Amazon SES, so broad blocking could disrupt real customer messages, password resets, invoices, and support notifications.

Abused feature	Why it helps attackers
Trusted AWS infrastructure	Emails come from a platform many filters already trust.
SPF, DKIM, and DMARC alignment	Messages can pass standard authentication checks.
Amazon SES headers	Headers can make the email look like normal cloud mail traffic.
Custom HTML templates	Attackers can create polished messages that resemble real services.
AWS-hosted links	Victims may trust links that appear to involve Amazon infrastructure.

How attackers get access to Amazon SES

The attacks usually start with leaked AWS IAM access keys. These keys can appear in public GitHub repositories, environment files, Docker images, backups, or misconfigured cloud storage.

Attackers use automated scanning tools to find exposed secrets. Once they find a working key, they check whether it can send email through Amazon SES and how many messages the account can deliver.

If the key has useful permissions, the attacker can send phishing emails from someone else’s legitimate AWS account. That gives the campaign clean infrastructure and a stronger chance of landing in inboxes.

• Attackers scan public repositories and exposed cloud assets for AWS secrets.
• They validate whether the IAM key still works.
• They check SES sending permissions and account limits.
• They send phishing emails using the compromised cloud account.
• They rely on Amazon SES reputation to avoid easy blocking.

DocuSign lures remain a common theme

Kaspersky said one common early 2026 lure involved fake electronic signature notifications. These emails impersonated document-signing services such as DocuSign.

The message usually asked the recipient to review or sign a document. The link appeared safe because it could point to AWS-related infrastructure before redirecting the victim to a phishing form.

The final page collected credentials. Because the email passed authentication checks, the victim had fewer obvious warning signs than they would see in a traditional spoofing attempt.

Phishing stage	What the victim sees
Email lure	A fake document-signing notification.
Sender appearance	A message that appears technically authenticated.
Link	A URL that may appear to involve AWS infrastructure.
Landing page	A sign-in form designed to steal credentials.
Goal	Credential theft and account compromise.

Amazon SES is also being used for BEC attacks

The abuse does not stop at credential phishing. Kaspersky also observed Amazon SES being used in business email compromise campaigns.

In one case, attackers sent an email that appeared to include a conversation between an employee and a service provider about an unpaid invoice. The message then asked the finance team to process an urgent payment.

The attached PDF did not need malware, a QR code, or a phishing link. It only needed forged payment details and a convincing business context.

Why authenticated email is not always safe

Email authentication helps stop spoofing, but it cannot prove that the sender’s cloud account has not been compromised.

This is the central problem with Amazon SES abuse. SPF, DKIM, and DMARC can confirm that the message came through an authorized sending path, but they cannot confirm that the person using that path is legitimate.

That means security teams need to combine authentication checks with content analysis, behavioral detection, link inspection, cloud account monitoring, and user verification.

• Authenticated emails can still be malicious.
• Reputation-based filtering can miss abuse from trusted platforms.
• Finance teams should verify payment requests outside email.
• Users should not trust a link only because it appears cloud-hosted.
• Security teams should monitor for abnormal SES sending behavior.

How AWS customers should reduce the risk

AWS customers should treat IAM access keys as high-value secrets. A leaked key with email-sending permissions can quickly become a phishing tool.

The strongest approach is to avoid long-lived access keys where possible and use IAM roles with temporary credentials instead. When access keys remain necessary, they should use least privilege and rotate regularly.

Organizations should also monitor SES usage for unusual spikes, new sending patterns, unexpected regions, unfamiliar sender identities, and bounce or complaint changes.

Control	Why it helps
Least privilege IAM policies	Limits what a leaked key can do.
IAM roles where possible	Reduces reliance on long-lived static keys.
Regular key rotation	Shortens the useful life of exposed credentials.
MFA for privileged users	Protects cloud accounts from easy takeover.
IP or condition-based restrictions	Blocks key use from unexpected locations or environments.
Secret scanning	Finds exposed keys in code, containers, and configuration files.
SES monitoring	Detects abnormal sending volume or new phishing-like patterns.

How companies can protect users

Email security teams should not allow authentication results to be the only trust signal. A message can pass technical checks and still carry a phishing lure.

Organizations should inspect links, attachments, sender behavior, message language, and user reports. Finance-related emails also need special handling because BEC attacks often avoid obvious malware indicators.

Employees should verify unexpected document-signing requests, invoice changes, bank account updates, and urgent payment demands through a separate trusted channel.

• Scan PDF attachments even when they contain no obvious malware.
• Analyze redirect chains before allowing users to open links.
• Flag new or unusual SES-sent messages that mimic trusted brands.
• Require callback verification for payment changes.
• Train employees to distrust urgency, not just unknown senders.
• Review cloud audit logs for exposed or abused IAM keys.

What users should watch for

Users should be careful with any unexpected document-signing email, even if it appears to pass security checks or comes from a familiar cloud service.

A safe-looking domain does not guarantee a safe login page. Attackers can use redirects, cloud-hosted forms, and polished templates to make phishing pages look more credible.

The safest response is to open the service directly from a browser bookmark or official app, then check whether the document or request appears there.

Warning sign	Safer response
Unexpected DocuSign-style notice	Open the service directly instead of clicking the email link.
Urgent invoice or wire transfer request	Verify by phone or internal finance workflow.
PDF with payment details only	Check whether the vendor actually sent it.
Cloud-hosted login page	Confirm the full domain and avoid entering credentials after redirects.
Message passes authentication but feels unusual	Report it to security instead of trusting the headers.

FAQ