nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml

@@ -0,0 +1,95 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when the configuration is modified for a storage bucket in Google Cloud Platform (GCP). An adversary may
+modify the configuration of a storage bucket in order to weaken the security controls of their target's environment.
+"""
+false_positives = [
+    """
+    Storage bucket configuration may be modified by system administrators. Verify that the configuration change was
+    expected. Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Storage Bucket Configuration Modification"
+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 Storage Bucket Configuration Modification
+
+Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. Adversaries may alter bucket configurations to weaken security, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for successful configuration changes, flagging potential defense evasion attempts by identifying suspicious modifications to storage settings.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "storage.buckets.update" to identify the user or service account responsible for the configuration change.
+- Examine the event.outcome field to confirm the success of the configuration modification and gather details on what specific changes were made to the storage bucket settings.
+- Investigate the context of the change by checking the timestamp of the event to determine if it aligns with any known maintenance or deployment activities.
+- Assess the permissions and roles of the user or service account involved in the modification to ensure they have the appropriate level of access and determine if any privilege escalation occurred.
+- Cross-reference the modified bucket's configuration with security policies and best practices to identify any potential security weaknesses introduced by the change.
+- Check for any other recent suspicious activities or alerts related to the same user or service account to identify patterns of potentially malicious behavior.
+- If unauthorized changes are suspected, initiate a response plan to revert the configuration to its previous state and strengthen access controls to prevent future incidents.
+
+### False positive analysis
+
+- Routine administrative updates to storage bucket configurations by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their typical activities, and create exceptions for these actions in the monitoring system.
+- Automated processes or scripts that regularly update bucket configurations for maintenance or compliance purposes may cause false positives. Identify these processes and exclude their actions from triggering alerts by using service accounts or specific identifiers.
+- Changes made by cloud management tools or third-party services integrated with GCP might be flagged. Review and whitelist these tools if they are verified and necessary for operations.
+- Scheduled updates or configuration changes as part of regular security audits can appear suspicious. Document these schedules and incorporate them into the monitoring system to prevent unnecessary alerts.
+- Temporary configuration changes for testing or development purposes might be misinterpreted as threats. Ensure that such activities are logged and communicated to the security team to adjust monitoring rules accordingly.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized access to the affected GCP storage bucket by reviewing and adjusting IAM policies to ensure only legitimate users have access.
+- Conduct a thorough review of recent bucket configuration changes to identify any unauthorized modifications and revert them to their original secure state.
+- Isolate the affected storage bucket from the network if suspicious activity is detected, to prevent further unauthorized access or data exfiltration.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure coordinated response efforts.
+- Implement additional logging and monitoring on the affected bucket to detect any further unauthorized access attempts or configuration changes.
+- Review and update security policies and access controls for all GCP storage buckets to prevent similar incidents in the future.
+- Escalate the incident to the cloud security team for a comprehensive analysis and to determine if further action is required, such as involving legal or compliance teams.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
+risk_score = 47
+rule_id = "97359fd8-757d-4b1d-9af1-ef29e4a8680e"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:"storage.buckets.update" and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1578"
+name = "Modify Cloud Compute Infrastructure"
+reference = "https://attack.mitre.org/techniques/T1578/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml

