|
Resource Hijacking: Cloud Service Hijacking - SES Messaging
AWS Specific Sub-Technique
Other sub-techniques of Resource Hijacking (7)
| ID | Name |
|---|---|
| T1496.004 | Cloud Service Hijacking |
| T1496.A007 | Cloud Service Hijacking - Bedrock LLM Abuse |
| T1496.A001 | Cloud Service Hijacking - SES Messaging |
| T1496.001 | Compute Hijacking |
| T1496.A008 | Compute Hijacking - EC2 Use |
| T1496.A006 | Compute Hijacking - ECS |
| T1496.003 | SMS Pumping |
AWS Specific Content
A prerequisite for this technique is that a threat actor has already gained control of an AWS identity with the permissions to perform the actions in the Event Name(s) section
Using this technique, if a threat actor has access to an AWS identity in an AWS account where production access to SES is enabled (ie. the AWS account has been moved out of the Amazon SES sandbox) and the credentials have sufficient permissions to send email messages with SES, then the threat actor can take advantage of this access by sending spam emails or emails containing malicious content from the AWS account.
Detection
AWS Specific Content
You can create opportunities for detection by configuring logging and monitoring in Amazon SES. In AWS CloudTrail, you can log SES actions listed in the SES API Reference and SES API v2 Reference as events in CloudTrail. You can also use Amazon SES to publish metrics for your email sending events to Amazon CloudWatch. For example, you can use these metrics to monitor the performance of your email sending and set CloudWatch to alert you when you experience a high amount of hard Bounces. Steps on how to publish metrics to CloudWatch are available here. You can also use SES event publishing to monitor and track email sending events such as sends, deliveries, opens, clicks, bounces, complaints, rejections, rendering failures, and delivery delays. This information can be useful for operational and analytical purposes.
Mitigation
AWS Specific Content
Depending on how Amazon SES is used in your environment, there are two different authorization types that you can configure to help mitigate this technique - sending authorization and identity authorization. With sending authorization, you configure Amazon SES to authorize other users to send emails from the identities that you own (domains or email addresses) using their own Amazon SES accounts, and you can restrict the use of this by using a sending authorization policy. With identity authorization, you can define how individual verified identities can use Amazon SES by specifying which SES API actions are allowed or denied for the identity, and under what condition, by using identity authorization on policies. This includes restricting the source of where emails are sent from to specific locations by using condition keys such as
aws:SourceVpc and aws:SourceIp (see this reference for additional information). In general, you can also restrict access to services that aren't actively being used by implementing a strategy of SCPs. This link provides further guidance and examples of how to accomplish this.