Leaked AWS keys let phishers send through Amazon SES and pass SPF, DKIM and DMARC

In May 2026 Kaspersky reported that phishing and business email compromise (BEC) messages were increasingly being sent through hijacked Amazon Simple Email Service (SES) accounts. The way in is the problem developers can actually fix: AWS IAM access keys left in public repositories, .env files, Docker images and backups. If your keys can call SES, a leaked key does more than run up a bill. It hands attackers a sending pipeline that receiving mail servers trust.

What happened

On 4 May 2026, Kaspersky anti-spam expert Roman Dedenok published research on Securelist describing phishing sent through legitimate Amazon SES infrastructure. Kaspersky says this activity rose in January 2026 and stayed fairly steady through the first quarter. BleepingComputer covered the research the same day and later added a clarification: the increase reflects Kaspersky's own telemetry, not a measured industry-wide trend. Kaspersky followed up with a press release on 11 May.

According to the research, attackers usually get into SES with leaked IAM access keys. They find those keys with bots built on TruffleHog, the open-source secret scanner, then check what each key is allowed to do and how much it can send before starting a campaign. Kaspersky described two main kinds of lure:

• E-signature phishing. Fake DocuSign-style "review and sign" notifications that send victims to credential-harvesting sign-in forms hosted on amazonaws.com.
• BEC. A made-up email thread between an employee and a supplier about an unpaid invoice, sent to the finance team with PDF attachments containing bank details. These messages contained no links or QR codes, so link-scanning defenses had nothing to inspect.

Amazon told BleepingComputer that it acts on reports of terms-of-service violations and pointed customers to its guidance on exposed credentials. Suspected abuse can be reported to AWS Trust & Safety.

Who is affected

• AWS account owners whose IAM users have long-lived access keys with ses:SendEmail, ses:SendRawEmail or broad ses:* permissions, especially keys that have ever been committed to Git, baked into container images or stored in public S3 buckets.
• Teams that use SES for transactional mail. A hijacked account can damage your sending reputation, push you into an SES review or sending pause, and leave you with the bill.
• Finance and accounts-payable staff anywhere, because the messages pass the authentication checks they've been told to rely on.

What it means for developers and engineering teams

SPF, DKIM and DMARC answer one question: was this message sent by infrastructure the domain owner authorized? They say nothing about whether the content is honest. When attackers send through a real SES account, the mail goes out from Amazon's sending IPs and carries Amazon's signatures, and Kaspersky notes that Message-ID headers typically contain .amazonses.com. The messages pass authentication. Blocking SES IP ranges isn't a realistic response, because it would block a huge amount of legitimate mail along with the abuse.

The weak link is credential handling in the build and deploy pipeline. Common ways keys leak:

• A key committed to Git and later "deleted," while it stays in history and in every fork.
• ENV AWS_SECRET_ACCESS_KEY=... or a copied .env file in a Dockerfile layer pushed to a public registry. Layers can be extracted even if a later layer removes the file.
• Config backups or Terraform state left in a public bucket.

Secret-scanning bots watch public sources continuously, so the time between a leak and the first abuse can be very short. The fix isn't faster rotation alone. Design the system so that a leaked static key either doesn't exist or can't do much.

What to do now

1. Find long-lived keys. Run aws iam list-access-keys --user-name <user> and check the IAM credential report (aws iam generate-credential-report) for old or unused keys. Delete any you don't need.
2. Replace static keys with roles. Use IAM roles for EC2, ECS and Lambda, and OIDC federation for CI (GitHub Actions and GitLab CI both support assuming an AWS role without stored secrets).
3. Scope SES permissions tightly. Grant only ses:SendEmail/ses:SendRawEmail on specific identity ARNs, and add a ses:FromAddress condition so a stolen credential can't send as arbitrary senders.
4. Restrict where credentials work. Add aws:SourceIp or aws:SourceVpce conditions to policies for keys that have to stay static.
5. Scan before you push. Run TruffleHog or gitleaks as a pre-commit hook and in CI, for example trufflehog git file://. --only-verified. Turn on GitHub push protection.
6. Watch SES usage. Set CloudWatch alarms on SES send volume, bounce rate and complaint rate, and alert on CloudTrail events such as VerifyDomainIdentity, CreateEmailIdentity or UpdateAccountSendingEnabled from unexpected principals.
7. Rotate immediately if a key leaks. Deactivate the key, check CloudTrail for what it was used for, and contact AWS Support.
8. Brief your finance team. Payment-change requests should be confirmed through a known phone number or channel, whatever the email authentication results say.

Related on TechLogHub

• Authorization: least privilege, explained
• GitHub Actions vs GitLab CI: both support OIDC-based cloud credentials
• Resend vs SendGrid vs Postmark: transactional email providers compared

Sources

• Kaspersky Securelist: How attackers weaponize Amazon SES to bypass email security (4 May 2026)
• Kaspersky press release (11 May 2026)
• BleepingComputer: Amazon SES increasingly abused in phishing to evade detection