SNS Direct-to-Phone Messaging Spike

from logs-aws.cloudtrail-*
| WHERE @timestamp > now() - 7 day
| EVAL target_time_window = DATE_TRUNC(10 seconds, @timestamp)
| WHERE
    event.dataset == "aws.cloudtrail" 
AND
    event.provider == "sns.amazonaws.com" 
AND
    event.action == "Publish" 
AND
    event.outcome == "success" 
AND
    aws.cloudtrail.request_parameters LIKE "*phoneNumber*"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| KEEP target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| STATS sms_message_count = COUNT(*) by target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE sms_message_count > 30

False Positives

• ⚠ AWS removes phone numbers in logs, so deeper analysis via CloudWatch logs may be necessary.
• ⚠ While investigating in CloudWatch, the message context is also sanitized. It would be ideal to investigate the message for any suspicious URL links being embedded in the text messages.
• ⚠ You can also review AWS SNS delivery logs (if enabled) for message metadata.
• ⚠ If messages are not using a topic-based subscription, it suggests direct targeting.
• ⚠ The source of these requests is important, if you notice them from an EC2 instance, that is rather odd or Lambda may be an expected serverless code
• ⚠ Review if `aws.cloudtrail.user_identity.access_key_id` exists in the CloudTrail audit log, then this request was accomplished via the CLI or programmatically. These keys could be compromised and warrant further investigation.
• ⚠ If direct SMS messages are common in your environment, you can adjust the threshold accordingly.