Hackers Weaponize Amazon SES to Deliver Undetectable Phishing Emails – Bypassing SPF, DKIM, and DMARC + Video

By /

Listen to this Post

Featured Image

Introduction:

Attackers are now abusing legitimate cloud infrastructure – specifically Amazon Simple Email Service (SES) – to send authenticated phishing emails that slip past traditional email security controls. Because these emails pass SPF and DKIM checks (originating from a trusted AWS IP range and bearing a valid cryptographic signature), they appear genuine to mail servers and users alike, forcing security teams to rethink content-level inspection and identity verification.

Learning Objectives:

  • Understand how threat actors exploit Amazon SES to spoof trusted senders and bypass email authentication protocols.
  • Learn to analyze email headers and use Linux/Windows commands to detect SES‑based phishing attempts.
  • Implement hardening measures for AWS SES, deploy content‑verification techniques, and configure advanced DMARC policies to mitigate this attack vector.
  1. Understanding the Attack Vector: How Authenticated Phishing Leverages Amazon SES

Amazon SES is a scalable email service that allows customers to send transactional and marketing emails with high deliverability. Attackers exploit this by:
– Registering for an AWS account and requesting SES production access (often with stolen or synthetic identities).
– Configuring SES to send emails from arbitrary “From” domains (spoofed brands), while SES itself signs the email with its own DKIM key or a customer‑configured key.
– Relying on SES’s IP reputation to bypass spam filters – since SES IPs are rarely blocklisted.

The result: an email that passes SPF (because SES’s sending IP is authorized by AWS’s SPF record) and DKIM (valid signature from SES). Only DMARC alignment may fail if the “From” domain doesn’t match the DKIM domain, but many organizations use a relaxed or permissive DMARC policy (p=none or p=quarantine). Users see a legitimate “via amazonses.com” indicator, which many ignore.

Step‑by‑step what this does:

  1. Attacker creates AWS account, verifies a domain they control (e.g., “malicious-bucket.com”) in SES.
  2. They set up DKIM signing for that domain.
  3. They craft a phishing email spoofing “[email protected]” with a malicious link.
  4. SES sends the email – SPF passes (AWS IP), DKIM passes (signed by malicious-bucket.com).
  5. Recipient’s email server accepts the message because authentication checks succeed.

Linux command to inspect received email headers:

cat suspicious.eml | grep -E "Received-SPF|DKIM-Signature|Authentication-Results"

Look for `spf=pass (google.com: domain of [email protected] designates xxx as permitted sender)` and dkim=pass. If DMARC fails but policy is relaxed, the email lands in the inbox.

Windows PowerShell (Exchange Online) to retrieve authentication results:

Get-MessageTrace -RecipientAddress [email protected] -StartDate (Get-Date).AddHours(-24) | Select-Object Received, SenderAddress, RecipientAddress, Status, AuthenticationResults

2. Detecting SES‑Based Phishing with Email Header Forensics

Security analysts can identify this abuse by inspecting specific header fields added by Amazon SES. Unlike traditional phishing that fails SPF/DKIM, SES‑abused emails contain telltale traces.

Step‑by‑step guide:

  1. Open the full email source (in Outlook: File → Properties → Internet headers; in Gmail: Show original).
  2. Search for `X-SES-` headers – legitimate SES emails include `X-SES-Outgoing` and X-SES-Spam-Verdict.
  3. Check the `Authentication-Results` header – it will show `spf=pass (spfCheck: domain of amazonses.com designates …)` and dkim=pass (signature was verified).
  4. Look for `Return-Path` or `Envelope-From` containing `[email protected]` or similar. The envelope sender rarely matches the displayed “From” domain.

Linux command to extract SES indicators:

grep -E "X-SES-|[email protected]" suspicious.eml

Windows command (using findstr):

findstr /R "X-SES- [email protected]" suspicious.eml

Using `swaks` to test SES authentication bypass (for red‑team validation): 

swaks --to [email protected] --from [email protected] --header "Subject: Your account expired" --body "Click http://evil.com" --server email-smtp.us-east-1.amazonaws.com:587 --auth LOGIN --auth-user YOUR_SES_SMTP_USER --auth-password YOUR_SES_PASSWORD --tls

