Threat Actors Using AWS WorkMail in Phishing Campaigns

[carlospolop]

🤖 Automated Content Update

This PR was automatically generated by the HackTricks News Bot based on a technical blog post.

📝 Source Information

• Blog URL: https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns
• Blog Title: Threat Actors Using AWS WorkMail in Phishing Campaigns
• Suggested Section: AWS Pentesting -> AWS - Post Exploitation (or a new page under AWS - SES/Email services) covering: SES sandbox evasion via WorkMail, WorkMail org/domain/user provisioning for spam/phishing, and detection/telemetry gaps; plus a small technique note under AWS Methodology/Enumeration for 'permission confirmation via safe error forcing' in IAM APIs.

🎯 Content Summary

Title / context
Rapid7 MDR investigated a real-world AWS account takeover / cloud service hijacking case where threat actors used exposed long-term AWS access keys to build phishing/spam infrastructure inside the victim’s AWS account. Their objective was to leverage Amazon’s sender reputation and offload operational costs (email infrastructure + potential large bills) onto the victim, while also benefiting from monitoring and attribution gaps in AWS-native ...

🔧 Technical Details

Permission probing via “safe error” forcing in AWS APIs: attempt actions that reliably fail in a controlled way (e.g., iam:CreateUser for an existing username to trigger EntityAlreadyExistsException; iam:CreateLoginProfile with a password that violates policy to trigger PasswordPolicyViolationException) to confirm permissions while minimizing persistent changes and noisy artifacts.

SES sandbox evasion for phishing/spam: when ses:GetAccount shows the account is in the SES sandbox and ses:ListIdentities shows no verified identities (sandbox constraints: verified-only recipients, 200/24h, 1 msg/s), attackers may request removal and quota raises (e.g., servicequotas:RequestServiceQuotaIncrease to 100,000/day) but simultaneously pivot to AWS WorkMail. WorkMail abuse consists of creating organizations (workmail:CreateOrganization), verifying attacker-controlled domains using SES v...

🤖 Agent Actions

Updated HackTricks with AWS WorkMail phishing abuse and stealth IAM permission probing:

• Added a dedicated WorkMail post-exploitation page detailing SES sandbox bypass via WorkMail org/domain/user provisioning, sending paths (web vs SMTP), telemetry gaps, detection points, and commands/code.
• Documented intentional error-based permission confirmation in the IAM enumeration guide, plus references.
• Linked SES post-exploitation to the new WorkMail pivot guidance and added references.

Files changed:

• src/pentesting-cloud/aws-security/aws-post-exploitation/aws-workmail-post-exploitation/README.md
• src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md
• src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md

---

This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.

[carlospolop]

🔗 Additional Context

Original Blog Post: https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns

Content Categories: Based on the analysis, this content was categorized under "AWS Pentesting -> AWS - Post Exploitation (or a new page under AWS - SES/Email services) covering: SES sandbox evasion via WorkMail, WorkMail org/domain/user provisioning for spam/phishing, and detection/telemetry gaps; plus a small technique note under AWS Methodology/Enumeration for 'permission confirmation via safe error forcing' in IAM APIs.".

Repository Maintenance:

• MD Files Formatting: 575 files processed

Review Notes:

• This content was automatically processed and may require human review for accuracy
• Check that the placement within the repository structure is appropriate
• Verify that all technical details are correct and up-to-date
• All .md files have been checked for proper formatting (headers, includes, etc.)

Bot Version: HackTricks News Bot v1.0