They sent the phish from your own email service
An attacker in your AWS account does not need a lookalike domain. They send the phish through your own SES, from your real domain, signed and trusted. Here is the abuse, and how to shut it.
The most convincing phishing email comes from a real, trusted sender. Sometimes that sender is you.
What it is
Amazon SES sends email on behalf of your verified domains, with your DKIM, SPF, and DMARC alignment. An attacker who compromises an AWS identity with SES permissions, in an account that is out of the SES sandbox, sends phishing or business-email-compromise mail from your own domain, fully authenticated, to your staff, customers, or partners. It is T1078 (valid accounts) into T1566 (phishing) and T1534 (internal spearphishing).
Why it works
The email is DKIM-signed by your real domain and aligns with DMARC, so it passes authentication and looks legitimate to both filters and recipients. There is no lookalike domain to notice.
How to detect it
In CloudTrail and SES sending events, watch for a spike in SES sends, new verified identities or configuration sets, or sends from a principal that does not normally use SES, especially internal recipients or unusual volume.
The fix that holds
Least-privilege SES permissions, and keep accounts that do not send mail in the SES sandbox. Alert on SES send-rate spikes and new identities or config sets, restrict who can manage SES, and watch for internal-to-internal sends. Treat unexpected SES use as account compromise: rotate and investigate.
Practice it
We built an SES abuse scenario in GraphLattice Range so teams learn to catch phishing sent from their own domain and lock SES down.