Cybercriminals are exploiting Amazon Simple Email Service to send authenticated phishing emails that look legitimate, pass basic email checks and reach users through a trusted cloud delivery channel, raising fresh concern over the misuse of mainstream internet infrastructure.The tactic gives attackers a powerful advantage. Instead of relying on obviously suspicious domains or poorly configured mail servers, they abuse legitimate Amazon SES accounts, often by using stolen or exposed AWS access keys. Once inside, they can send large volumes of email through infrastructure that many corporate filters treat as reputable.
Amazon SES is widely used by businesses, developers and marketing teams to send transactional messages, password resets, account alerts, newsletters and customer notifications. Its credibility is precisely what makes the abuse harder to detect. Messages routed through the service may satisfy authentication checks such as SPF, DKIM and DMARC, reducing the likelihood that traditional defences will reject them at the gateway.
Security researchers tracking the activity have identified phishing lures designed to imitate document-signing services, payment notices, invoice exchanges and corporate workflow alerts. A common pattern involves an email asking the recipient to review or sign a document. The embedded link then redirects to a fake login page, sometimes hosted on infrastructure bearing an amazonaws. com domain, giving the victim another reason to believe the page is safe.
The campaigns go beyond standard credential theft. Some attacks show signs of business email compromise, with fabricated message threads, fake invoices and payment requests aimed at finance departments. These emails are crafted to appear as part of an ongoing exchange between staff and service providers, increasing pressure on employees to act quickly.
The method reflects a broader shift in phishing operations, where attackers no longer depend only on spoofing a sender’s identity. They increasingly seek access to legitimate platforms that can send authenticated mail on their behalf. This approach undermines controls that were designed mainly to detect impersonation, not abuse from inside a trusted sending ecosystem.
The route into Amazon SES accounts is often predictable. Long-term AWS access keys exposed in code repositories, configuration files, container images, backups and public storage buckets can be harvested automatically. Tools used to scan for leaked secrets allow attackers to find keys at scale, test permissions, check sending limits and then launch phishing runs before the legitimate account owner notices the misuse.
The risk is heightened because blocking Amazon SES outright is rarely practical. Many companies receive legitimate messages from the service every day, including business-critical alerts and customer communications. Blocking the delivery source could disrupt genuine mail flows, leaving security teams to make more precise decisions based on message content, sender behaviour, URL analysis and account reputation.
Cloud service abuse has become a persistent challenge for defenders. Similar tactics have been observed across other cloud-based mail and collaboration systems, including AWS WorkMail and identity-related workflows. The common thread is the attacker’s preference for trusted infrastructure, where malicious activity can blend into normal enterprise traffic.
Amazon’s own documentation states that SES users must verify the email addresses or domains they send from and that the service supports DKIM and DMARC alignment through SPF, DKIM or both. The company also says it applies content filtering and may pause accounts that send spam, malicious material or poor-quality mail. Abuse can be reported with full email headers so investigators can trace the sending account and related activity.
For organisations using AWS, the issue places renewed importance on identity and access management. Least-privilege permissions, multi-factor authentication, short-lived credentials, regular key rotation and restrictions based on network location can reduce exposure. Continuous scanning for leaked secrets across repositories and build environments has become essential, particularly for teams running automated development pipelines.
Email security teams also need to treat authenticated messages with caution. Passing SPF, DKIM and DMARC should not be treated as proof of safety. Those checks confirm aspects of sending legitimacy, but they do not guarantee that the sender’s account has not been compromised or abused.
Topics
Technology