What happens when an attacker can combine SES identity enumeration with sending enablement?

How SES identity enumeration turns into a sending abuse path

The important shift is not the enumeration itself, but the trust signal it creates. Once an attacker knows which SES identities are verified and which addresses or domains are allowed to send, they can pick the most credible origin for outbound mail and move from discovery into abuse. In practice, that means the attacker is no longer guessing at legitimacy, they are selecting it.

That matters because SES is designed to deliver mail from identities the organisation already trusted and verified. If sending is enabled, the attacker can leverage that trust to bypass the usual skepticism recipients apply to unknown senders, especially when the messages are brief, urgent, or impersonate internal workflows. The abuse is therefore an access problem as much as a mail problem.

When teams want a deeper view of the identity side of the issue, NHIMG’s Ultimate Guide to NHIs is the best broad reference for governance, lifecycle and credential risk across non-human identities.

Why enabled SES identities are attractive to phishers

Verified SES identities are useful to attackers because they provide both legitimacy and scale. A trusted domain can improve deliverability, reduce immediate suspicion, and allow the campaign to keep running until defenders notice user reports or unusual send patterns. If the account is not sandboxed, the attacker also avoids the artificial limits that would otherwise slow or contain abuse.

The practical consequence is that a single compromised or misused SES identity can become a launch point for business email compromise style activity, internal impersonation, or external phishing that appears to come from the organisation itself. That is why send enablement is the decisive control point, not just identity verification. Verification proves ownership; enablement permits operation.

For a concrete catalogue of how identity and credential abuse become real incidents, NHIMG’s 52 NHI Breaches Analysis is a useful companion because it shows the attack path from access to abuse across many real cases.

Containment, reporting and control points after abuse is detected

Once abuse is suspected, the response should be aimed at stopping further mail and reducing recipient harm, not just confirming the initial source. That usually means disabling or restricting the sending path, blocking the affected domain or sender patterns where possible, warning users that messages may look legitimate, and preserving evidence for AWS support or abuse reporting.

The failure mode is often delay. SES abuse can scale faster than manual review if a trusted identity is left active, so defenders should assume that the first wave of phishing may already be in mailboxes before detection. The right question is therefore whether the sending identity can still operate, not whether the attacker has already caused visible damage.

For practitioners who want the broader identity-control context, the OWASP Non-Human Identity Top 10 is a useful external lens on overprivilege, secret exposure and lifecycle weaknesses that commonly enable this kind of misuse.

Risk and Threat Considerations

SES identity enumeration is risky because it gives an attacker a map of trusted outbound identities before any abuse begins. If sending is enabled, that trust can be converted into phishing capability quickly, and the organisation may also inherit the operational and reputational cost of mail delivered under its own name.

Failure mechanism: An attacker enumerates verified SES identities, selects a trusted domain or address, and uses enabled sending to deliver convincing phishing or impersonation mail at scale.

Impact: Recipients are more likely to trust the message, abuse can spread before containment, and the organisation may face user harm, brand damage, and abuse-handling overhead with AWS and internal stakeholders.

Practitioner Guidance

What to prioritise: Treat SES send enablement as the real blast-radius control. If an identity does not need to send, keep it disabled or sandboxed, because a verified but inactive identity is far less useful to an attacker than a verified and operational one.

What to verify: Confirm which verified domains and addresses are actually permitted to send, who owns them, and whether the current permissions still match business need. Review mail logs for unusual volume, new sender patterns, and messages that resemble internal or billing workflows.

Practitioner takeaway: The security boundary is not just identity verification, it is whether that identity can still produce trusted mail in the real world, so containment should focus on send authority and blast radius first.

Related resources from NHI Mgmt Group

• What happens when an attacker is hired into a remote role using a synthetic identity?
• How should security teams detect AWS SES abuse before an attacker starts sending mail at scale?
• What do teams get wrong about detecting attacker persistence in cloud identity and access management?
• What happens when identity platforms do not provide enough logging to investigate intrusions?