Note: Only run against owned infrastructure or with explicit authorization.

3. Hardening Amazon SES Against Unauthorized Use

Organizations using AWS must prevent attackers from abusing their own SES quotas and identities. The following IAM and SES configurations reduce risk.

Step‑by‑step guide to secure SES:

  1. Enforce IAM policies that require Multi‑Factor Authentication (MFA) for any action on ses:SendEmail, ses:SendRawEmail.
  2. Use AWS Organizations Service Control Policies (SCPs) to block SES sending from untrusted regions or outside corporate IP ranges.
  3. Configure SES Configuration Sets to log all sends to CloudWatch and S3 for anomaly detection.
  4. Enable SES Feedback Forwarding to catch bounce and complaint spikes.
  5. Regularly audit verified identities (domains and email addresses) in SES and remove stale ones.

IAM policy example to restrict SES sending to a specific IP: 

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "ses:SendRawEmail",
"Resource": "",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": ["203.0.113.0/24"]
}
}
}]
}

CloudWatch alarm for anomalous SES sends (AWS CLI):

aws cloudwatch put-metric-alarm --alarm-name SES-Send-Spike --alarm-description "Alert on >1000 sends per hour" --metric-name Send --namespace AWS/SES --statistic Sum --period 3600 --threshold 1000 --comparison-operator GreaterThanThreshold --evaluation-periods 1 --alarm-actions arn:aws:sns:us-east-1:123456789012:ses-alerts
  1. Implementing Content‑Level Verification to Distinguish Real Login Pages from Spoofed Ones

As Paul Price noted in the original discussion, even if an email arrives via trusted infrastructure, the user remains vulnerable to a fake login page. Content‑level verification answers: “Is this page explicitly authorized by the organization it claims to represent?”

Step‑by‑step guide using browser‑based verification (e.g., TrustdLogo concept):

  1. A browser extension or native browser feature requests a signed attestation from the visited page.
  2. The legitimate organization’s web server responds with a cryptographic proof (e.g., a JWT signed by a key pinned in DNS TXT records or a well‑known endpoint).
  3. If the page cannot produce a valid attestation (because it’s a spoofed page hosted on S3, EC2, or a CDN controlled by attackers), the browser displays a red warning.
  4. For email clients, a similar check can be performed at click‑time: before redirecting, the client fetches a `.well-known/authorization` file from the claimed domain.

Example curl command to simulate verification:

curl -s https://login.microsoftonline.com/.well-known/authorization | jq '.attestation'

If the page is spoofed (e.g., `https://evil-bucket.s3.amazonaws.com/login`), the request will either fail or return an invalid signature.

Implementing simple HTML meta‑verification (for organizations):

Add to your login page:

<meta name="page-authorization" content="signed_hash_here; expires=2026-12-31" />

Then configure email clients or link scanners to require this meta tag before rendering the page as safe.

  1. Strengthening DMARC to Reject Unaligned Mail from Legitimate Cloud Providers

The root cause of SES abuse is that many organizations still use a DMARC policy of `p=none` (monitor only) or p=quarantine. Setting a strict `p=reject` for your domain forces receiving servers to drop emails where the `From` domain does not align with the DKIM or SPF domain.

Step‑by‑step DMARC hardening guide:

  1. Generate a DMARC record for your domain (e.g., _dmarc.yourdomain.com). Start with `p=quarantine` and a low percentage (pct=10) to test.
  2. Monitor reports (aggregate and forensic) sent to [email protected]. Use tools like `dmarc.report` or postmarkapp’s DMARC parser.
  3. After confirming legitimate senders (including third‑party services like Salesforce or SES‑authorized subdomains) pass alignment, change policy to p=reject.
  4. Use subdomain policy (sp=reject) to also protect subdomains.
  5. Implement BIMI (Brand Indicators for Message Identification) to display verified logos – attackers cannot generate valid BIMI certificates.