@@ -0,0 +1,95 @@
+[metadata]
+creation_date = "2020/09/21"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when the Identity and Access Management (IAM) permissions are modified for a Google Cloud Platform (GCP)
+storage bucket. An adversary may modify the permissions on a storage bucket to weaken their target's security controls
+or an administrator may inadvertently modify the permissions, which could lead to data exposure or loss.
+"""
+false_positives = [
+    """
+    Storage bucket permissions may be modified by system administrators. Verify that the configuration change was
+    expected. Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Storage Bucket Permissions Modification"
+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 Storage Bucket Permissions Modification
+
+Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. IAM permissions control access to these buckets, ensuring data security. Adversaries may alter these permissions to bypass security measures, leading to unauthorized data access or exposure. The detection rule identifies successful permission changes, signaling potential misuse or accidental misconfigurations, aiding in timely security audits and responses.
+
+### Possible investigation steps
+
+- Review the event logs for the specific action "storage.setIamPermissions" to identify which IAM permissions were modified and by whom.
+- Check the event.outcome field to confirm the success of the permission change and correlate it with any recent access attempts or data access patterns.
+- Investigate the identity of the user or service account that performed the permission change to determine if it aligns with expected administrative activities.
+- Assess the current IAM policy of the affected storage bucket to understand the new permissions and evaluate any potential security risks or exposure.
+- Cross-reference the timing of the permission change with other security events or alerts to identify any suspicious activity or patterns.
+- Consult with the bucket owner or relevant stakeholders to verify if the permission change was authorized and necessary for operational purposes.
+
+### False positive analysis
+
+- Routine administrative updates to IAM permissions can trigger alerts. To manage this, create exceptions for known maintenance windows or specific administrative accounts that regularly perform these updates.
+- Automated scripts or tools that adjust permissions as part of their normal operation may cause false positives. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags.
+- Changes made by trusted third-party services integrated with GCP might be flagged. Review and whitelist these services if they are verified and necessary for business operations.
+- Temporary permission changes for troubleshooting or testing purposes can be mistaken for malicious activity. Document and schedule these changes, and exclude them from alerts during the specified timeframes.
+- Permissions modified by cloud management platforms or orchestration tools should be reviewed. If these tools are part of standard operations, consider excluding their actions from the detection rule.
+
+### Response and remediation
+
+- Immediately revoke any unauthorized IAM permissions changes by restoring the previous known good configuration for the affected GCP storage bucket.
+- Conduct a thorough review of the IAM policy change logs to identify the source and nature of the modification, focusing on the user or service account responsible for the change.
+- Isolate the affected storage bucket from external access until the permissions are verified and secured to prevent further unauthorized access.
+- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and the steps taken to mitigate the risk.
+- Implement additional monitoring on the affected storage bucket and related IAM policies to detect any further unauthorized changes or suspicious activities.
+- Review and update IAM policies to ensure the principle of least privilege is enforced, reducing the risk of similar incidents in the future.
+- If the incident is suspected to be part of a larger attack, escalate to incident response teams for a comprehensive investigation and potential involvement of law enforcement if necessary.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/storage/docs/access-control/iam-permissions"]
+risk_score = 47
+rule_id = "2326d1b2-9acf-4dee-bd21-867ea7378b4d"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:"storage.setIamPermissions" and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1222"
+name = "File and Directory Permissions Modification"
+reference = "https://attack.mitre.org/techniques/T1222/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a Virtual Private Cloud (VPC) network is deleted in Google Cloud Platform (GCP). A VPC network is a
+virtual version of a physical network within a GCP project. Each VPC network has its own subnets, routes, and firewall,
+as well as other elements. An adversary may delete a VPC network in order to disrupt their target's network and business
+operations.
+"""
+false_positives = [
+    """
+    Virtual Private Cloud networks may be deleted by system administrators. Verify that the configuration change was
+    expected. Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Virtual Private Cloud Network Deletion"
+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 Virtual Private Cloud Network Deletion
+
+Google Cloud Platform's Virtual Private Cloud (VPC) networks are essential for managing isolated network environments within a project, encompassing subnets, routes, and firewalls. Adversaries may target VPC deletions to disrupt operations and evade defenses. The detection rule monitors audit logs for successful VPC deletions, flagging potential malicious activity by correlating specific event actions and outcomes.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action value "v*.compute.networks.delete" to identify the exact time and user account associated with the VPC network deletion.
+- Check the event.outcome field to confirm the success of the deletion and correlate it with any other suspicious activities around the same timeframe.
+- Investigate the user account or service account that performed the deletion to determine if it was authorized and if there are any signs of compromise or misuse.
+- Examine the project and network configurations to assess the impact of the VPC deletion on the organization's operations and identify any critical resources that were affected.
+- Look for any recent changes in IAM roles or permissions that might have allowed unauthorized users to delete the VPC network.
+- Cross-reference the deletion event with other security alerts or incidents to identify potential patterns or coordinated attacks.
+
+### False positive analysis
+
+- Routine maintenance activities may involve the deletion of VPC networks as part of infrastructure updates or reconfigurations. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for environment cleanup might trigger false positives if they delete VPC networks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags associated with these tools.
+- Development and testing environments often undergo frequent changes, including VPC deletions. Consider excluding these environments from alerts by filtering based on project IDs or environment tags to reduce noise.
+- Organizational policy changes might lead to the intentional deletion of VPC networks. Ensure that such policy-driven actions are documented and that the responsible teams are excluded from triggering alerts by using role-based access controls or specific user identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected project by restricting network access to prevent further unauthorized deletions or modifications.
+- Review the audit logs to identify the source of the deletion request, including the user account and IP address, and verify if it was authorized.
+- Recreate the deleted VPC network using the latest backup or configuration snapshot to restore network operations and minimize downtime.
+- Implement additional access controls, such as multi-factor authentication and least privilege principles, to prevent unauthorized access to VPC management.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to Google Cloud Platform support if necessary, especially if there are indications of a broader compromise or if assistance is needed in recovery.
+- Enhance monitoring and alerting for VPC-related activities to detect and respond to similar threats more effectively in the future.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/vpc/docs/vpc"]
+risk_score = 47
+rule_id = "c58c3081-2e1d-4497-8491-e73a45d1a6d6"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Configuration Audit",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:v*.compute.networks.delete and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.007"
+name = "Disable or Modify Cloud Firewall"
+reference = "https://attack.mitre.org/techniques/T1562/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml

