Detects creation of a container with a hostPath mount. A hostPath volume mounts a directory or a file from the node to the container. Attackers who have permissions to create a new pod in the cluster may create one with a writable hostPath volume and chroot to escape to the underlying node.

Read More

Detects deployments of pods within the kube-system namespace, which could be intended to imitate system pods. System pods, created by controllers such as Deployments or DaemonSets have random suffixes in their names. Attackers can use this fact and name their backdoor pods as if they were created by these controllers to avoid detection. Deployment of such a backdoor container e.g. named kube-proxy-bv61v, could be attempted in the kube-system namespace alongside the other administrative containers.

Read More

Detects the removal of a deployment from a Kubernetes cluster. This could indicate disruptive activity aiming to impact business operations.

Read More

Detects when a modification (create, update or replace) action is taken that affects mutating or validating webhook configurations, as they can be used by an adversary to achieve persistence or exfiltrate access credentials.

Read More

Detects when a Kubernetes CronJob or Job is created or modified. A Kubernetes Job creates one or more pods to accomplish a specific task, and a CronJob creates Jobs on a recurring schedule. An adversary can take advantage of this Kubernetes object to schedule Jobs to run containers that execute malicious code within a cluster, allowing them to achieve persistence.

Read More

Detects when events are deleted in Kubernetes. An adversary may delete Kubernetes events in an attempt to evade detection.

Read More

Detects when a Kubernetes Rolebinding is created or modified.

Read More

Detects enumeration of Kubernetes secrets.

Read More

Detects when Kubernetes Secrets are Modified or Deleted.

Read More

Detects when a request to the Kubernetes API is rejected due to lack of authorization or due to an expired authentication token being used. This may indicate an attacker attempting to leverage credentials they have obtained.

Read More

Detects creation of new Kubernetes service account, which could indicate an attacker's attempt to persist within a cluster.

Read More

Detects attempts to execute remote commands, within a Pod's container using e.g. the "kubectl exec" command.

Read More

Detects attempts to inject a sidecar container into a running deployment. A sidecar container is an additional container within a pod, that resides alongside the main container. One way to add containers to running resources like Deployments/DeamonSets/StatefulSets, is via a "kubectl patch" operation. By injecting a new container within a legitimate pod, an attacker can run their code and hide their activity, instead of running their own separated pod in the cluster.

Read More

Detects the creation of a "privileged" container, an action which could be indicative of a threat actor mounting a container breakout attacks. A privileged container is a container that can access the host with all of the root capabilities of the host machine. This allows it to view, interact and modify processes, network operations, IPC calls, the file system, mount points, SELinux configurations etc. as the root user on the host. Various versions of "privileged" containers can be specified, e.g. by setting the securityContext.privileged flag in the resource specification, setting non-standard Linux capabilities, or configuring the hostNetwork/hostPID fields

Read More

Detects identities attempting to enumerate their Kubernetes RBAC permissions. In the early stages of a breach, attackers will aim to list the permissions they have within the compromised environment. In a Kubernetes cluster, this can be achieved by interacting with the API server, and querying the SelfSubjectAccessReview API via e.g. a "kubectl auth can-i --list" command. This will enumerate the Role-Based Access Controls (RBAC) rules defining the compromised user's authorization.

Read More