“Legitimate” phishing: how attackers weaponize Amazon SES to bypass email security

What Happened

Cybercriminals are using stolen access keys to hijack Amazon's legitimate email service, Amazon SES, to send scam emails. Organizations that accidentally leak their Amazon access keys are having their infrastructure abused to target unsuspecting victims. This matters because emails sent this way easily bypass standard security filters and look completely real, making it much harder to spot fake login pages or fraudulent payment requests. To protect against this, organizations should secure their Amazon access keys, use multi-factor authentication, and train employees to double-check unexpected payment requests or document links.

Key Takeaways

• Attackers are increasingly abusing Amazon SES to send phishing and BEC emails that bypass standard email security checks (SPF, DKIM, DMARC).
• Compromise typically occurs via leaked AWS IAM keys found in public repositories, ENV files, Docker images, or S3 buckets.
• Phishing links often direct victims to credential harvesting forms hosted on legitimate AWS infrastructure, such as S3 buckets.
• BEC campaigns utilize fabricated email threads and forged financial documents to trick victims into authorizing fraudulent payments.
• Blocking Amazon SES IP addresses is ineffective and causes significant false positives due to the platform's widespread legitimate use.

Affected Systems

• AWS IAM
• Amazon SES
• Corporate Email Systems

Attack Chain

Attackers first scan public repositories, Docker images, and S3 buckets using tools like TruffleHog to find leaked AWS IAM keys. Once compromised, they use these keys to access Amazon SES and verify sending limits. They then launch mass phishing or BEC campaigns using custom HTML templates, sending emails that pass SPF, DKIM, and DMARC checks. Victims click links leading to credential harvesting pages hosted on AWS S3 or are tricked into authorizing fraudulent payments via fabricated email threads.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No

The article does not provide specific detection rules or queries.

Detection Engineering Assessment

EDR Visibility: None — The attack infrastructure is entirely cloud-based (AWS SES/S3) and email-based. EDR will only have visibility if a malicious payload is downloaded to the endpoint, which is not the primary TTP described here. Network Visibility: Medium — Network proxies can log traffic to the S3 buckets hosting the phishing pages, but the traffic is encrypted and directed to legitimate AWS domains. Detection Difficulty: Hard — Detecting this requires distinguishing between legitimate and malicious use of highly trusted Amazon infrastructure, which is prone to massive false positive rates.

Required Log Sources

• AWS CloudTrail
• Email Gateway Logs
• Web Proxy Logs

Hunting Hypotheses

Hypothesis	Telemetry	ATT&CK Stage	FP Risk
Attackers are using newly created or previously dormant AWS IAM users to send high volumes of email via Amazon SES.	AWS CloudTrail	Execution	Medium
Phishing emails are bypassing filters by using legitimate Amazon SES infrastructure but containing links to suspicious S3 buckets.	Email Gateway Logs	Delivery	High

Control Gaps

• Standard Email Authentication (SPF/DKIM/DMARC)
• Reputation-based IP blocklists

Key Behavioral Indicators

• Message-ID headers ending in .amazonses.com combined with suspicious sender domains
• Email bodies containing links to raw S3 buckets (amazonaws.com) used for credential harvesting

False Positive Assessment

• High. Blocking Amazon SES IP addresses or domains will result in blocking a massive amount of legitimate transactional and marketing emails from various businesses.

Recommendations

Immediate Mitigation

• Audit AWS IAM users and immediately revoke any exposed, leaked, or unused access keys.
• Rotate active IAM keys.

Infrastructure Hardening

• Transition from IAM access keys to AWS IAM roles for better permission management.
• Implement IP-based access restrictions for AWS services.
• Use AWS Key Management Service (KMS) for centralized encryption.
• Implement the principle of least privilege for all IAM configurations.

User Protection

• Deploy robust email security solutions capable of analyzing email content, context, and anomalies, rather than relying solely on sender reputation.
• Implement strict multi-factor authentication (MFA) for all corporate accounts.

Security Awareness

• Train employees to verify unexpected payment requests or document links via alternate communication channels.
• Educate developers on secure coding practices to prevent hardcoding secrets in repositories, Docker images, or ENV files.

MITRE ATT&CK Mapping

• T1586.002 - Compromise Accounts: Cloud Accounts
• T1078.004 - Valid Accounts: Cloud Accounts
• T1566.001 - Phishing: Spearphishing Attachment
• T1566.002 - Phishing: Spearphishing Link
• T1588.002 - Obtain Capabilities: Tool

Additional IOCs

• Domains:
  • amazonses[.]com - Root domain for Amazon SES, frequently seen in Message-IDs of these campaigns.
  • amazonaws[.]com - Root domain for AWS services, frequently used to host phishing forms via S3 buckets.
• Other:
  • TruffleHog - Open-source secret scanning tool abused by attackers to find leaked AWS IAM keys.