Sensitive Kubernetes Mount Pod Detected

Sensitive Kubernetes Mount Pod Detected


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


Abuse, Account Compromise, Cloud Security

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


SPL Difficulty


Data Availability



Stage 3



MITRE ATT&CK Techniques

Resource Hijacking

MITRE Threat Groups

Lazarus Group
Blue Mockingbird

Kill Chain Phases


Data Sources


   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.


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.

SPL for Sensitive Kubernetes Mount Pod Detected

Live Data

First we find pod start events where the keyword hostPath and image exists. Then we match against known sensitive host paths