Amazon SES

Wiz Research described a campaign from May 2025. An attacker obtained an AWS access key provisioned for SES; how it leaked is unknown. Within ten seconds they had requested production access in every AWS region. AWS approved the request, which was written in generic text and cited an unrelated construction company’s website. With production access, the attacker verified their own domains as senders and ran a phishing campaign about tax forms. Two attempts to go further failed because the key lacked the permissions: opening a support case to raise the quota, and attaching a new IAM policy to itself. Wiz calls SES abuse a primary way attackers make money from leaked AWS keys, because the mail goes out from the victim’s account and reputation.

• The application’s key gets only the permissions it needs to send. It should not be able to request production access, verify new identities or change IAM; here those permissions were the whole attack. An agent writing the IAM policy will often reach for ses:*, which is our inference, not Wiz’s finding.
• Block SES entirely in AWS accounts that do not send email, with a service control policy, as Wiz recommends.
• Log and alert on SES configuration calls — requests for production access, new sender identities — not only on sending volume.
• Rotate keys, and treat a dormant key that suddenly becomes active as compromised.

• A new account starts in the sandbox, in each region. Mail reaches only verified addresses until production access is granted, and the request is reviewed — plan for it before launch day.
• Handle bounce and complaint notifications. High rates can pause sending for the whole account.