Full Report
Exposed cloud credentials become the launchpad for mass phishing, highlighting email services as a prime target in cloud exploitation campaigns.
Analysis Summary
# Incident Report: AWS SES Abuse for Mass Phishing Launch
## Executive Summary
Wiz Research identified a sophisticated SES abuse campaign in May 2025 where an attacker leveraged previously compromised AWS Access Keys to take control of an AWS SES account. The primary goal was to move the SES account out of the restrictive "sandbox" mode into "production" to enable large-scale, low-cost phishing operations launched from trusted domains. The attack showcased novel multi-regional attempts to bypass SES restrictions.
## Incident Details
- Discovery Date: May 2025 (Detection via Wiz Defend rules)
- Incident Date: May 2025
- Affected Organization: Undisclosed victim organization utilizing AWS.
- Sector: Technology/Cloud Service User (Implied)
- Geography: Global (Attack targeted multiple AWS regions)
## Timeline of Events
### Initial Access
- Date/Time: Unknown, prior to May 2025
- Vector: Compromised AWS Access Keys. (Likely accidental public exposure in code repositories or theft from workstations).
- Details: Attacker obtained keys later confirmed to have SES permissions (indicated by "ses-" in the key name).
### Reconnaissance & Sandbox Escape Attempt
- **Date/Time:** Within a very short period following key use in May 2025.
- **Vector:** Legitimate AWS API calls using compromised credentials.
- **Details:**
1. Attacker executed `GetCallerIdentity` to confirm the key's SES association.
2. Probed SES configuration using subsequent calls (`GetSendQuota`, `GetAccount`) to determine if the account was in the restricted "sandbox" mode.
3. **Novel Technique:** Within a ten-second burst, the attacker issued multiple `PutAccountDetails` requests across **all AWS regions** simultaneously, attempting to transition the account out of the sandbox into production mode, likely seeking higher send quotas or evasion of region-specific restrictions.
### Lateral Movement
Not explicitly detailed in the initial stages, as the attack remained focused within the compromised AWS account boundary, specifically leveraging AWS SES capabilities.
### Data Exfiltration/Impact (Intended)
- **Impact:** Preparation for large-scale phishing campaigns targeting external recipients. Attacker aimed to utilize the victim’s trusted domain to launch attacks, shifting financial and reputational costs.
### Detection & Response
- **Detection:** Identified by Wiz Research team using automated threat detection rules monitoring TTPs in the cloud environment.
- **Response Actions:** Wiz analyzed the activity, identified the novel techniques (multi-regional `PutAccountDetails`), and codified these patterns into new detection rules to cover subsequent stages of the kill chain for the victim and other customers.
## Attack Methodology
- **Initial Access:** Compromised AWS Access Keys (T1078.004).
- **Persistence:** Not fully detailed, but access was maintained via the stolen keys.
- **Privilege Escalation:** Not explicitly detailed, but the goal was escalating privileges *within SES* from sandbox to production mode.
- **Defense Evasion:** Using legitimate AWS APIs; launching attacks from an established, trusted cloud provider (AWS).
- **Credential Access:** Assumed via accidental exposure or workstation theft (pre-incident).
- **Discovery:** Targeted reconnaissance on SES configuration (`GetSendQuota`, `GetAccount`, `GetCallerIdentity`) (T1526).
- **Lateral Movement:** Not applicable in the traditional sense; focus was on **privilege escalation within the SES service** across regions (T1098).
- **Collection:** Setting up infrastructure for mass email sending.
- **Exfiltration:** Preparation for mass phishing dissemination, not direct data exfiltration from core systems.
- **Impact:** Abuse of organizational trust and infrastructure for phishing delivery.
## Impact Assessment
- **Financial:** Costs likely shifted to the victim (AWS fees for high volume sending, remediation costs).
- **Data Breach:** No direct mass data exfiltration mentioned; the impact was the compromise of email sending capabilities.
- **Operational:** Potential disruption if the attacker successfully overwhelmed SES resources or if remediation required locking down the AWS account.
- **Reputational:** High risk of reputational damage due to being the apparent source of high-volume phishing traffic sent from trusted domains.
## Indicators of Compromise
*Note: Specific indicators must be defanged based on the context provided.*
- **Network indicators:** High volume, rapid succession of `PutAccountDetails` calls originating from the compromised credentials across multiple AWS regions.
- **File indicators:** Not provided/applicable to this stage.
- **Behavioral indicators:** Attempts to transition SES account from sandbox constraints to production limits immediately after initial access.
## Response Actions
- **Containment:** Undisclosed, but would involve immediate rotation/revocation of the compromised AWS Access Keys and potentially service control policies (SCPs) to restrict `PutAccountDetails` actions.
- **Eradication:** Removal of any newly verified sender identities created by the attacker within SES.
- **Recovery:** Hardening of key management and access controls; potentially reverting SES account status if production mode was achieved.
## Lessons Learned
- Compromised cloud credentials remain a primary and highly effective initial access vector.
- Attackers are actively seeking methods to bypass SES sandbox restrictions to weaponize services for large-scale phishing.
- The move to multi-regional, rapid configuration changes (e.g., multi-regional `PutAccountDetails`) is an emerging, novel technique used to maximize reach or evade region-specific security policies.
## Recommendations
- Implement strict runtime monitoring to detect rapid, multi-regional configuration API calls like `PutAccountDetails` from automated or anomalous sources.
- Enforce strong least privilege for all IAM users and roles, specifically limiting the ability to request quota increases or production mode transitions for sensitive services like SES.
- Regularly audit and audit the usage patterns associated with newly exposed access keys, especially those flagged with service-specific prefixes (like 'ses-').
- Restrict the number of pre-verified sender identities an IAM principal can create.