GCP Pub/Sub Topic Creation

ELASTIC detection rule by Elastic · Elastic License v2

Identifies the creation of a topic in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship (Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A topic is used to forward messages from publishers to subscribers.

[metadata]
creation_date = "2020/09/23"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies the creation of a topic in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship
(Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A topic is
used to forward messages from publishers to subscribers.
"""
false_positives = [
    """
    Topic creations may be done by a system or network administrator. Verify whether the user email, resource name,
    and/or hostname should be making changes in your environment. Topic creations by unfamiliar users or hosts should be
    investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Pub/Sub Topic Creation"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating GCP Pub/Sub Topic Creation

Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between independent applications. It uses topics to route messages from publishers to subscribers. Adversaries might exploit this by creating unauthorized topics to exfiltrate data or disrupt services. The detection rule monitors successful topic creation events, helping identify potential misuse by flagging unexpected or suspicious activity.

### Possible investigation steps

- Review the event details to confirm the presence of the event.action field with the value google.pubsub.v*.Publisher.CreateTopic and ensure the event.outcome is success.
- Identify the user or service account associated with the topic creation by examining the actor information in the event logs.
- Check the project and resource details to determine the context and environment where the topic was created, including the project ID and resource name.
- Investigate the purpose and necessity of the newly created topic by consulting with relevant stakeholders or reviewing documentation related to the project.
- Analyze historical logs to identify any unusual patterns or anomalies in topic creation activities by the same user or within the same project.
- Assess the permissions and roles assigned to the user or service account to ensure they align with the principle of least privilege.
- If suspicious activity is confirmed, consider implementing additional monitoring or access controls to prevent unauthorized topic creation in the future.

### False positive analysis

- Routine topic creation by automated processes or scripts can trigger false positives. Identify and document these processes to create exceptions in the monitoring system.
- Development and testing environments often involve frequent topic creation. Exclude these environments from alerts by using environment-specific tags or labels.
- Scheduled maintenance or updates by cloud administrators may result in legitimate topic creation. Coordinate with the operations team to whitelist these activities during known maintenance windows.
- Third-party integrations or services that rely on Pub/Sub for communication might create topics as part of their normal operation. Review and approve these integrations to prevent unnecessary alerts.
- Internal applications with dynamic topic creation as part of their workflow should be assessed and, if deemed non-threatening, added to an exception list to reduce noise.

### Response and remediation

- Immediately review the audit logs to confirm the unauthorized creation of the Pub/Sub topic and identify the user or service account responsible for the action.
- Revoke or limit permissions for the identified user or service account to prevent further unauthorized actions, ensuring that only necessary permissions are granted.
- Delete the unauthorized Pub/Sub topic to prevent any potential data exfiltration or disruption of services.
- Conduct a thorough review of other Pub/Sub topics and related resources to ensure no additional unauthorized topics have been created.
- Notify the security team and relevant stakeholders about the incident for further investigation and to assess potential impacts on the organization.
- Implement additional monitoring and alerting for Pub/Sub topic creation events to detect and respond to similar threats more quickly in the future.
- Consider enabling organization-wide policies that restrict who can create Pub/Sub topics to reduce the risk of unauthorized actions.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/pubsub/docs/admin"]
risk_score = 21
rule_id = "a10d3d9d-0f65-48f1-8b25-af175e2594f5"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Log Auditing",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Publisher.CreateTopic and event.outcome:success
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1530"
name = "Data from Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1530/"

[rule.threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1651"
name = "Cloud Administration Command"
reference = "https://attack.mitre.org/techniques/T1651/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

84efb5ef-3308-4d6d-8fd6-1f9170cb1a7b

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion