Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
678 detections
Filters
Last updated
All Time
Detection languages
285
97
83
66
59
Contributors
280
127
92
28
26
Categories
20,443
11,831
5,872
5,155
4,866
678
Platforms
660
33
6
Products / Services
284
244
53
33
18
MITRE Techniques
513
285
245
224
222
CVEs
6
1
1
1
1
Flags suspicious execution of X-VPN.exe or related installers loading unexpected DLLs, consistent with the CWE‑427 uncontrolled search path exploited in the campaign.
This rule detects activity associated with the GhostLock ransomware by combining three types of signals: file artifact creation/access, specific Python module loads indicative of GhostLock's execution, and the presence of GhostLock-specific command-line arguments. It aims to identify the ransomware across different stages of its operation.
Detects execution chains where a suspicious DLL (autorun.dll) is loaded from user-controlled directories and followed by a silent MSI installation. This pattern is commonly associated with malware staging and secondary payload deployment.
This rule detects suspicious DLL injection activity by identifying multiple DLL loads from unusual folders such as 'Temp', 'AppData', or 'Windows\Temp'. Adversaries often drop malicious DLLs into these directories and then inject them into legitimate processes to achieve persistence, privilege escalation, or defense evasion. The rule counts the number of DLL loads from these suspicious locations by the same initiating process on the same device, triggering an alert if five or more such loads occur, indicating a concerted malicious effort.
This rule set detects various stages of the JFMBackdoor and Showboat malware, including DLL sideloading of FLTLIB.dll by fltMC.exe from non-standard directories, network connections to known C2 and staging infrastructure (namefuture.site or 23.27.201.160), command-line activity referencing a specific Pastebin URL used by Showboat for process-hiding code, and the creation of JFMBackdoor payload artifacts (flt.bin, scr.mui).
This rule set detects various stages of the JFMBackdoor and Showboat malware, including DLL sideloading of FLTLIB.dll by fltMC.exe from non-standard directories, network connections to known C2 and staging infrastructure (namefuture.site or 23.27.201.160), command-line activity referencing a specific Pastebin URL used by Showboat for process-hiding code, and the creation of JFMBackdoor payload artifacts (flt.bin, scr.mui).
This rule set detects various stages of the JFMBackdoor and Showboat malware, including DLL sideloading of FLTLIB.dll by fltMC.exe from non-standard directories, network connections to known C2 and staging infrastructure (namefuture.site or 23.27.201.160), command-line activity referencing a specific Pastebin URL used by Showboat for process-hiding code, and the creation of JFMBackdoor payload artifacts (flt.bin, scr.mui).
This rule detects suspicious DLL side-loading activity. It looks for DLL files being loaded from common user-writable or temporary directories (like `\temp\` or `\users\`) by legitimate Windows processes such as `rundll32.exe`, `explorer.exe`, or `svchost.exe`. The rule specifically flags instances where a DLL is loaded more than 3 times within an hour by these processes, indicating potential malicious activity where an adversary might be attempting to execute their own malicious DLLs by hijacking the loading process of a legitimate application.
This rule detects suspicious DLL side-loading activity. It looks for DLL files being loaded from common user-writable or temporary directories (like `\temp\` or `\users\`) by legitimate Windows processes such as `rundll32.exe`, `explorer.exe`, or `svchost.exe`. The rule specifically flags instances where a DLL is loaded more than 3 times within an hour by these processes, indicating potential malicious activity where an adversary might be attempting to execute their own malicious DLLs by hijacking the loading process of a legitimate application.
This rule detects the loading of modules (DLLs or executables) from user-specific AppData folders that are not commonly observed across the environment. It specifically excludes common legitimate paths within AppData like 'Local\Programs' and 'Local\Temp' to reduce false positives. The rule identifies modules loaded by processes that also originate from an AppData folder, indicating potentially suspicious activity such as malware or custom tools operating from user-writable locations.
This rule detects suspicious DLL injection activity by identifying multiple DLL loads from unusual folders such as 'Temp', 'AppData', or 'Windows\Temp'. Adversaries often drop malicious DLLs into these directories and then inject them into legitimate processes to achieve persistence, privilege escalation, or defense evasion. The rule counts the number of DLL loads from these suspicious locations by the same initiating process on the same device, triggering an alert if five or more such loads occur, indicating a concerted malicious effort.
This rule detects the loading of modules (DLLs or executables) from user-specific AppData folders that are not commonly observed across the environment. It specifically excludes common legitimate paths within AppData like 'Local\Programs' and 'Local\Temp' to reduce false positives. The rule identifies modules loaded by processes that also originate from an AppData folder, indicating potentially suspicious activity such as malware or custom tools operating from user-writable locations.
Detects ctfmon.exe calling NtCreateSymbolicLinkObject or loading cldapi.dll, which indicates the initial stages of the GreenPlasma exploit. This behavior is indicative of process injection or privilege escalation attempts.
This rule detects the staging or execution of the LaxGopher payload, disguised as 'whisper.dll', by monitoring DLL loading and file writing events. It specifically looks for the filename 'whisper.dll' in ImageModuleLoad, PeFileWritten, or NewExecutableWritten events.
Detects potential DLL side-loading where the legitimate Palo Alto Networks executable 'PanGpHip.exe' is launched from a non-standard directory and loads 'libwaapi.dll' from the same path. This behavior is consistent with the technique described in the dmpdump report, where an LNK file executes the legitimate application to load a malicious DLL.
Detects Code Integrity (CI) engine blocking processes from loading unsigned DLLs residing in suspicious locations
This rule detects a DHCP server error in which a specified Callout DLL (in registry) could not be loaded
Detects Code Integrity (CI) engine blocking Microsoft Defender's processes (MpCmdRun and NisSrv) from loading unsigned DLLs which may be an attempt to sideload arbitrary DLL
This rule detects when 'offreg.dll' is loaded by an application that is not located in common, legitimate Windows or program files directories. 'offreg.dll' is a legitimate Windows DLL related to offline registry manipulation. Its loading by unusual applications outside of expected system paths could indicate an attempt at DLL hijacking, persistence, or other malicious activity, as adversaries might use it to load their own malicious code or manipulate the registry. The rule explicitly excludes known legitimate paths to reduce false positives.
This rule detects suspicious activity involving the writing of both DLL and EXE files to the same path, followed by process masquerading (where the file name differs from the original file name) and subsequent DLL side-loading. It also attempts to identify the source URL if the Mark-of-the-Web (MOTW) is present, indicating a downloaded file. The detection chain tracks the process that writes the files, the parent process that initiates the file write, the process that performs the DLL side-load, and finally the loaded DLLs themselves, including various module load telemetry classifications.
This rule detects suspicious activity involving the writing of both DLL and EXE files to the same path, followed by process masquerading (where the file name differs from the original file name) and subsequent DLL side-loading. It also attempts to identify the source URL if the Mark-of-the-Web (MOTW) is present, indicating a downloaded file. The detection chain tracks the process that writes the files, the parent process that initiates the file write, the process that performs the DLL side-load, and finally the loaded DLLs themselves, including various module load telemetry classifications.
Page 28 of 33