Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,005 detections
Filters
Last updated
All Time
Detection languages
371
363
66
56
54
Contributors
191
187
115
105
103
Categories
468
262
245
169
116
Platforms
995
21
2
1
1
Products / Services
317
286
46
37
35
MITRE Techniques
18,113
15,640
12,591
8,389
6,208
1,005
CVEs
10
5
4
3
2
IDS Classtypes
1
IDS Protocols
1
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.
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.
This rule detects potential DLL sideloading of 'libvlc.dll'. Adversaries may place a malicious 'libvlc.dll' in a directory that is searched before the legitimate VLC installation path, causing a legitimate application to load the malicious DLL instead of the intended one. This technique can be used for defense evasion, persistence, and privilege escalation. The rule specifically looks for 'libvlc.dll' being loaded from any location other than the default VLC installation directories.
This rule detects potential DLL sideloading of an unsigned 'dbghelp.dll' by the Sysinternals tool VMMap. Adversaries may place a malicious, unsigned 'dbghelp.dll' in a location where VMMap (vmmap.exe or vmmap64.exe) will load it instead of the legitimate, signed version. This technique can be used for defense evasion, persistence, or privilege escalation by executing arbitrary code within the context of a trusted application.
This rule detects potential DLL sideloading activity involving the 'JSESPR.dll' library when it is loaded from a location other than the legitimate 'C:\Program Files\Common Files\Justsystem\JsSchHlp\' directory. This specific behavior is associated with the JUSTSYSTEMS Japanese word processor and has been observed in campaigns like 'Operation LiberalFace' targeting Japanese political entities.
Detects DLL sideloading of system DLLs that are not present on the system by default (at least not in system directories).
Usually this technique is used to achieve UAC bypass or privilege escalation.
Usually this technique is used to achieve UAC bypass or privilege escalation.
Detects processes loading the non-existent DLL "ShellChromeAPI.dll". This behavior is often associated with DLL sideloading attacks, where an adversary places a malicious DLL with a name that a legitimate application expects to load. A known example involves "DeviceEnroller.exe" attempting to load this DLL when used with the "PhoneDeepLink" flag. Adversaries can exploit this by dropping their own renamed malicious DLL to achieve defense evasion, persistence, or privilege escalation.
Detects DLL sideloading of 'vmGuestLib.dll' by the 'WmiApSrv.exe' service. This rule specifically looks for instances where 'WmiApSrv.exe' loads 'vmGuestLib.dll' from a path that includes '\VMware\VMware Tools\vmStatsProvider\win32', while the DLL itself is not legitimately signed. This behavior can indicate an attempt to execute malicious code by tricking a legitimate process into loading a rogue DLL.
Detects potential DLL sideloading of a signed dbghelp.dll by the Sysinternals VMMap utility. This rule specifically looks for VMMap (vmmap.exe or vmmap64.exe) loading a dbghelp.dll from a non-standard path ('C:\Debuggers\dbghelp.dll') where the loaded DLL is signed. This could indicate an adversary attempting to load a malicious, yet signed, DLL to evade detection or achieve persistence/privilege escalation.
Page 46 of 48