Amazon SES abused by leaked keys

Email authentication is supposed to help you trust what lands in your inbox. But this story is about the opposite — attackers using real cloud email plumbing so their phishing looks cleaner, not sloppier. That is what made Microsoft’s new writeup land. The campaign did not lean on obvious spoofing. It used legitimate mail services, attacker-controlled domains, and a multi-step adversary-in-the-middle flow to steal credentials and session tokens from tens of thousands of targets, mostly in the U.S. (microsoft.com) ### Why does Amazon SES matter here? Amazon SES is Amazon’s bulk email service. Companies use it for receipts, alerts, newsletters, and app mail. If an attacker gets valid AWS credentials or otherwise controls an SES setup, the mail can pass the normal trust checks because i(microsoft.com)essages look fully authenticated to receiving systems. (docs.aws.amazon.com) ### So did the attackers “bypass” SPF, DKIM, and DMARC? Not in the usual exploit sense. They did something more annoying — they worked with the rules instead of breaking them. DMARC is built on SPF and DKIM alignment. If the sender controls the domain and the SES configuration, the message can authenticate correctly even though the campaign it(docs.aws.amazon.com)ot forged junk failing authentication checks. It is authenticated bad mail. (docs.aws.amazon.com) ### What did the phishing email look like? The lure was a “code of conduct” message. Microsoft said the campaign used fully authenticated emails from attacker-controlled domains and pushed victims through multiple stages before the credential prompt ever appeared. That included CAPTCHA and staging pages — basically little trust-building speed bumps that make the flow feel more legitimate and also screen out some automated defenses. (microsoft.com) ### Where does the AiTM piece come in? AiTM means adversary-in-the-middle. Instead of just stealing a password on a fake login page, the attacker sits between the victim and the real sign-in flow. That lets the attacker capture credentials, MFA inputs, and the session materi(microsoft.com)t needing to trigger MFA again. (microsoft.com) ### Why is that worse than ordinary phishing? Because the inbox defenses and the identity defenses both get weaker at the same time. The email looks cleaner because it is sent through legitimate infrastructure. Then the login theft is stronger because AiTM can grab the live (microsoft.com) fail — several layers were made less useful together. (microsoft.com) ### Does this mean SES itself is broken? No. The core issue is abuse of legitimate services and credentials, not proof that SES cannot authenticate mail correctly. AWS’s own docs are pretty clear about how SES signs and authenticates messages, and AWS has separately publishe(microsoft.com)is itself under attacker control. (docs.aws.amazon.com) ### What should defenders do first? Start with the boring stuff — because here it is the important stuff. Revoke exposed AWS keys, rotate SES and IAM credentials, lock down who can send through SES, and watch outbound mail for new identities, regions, or volume spikes. Then tighten the identity side: phishing-resistant MFA where possible, ses(docs.aws.amazon.com)ign-in. If the mail is authenticated, the catch is you have to get much better at spotting whether the sender behavior is normal. (docs.aws.amazon.com) ### Bottom line? This campaign matters because it shows phishing getting more “legitimate,” not less. Real cloud services, valid authentication, and live-session theft are now being combined into one clean chain — and that makes old inbox trust shortcuts a lot less reliable. (microsoft.com))