Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
361 detections
Filters
Last updated
All Time
Detection languages
155
66
39
27
23
Contributors
84
65
37
29
27
Categories
20,440
11,814
5,871
5,145
4,864
Platforms
188
168
165
59
24
Products / Services
141
115
50
36
28
MITRE Techniques
153
125
114
85
63
CVEs
6
5
5
5
5
IDS Classtypes
9
8
3
2
1
IDS Protocols
21
1
1
Detects attempts to enumerate Kubernetes secrets, which could indicate an adversary is searching for sensitive information like API keys, tokens, or other credentials stored within the cluster.
This rule detects when an Azure Container Registry is either created or deleted. Monitoring these operations can help identify unauthorized infrastructure changes, potential resource manipulation, or attempts to cover tracks by removing evidence. An adversary might create a new container registry to host malicious images or delete an existing one to disrupt services or remove forensic artifacts.
Identifies when a Kubernetes account accesses sensitive objects such as ConfigMaps or Secrets within Azure Kubernetes Service. This rule specifically looks for write or delete operations on these objects, which could indicate unauthorized access or malicious activity.
This rule identifies when sensitive ClusterRoles or Roles are being modified, deleted, or when their permissions are being escalated or bound in Azure Kubernetes Service (AKS). These operations can indicate an attempt to gain elevated privileges or disrupt access within the Kubernetes cluster.
Detects attempts to inject a sidecar container into a running Kubernetes deployment. This is achieved by monitoring for 'patch' operations on 'deployments' resources within the 'apps' API group. An attacker might use this technique to run their code and hide activity within a legitimate pod, rather than deploying a separate, potentially more conspicuous, pod.
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 a Azure Kubernetes Cluster is created or deleted.
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.
The following analytic detects the creation of a Kubernetes cron job, which is a task scheduled to run automatically at specified intervals. It identifies this activity by monitoring Kubernetes Audit logs for the creation events of cron jobs. This behavior is significant for a SOC as it could allow an attacker to execute malicious tasks repeatedly and automatically, posing a threat to the Kubernetes infrastructure. If confirmed malicious, this activity could lead to persistent attacks, service disruptions, or unauthorized access to sensitive information.
The analytic detects the creation or update of privileged pods in Kubernetes. It identifies this activity by monitoring Kubernetes Audit logs for pod configurations that include root privileges. This behavior is significant for a SOC as it could indicate an attempt to escalate privileges, exploit the kernel, and gain full access to the host's namespace and devices. If confirmed malicious, this activity could lead to unauthorized access to sensitive information, data breaches, and service disruptions, posing a severe threat to the environment.
The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user agents. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests based on user agents. This activity is significant for a SOC because Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, potentially resulting in significant security breaches and exfiltration of critical information.
The following analytic detects unauthorized access or misuse of Kubernetes Secrets by unusual user names. It leverages Kubernetes Audit logs to identify anomalies in access patterns by analyzing the source of requests based on user names. This activity is significant for a SOC as Kubernetes Secrets store sensitive information like passwords, OAuth tokens, and SSH keys, making them critical assets. If confirmed malicious, this activity could lead to unauthorized access to sensitive systems or data, potentially resulting in significant security breaches and exfiltration of sensitive information.
The following analytic detects the creation of a DaemonSet in a Kubernetes cluster. This behavior is identified by monitoring Kubernetes Audit logs for the creation event of a DaemonSet. DaemonSets ensure a specific pod runs on every node, making them a potential vector for persistent access. This activity is significant for a SOC as it could indicate an attempt to maintain persistent access to the Kubernetes infrastructure. If confirmed malicious, it could lead to persistent attacks, service disruptions, or unauthorized access to sensitive information.
The analytic detects the creation of Kubernetes pods in the default, kube-system, or kube-public namespaces. It leverages Kubernetes audit logs to identify pod creation events within these specific namespaces. This activity is significant for a SOC as it may indicate an attacker attempting to hide their presence or evade defenses. Unauthorized pod creation in these namespaces can suggest a successful cluster breach, potentially leading to privilege escalation, persistent access, or further malicious activities within the cluster.
Page 16 of 18