Example DMARC record (TXT `_dmarc.yourdomain.com`):

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s; pct=100; sp=reject

– `adkim=s` / `aspf=s` : strict alignment kills most SES spoofing because the DKIM domain must exactly match the From domain.

Linux command to check current DMARC policy:

dig +short TXT _dmarc.yourdomain.com

Windows nslookup alternative:

nslookup -type=TXT _dmarc.yourdomain.com

6. Proactive Monitoring with Custom SIEM Rules

Detection requires correlating email logs with cloud API calls. Attackers first verify domains in SES before sending phishing waves. Audit AWS CloudTrail for VerifyDomainIdentity, VerifyEmailIdentity, SendRawEmail, and CreateConfigurationSet.

Step‑by‑step SIEM rule (Splunk/ELK example):

1. Ingest CloudTrail logs and email gateway logs.

  1. Alert when a new domain is verified in SES, followed within 5 minutes by a `SendRawEmail` to more than 50 unique recipients.
  2. Also alert on `ses:SendEmail` API calls originating from unusual ASN or countries not associated with your business.

Sample Sigma rule snippet (applicable to Sentinel/QL:

title: SES Domain Verification Then Bulk Send
status: experimental
logsource:
product: aws
service: cloudtrail
detection:
selection_verify:
eventName: VerifyDomainIdentity
selection_send:
eventName: SendRawEmail
timeframe: 5m
condition: selection_verify and selection_send

Python script to monitor SES sending patterns (run in Lambda): 

import boto3
from datetime import datetime, timedelta
ses = boto3.client('ses')
cloudwatch = boto3.client('cloudwatch')
response = ses.get_send_statistics()
for send in response['SendDataPoints']:
if send['DeliveryAttempts'] > 100 and send['Bounces'] > 0.5  send['DeliveryAttempts']:
 Trigger alert
print(f"Suspicious send: {send}")

What Undercode Say:

  • Authentication ≠ Authorization – SPF/DKIM passes only prove the email came from an authorized server (AWS SES), not that the content or displayed sender is legitimate. Organizations must enforce DMARC alignment with `p=reject` to close this loophole.
  • Cloud Infrastructure is the New Phishing Launchpad – Attackers prefer trusted platforms like AWS, Azure, or SendGrid because they inherit IP reputation. Defenders must treat “passed” authentication as just one signal among many, not an all‑clear.
  • Content‑Level Verification is the Next Frontier – As Paul Price highlighted, users need a way to ask any login page, “Are you real?”. Browser‑based attestation, signed meta tags, and well‑known authorization endpoints can break the chain of SES‑delivered fake pages.

Analysis: The SES abuse technique demonstrates a fundamental failure of the email security model built 30+ years ago – trust is placed in infrastructure rather than content. While DMARC strict alignment can mitigate spoofing of your own domain, attackers can still impersonate third‑party brands (e.g., “[email protected]” spoofed via SES) if PayPal’s DMARC is not p=reject. This is why major providers (Google, Microsoft, PayPal) have moved to reject policies. Smaller organizations remain vulnerable. Additionally, SES’s own abuse prevention is reactive; AWS typically requires a manual report to suspend malicious accounts. Proactive monitoring of SES identity verification events is essential.

Prediction:

In the next 12–18 months, we will see a surge of phishing campaigns abusing Amazon SES, followed by similar attacks using Azure Communication Services and SendGrid. Email providers will respond by integrating real‑time verification of “via” headers with user‑facing warnings (“This email passed SPF/DKIM but originated from a shared cloud service – proceed with caution”). At the same time, AWS will likely introduce mandatory DMARC alignment checks for all outgoing SES emails (similar to Google Workspace’s enforcement), potentially disabling sending from domains that do not publish strict DMARC. Security awareness training will shift from “check the sender address” to “always verify the page content via a trusted mechanism” – making browser‑based attestation as common as HTTPS padlocks. Forward‑looking enterprises will adopt zero‑trust email architecture, where no email is trusted by default, even if it passes all authentication checks, relying instead on behavioral analysis and real‑time content signing.

▶️ Related Video (78% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Mayura Kathiresh – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: