GCP Logging Sink Modification

Identifies a modification to a Logging sink in Google Cloud Platform (GCP). Logging compares the log entry to the sinks in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to the sink's export destination. An adversary may update a Logging sink to exfiltrate logs to a different export destination.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2020/09/22"
 3integration = ["gcp"]
 4maturity = "production"
 5updated_date = "2025/01/15"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Identifies a modification to a Logging sink in Google Cloud Platform (GCP). Logging compares the log entry to the sinks
11in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to the sink's export
12destination. An adversary may update a Logging sink to exfiltrate logs to a different export destination.
13"""
14false_positives = [
15    """
16    Logging sink modifications may be done by a system or network administrator. Verify whether the user email, resource
17    name, and/or hostname should be making changes in your environment. Sink modifications from unfamiliar users or
18    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
19    """,
20]
21index = ["filebeat-*", "logs-gcp*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "GCP Logging Sink Modification"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> 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.
29
30### Investigating GCP Logging Sink Modification
31
32In GCP, logging sinks are used to route log entries to specified destinations for storage or analysis. Adversaries may exploit this by altering sink configurations to redirect logs to unauthorized locations, facilitating data exfiltration. The detection rule identifies successful modifications to logging sinks, signaling potential misuse by monitoring specific audit events related to sink updates.
33
34### Possible investigation steps
35
36- Review the event details for the specific `event.action` field value `google.logging.v*.ConfigServiceV*.UpdateSink` to confirm the type of modification made to the logging sink.
37- Check the `event.outcome` field to ensure the modification was successful, as indicated by the value `success`.
38- Identify the user or service account responsible for the modification by examining the `actor` or `principalEmail` fields in the audit log.
39- Investigate the `resource` field to determine which logging sink was modified and assess its intended purpose and usual configuration.
40- Analyze the `destination` field in the sink configuration to verify if the new export destination is authorized and aligns with organizational policies.
41- Review historical logs for any previous modifications to the same logging sink to identify patterns or repeated unauthorized changes.
42- Correlate this event with other security alerts or anomalies in the environment to assess if this modification is part of a broader attack or data exfiltration attempt.
43
44### False positive analysis
45
46- Routine updates to logging sinks by authorized personnel can trigger alerts. To manage this, maintain a list of known and trusted users who regularly perform these updates and create exceptions for their actions.
47- Automated processes or scripts that update logging sinks as part of regular maintenance or deployment activities may cause false positives. Identify these processes and exclude their specific actions from triggering alerts.
48- Changes to logging sinks during scheduled maintenance windows can be mistaken for unauthorized modifications. Define and exclude these time periods from monitoring to reduce unnecessary alerts.
49- Integration with third-party tools that require sink modifications for functionality might generate false positives. Document these integrations and adjust the detection rule to account for their expected behavior.
50- Frequent changes in a dynamic environment, such as development or testing environments, can lead to false positives. Consider applying the rule more stringently in production environments while relaxing it in non-production settings.
51
52### Response and remediation
53
54- Immediately review the audit logs to confirm the unauthorized modification of the logging sink and identify the source of the change, including the user account and IP address involved.
55- Revert the logging sink configuration to its original state to ensure logs are directed to the intended, secure destination.
56- Temporarily disable or restrict access to the user account or service account that made the unauthorized change to prevent further unauthorized actions.
57- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized modification and initial containment actions taken.
58- Conduct a thorough investigation to determine if any data was exfiltrated and assess the potential impact on the organization.
59- Implement additional monitoring and alerting for changes to logging sink configurations to detect similar unauthorized modifications in the future.
60- Review and strengthen access controls and permissions related to logging sink configurations to prevent unauthorized modifications, ensuring that only authorized personnel have the necessary permissions.
61
62## Setup
63
64The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
65references = ["https://cloud.google.com/logging/docs/export#how_sinks_work"]
66risk_score = 21
67rule_id = "184dfe52-2999-42d9-b9d1-d1ca54495a61"
68severity = "low"
69tags = [
70    "Domain: Cloud",
71    "Data Source: GCP",
72    "Data Source: Google Cloud Platform",
73    "Use Case: Log Auditing",
74    "Tactic: Exfiltration",
75    "Resources: Investigation Guide",
76]
77timestamp_override = "event.ingested"
78type = "query"
79
80query = '''
81event.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.UpdateSink and event.outcome:success
82'''
83
84
85[[rule.threat]]
86framework = "MITRE ATT&CK"
87[[rule.threat.technique]]
88id = "T1537"
89name = "Transfer Data to Cloud Account"
90reference = "https://attack.mitre.org/techniques/T1537/"
91
92
93[rule.threat.tactic]
94id = "TA0010"
95name = "Exfiltration"
96reference = "https://attack.mitre.org/tactics/TA0010/"
...
toml

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.

In GCP, logging sinks are used to route log entries to specified destinations for storage or analysis. Adversaries may exploit this by altering sink configurations to redirect logs to unauthorized locations, facilitating data exfiltration. The detection rule identifies successful modifications to logging sinks, signaling potential misuse by monitoring specific audit events related to sink updates.

  • Review the event details for the specific event.action field value google.logging.v*.ConfigServiceV*.UpdateSink to confirm the type of modification made to the logging sink.
  • Check the event.outcome field to ensure the modification was successful, as indicated by the value success.
  • Identify the user or service account responsible for the modification by examining the actor or principalEmail fields in the audit log.
  • Investigate the resource field to determine which logging sink was modified and assess its intended purpose and usual configuration.
  • Analyze the destination field in the sink configuration to verify if the new export destination is authorized and aligns with organizational policies.
  • Review historical logs for any previous modifications to the same logging sink to identify patterns or repeated unauthorized changes.
  • Correlate this event with other security alerts or anomalies in the environment to assess if this modification is part of a broader attack or data exfiltration attempt.
  • Routine updates to logging sinks by authorized personnel can trigger alerts. To manage this, maintain a list of known and trusted users who regularly perform these updates and create exceptions for their actions.
  • Automated processes or scripts that update logging sinks as part of regular maintenance or deployment activities may cause false positives. Identify these processes and exclude their specific actions from triggering alerts.
  • Changes to logging sinks during scheduled maintenance windows can be mistaken for unauthorized modifications. Define and exclude these time periods from monitoring to reduce unnecessary alerts.
  • Integration with third-party tools that require sink modifications for functionality might generate false positives. Document these integrations and adjust the detection rule to account for their expected behavior.
  • Frequent changes in a dynamic environment, such as development or testing environments, can lead to false positives. Consider applying the rule more stringently in production environments while relaxing it in non-production settings.
  • Immediately review the audit logs to confirm the unauthorized modification of the logging sink and identify the source of the change, including the user account and IP address involved.
  • Revert the logging sink configuration to its original state to ensure logs are directed to the intended, secure destination.
  • Temporarily disable or restrict access to the user account or service account that made the unauthorized change to prevent further unauthorized actions.
  • Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized modification and initial containment actions taken.
  • Conduct a thorough investigation to determine if any data was exfiltrated and assess the potential impact on the organization.
  • Implement additional monitoring and alerting for changes to logging sink configurations to detect similar unauthorized modifications in the future.
  • Review and strengthen access controls and permissions related to logging sink configurations to prevent unauthorized modifications, ensuring that only authorized personnel have the necessary permissions.

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

References

Related rules

to-top