Merge pull request #2941 from splunk/gitlab_release_v4.19.0

Gitlab release v4.19.0

baselines/baseline_of_kubernetes_container_network_io.yml

@@ -0,0 +1,52 @@
+name: Baseline Of Kubernetes Container Network IO
+id: 6edaca1d-d436-42d0-8df0-6895d3bf5b70
+version: 1
+date: '2023-12-19'
+author: Matthew Moore, Splunk
+type: Baseline
+datamodel: []
+description: This baseline rule calculates the average and standard deviation of inbound and outbound network IO for each Kubernetes container. 
+  It uses metrics from the Kubernetes API and the Splunk Infrastructure Monitoring Add-on. The rule generates a lookup table with the average and 
+  standard deviation of the network IO for each container. This baseline can be used to detect anomalies in network communication behavior, 
+  which may indicate security threats such as data exfiltration, command and control communication, or compromised container behavior.
+search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s 
+  | eval service = replace(''k8s.pod.name'', "-\w{5}$|-[abcdef0-9]{8,10}-\w{5}$", "")
+  | eval key = ''k8s.cluster.name'' + ":" + ''service'' 
+  | stats avg(eval(if(direction="transmit", io,null()))) as avg_outbound_network_io avg(eval(if(direction="receive", io,null()))) as avg_inbound_network_io 
+        stdev(eval(if(direction="transmit", io,null()))) as stdev_outbound_network_io stdev(eval(if(direction="receive", io,null()))) as stdev_inbound_network_io
+        count latest(_time) as last_seen by key
+  | outputlookup k8s_container_network_io_baseline '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on (ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: none
+references: []
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  detections:
+  - Kubernetes Anomalous Inbound Outbound Network IO
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - k8s.pod.network.io
+  - k8s.cluster.name 
+  - k8s.node.name
+  - k8s.pod.name  
+  security_domain: network
+deployment:
+  scheduling:
+    cron_schedule: 0 2 * * 0
+    earliest_time: -30d@d
+    latest_time: -1d@d
+    schedule_window: auto

baselines/baseline_of_kubernetes_container_network_io_ratio.yml

@@ -0,0 +1,55 @@
+name: Baseline Of Kubernetes Container Network IO Ratio
+id: f395003b-6389-4e14-89bf-ac4dbea215bd
+version: 1
+date: '2023-12-19'
+author: Matthew Moore, Splunk
+type: Baseline
+datamodel: []
+description: This baseline rule calculates the average ratio of inbound to outbound network IO for each Kubernetes container. 
+  It uses metrics from the Kubernetes API and the Splunk Infrastructure Monitoring Add-on. 
+  The rule generates a lookup table with the average and standard deviation of the network IO ratio for each container. 
+  This baseline can be used to detect anomalies in network communication behavior, which may indicate security threats such as data exfiltration, 
+  command and control communication, or compromised container behavior.
+search: '| mstats avg(k8s.pod.network.io) as io where `kubernetes_metrics` by k8s.cluster.name k8s.pod.name k8s.node.name direction span=10s 
+  | eval service = replace(''k8s.pod.name'', "-\w{5}$|-[abcdef0-9]{8,10}-\w{5}$", "") 
+  | eval key = ''k8s.cluster.name'' + ":" + ''service'' 
+  | stats avg(eval(if(direction="transmit", io,null()))) as outbound_network_io avg(eval(if(direction="receive", io,null()))) as inbound_network_io by key _time 
+  | eval inbound:outbound = inbound_network_io/outbound_network_io 
+  | eval outbound:inbound = outbound_network_io/inbound_network_io 
+  | stats avg(*:*) as avg_*:* stdev(*:*) as stdev_*:*
+    count latest(_time) as last_seen by key 
+  | outputlookup k8s_container_network_io_ratio_baseline '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: none
+references: []
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  detections:
+  - Kubernetes Anomalous Inbound to Outbound Network IO Ratio
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - k8s.pod.network.io
+  - k8s.cluster.name 
+  - k8s.node.name
+  - k8s.pod.name  
+  security_domain: network
+deployment:
+  scheduling:
+    cron_schedule: 0 2 * * 0
+    earliest_time: -30d@d
+    latest_time: -1d@d
+    schedule_window: auto

baselines/baseline_of_kubernetes_process_resource.yml

