Two independent research teams have now mapped the same attack pipeline from different angles. Kaspersky’s Securelist group documented a sharp rise in phishing and business email compromise campaigns abusing Amazon Simple Email Service in early 2026, while cloud security firm Wiz separately traced the technical mechanics: how a leaked AWS access key becomes a working phishing platform in minutes. Neither team found a flaw in SPF, DKIM, or DMARC. They found something more uncomfortable: attackers sending mail through infrastructure that legitimately passes all three, because it is Amazon’s own infrastructure, rented with someone else’s stolen credentials.
From Leaked Key to Production Sending Quota
The pipeline starts with reconnaissance that has nothing to do with email. Automated bots, often built on open-source secret-scanning tools, sweep public GitHub repositories, exposed .env files, Docker images, and misconfigured S3 buckets looking for AWS IAM access keys developers left behind. Once a key turns up, attackers check what it can do with a simple GetCallerIdentity call. A key name containing “ses” is often enough to signal it was provisioned for Amazon’s email service.
The next move is the one that turned this from a nuisance into a scaled weapon. Amazon caps new SES accounts in a sandbox mode with tight sending limits until a human requests production access. Researchers observed attackers automating that request, firing PutAccountDetails calls across every AWS region within seconds of each other, pushing the account into production mode region by region and unlocking a default quota of tens of thousands of emails per day, multiplied by however many regions they activate at once.
Two Lures, One Trusted Envelope
With sending access secured, Kaspersky documented two distinct campaign types riding the same infrastructure. The first impersonates e-signature services, most commonly Docusign, asking the recipient to click through and review a document. The link resolves to amazonaws.com, infrastructure most users and plenty of security filters treat as inherently safe, before redirecting to a credential harvesting page. The second is a more patient business email compromise play: a fabricated thread made to look like an ongoing conversation between an employee and a vendor about an outstanding invoice, sent to the target’s finance team with an urgent request to release payment.
Why Authentication Passes Cleanly
This is the part worth sitting with. SPF, DKIM, and DMARC exist to answer one question: did the domain owner authorize this infrastructure to send on their behalf. They were never built to ask a second question that matters just as much here: is the party currently holding the keys to that infrastructure still the party the domain owner trusts. Amazon SES is authorized infrastructure. A stolen IAM key does not change that fact from the protocol’s point of view, so mail sent through a hijacked SES account authenticates exactly as cleanly as mail sent by the account’s rightful owner.
Wiz’s research adds a sharper detail. Attackers verified new identities in the compromised account for domains they controlled outright, which is expected. But they also found attackers reusing domain identities that were already verified in the account before it was stolen, specifically domains with weak or unenforced DMARC policies, letting them spoof a real, previously trusted brand through infrastructure that brand’s own team had set up. Blocking Amazon’s sending IP ranges is not a workable defense either, since that would take down enormous volumes of legitimate SES traffic used by ordinary businesses worldwide.
Closing the Gap on Both Ends
Treat cloud sending credentials as an identity problem, not an email problem. Scope IAM policies to least privilege, move from long-lived static keys to short-lived roles wherever SES automation allows it, enforce MFA on the accounts that manage those credentials, and scan your own repositories and configuration backups for exposed keys before an attacker’s bot finds them first.
Enforce DMARC at full coverage on every domain identity you have ever verified in a cloud sending service, not only your primary domain. Wiz’s finding was specific: it was the identities with weak DMARC that got reused for spoofing. A forgotten subdomain or legacy identity with no policy is exactly the kind of loose end this campaign is built to find.
Watch the account, not just the inbox. A burst of region-spanning API calls, a sudden production-access request, or a new identity verification nobody on the team initiated are visible well before the first phishing message goes out. That telemetry belongs in the same monitoring pipeline as your DMARC aggregate reports.
On the receiving side, remember what DMARC alignment actually certifies. It confirms the sending infrastructure was authorized by a domain owner at some point, not that today’s message came from the same hands that were trusted originally. Messages that clear authentication still need content and behavioral inspection layered on top, especially the ones asking finance to move money.
The Takeaway
Trusted cloud infrastructure being turned into a phishing platform is not a new idea, but the scale here is a reminder of how much of the defense now sits upstream of the inbox, in credential hygiene and DMARC coverage most teams never think to check. A domain with a strong DMARC policy and clean IAM practices gives an attacker nothing to work with, even after they find a working key.
Full DMARC coverage across every domain and subdomain identity you own closes off exactly the kind of reused, weakly protected identity this campaign relies on. Sign up for free to Excello Mail to get the visibility and enforcement tools to find those gaps before someone else does.