Rules

Detects suspicious Django web application framework exceptions that could indicate exploitation attempts

Detects potential JNDI Injection exploitation. Often coupled with Log4Shell exploitation.

Detects potential local file read vulnerability in JVM based apps. If the exceptions are caused due to user input and contain path traversal payloads then it's a red flag.

Detects potential OGNL Injection exploitation, which may lead to RCE. OGNL is an expression language that is supported in many JVM based systems. OGNL Injection is the reason for some high profile RCE's such as Apache Struts (CVE-2017-5638) and Confluence (CVE-2022-26134)

Detects process execution related exceptions in JVM based apps, often relates to RCE

Detects XML parsing issues, if the application expects to work with XML make sure that the parser is initialized safely.

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.

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.

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

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

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

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.

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.

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

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.

Detects when a Kubernetes Rolebinding is created or modified.

Detects enumeration of Kubernetes secrets.

Detects when Kubernetes Secrets are Modified or Deleted.

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

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.