Full Report
Datadog researchers identified an intrusion targeting Amazon Simple Email Service (SES) in an AWS environment, where attackers employed advanced persistence techniques. The attack was notable for leveraging an external AWS account to assume roles within the victim's environmen...
Analysis Summary
# Incident Report: AWS Role Assumption & Amazon SES Intrusion
## Executive Summary
Threat actors compromised an AWS environment to gain unauthorized access to Amazon Simple Email Service (SES) for the purpose of sending large-scale malicious emails. The attack was characterized by the use of an external AWS account to maintain persistence through "cross-account role assumption," allowing the attackers to bypass standard credential rotation policies. Datadog Security Labs identified the activity and assisted in the remediation and analysis of the multi-stage intrusion.
## Incident Details
- **Discovery Date:** Not explicitly disclosed (Reported August 2024)
- **Incident Date:** Timeline spans multiple days of activity
- **Affected Organization:** Not disclosed (Datadog Customer Environment)
- **Sector:** Technology/Cloud Services
- **Geography:** Global (AWS Environment)
## Timeline of Events
### Initial Access
- **Date/Time:** T-0
- **Vector:** Compromised IAM User Credentials
- **Details:** The attacker obtained long-lived AWS Access Keys for an IAM user. These keys were used to perform initial reconnaissance of the environment's SES configuration.
### Lateral Movement
- **Movement:** The attacker leveraged the initial IAM user to identify and assume roles with higher privileges or broader service access.
- **Specifics:** They moved from a standard IAM user to an administrative role, which was then used to modify Trust Relationships on victim roles to allow access from an attacker-controlled external AWS account.
### Data Exfiltration/Impact
- **Activity:** The attackers initiated high-volume email campaigns via Amazon SES.
- **Impact:** Abuse of the organization's domain reputation; consumption of SES quotas; potential delivery of phishing or malware to third parties via the trusted infrastructure.
### Detection & Response
- **Discovery:** Unusual CloudTrail activity was detected, specifically regarding `UpdateAssumeRolePolicy` and `SendRawEmail` events.
- **Response:** The victim organization rotated compromised credentials, deleted the unauthorized Trust Relationships, and revoked active sessions for the compromised roles.
## Attack Methodology
- **Initial Access:** Compromised IAM Access Keys.
- **Persistence:** Modified IAM Role Trust Policies to allow an **external attacker-controlled AWS Account** to assume internal roles.
- **Privilege Escalation:** Assumption of existing roles with broader permissions (e.g., `AdministratorAccess`).
- **Defense Evasion:** Use of legitimate AWS-to-AWS cross-account functionality to avoid detection by tools only monitoring for local IAM user anomalies.
- **Credential Access:** Extraction of temporary security tokens via `AssumeRole`.
- **Discovery:** Enumeration of SES identities, quotas, and verified senders using `ListIdentities` and `GetSendQuota`.
- **Lateral Movement:** Role-chaining and cross-account access.
- **Collection:** Gathering of internal SES configuration data.
- **Exfiltration:** N/A (Focus was on resource hijacking).
- **Impact:** Unauthorized use of Amazon SES for spam/phishing distribution.
## Impact Assessment
- **Financial:** Potential AWS overage charges for SES usage.
- **Data Breach:** Exposure of internal IAM structure and SES configuration metadata.
- **Operational:** Temporary suspension of SES capabilities by AWS due to "fraudulent activity" detection.
- **Reputational:** High risk; the organization's domain was used to send malicious emails, potentially leading to domain blacklisting.
## Indicators of Compromise
- **Network indicators:**
- `127[.]0[.]0[.]1` (Placeholder for attacker IP - check CloudTrail `sourceIPAddress`)
- **Behavioral indicators:**
- `UpdateAssumeRolePolicy` calls originating from unfamiliar IAM users.
- `AssumeRole` events where the `originatingAccountId` is not part of the organization.
- Sudden spikes in `SendRawEmail` or `SendEmail` API calls.
- Multiple `GetSendQuota` requests in quick succession.
## Response Actions
- **Containment:** Immediately updated the Trust Policy of affected IAM roles to remove the attacker's AWS Account ID.
- **Eradication:** Deleted the compromised initial IAM user credentials and audited all other IAM users for unauthorized keys.
- **Recovery:** Requested SES quota resets from AWS and monitored domain blacklists for reputation repair.
## Lessons Learned
- **Cross-Account Risk:** Trust relationships are a powerful persistence mechanism that can bypass password resets and MFA on the original compromised user.
- **Key Management:** Long-lived IAM access keys remain a primary entry point for cloud intrusions.
- **Monitoring Gaps:** Standard logging often misses "Who" is assuming a role if it originates from an external account unless cross-account activity is specifically alerted.
## Recommendations
- **Enforce IMDSv2:** Ensure all EC2 instances use Instance Metadata Service v2 to prevent credential SSRF.
- **Identify External Trusts:** Regularly run queries to identify IAM roles where the `Principal` is an AWS account ID outside of the AWS Organization.
- **Least Privilege:** Restrict `iam:UpdateAssumeRolePolicy` and `iam:CreateRole` to a very small number of highly protected identities.
- **Service Control Policies (SCPs):** Implement SCPs to restrict the ability to modify IAM settings or sensitive services (like SES) in non-production regions.
- **Credential Rotation:** Transition from long-lived Access Keys to temporary credentials using IAM Roles or AWS IAM Identity Center.