Look for long lived access keys making SES reconnaissance calls such as GetAccount, GetSendQuota, ListServiceQuotas, ListIdentities, and GetIdentityVerificationAttributes. Those actions often show an attacker testing sandbox limits, enumerating verified senders, and checking whether sending is enabled. The strongest signal is the sequence of discovery actions followed by changes to sending status, especially when they come from a key that should not manage email operations.
Detecting the setup phase before SES becomes a spam cannon
The key is to treat SES as a cloud control-plane target first, not just an email service. Attackers usually need to learn quota limits, list verified identities, and confirm whether sending is allowed before they can turn an account into a reliable mail stream. That means detection should favour early reconnaissance sequences, not only the eventual burst of outbound mail.
In practice, the most useful signal is not one API call in isolation, but a short chain of SES discovery activity followed by a change in sending posture. A long-lived key that has never handled email operations before, then starts querying account state and verified identities, is often a better warning than volume-based email alerts that arrive after abuse has already started.
When these calls come from automation, build a baseline of which roles normally touch SES administration and which ones should never do so. That distinction matters because reconnaissance against SES often looks legitimate at the API level, so the detection question becomes whether the caller has an expected business reason to inspect mail configuration at all.
For background on the broader identity patterns that make this kind of abuse possible, NHI Mgmt Group’s Ultimate Guide to NHIs is a useful reference point, and its lifecycle guidance is reinforced by the NHI Lifecycle Management Guide.
The hard part is that SES abuse often starts with read-only discovery, which many teams under-monitor because it does not look destructive. If you only alert on send spikes, you miss the preparatory phase where the attacker is learning which identities are verified, what quota remains, and whether sandbox constraints can be removed or bypassed.
That is why detection logic should correlate SES API calls with the credential age, privilege scope, and recentness of prior activity. A key that suddenly performs SES enumeration after a quiet period is more suspicious than a known mail-sending workload making the same calls as part of normal operations.
Signals that separate reconnaissance from normal mail administration
The most defensible detections focus on behaviour that changes the operator’s knowledge state, not just their send count. Calls such as GetAccount, GetSendQuota, ListServiceQuotas, ListIdentities, and GetIdentityVerificationAttributes are useful because together they show an actor testing operational boundaries, mapping senders, and checking whether a path to delivery exists.
Sequence matters more than single-event detection. A benign administrator may occasionally inspect SES state, but a sequence of quota lookup, identity enumeration, and then configuration change is a much stronger indicator that the caller is preparing to send at scale. If the same identity then begins sending to new destinations or at a new cadence, the risk has moved from probing to active abuse.
Use this pattern with infrastructure context, not just API telemetry. Calls from unusual source IPs, unfamiliar automation environments, or identities that normally only read other AWS services are higher-signal than the same actions from a dedicated email ops role. For a broader view of how stolen cloud credentials are used before abuse scales, the 52 NHI Breaches Analysis is a useful companion, as is the broader AWS credential abuse pattern in Amazon AWS Hacked Accounts Crypto-Mining.
Do not overfit detections to one provider event name or one alert rule. The better approach is to treat SES as part of the cloud abuse chain: discovery, verification, permission change, delivery attempt, then scale. The earlier you anchor on that chain, the more likely you are to interrupt abuse before recipients ever see a message.
What good detection and response looks like for SES abuse
Good coverage combines API monitoring, identity baselining, and fast containment. You want alerts that can be triaged quickly into three buckets: expected admin activity, suspicious reconnaissance, and active delivery preparation. The main operational decision is whether the identity should be rotated or disabled immediately, or whether a narrower containment step is enough while you investigate.
Security teams should also preserve the evidence needed to explain intent: who issued the calls, from where, what identities were enumerated, whether verification status changed, and whether any new sending path was established. That record is important because SES abuse is often a prelude to phishing, business email compromise, or broader cloud account misuse. Related case studies in TruffleNet BEC Attack, Stolen AWS Credentials and Codefinger AWS S3 ransomware attack show how quickly stolen cloud credentials can be converted into high-impact abuse.
Practitioner takeaway: the best SES detections fire before send volume becomes visible, so prioritise rare control-plane activity, unexpected identity context, and the transition from reconnaissance to configuration change over outbound-mail thresholds alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | SES abuse depends on excessive or misused cloud access. |
| CIS 8 — Audit Log Management | Early SES abuse is detected through API-call sequences and identity context. | |
| Recommendation — Review and revoke unnecessary SES permissions for identities that should not manage mail. Log and alert on SES enumeration, quota checks, and verification-status changes. | ||
| MITRE ATT&CK | T1580 — Cloud Infrastructure Discovery | SES reconnaissance uses cloud control-plane discovery before abuse scales. |
| T1078 — Valid Accounts | Attackers commonly abuse legitimate AWS credentials to inspect and use SES. | |
| Recommendation — Map SES discovery calls to cloud discovery techniques and hunt for preparatory activity. Investigate legitimate-looking SES activity from accounts that should not touch email. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Continuous monitoring is needed to catch reconnaissance before large-scale sending starts. |
| PR.AC — Access Control Management | Restrict SES access to only the identities that truly need it. | |
| Recommendation — Monitor SES API behaviour for reconnaissance-to-send transitions. Limit SES permissions to approved roles and enforce least privilege. | ||
Related resources from NHI Mgmt Group
- How should security teams detect intrusion chains that abuse legitimate enterprise tools before ransomware encryption starts?
- How should security teams detect and block IAM abuse that creates persistent access for spam campaigns?
- Why is the abuse of NHIs a priority for security teams?
- How should security teams detect ransomware before encryption starts?
