-
Notifications
You must be signed in to change notification settings - Fork 425
Cisco Isovalent - new detections batch 1 #3706
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
@@ -0,0 +1,3 @@ | |||
definition: pod_image_name IN ("docker.io/library/ubuntu:22.04") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add cilium versions since its seems to be used with isovalent too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, adding these images since they are configured while setting up isovalent:
("docker.io/library/ubuntu:22.04","docker.io/grafana/grafana:12.0.1", "quay.io/isovalent-dev/tetragon-ci*",""quay.io/isovalent/tetragon-ci*","quay.io/isovalent/hubble-export-fluentd*")
status: production | ||
description: The following analytic detects execution of nsenter from within a container, including explicit attempts to join the host’s mount namespace via --mount=/host/proc/1/ns/mnt. Adversaries commonly use nsenter when a pod is misconfigured with excessive privileges (e.g., privileged, hostPID, or broad hostPath mounts) to interact with the underlying node filesystem and processes. This behavior may indicate a container escape attempt to gain persistence or control over the Kubernetes node. Extra scrutiny is warranted for workloads running with privileged security contexts or access to host namespaces and for pods that suddenly begin invoking nsenter outside of normal maintenance activity. | ||
search: | | ||
`cisco_isovalent_process_exec` process_name="nsenter" OR process="--mount=/host/proc/1/ns/mnt" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the proc/1
in this instance refers to your shell i presume. But I don't think this would always be the case right?
If so maybe we can drop it and focus on the binary name?
Just thinking out loud
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, i had initially written this based on a search provided by the isovalent team: however, i think you are right : i am gonna go ahead and remove the cli flag and instead focus on usage of nsenter.
proc/1 is specifically used to escape onto the host as root
https://kubehound.io/reference/attacks/CE_NSENTER/

Co-authored-by: Nasreddine Bencherchali <nasreddineb@splunk.com>
Co-authored-by: Nasreddine Bencherchali <nasreddineb@splunk.com>
Added 8 new detections , added isovalent datasets for existing searches
1 new story
1 data source