@@ -0,0 +1,50 @@
+name: Baseline Of Kubernetes Process Resource
+id: f749862b-5fae-415f-940b-823bdeba2315
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+type: Baseline
+datamodel: []
+description: This baseline rule calculates the average and standard deviation of various process resources in a Kubernetes environment. 
+  It uses metrics from the Kubernetes API and the Splunk Infrastructure Monitoring Add-on. The rule generates a lookup table with the average and 
+  standard deviation of the resource utilization for each process. This baseline can be used to detect anomalies in process resource utilization, 
+  which may indicate security threats such as resource exhaustion attacks, cryptojacking, or compromised process behavior.
+search: '| mstats avg(process.*) as avg_process.* stdev(*) as stdev_* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name 
+  | eval key = ''k8s.cluster.name'' + ":" + ''host.name'' + ":" + ''process.executable.name''
+  | fillnull
+  | outputlookup k8s_process_resource_baseline'
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: none
+references: []
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+  detections:
+  - Kubernetes Process with Anomalous Resource Utilisation
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.*
+  - host.name 
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - process.executable.name
+  security_domain: network
+deployment:
+  scheduling:
+    cron_schedule: 0 2 * * 0
+    earliest_time: -30d@d
+    latest_time: -1d@d
+    schedule_window: auto

baselines/baseline_of_kubernetes_process_resource_ratio.yml

