What breaks when stolen AWS credentials can send mail through SES?

Why This Matters for Security Teams

When stolen AWS credentials can send mail through SES, the problem is not just unauthorised access. It is that a valid cloud identity can be turned into trusted outbound communication at speed, bypassing many perimeter-era assumptions. That makes fraud, phishing, invoice diversion, and business email compromise far harder to spot than ordinary malware traffic. The practical lesson is that identity compromise can become delivery compromise almost immediately.

Security teams often focus on blocking suspicious payloads, but SES abuse is usually a trust problem rooted in cloud-native permissions, sender reputation, and weak credential handling. NHIMG’s 52 NHI Breaches Analysis shows how often secrets exposure becomes a downstream identity abuse event rather than a simple leakage incident. External guidance from the OWASP Non-Human Identity Top 10 reinforces that over-permissioned machine identities create durable abuse paths. In practice, many security teams only discover SES misuse after customers, finance staff, or mail providers report the damage.

How It Works in Practice

SES is attractive to attackers because AWS already provides the trust wrapper: a legitimate account, a valid API surface, and mail that can be delivered through a reputable provider. Once credentials are stolen, the attacker does not need to break SMTP filtering in the classic sense. They can authenticate to AWS, use the allowed SES actions, and send messages that appear operationally normal from the outside.

The main controls that matter are identity-centric, not message-centric. Best practice is evolving toward short-lived credentials, tightly scoped IAM policies, and continuous detection of abnormal API use. That means replacing long-lived access keys where possible, using workload identity and JIT secrets where automation is involved, and limiting SES permissions to the smallest viable sender set. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because SES abuse typically begins with static secrets that survive far longer than the task they were meant to support.

• Constrain IAM so only approved applications can call SES send actions.
• Rotate or eliminate access keys that are not backed by workload identity.
• Alert on first-time sender regions, unusual recipient volume, and new IAM principals using SES.
• Use policy-as-code and runtime authorization checks rather than static allowlists alone.

For identity assurance, the NIST SP 800-63 Digital Identity Guidelines are relevant conceptually, even though SES abuse is a workload problem rather than a human login issue. The operational point is simple: if the identity can authenticate, it can often send. These controls tend to break down in legacy AWS environments where shared keys, broad SES permissions, and weak visibility into mail-sending workloads all coexist.

Common Variations and Edge Cases

Tighter mail controls often increase operational overhead, so organisations have to balance delivery convenience against abuse resistance. That tradeoff becomes visible in environments that rely on shared service accounts, multi-account AWS setups, or third-party integrations that send mail on behalf of many teams.

There is no universal standard for this yet, but current guidance suggests treating SES as a privileged capability rather than a commodity API. If marketing, billing, support, and application notifications all share one sending path, compromise of a single key can create broad blast radius. NHIMG’s Guide to the Secret Sprawl Challenge is directly relevant because SES abuse frequently emerges from scattered secrets with unclear ownership. The same pattern appears in broader cloud compromise research, including NHIMG’s 230M AWS environment compromise, where weak identity hygiene amplifies downstream impact.

One important edge case is legitimate automation that sends high-volume mail. Those workloads can look abusive unless baselined by sender, schedule, and recipient patterns. Another is incident response: blocking SES too aggressively can cut off customer notifications or password reset flows. The better pattern is scoped containment, temporary credential revocation, and per-workload controls rather than a blanket shutdown. Mature environments also validate that SES permissions cannot be reused across unrelated business units, because that is where abuse and false positives both become harder to control.

Related resources from NHI Mgmt Group

• What breaks when stolen cloud credentials are allowed to authenticate without strong MFA?
• What breaks when stolen credentials are reused but not correlated across systems?
• What breaks when NHI credentials are long-lived and hard to monitor?
• What breaks when Active Directory attacks are only monitored through SIEM logs?