AWS SNS Topic Created by Rare User
Identifies when an SNS topic is created by a user who does not typically perform this action. Adversaries may create SNS topics to stage capabilities for data exfiltration or other malicious activities. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/02/11"
3integration = ["aws"]
4maturity = "production"
5updated_date = "2026/09/18"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies when an SNS topic is created by a user who does not typically perform this action. Adversaries may create SNS
11topics to stage capabilities for data exfiltration or other malicious activities. This is a New Terms rule that only flags
12when this behavior is observed for the first time by a user or role.
13"""
14false_positives = [
15 """
16 Legitimate users may create SNS topics for legitimate purposes. Ensure that the creation is authorized before taking
17 action.
18 """,
19]
20from = "now-6m"
21index = ["filebeat-*", "logs-aws.cloudtrail-*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "AWS SNS Topic Created by Rare User"
25note = """## Triage and Analysis
26
27### Investigating AWS SNS Topic Created by Rare User
28
29This rule detects the creation of an AWS Simple Notification Service (SNS) topic by a user who does not typically perform this action. Adversaries may create SNS topics to facilitate data exfiltration or other malicious activities.
30
31This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that only flags when this behavior is observed for the first time by a user or role.
32
33### Possible investigation steps
34
35**Identify the actor and context**
36 - Examine `aws.cloudtrail.user_identity.arn` to determine **who** created the SNS topic.
37 - Identify whether the actor assumed a privileged IAM role (`aws.cloudtrail.user_identity.type: "AssumedRole"`) or used a long term access keys (`aws.cloudtrail.user_identity.access_key_id`).
38 - Check `user_agent.original` to determine if this action was performed via the AWS CLI, SDK, or Console.
39 - If `aws-cli` was used, review whether it aligns with typical automation or administrative behavior.
40 - Review `source.ip` and `source.geo` fields to confirm if the request originated from a trusted or unexpected location.
41
42**Evaluate the SNS topic creation**
43 - Check `aws.cloudtrail.request_parameters` for the SNS topic name and determine whether it appears suspicious (e.g., random strings, unusual keywords).
44 - Verify `cloud.region` and `cloud.account.id` to ensure the SNS topic was created in an expected environment.
45 - Identify additional actions **before or after** this event using `event.action` values like:
46 - `Subscribe`
47 - `Publish`
48 - `SetTopicAttributes`
49 - These may indicate follow-up steps taken to misuse the SNS topic.
50
51**Analyze potential malicious intent**
52 - Check if this user has previously created SNS topics using historical CloudTrail logs.
53 - Look for multiple topic creations in a short period, which may suggest an automation script or malicious behavior.
54 - If `aws.cloudtrail.user_identity.arn` references an EC2 instance role, verify whether that instance typically performs SNS operations.
55 - Review whether new subscriptions were added (`Subscribe` API action) to forward data externally.
56 - If an SNS topic was configured to trigger Lambda functions or S3 events, it may indicate an attempt to persist in the environment.
57
58### False positive analysis
59- Check whether the SNS topic creation aligns with known DevOps, automation, or monitoring activities.
60- If the user typically interacts with SNS, consider allowlisting expected IAM roles for this action.
61- Some AWS services may auto-create SNS topics for alerts and monitoring. Confirm whether the creation was system-generated.
62
63### Response and remediation
64- **Confirm Authorization**:
65 - If the user was not expected to create SNS topics, verify whether their IAM permissions should be restricted.
66 - If unauthorized, disable the access keys or IAM role associated with the event.
67- **Monitor for Further SNS Modifications**:
68 - Set up additional monitoring for SNS Publish or Subscription events (`Publish`, `Subscribe`).
69- **Investigate for Persistence**:
70 - Check whether the SNS topic is being used as a notification channel for Lambda, S3, or other AWS services.
71- **Enhance IAM Policy Controls**:
72 - Consider enforcing least privilege IAM policies and enabling multi-factor authentication (MFA) where applicable.
73"""
74references = [
75 "https://docs.aws.amazon.com/sns/latest/api/API_CreateTopic.html",
76 "https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/",
77 "https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/",
78]
79risk_score = 21
80rule_id = "3c3f65b8-e8b4-11ef-9511-f661ea17fbce"
81severity = "low"
82tags = [
83 "Domain: Cloud",
84 "Data Source: AWS",
85 "Data Source: Amazon Web Services",
86 "Data Source: AWS SNS",
87 "Resources: Investigation Guide",
88 "Use Case: Threat Detection",
89 "Tactic: Resource Development",
90 "Tactic: Impact",
91 "Noise: Low",
92 "Performance: Normal",
93 "Rule Type: New Terms",
94 "Platform: AWS",
95 "Data Source: AWS CloudTrail",
96 "Service: AWS SNS",
97]
98timestamp_override = "event.ingested"
99type = "new_terms"
100
101query = '''
102data_stream.dataset: "aws.cloudtrail"
103 and event.provider: "sns.amazonaws.com"
104 and event.action: "CreateTopic"
105 and event.outcome: "success"
106'''
107
108
109[[rule.threat]]
110framework = "MITRE ATT&CK"
111[[rule.threat.technique]]
112id = "T1608"
113name = "Stage Capabilities"
114reference = "https://attack.mitre.org/techniques/T1608/"
115
116
117[rule.threat.tactic]
118id = "TA0042"
119name = "Resource Development"
120reference = "https://attack.mitre.org/tactics/TA0042/"
121[[rule.threat]]
122framework = "MITRE ATT&CK"
123[[rule.threat.technique]]
124id = "T1496"
125name = "Resource Hijacking"
126reference = "https://attack.mitre.org/techniques/T1496/"
127[[rule.threat.technique.subtechnique]]
128id = "T1496.004"
129name = "Cloud Service Hijacking"
130reference = "https://attack.mitre.org/techniques/T1496/004/"
131
132
133[rule.threat.tactic]
134id = "TA0040"
135name = "Impact"
136reference = "https://attack.mitre.org/tactics/TA0040/"
137
138[rule.investigation_fields]
139field_names = [
140 "@timestamp",
141 "user.name",
142 "user_agent.original",
143 "source.ip",
144 "aws.cloudtrail.user_identity.arn",
145 "aws.cloudtrail.user_identity.type",
146 "aws.cloudtrail.user_identity.access_key_id",
147 "event.action",
148 "event.outcome",
149 "cloud.account.id",
150 "cloud.region",
151 "aws.cloudtrail.request_parameters",
152 "aws.cloudtrail.response_elements"
153]
154[rule.new_terms]
155field = "new_terms_fields"
156value = ["cloud.account.id", "user.name"]
157[[rule.new_terms.history_window_start]]
158field = "history_window_start"
159value = "now-10d"
Triage and Analysis
Investigating AWS SNS Topic Created by Rare User
This rule detects the creation of an AWS Simple Notification Service (SNS) topic by a user who does not typically perform this action. Adversaries may create SNS topics to facilitate data exfiltration or other malicious activities.
This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role.
Possible investigation steps
Identify the actor and context
- Examine
aws.cloudtrail.user_identity.arnto determine who created the SNS topic. - Identify whether the actor assumed a privileged IAM role (
aws.cloudtrail.user_identity.type: "AssumedRole") or used a long term access keys (aws.cloudtrail.user_identity.access_key_id). - Check
user_agent.originalto determine if this action was performed via the AWS CLI, SDK, or Console. - If
aws-cliwas used, review whether it aligns with typical automation or administrative behavior. - Review
source.ipandsource.geofields to confirm if the request originated from a trusted or unexpected location.
Evaluate the SNS topic creation
- Check
aws.cloudtrail.request_parametersfor the SNS topic name and determine whether it appears suspicious (e.g., random strings, unusual keywords). - Verify
cloud.regionandcloud.account.idto ensure the SNS topic was created in an expected environment. - Identify additional actions before or after this event using
event.actionvalues like:SubscribePublishSetTopicAttributes
- These may indicate follow-up steps taken to misuse the SNS topic.
Analyze potential malicious intent
- Check if this user has previously created SNS topics using historical CloudTrail logs.
- Look for multiple topic creations in a short period, which may suggest an automation script or malicious behavior.
- If
aws.cloudtrail.user_identity.arnreferences an EC2 instance role, verify whether that instance typically performs SNS operations. - Review whether new subscriptions were added (
SubscribeAPI action) to forward data externally. - If an SNS topic was configured to trigger Lambda functions or S3 events, it may indicate an attempt to persist in the environment.
False positive analysis
- Check whether the SNS topic creation aligns with known DevOps, automation, or monitoring activities.
- If the user typically interacts with SNS, consider allowlisting expected IAM roles for this action.
- Some AWS services may auto-create SNS topics for alerts and monitoring. Confirm whether the creation was system-generated.
Response and remediation
- Confirm Authorization:
- If the user was not expected to create SNS topics, verify whether their IAM permissions should be restricted.
- If unauthorized, disable the access keys or IAM role associated with the event.
- Monitor for Further SNS Modifications:
- Set up additional monitoring for SNS Publish or Subscription events (
Publish,Subscribe).
- Set up additional monitoring for SNS Publish or Subscription events (
- Investigate for Persistence:
- Check whether the SNS topic is being used as a notification channel for Lambda, S3, or other AWS services.
- Enhance IAM Policy Controls:
- Consider enforcing least privilege IAM policies and enabling multi-factor authentication (MFA) where applicable.
References
Related rules
- AWS SNS Topic Message Publish by Rare User
- AWS SNS Rare Protocol Subscription by User
- Unusual AWS S3 Object Encryption with SSE-C
- AWS DynamoDB Scan by Unusual User
- AWS DynamoDB Table Exported to S3