Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
275 detections
Filters
Last updated
All Time
Detection languages
118
62
41
18
11
Contributors
55
47
38
31
18
Categories
164
71
63
63
48
Platforms
39,897
7,231
6,523
3,864
3,624
275
Products / Services
182
37
34
31
25
MITRE Techniques
91
65
61
59
52
CVEs
5
5
5
5
2
IDS Classtypes
4
3
2
2
1
IDS Protocols
11
Identifies when a service account in Azure Kubernetes Service is modified or deleted. This could indicate an adversary attempting to disrupt services, remove access, or manipulate accounts for persistence or privilege escalation within the Kubernetes cluster.
Detects the modification or deletion of Kubernetes RoleBindings or ClusterRoleBindings within Azure Kubernetes Service. These actions can indicate an adversary attempting to escalate privileges, maintain persistence, or disrupt services by altering access control configurations.
Detects when a Kubernetes CronJob or Job is created, modified, or deleted. 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.
This rule identifies when an Azure Kubernetes network policy is modified or deleted. Network policies control the traffic flow between pods/namespaces and to/from external network endpoints. Unauthorized modification or deletion of these policies can lead to security vulnerabilities, such as allowing unauthorized network access to sensitive services or disrupting legitimate communication within the cluster, potentially leading to a denial of service or data exfiltration.
This rule detects the creation of a Kubernetes container that includes a hostPath mount. A hostPath volume allows a directory or file from the node to be mounted directly into the container. Attackers with permissions to create pods can leverage writable hostPath volumes to perform container escapes, potentially gaining access to the underlying host node by using techniques like chroot.
Detects the creation of a "privileged" container in Kubernetes. A privileged container has root capabilities on the host, allowing it to access and modify host processes, network operations, IPC calls, file system, mount points, and SELinux configurations. This action can indicate a threat actor attempting container breakout or privilege escalation. The rule specifically looks for 'create' verbs on 'pods' resources where 'capabilities' are present, which implies elevated privileges.
Detects when an Azure Kubernetes Cluster is created or deleted. This activity can indicate significant infrastructure changes, either legitimate or malicious. Monitoring these operations is crucial for maintaining the security and integrity of containerized environments.
Detects the removal of a deployment from a Kubernetes cluster. This could indicate disruptive activity aiming to impact business operations.
Detects when a Kubernetes RoleBinding or ClusterRoleBinding is created, modified, or deleted. This activity can indicate privilege escalation attempts or unauthorized access within a Kubernetes cluster.
Detects when Kubernetes Secrets are created, modified, or deleted. This activity is critical to monitor as secrets often contain sensitive information like API keys, passwords, and OAuth tokens. Unauthorized modification or deletion of these secrets could lead to credential compromise, unauthorized access, or denial of service within a Kubernetes cluster.
Detects attempts to execute remote commands, within a Pod's container using e.g. the "kubectl exec" command.
Detects enumeration of Kubernetes secrets.
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.
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.
Detects when a Kubernetes Rolebinding is created or modified.
Detects when Kubernetes Secrets are Modified or Deleted.
Detects the removal of a deployment from a Kubernetes cluster.
This could indicate disruptive activity aiming to impact business operations.
This could indicate disruptive activity aiming to impact business operations.
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.
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 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
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.
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 events are deleted in Kubernetes. An adversary may delete Kubernetes events in an attempt to evade detection.
Detects the creation of new pods within the `kube-system` namespace. This activity is suspicious because attackers might create pods with names similar to legitimate system components (e.g., `kube-proxy-bv61v`) to masquerade as system pods and evade detection. Legitimate system pods created by controllers typically have random suffixes in their names. This rule specifically looks for `create` operations on `pods` within the `kube-system` namespace.
Page 11 of 14