Kubernetes Previously Unseen Container Image Name

THIS IS A EXPERIMENTAL DETECTION

This detection has been marked experimental by the Splunk Threat Research team. This means we have not been able to test, simulate, or build datasets for this detection. Use at your own risk. This analytic is NOT supported.

Try in Splunk Security Cloud

Description

The following analytic identifies containerised workloads that have been created using a previously unseen image. This detection leverages process metrics harvested using an OTEL collector and kubernetes cluster receiver, and is pulled from Splunk Observability cloud using the Splunk Infrastructure Monitoring Add-on. (https://splunkbase.splunk.com/app/5247). This detection uses the k8s.container.ready metric to compare the container image names seen in the last 1 hour with those seen in the 30 days prior to those 1 hour, and alerts if a new container image is detected. When a container in a Kubernetes cluster created using a previously unseen image it raises potential security risks and unknown variables. Unfamiliar container images could contain vulnerabilities, malware, or misconfigurations that pose threats to the cluster's integrity and the applications it hosts. The absence of prior knowledge about the image makes it difficult to assess its trustworthiness, track its lineage, or verify its compliance with security policies. The potential security impact of a container created using a compromised image is significant. Compromised containers can potentially introduce malware, backdoors, or other malicious code into the containerized application, leading to data breaches, service disruptions, and unauthorized access within the Kubernetes cluster. A compromised image can serve as a foothold for lateral movement and privilege escalation, potentially compromising other containers, pods, or nodes in the cluster. Additionally, it may enable the actor to exfiltrate sensitive data, manipulate configurations, or execute arbitrary code, posing risks to the confidentiality, availability, and integrity of applications and data hosted within the cluster

Type: Anomaly
Product: Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud
Last Updated: 2023-12-18
Author: Matthew Moore, Splunk
ID: fea515a4-b1d8-4cd6-80d6-e0d71397b891

Annotations

ATT&CK

ID	Technique	Tactic
T1204	User Execution	Execution

Kill Chain Phase

Installation

NIST

DE.AE

CIS20

CIS 13

CVE

Search

| mstats  count(k8s.container.ready) as k8s.container.ready_count where `kubernetes_metrics` AND earliest=-24h by host.name k8s.cluster.name k8s.node.name container.image.name 
| eval current="True" 
| append [mstats  count(k8s.container.ready) as k8s.container.ready_count where `kubernetes_metrics` AND earliest=-30d latest=-1h  by host.name k8s.cluster.name k8s.node.name container.image.name 
| eval current="false" ] 
| stats values(current) as current by host.name k8s.cluster.name k8s.node.name container.image.name 
| search current="true" AND current!="false" 
| rename host.name as host 
| `kubernetes_previously_unseen_container_image_name_filter` 

Macros

The SPL above uses the following Macros:

kubernetes_metrics

kubernetes_previously_unseen_container_image_name_filter is a empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.

Required fields

List of fields required to use this analytic.

k8s.container.ready_count
host.name
k8s.cluster.name
k8s.node.name

How To Implement

To implement this detection, follow these steps: \

Deploy the OpenTelemetry Collector (OTEL) to your Kubernetes cluster.\
Enable the hostmetrics/process receiver in the OTEL configuration.\
Ensure that the process metrics, specifically Process.cpu.utilization and process.memory.utilization, are enabled.\
Install the Splunk Infrastructure Monitoring (SIM) add-on. (ref: https://splunkbase.splunk.com/app/5247)\
Configure the SIM add-on with your Observability Cloud Organization ID and Access Token.\
Set up the SIM modular input to ingest Process Metrics. Name this input "sim_process_metrics_to_metrics_index".\
In the SIM configuration, set the Organization ID to your Observability Cloud Organization ID.\
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')\
Set the Metric Resolution to 10000.\
Leave all other settings at their default values.\
Run the Search Baseline Of Kubernetes Container Network IO Ratio
Known False Positives

unknown

Associated Analytic Story

Abnormal Kubernetes Behavior using Splunk Infrastructure Monitoring

RBA

Risk Score	Impact	Confidence	Message
25.0	50	50	Kubernetes Previously Unseen Container Image Name on host $host$

The Risk Score is calculated by the following formula: Risk Score = (Impact * Confidence/100). Initial Confidence and Impact is set by the analytic author.

Reference

https://github.com/signalfx/splunk-otel-collector-chart

Test Dataset

Replay any dataset to Splunk Enterprise by using our replay.py tool or the UI. Alternatively you can replay a dataset into a Splunk Attack Range

source | version: 1

Twitter Facebook LinkedIn