Navigation :

Sensitive Kubernetes Mount Pod Detected

Description

This search looks for pod start events with a mount host path that is classified as sensitive. Some pods will do this as part of normal operations but this is also a way for an attacker to do privilege escalation and lateral movement.

Alert: Low

Content Mapping

This content is not mapped to any local saved search. Add mapping

Use Case

Advanced Threat Detection, Security Monitoring

Security Impact

Using this technique is is possible for an attacker to abuse hostPath volume mounts for a Pod to escape the namespace constraints and gain access to Pods in any other namespace. This ability can in turn be leveraged to eventually gain maximum privilege in the cluster i.e. Cluster Admin. Reference scenarios include these Kubernetes Namespace Breakout using Insecure Host Path Volume

Alert Volume

Low

SPL Difficulty

Medium

Data Availability

Bad

Journey

Stage 3

MITRE ATT&CK Tactics

Impact

MITRE ATT&CK Techniques

Resource Hijacking

MITRE Threat Groups

Lazarus Group

APT41

Blue Mockingbird

Rocke

Kill Chain Phases

Exploitation

Data Sources

Kubernetes

How to Implement
The data is coming from Pod logs which you can get if you deploy Splunk Connect for Kubernetes. These logs are generated from the Pods themselves and reveals the image, container and repository information. While implementing, make sure you follow the best practice of specifying the index for your data.

How to Implement

The data is coming from Pod logs which you can get if you deploy Splunk Connect for Kubernetes. These logs are generated from the Pods themselves and reveals the image, container and repository information. While implementing, make sure you follow the best practice of specifying the index for your data.

Known False Positives
This search should trigger very few false positives, because it's filtered to just very specific events. The keyword list does not use wildcards but some pods have genuine reasons to have these sensitive mount paths. If that is the case in your environment you can add these pods to the allow list directly in the search or via a lookup.

How To Respond
This alert is very clearly tied to a known threat, so when it fires your concern is that this represents an attacker inside of one of your systems. Recommended steps are to begin incident response on the host where this alert fired from, to look for signs of other suspicious activities. The first step in that process will be to look for other events that involve the same IP or user name, and see what other activities the attacker might have done. That should guide you to the underlying problem.

How To Respond

This alert is very clearly tied to a known threat, so when it fires your concern is that this represents an attacker inside of one of your systems. Recommended steps are to begin incident response on the host where this alert fired from, to look for signs of other suspicious activities. The first step in that process will be to look for other events that involve the same IP or user name, and see what other activities the attacker might have done. That should guide you to the underlying problem.

Help
Sensitive Kubernetes Mount Pod Detected Help The basic idea behind this search is to take a set of known sensitive mount host paths and checking if any pods are started with these. The last lines of the search are more concerened with renaming and formatting and making it look understandable for an analyst.

Help