@@ -0,0 +1,101 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a virtual private cloud (VPC) route is created in Google Cloud Platform (GCP). Google Cloud routes
+define the paths that network traffic takes from a virtual machine (VM) instance to other destinations. These
+destinations can be inside a Google VPC network or outside it. An adversary may create a route in order to impact the
+flow of network traffic in their target's cloud environment.
+"""
+false_positives = [
+    """
+    Virtual Private Cloud routes may be created by system administrators. Verify that the configuration change was
+    expected. Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Virtual Private Cloud Route 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 Virtual Private Cloud Route Creation
+
+In Google Cloud Platform, VPC routes dictate the network paths for traffic from VM instances to various destinations, both within and outside the VPC. Adversaries may exploit this by creating routes to reroute or intercept traffic, potentially disrupting or spying on network communications. The detection rule identifies such activities by monitoring specific audit events related to route creation, aiding in the early detection of unauthorized network modifications.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:gcp.audit and event.action values (v*.compute.routes.insert or "beta.compute.routes.insert") to identify the exact time and user account associated with the route creation.
+- Examine the details of the newly created route, including the destination IP range and next hop, to determine if it aligns with expected network configurations or if it appears suspicious.
+- Check the IAM permissions and roles of the user account that created the route to assess if they had the necessary privileges and if those privileges are appropriate for their role.
+- Investigate any recent changes in the environment that might explain the route creation, such as new deployments or changes in network architecture.
+- Correlate the route creation event with other security events or alerts in the same timeframe to identify potential patterns or coordinated activities that could indicate malicious intent.
+- Consult with the network or cloud infrastructure team to verify if the route creation was part of an authorized change or if it was unexpected.
+
+### False positive analysis
+
+- Routine network configuration changes by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who frequently make legitimate changes and exclude their activities from triggering alerts.
+- Automated deployment tools that create or modify routes as part of their normal operation may cause false positives. Identify these tools and their associated service accounts, then configure exceptions for these accounts in the monitoring system.
+- Scheduled maintenance activities often involve creating or updating routes. Document these activities and set temporary exceptions during the maintenance window to prevent unnecessary alerts.
+- Integration with third-party services might require route creation. Verify these integrations and whitelist the associated actions to avoid false positives.
+- Development and testing environments may have frequent route changes. Consider applying different monitoring thresholds or rules for these environments to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate the affected VM instances by removing or disabling the suspicious route to prevent further unauthorized traffic redirection.
+- Conduct a thorough review of recent route creation activities in the GCP environment to identify any other unauthorized or suspicious routes.
+- Revoke any unauthorized access or permissions that may have allowed the adversary to create the route, focusing on IAM roles and service accounts with route creation privileges.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement network monitoring and logging to detect any future unauthorized route creation attempts, ensuring that alerts are configured for similar activities.
+- Review and update the GCP VPC network security policies to enforce stricter controls on route creation and modification, limiting these actions to trusted administrators only.
+- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any additional security measures or advisories.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"]
+risk_score = 21
+rule_id = "9180ffdf-f3d0-4db3-bf66-7a14bcff71b8"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Configuration Audit",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:(v*.compute.routes.insert or "beta.compute.routes.insert")
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.007"
+name = "Disable or Modify Cloud Firewall"
+reference = "https://attack.mitre.org/techniques/T1562/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml

@@ -0,0 +1,101 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a Virtual Private Cloud (VPC) route is deleted in Google Cloud Platform (GCP). Google Cloud routes
+define the paths that network traffic takes from a virtual machine (VM) instance to other destinations. These
+destinations can be inside a Google VPC network or outside it. An adversary may delete a route in order to impact the
+flow of network traffic in their target's cloud environment.
+"""
+false_positives = [
+    """
+    Virtual Private Cloud routes may be deleted by system administrators. Verify that the configuration change was
+    expected. Exceptions can be added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Virtual Private Cloud Route Deletion"
+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 Virtual Private Cloud Route Deletion
+
+In GCP, VPC routes dictate network traffic paths between VM instances and other destinations. Adversaries may delete these routes to disrupt traffic flow, potentially evading defenses or impairing network operations. The detection rule monitors audit logs for successful route deletions, flagging potential misuse by identifying specific actions linked to route removal, thus aiding in timely threat response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:gcp.audit and event.action:v*.compute.routes.delete to identify the exact time and user account associated with the route deletion.
+- Check the event.outcome:success field to confirm the deletion was successful and not an attempted action.
+- Investigate the user account or service account that performed the deletion to determine if it was authorized to make such changes, including reviewing recent activity and permissions.
+- Assess the impact of the route deletion by identifying which VPC and network traffic paths were affected, and determine if any critical services were disrupted.
+- Correlate the route deletion event with other security events or alerts around the same timeframe to identify potential coordinated actions or broader attack patterns.
+- Contact the relevant stakeholders or system owners to verify if the route deletion was intentional and part of a planned change or if it was unauthorized.
+
+### False positive analysis
+
+- Routine maintenance activities by network administrators can trigger route deletions. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or tools used for network configuration updates may delete and recreate routes as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts.
+- Cloud infrastructure changes during deployment processes might involve temporary route deletions. Document these processes and exclude related events from detection during deployment periods.
+- Scheduled network reconfigurations that involve route deletions should be logged and excluded from alerts by correlating with change management records.
+- Test environments often undergo frequent network changes, including route deletions. Exclude events from test environments by filtering based on project or environment tags.
+
+### Response and remediation
+
+- Immediately isolate the affected VPC to prevent further unauthorized network traffic disruptions. This can be done by temporarily disabling external access or applying restrictive firewall rules.
+- Review the audit logs to identify the user or service account responsible for the route deletion. Verify if the action was authorized and investigate any anomalies in user behavior or access patterns.
+- Restore the deleted route using the latest backup or configuration management tools to re-establish normal network traffic flow. Ensure that the restored route aligns with the intended network architecture.
+- Implement additional access controls and monitoring for the affected VPC, such as enabling more granular IAM roles and setting up alerts for any future route modifications.
+- Conduct a security review of the affected environment to identify any other potential misconfigurations or vulnerabilities that could be exploited in a similar manner.
+- Escalate the incident to the security operations team for further investigation and to determine if the route deletion was part of a larger attack campaign.
+- Document the incident, including the root cause analysis and remediation steps taken, to enhance organizational knowledge and improve future incident response efforts.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"]
+risk_score = 47
+rule_id = "a17bcc91-297b-459b-b5ce-bc7460d8f82a"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Configuration Audit",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:v*.compute.routes.delete and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.007"
+name = "Disable or Modify Cloud Firewall"
+reference = "https://attack.mitre.org/techniques/T1562/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+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.
+"""
+false_positives = [
+    """
+    Logging sink modifications 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. Sink modifications from 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 Logging Sink Modification"
+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 Logging Sink Modification
+
+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.
+
+### Possible investigation steps
+
+- 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.
+
+### False positive analysis
+
+- 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.
+
+### Response and remediation
+
+- 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.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/logging/docs/export#how_sinks_work"]
+risk_score = 21
+rule_id = "184dfe52-2999-42d9-b9d1-d1ca54495a61"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Log Auditing",
+    "Tactic: Exfiltration",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.UpdateSink and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1537"
+name = "Transfer Data to Cloud Account"
+reference = "https://attack.mitre.org/techniques/T1537/"
+
+
+[rule.threat.tactic]
+id = "TA0010"
+name = "Exfiltration"
+reference = "https://attack.mitre.org/tactics/TA0010/"
+