@@ -0,0 +1,64 @@
+name: Baseline Of Kubernetes Process Resource Ratio
+id: 427f81cf-ce6a-4a24-a73d-70c50171ea66
+version: 1
+date: '2023-12-18'
+author: Matthew Moore, Splunk
+type: Baseline
+datamodel: []
+description: This baseline rule calculates the average and standard deviation of the ratio of various process resources in a Kubernetes environment. 
+  It uses metrics from the Kubernetes API and the Splunk Infrastructure Monitoring Add-on. The rule generates a lookup table with the average and 
+  standard deviation of the resource ratios for each process. This baseline can be used to detect anomalies in process resource utilization, 
+  which may indicate security threats such as resource exhaustion attacks, cryptojacking, or compromised process behavior.
+search: '| mstats avg(process.*) as process.* where `kubernetes_metrics` by host.name k8s.cluster.name k8s.node.name process.executable.name span=10s 
+  | eval cpu:mem = ''process.cpu.utilization''/''process.memory.utilization'' 
+  | eval cpu:disk = ''process.cpu.utilization''/''process.disk.operations'' 
+  | eval mem:disk = ''process.memory.utilization''/''process.memory.utilization'' 
+  | eval cpu:threads = ''process.cpu.utilization''/''process.threads'' 
+  | eval disk:threads = ''process.disk.operations''/''process.threads'' 
+  | eval key = ''k8s.cluster.name'' + ":" + ''host.name'' + ":" + ''process.executable.name''
+  | fillnull 
+  | stats avg(cpu:mem) as avg_cpu:mem stdev(cpu:mem) as stdev_cpu:mem avg(cpu:disk) as avg_cpu:disk stdev(cpu:disk) as stdev_cpu:disk
+    avg(mem:disk) as avg_mem:disk stdev(mem:disk) as stdev_mem:disk avg(cpu:threads) as avg_cpu:threads stdev(cpu:threads) as stdev_cpu:threads
+    avg(disk:threads) as avg_disk:threads stdev(disk:threads) as stdev_disk:threads count latest(_time) as last_seen by key 
+  | outputlookup k8s_process_resource_ratio_baseline '
+how_to_implement: 'To implement this detection, follow these steps:
+  1. Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.
+  2. Enable the hostmetrics/process receiver in the OTEL configuration.
+  3. Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.
+  4. Install the Splunk Infrastructure Monitoring (SIM) add-on.(ref: https://splunkbase.splunk.com/app/5247) 
+  5. Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.
+  6. Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".
+  7. In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.
+  8. Set the Signal Flow Program to the following: data(''process.threads'').publish(label=''A''); data(''process.cpu.utilization'').publish(label=''B''); data(''process.cpu.time'').publish(label=''C''); data(''process.disk.io'').publish(label=''D''); data(''process.memory.usage'').publish(label=''E''); data(''process.memory.virtual'').publish(label=''F''); data(''process.memory.utilization'').publish(label=''G''); data(''process.cpu.utilization'').publish(label=''H''); data(''process.disk.operations'').publish(label=''I''); data(''process.handles'').publish(label=''J''); data(''process.threads'').publish(label=''K'')
+  9. Set the Metric Resolution to 10000.
+  10. Leave all other settings at their default values.'
+known_false_positives: none
+references: []
+tags:
+  analytic_story:
+  - Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring
+
+
+
+
+
+
+  detections:
+  - Kubernetes Process with Resource Ratio Anomalies
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - process.*
+  - host.name 
+  - k8s.cluster.name 
+  - k8s.node.name 
+  - process.executable.name
+  security_domain: network
+deployment:
+  scheduling:
+    cron_schedule: 0 2 * * 0
+    earliest_time: -30d@d
+    latest_time: -1d@d
+    schedule_window: auto

contentctl.yml

@@ -5,8 +5,8 @@ build:
   name: DA-ESS-ContentUpdate
   path_root: dist
   prefix: ESCU
-  build: 004180
-  version: 4.18.0
+  build: 004190
+  version: 4.19.0
   label: ES Content Updates
   author_name: Splunk Threat Research Team
   author_email: [email protected]

detections/application/splunk_es_dos_investigations_manager_via_investigation_creation.yml

@@ -0,0 +1,49 @@
+name: Splunk ES DoS Investigations Manager via Investigation Creation
+id: 7f6a07bd-82ef-46b8-8eba-802278abd00e
+version: 1
+date: '2024-01-04'
+author: Rod Soto, Eric McGinnis, Chase Franklin
+status: production
+type: TTP
+data_source: []
+description: In Splunk Enterprise Security (ES) versions lower than 7.1.2, an attacker can create a malformed Investigation to perform a denial of service (DoS). The malformed investigation prevents the generation and rendering of the Investigations manager until it is deleted.
+search: '`splunkd_investigation_rest_handler` method=put msg=*investigation* status=error | stats count min(_time) as firstTime max(_time) as lastTime by user method msg 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` 
+  | `splunk_es_dos_investigations_manager_via_investigation_creation_filter`'
+how_to_implement: This search requires access to internal indexes. Only affects Splunk Enterprise Security versions lower than 7.1.2. 
+known_false_positives: The vulnerability requires an authenticated session and access to create an Investigation. It only affects the availability of the Investigations manager, but without the manager, the Investigations functionality becomes unusable for most users. This search gives the exact offending event. 
+references:
+- https://advisory.splunk.com/advisories/SVD-2024-0102
+tags:
+  analytic_story:
+  - Splunk Vulnerabilities
+  asset_type: Endpoint
+  confidence: 100
+  impact: 100
+  message: Denial of Service Attack against Splunk ES Investigation Manager by $user$
+  cve:
+  - CVE-2024-22165
+  mitre_attack_id:
+  - T1499
+  observable:
+  - name: user
+    type: User 
+    role:
+    - Attacker
+  product:
+  - Splunk Enterprise Security
+  risk_score: 100
+  required_fields:
+  - method
+  - msg 
+  - status 
+  - user 
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22165_investigation_rest_handler.log
+    source: /opt/splunk/var/log/splunk/investigation_handler.log
+    sourcetype: investigation_rest_handler
+    custom_index: _internal

detections/application/splunk_es_dos_through_investigation_attachments.yml

@@ -0,0 +1,51 @@
+name: Splunk ES DoS Through Investigation Attachments
+id: bb85b25e-2d6b-4e39-bd27-50db42edcb8f
+version: 1
+date: '2024-01-04'
+author: Rod Soto, Eric McGinnis, Chase Franklin
+status: production
+type: TTP
+data_source: []
+description: In Splunk Enterprise Security (ES) versions below 7.1.2, an attacker can use investigation attachments to perform a denial of service (DoS) to the Investigation. The attachment endpoint does not properly limit the size of the request which lets an attacker cause the Investigation to become inaccessible.
+search: '`splunkd_investigation_rest_handler` status=error object=investigation 
+  | stats min(_time) as firstTime max(_time) as lastTime values(status) as status values(msg) as msg values(id) as investigation_id by user 
+  | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)`
+  | `splunk_es_dos_through_investigation_attachments_filter`'
+how_to_implement: This search requires access to internal indexes, only affects Enterprise Security versions below 7.1.2. 
+known_false_positives: This search will show the exact DoS event via error message and investigation id. The error however does not point exactly at the uploader as any users associated with the investigation will be affected. Operator must investigate using investigation id the possible origin of the malicious upload. Attack only affects specific investigation not the investigation manager.
+references:
+- https://advisory.splunk.com/advisories/SVD-2024-0101
+tags:
+  analytic_story:
+  - Splunk Vulnerabilities
+  asset_type: Endpoint
+  confidence: 100
+  impact: 100
+  cve:
+  - CVE-2024-22164
+  message: Denial of Service detected at Splunk ES affecting $user$
+  mitre_attack_id:
+  - T1499
+  observable:
+  - name: user
+    type: User 
+    role:
+    - Victim
+  product:
+  - Splunk Enterprise Security
+  risk_score: 100
+  required_fields:
+  - user 
+  - status 
+  - msg 
+  - id 
+  - object 
+  security_domain: endpoint
+tests:
+- name: True Positive Test
+  attack_data:
+  - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1499/splunk/splunk_cve_2024_22164_investigation_rest_handler.log
+    source: /opt/splunk/var/log/splunk/investigation_handler.log
+    sourcetype: investigation_rest_handler
+    custom_index: _internal