Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
180 detections
Filters
Last updated
All Time
Detection languages
91
29
14
14
11
Contributors
66
42
28
6
6
Categories
125
119
42
35
32
Platforms
120
95
36
27
8
Products / Services
85
38
27
21
18
MITRE Techniques
18,113
15,640
12,591
8,389
6,208
CVEs
4
3
3
2
2
IDS Classtypes
3
1
IDS Protocols
2
2
This query identifies potential post-exploitation behavior on Linux systems by monitoring for clusters of discovery and enumeration commands. Instead of alerting on single, potentially benign commands, it utilizes a behavioral scoring engine that categorizes activities such as credential hunting, privilege escalation, and network scanning.
By implementing extensive allowlists for common administrative tools (e.g., Ansible, Zabbix, Monitoring Agents) and requiring a minimum threshold of unique activity categories, the query effectively filters out "noise." It calculates a dynamic Risk Score and assigns a Severity level based on the criticality of the commands and the speed of execution (Burst Detection), making it a highly reliable tool for SOC analysts to detect active hands-on-keyboard attacks.
By implementing extensive allowlists for common administrative tools (e.g., Ansible, Zabbix, Monitoring Agents) and requiring a minimum threshold of unique activity categories, the query effectively filters out "noise." It calculates a dynamic Risk Score and assigns a Severity level based on the criticality of the commands and the speed of execution (Burst Detection), making it a highly reliable tool for SOC analysts to detect active hands-on-keyboard attacks.
Detects persistence establishment after docker container escape
Detects persistence establishment after docker container escape
Detects scripts designed for container escape and host persistence
This rule detects various behaviors associated with the VoidLink threat, focusing on persistence, privilege escalation, and evasion techniques. It identifies suspicious kernel module loading from temporary directories, the presence of hidden rootkit files, container escape attempts, and cloud metadata harvesting. The rule correlates these activities to reduce false positives, specifically looking for combinations such as suspicious module loads with hidden rootkit files or container escapes, container escapes with cloud metadata harvesting, hidden rootkit files with container escapes or cloud metadata harvesting, and eBPF evasion techniques combined with suspicious module loads or hidden rootkit files. The detection logic suggests an adversary attempting to establish persistence, elevate privileges, and potentially exfiltrate cloud credentials within a Linux environment, possibly involving containerized setups.
Detects privilege escalation attempts used by the Shai-Hulud malware. This includes checking for passwordless sudo ('sudo -n true') and exploiting Docker to modify the 'sudoers.d' file to grant root privileges.
KQL Query from file: BadSuccessor Detection
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 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
The following analytic detects the creation or update of a Kubernetes pod with host network attachment. It leverages Kubernetes Audit logs to identify pods configured with host network settings. This activity is significant for a SOC as it could allow an attacker to monitor all network traffic on the node, potentially capturing sensitive information and escalating privileges. If confirmed malicious, this could lead to unauthorized access, data breaches, and service disruptions, severely impacting the security and integrity of the Kubernetes environment.
Page 9 of 9