Graphical visualization of the attack | Image: Rapid7
A new investigation by Rapid7 reveals that cybercriminals have found a clever way to bypass the strict anti-abuse controls of Amazon Simple Email Service (SES) by pivoting to a less scrutinized neighbor: AWS WorkMail.
The incident, detailed in a new report by Rapid7’s Managed Detection and Response (MDR) team, illustrates how attackers are “abusing native AWS email services to build phishing and spam infrastructure inside a compromised cloud environment”.
The attack begins with a common blunder: exposed credentials. Using tools like TruffleHog, attackers hunt for leaked AWS keys in public repositories. Once inside, their goal is often to hijack the victim’s infrastructure to launch massive spam or phishing campaigns.
However, AWS has a built-in safety valve. New SES accounts are placed in a “sandbox,” limiting them to 200 emails a day and preventing them from emailing unverified addresses.
In the case analyzed by Rapid7, the attackers hit this wall. But instead of giving up, they improvised. “Rather than remaining idle while SES sandbox removal and quota increases were pending, the attacker pivoted to AWS WorkMail, which offers an alternative email-sending pathway with significantly fewer upfront restrictions”.
AWS WorkMail is designed for corporate email and calendaring, not bulk sending. But crucially, it lacks the strict sandbox model of SES.
“Emails can be sent immediately to external, unverified recipients. Additionally, WorkMail supports significantly higher sending volumes than SES sandbox limits,” the report notes.
By creating legitimate-looking domains like ipad-service-london[.]com and provisioning mailboxes within the victim’s WorkMail environment, the attackers could start their campaigns immediately. This “staged approach allows attackers to establish sender reputation, validate infrastructure, and maintain operational momentum while bypassing many of the friction points intentionally built into SES”.
The brilliance of this pivot lies in its stealth. The spam isn’t coming from a shady server; it’s coming from legitimate AWS infrastructure owned by the victim.
“This allows the threat actor to leverage Amazon’s high sender reputation to masquerade as a valid business entity, with the ability to send email directly from victim-owned AWS infrastructure”.
Furthermore, the attackers discovered that sending email via WorkMail’s SMTP endpoint creates a significant blind spot. “Emails sent via SMTP do not generate CloudTrail events… creating a significant blind spot for defenders”.
Rapid7 advises that the best defense is to lock down unused services before an attacker can exploit them. “To mitigate this class of abuse, organizations should combine preventive guardrails with focused detection”.
For organizations that don’t use WorkMail, the report recommends explicitly blocking it using Service Control Policies (SCPs). For those that do, strict monitoring of new organization creation and domain verification is essential to spotting the pivot before the spam floodgates open.
Related Posts:
- 50,000 Emails a Day: How a Cloud Flaw Is Fueling Phishing Campaigns
- Cloud Abuse: TruffleNet BEC Campaign Hijacks AWS SES and Portainer to Orchestrate 800+ Malicious Hosts
- New Phishing Campaign Targets AWS Accounts: Security Experts Warn
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.