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/01/16"
  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]
 92timestamp_override = "event.ingested"
 93type = "new_terms"
 94
 95query = '''
 96event.dataset: "aws.cloudtrail"
 97    and event.provider: "sns.amazonaws.com"
 98    and event.action: "CreateTopic"
 99    and event.outcome: "success"
100'''
101
102
103[[rule.threat]]
104framework = "MITRE ATT&CK"
105[[rule.threat.technique]]
106id = "T1608"
107name = "Stage Capabilities"
108reference = "https://attack.mitre.org/techniques/T1608/"
109
110
111[rule.threat.tactic]
112id = "TA0042"
113name = "Resource Development"
114reference = "https://attack.mitre.org/tactics/TA0042/"
115[[rule.threat]]
116framework = "MITRE ATT&CK"
117[[rule.threat.technique]]
118id = "T1496"
119name = "Resource Hijacking"
120reference = "https://attack.mitre.org/techniques/T1496/"
121[[rule.threat.technique.subtechnique]]
122id = "T1496.004"
123name = "Cloud Service Hijacking"
124reference = "https://attack.mitre.org/techniques/T1496/004/"
125
126
127[rule.threat.tactic]
128id = "TA0040"
129name = "Impact"
130reference = "https://attack.mitre.org/tactics/TA0040/"
131
132[rule.investigation_fields]
133field_names = [
134    "@timestamp",
135    "user.name",
136    "user_agent.original",
137    "source.ip",
138    "aws.cloudtrail.user_identity.arn",
139    "aws.cloudtrail.user_identity.type",
140    "aws.cloudtrail.user_identity.access_key_id",
141    "event.action",
142    "event.outcome",
143    "cloud.account.id",
144    "cloud.region",
145    "aws.cloudtrail.request_parameters",
146    "aws.cloudtrail.response_elements"
147]
148[rule.new_terms]
149field = "new_terms_fields"
150value = ["cloud.account.id", "user.name"]
151[[rule.new_terms.history_window_start]]
152field = "history_window_start"
153value = "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.arn to 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.original to determine if this action was performed via the AWS CLI, SDK, or Console.
  • If aws-cli was used, review whether it aligns with typical automation or administrative behavior.
  • Review source.ip and source.geo fields to confirm if the request originated from a trusted or unexpected location.

Evaluate the SNS topic creation

  • Check aws.cloudtrail.request_parameters for the SNS topic name and determine whether it appears suspicious (e.g., random strings, unusual keywords).
  • Verify cloud.region and cloud.account.id to ensure the SNS topic was created in an expected environment.
  • Identify additional actions before or after this event using event.action values like:
    • Subscribe
    • Publish
    • SetTopicAttributes
  • 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.arn references an EC2 instance role, verify whether that instance typically performs SNS operations.
  • Review whether new subscriptions were added (Subscribe API 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).
  • 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

to-top