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,875
5,151
4,864
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
Detects suspicious API calls related to remote thread creation, memory allocation, and screen capturing, along with image loads of GDI32.dll from unusual paths and specific file activity. This rule also identifies processes associated with known malicious software product names.
Detects instances where specific DLLs known to be abused in malicious contexts (libwebp.dll, mingwm10.dll, libffi-6.dll, libpng15.dll) are loaded by common productivity and scripting processes, such as Microsoft Office applications (Word, Excel, Outlook) or scripting engines (wscript.exe, mshta.exe). This pattern is often indicative of side-loading or exploitation of malicious documents and scripts.
This rule detects the loading of specific DLL files (commonly associated with open-source software libraries like mingw or webp) from user-writable directories (Temp, Downloads, AppData, etc.) by specific processes. The rule further correlates these events with recent execution of potential phishing-related commands (WScript, CScript, or download-related activity) on the same host within a 1-hour window.
Detects activity consistent with the Grandoreiro banking trojan, including DLL sideloading, screen capturing, keystroke hooking, unauthorized network connections to known banking infrastructure, and suspicious data exfiltration bursts.
This rule detects indicators of compromise associated with the TinyRCT malware, including the loading of a malicious AppDomainManager DLL by chrome_setup.exe, network connections to a known TinyRCT staging server, and the dropping of second-stage payloads such as PerfWatson2.exe to the local application data directory.
Detects a suspicious execution chain potentially associated with Deed RAT (used by Mustang Panda/Twill Typhoon), consisting of DLL sideloading by a legitimate signed executable followed by persistence mechanism creation (Registry Run keys or Scheduled Tasks) on the same host. Additionally, it identifies devices exhibiting repeated outbound connections to the same remote public IP over multiple days, serving as an indicator of potential re-compromise or persistent C2.
This rule detects the suspicious initialization of the Common Language Runtime (CLR) components (mscoree.dll, clr.dll, or oleaut32.dll) within the explorer.exe process, followed closely by an outbound HTTPS connection to filen.io domains. This pattern is indicative of fileless .NET-based C2 implants, such as those generated by the Covenant framework, executing within the context of a legitimate Windows shell process.
This rule detects the suspicious initialization of the Common Language Runtime (CLR) components (mscoree.dll, clr.dll, or oleaut32.dll) within the explorer.exe process, followed closely by an outbound HTTPS connection to filen.io domains. This pattern is indicative of fileless .NET-based C2 implants, such as those generated by the Covenant framework, executing within the context of a legitimate Windows shell process.
Detects when a signed process loads a DLL from a non-standard, user-writable directory (e.g., Temp, Downloads, Public folders). This is a common indicator of DLL hijacking or side-loading, where a legitimate signed application is leveraged to load a malicious library from a compromised location.
Detects the loading of specific vulnerable drivers (Huawei, Topaz Antifraud, Tower of Fantasy, K7 Security) abused by DragonForce ransomware in Bring Your Own Vulnerable Driver (BYOVD) attacks to terminate security software.
This rule detects when the process 'MpExtMs.exe' loads the 'EndpointDlp.dll' library from a file path outside of the standard, expected directories (such as Windows Defender or System32 folders). This behavior is often indicative of potential DLL side-loading, where an attacker attempts to substitute a legitimate system DLL with a malicious version to execute code in the context of a trusted Microsoft process.
Detects svchost.exe (hosting Windows Store Install Service) loading InstallServicePlugin.dll from a UNC path or making outbound SMB connections as NT AUTHORITY\SYSTEM. This indicates successful UNCanny coercion where the SYSTEM-level service performs LoadLibraryW against an attacker-controlled UNC path, enabling NTLM machine account capture or SYSTEM code execution.
This rule detects various methods used to extract credentials protected by the Windows Data Protection API (DPAPI). It covers multiple vectors, including Mimikatz DPAPI module usage, unauthorized loading of the dpapi.dll library, suspicious access to browser or WiFi credential stores, and cross-process memory access to the LSASS process to extract DPAPI master keys.
This rule detects attempts to inject malicious DLLs into common Windows processes such as svchost.exe, explorer.exe, lsass.exe, and winlogon.exe. The detection is based on the loading of DLLs with suspicious names like 'hook.dll', 'inject.dll', 'payload.dll', or 'stage.dll' by these processes, which is indicative of process injection techniques often used by malware like Remcos RAT.
Detects instances where known endpoint security product binaries (EDR/AV) load DLL files from directories outside of their trusted, standard installation paths. This behavior is a common indicator of DLL sideloading, where an attacker attempts to masquerade malicious code as a component of a trusted security process to evade detection.
Detects behavior patterns associated with Payouts King ransomware, including direct syscall-style API calls (NtAllocateVirtualMemory, NtWriteVirtualMemory, CreateRemoteThread) from processes other than trusted system binaries, and the loading of ntdll.dll from non-standard file paths (outside System32/SysWOW64). It also includes a hash-based detection for known Payouts King malicious samples.
Detects the Havoc Demon utilizing execute-assembly to load post-exploitation .NET tooling (like Seatbelt or SharpHound) directly into memory without touching disk. This rule identifies processes loading 'mscoree.dll' (a .NET runtime component) and subsequently making network connections to non-localhost IP addresses, indicating potential in-memory .NET execution with C2 communication.
Detects behavior patterns associated with the SharkLoader malware, specifically monitoring for anomalous thread creation, potential modification of primary tokens, and suspicious loading of SystemSettings.dll from non-standard directories (e.g., AppData, ProgramData). This rule aims to identify evasive techniques used to bypass Windows Loader Lock detection.
Detects the loading of ntdll.dll or amsi.dll by the Windows Update Service (wusvc.exe). This pattern is often observed in the context of advanced techniques like SNOWLIGHT, which uses direct syscall table enumeration to bypass security controls. Monitoring for these modules in this specific process context can indicate memory-resident malicious activity or evasion attempts.
Detects keylogging behavior associated with the TrymeLocker malware. The rule monitors for processes executing from non-standard, potentially writable directories (such as Temp, AppData, or ProgramData) that load user32.dll. This activity is indicative of an attempt to install a global Windows hook (SetWindowsHookEx) to intercept keystrokes (WH_KEYBOARD_LL).
Detects the SNOWLIGHT dropper performing an Antimalware Scan Interface (AMSI) bypass. The rule identifies processes that load 'amsi.dll' and subsequently perform memory manipulation (WriteProcessMemory or VirtualProtect) on the module's memory region within a 10-second window, excluding known Windows security components.
Page 20 of 33