Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
8,407 detections
Filters
Last updated
All Time
Detection languages
3,122
2,729
773
499
379
Contributors
1,502
1,474
1,085
844
510
Categories
2,695
1,319
905
813
749
Platforms
5,933
913
885
299
280
Products / Services
1,617
1,401
1,090
454
419
MITRE Techniques
18,127
15,648
12,596
8,407
6,231
CVEs
29
27
16
16
15
IDS Classtypes
97
50
21
14
8
IDS Protocols
98
93
9
1
Detects when an account successfully recovers a Local Administrator Password Solution (LAPS) password from Microsoft Entra ID. This activity is logged in Azure audit logs under the 'Device' category with the activity type 'Recover device local administrator password' and additional details indicating 'Successfully recovered local credential by device id'. This event can signify an attacker attempting to gain elevated privileges or maintain persistence by obtaining local administrator credentials.
Detects when a Kubernetes Rolebinding is created or modified.
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 the creation of scheduled tasks by the Kapeka backdoor. This rule specifically looks for Event ID 4698 (A scheduled task was created) and then filters on specific content within the TaskContent field, including common Kapeka-related paths like ':\ProgramData\' or '\AppData\Local\', the presence of 'rundll32', '.wll', and '#1' in the command line, and task names such as 'OneDrive' or 'Sens Api'.
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.
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 potential DLL sideloading of "libcurl.dll" by the "gup.exe" process from an uncommon location. This technique can be used by adversaries to execute malicious code by tricking a legitimate application into loading a malicious DLL instead of its legitimate counterpart.
Detects the creation of a malicious DLL file named 'iphlpapi.dll' within the 'AppData\Local\Microsoft' directory, which is commonly used by applications like Microsoft Teams or OneDrive. This technique is often employed for DLL sideloading, where a legitimate application loads a malicious DLL placed in a specific directory, leading to code execution, persistence, privilege escalation, or defense evasion.
The following analytic identifies the first-time execution of child processes spawned by Zoom (zoom.exe or zoom.us). It leverages Endpoint Detection and Response (EDR) data, specifically monitoring process creation events and comparing them against previously seen child processes. This activity is significant because the execution of unfamiliar child processes by Zoom could indicate malicious exploitation or misuse of the application. If confirmed malicious, this could lead to unauthorized code execution, data exfiltration, or further compromise of the endpoint.
Detects the loading of Microsoft Office DLLs, specifically 'outllib.dll', from non-standard file system locations. This behavior is indicative of DLL sideloading, a technique used by adversaries for defense evasion, persistence, and privilege escalation.
Detects the creation of system DLLs that are usually not present on the system (or at least not in system directories). This technique is commonly used to achieve DLL hijacking, which can lead to defense evasion, persistence, and privilege escalation.
This rule detects attempts to bypass User Account Control (UAC) by loading a fake 'dismcore.dll' with 'dism.exe'. This technique involves placing a malicious 'dismcore.dll' in a location where 'dism.exe' will load it instead of the legitimate system DLL, often leading to privilege escalation.
This rule detects potential DLL sideloading of 'CCleanerReactivator.dll'. It specifically looks for instances where 'CCleanerReactivator.dll' is loaded by an image that is NOT the legitimate 'CCleanerReactivator.exe' located in the standard CCleaner installation paths ('C:\Program Files\CCleaner\' or 'C:\Program Files (x86)\CCleaner\'). This behavior can indicate an adversary attempting to execute malicious code by tricking a legitimate application into loading a malicious DLL.
Detects when an attacker creates a similar folder structure to Windows system folders (such as Windows, Program Files) but with an additional space in the directory name. This technique aims to trick the DLL load search order, leading to a "DLL Search Order Hijacking" attack where a malicious DLL can be loaded instead of a legitimate one.
Detects potential DLL sideloading of "7za.dll". This technique involves an attacker placing a malicious DLL (named 7za.dll in this case) in a location where a legitimate application expects to load a benign version of the DLL. By doing so, the malicious DLL is loaded and executed by the legitimate application, allowing the attacker to achieve defense evasion, persistence, or privilege escalation. The rule specifically looks for instances where '7za.dll' is loaded by an executable not residing in standard 'Program Files' directories, which are typically trusted locations.
Detects potential DLL sideloading of "CCleanerDU.dll" when loaded by an executable that is not the legitimate CCleaner application (CCleaner.exe or CCleaner64.exe) or is not located in the standard CCleaner installation paths.
Detects potential DLL sideloading using ClassicExplorer32.dll from the Classic Shell software
This rule detects potential DLL sideloading of "chrome_frame_helper.dll". It triggers when "chrome_frame_helper.dll" is loaded from a location other than the legitimate Google Chrome application directories (C:\Program Files\Google\Chrome\Application\ or C:\Program Files (x86)\Google\Chrome\Application\) or the user's local AppData path for Chrome.
Detects potential DLL sideloading using comctl32.dll by monitoring specific Windows executables loading this DLL from a '.local' directory, which is a common technique for privilege escalation and defense evasion.
This rule detects potential DLL sideloading attempts involving specific third-party software DLLs. It identifies when 'commfunc.dll' (associated with Lenovo software) or 'tosbtkbd.dll' (associated with Toshiba Bluetooth software) are loaded from unexpected or non-standard paths. The rule aims to catch instances where an attacker might place a malicious DLL with the same name in a location that a legitimate application will load before its intended, legitimate DLL, thereby achieving execution, persistence, privilege escalation, or defense evasion.
This rule detects potential DLL sideloading attempts targeting DLLs associated with the Wazuh security platform. Specifically, it looks for `libwazuhshared.dll` or `libwinpthread-1.dll` being loaded from locations outside of standard program file directories (e.g., `C:\Program Files\` or `C:\Program Files (x86)\`). It also filters out common legitimate loads of `libwinpthread-1.dll` from `AppData` or `ProgramData` within `mingw64` paths.
Page 360 of 401