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.
This content is not mapped to any local saved search. Add mapping
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
|First we find pod start events where the keyword hostPath and image exists. Then we match against known sensitive host paths|