Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,164 detections
Filters
Last updated
All Time
Detection languages
520
470
72
54
20
Contributors
259
229
161
156
125
Categories
20,456
11,839
5,876
5,155
4,865
1,164
Platforms
1,143
28
18
1
Products / Services
430
403
35
18
15
MITRE Techniques
814
472
460
442
429
CVEs
6
6
5
5
3
Detects the execution of a process from a non-standard writable directory (e.g., Temp, Downloads, AppData) which subsequently loads an unsigned DLL from the same directory within two minutes of process creation. This behavior is indicative of DLL side-loading, where an adversary uses a legitimate, potentially signed application to load a malicious DLL, bypassing security controls.
This rule performs a point-in-time sweep for known Indicators of Compromise (IOCs) associated with the NeedyMantis threat actor group. The detection logic searches for specific file, process, and image-load SHA256 hashes, communication with a known C2 domain (tripswithengine.com), and the use of a hard-coded user-agent string (Firefox/21.0) across various telemetry sources within the last 30 days.
Detects the two Windows-networking-named DLLs the report confirms as sideloaded via the normal OS loader (WinSparkle.dll, libcurl.dll) plus vim64.dll (a filename Vim's real installer never produces at all). Path check now covers any location outside a small allowlist of known-legitimate vendor install folders, not just ProgramData, so it also catches the reported ProgramData\\USOShared, ProgramData\\VIM, and ProgramData\\TightVNC\\VIM placements. Known limitation: the one reported case where the malicious WinSparkle.dll sits at the exact canonical Program Files\\Poedit path cannot be distinguished by path alone -- that specific sideload is instead caught by the companion 'Extensionless Archive Paired with Same-Named DLL Drop' rule via the archive-pairing signal.
Detects the loading of unsigned DLLs from non-system directories where the DLL filename matches common Windows system libraries. This behavior is indicative of DLL side-loading, where adversaries use a trusted, digitally-signed application to load a malicious DLL in an attempt to bypass security controls and maintain persistence.
Detects evidence of the Antino backdoor performing sleep-masking shellcode evasion. The rule monitors for 'slc.dll' being sideloaded by 'GatherOsState.exe' and the subsequent invocation of memory management APIs (VirtualAlloc, NtAllocateVirtualMemory) paired with memory protection changes (VirtualProtect) or thread context modification, which are characteristic behaviors used by Antino to mask malicious shellcode in memory between execution intervals.
Detects a potential process hollowing technique where 'Finalized.dll' (loaded from unconventional locations like a ComponentsFolder or System32) is used to spawn 'clspack.exe' in a suspended state from a non-standard path (e.g., AppData\Microsoft). This sequence indicates an attempt to mask malicious execution under a legitimate process name.
Detects instances where a signed executable, typically a security or trusted system binary, loads an unsigned DLL from a user-writable, non-default directory (e.g., Temp, AppData, ProgramData). The rule specifically targets common system or vendor library names, indicating potential DLL search-order hijacking used to execute malicious code within a trusted process context.
Detects instances where a process loads both amsi.dll and the .NET CLR (clr.dll or mscoree.dll) within a 60-second window, excluding known legitimate .NET and PowerShell hosts. This behavior is indicative of an in-memory shellcode loader attempting to bypass AMSI protections before executing .NET payloads in memory, a technique frequently observed in sophisticated malware campaigns.
This rule detects when the MpDlpService.exe process loads the 'mpclient.dll' library from a location other than the legitimate Windows Defender program directories. This behavior is indicative of potential DLL side-loading or hijack execution flow attempts targeting the Microsoft Data Loss Prevention service.
This rule detects potential DLL sideloading activity where legitimate, signed binaries (such as COTFileReadApp.exe or DeElevate64.exe) are executed from non-standard directories (e.g., AppData, Temp, Downloads) while loading specifically identified malicious or sideloaded DLLs. The detection identifies patterns where these binaries operate outside their expected vendor installation paths, indicating a likely attempt to hijack execution flow.
Detects a .ps1-named file being loaded as an executable image or created as a process's own file name (both anomalous under normal Windows semantics, since PowerShell always runs scripts via powershell.exe/pwsh.exe as the process image, never as the .ps1 itself). Anchored to the known NeedyMantis sideload staging folders to exclude unrelated developer/test tooling elsewhere on disk that might trip a similar anomaly.
Detects a .ps1-named file being loaded as an executable image or created as a process's own file name (both anomalous under normal Windows semantics, since PowerShell always runs scripts via powershell.exe/pwsh.exe as the process image, never as the .ps1 itself). Anchored to the known NeedyMantis sideload staging folders to exclude unrelated developer/test tooling elsewhere on disk that might trip a similar anomaly.
Detects a .ps1-named file being loaded as an executable image or created as a process's own file name (both anomalous under normal Windows semantics, since PowerShell always runs scripts via powershell.exe/pwsh.exe as the process image, never as the .ps1 itself). Anchored to the known NeedyMantis sideload staging folders to exclude unrelated developer/test tooling elsewhere on disk that might trip a similar anomaly.
Detects NeedyMantis-style DLL sideloading: a DLL is dropped at an anomalous ProgramData/ProgramFiles path mirroring known first-stage loader naming/path conventions (masquerading as Poedit, curl, Vim, TightVNC, Office, Broadcom, Intel, or NVIDIA components), AND that exact same DLL is subsequently loaded by a process within 10 minutes. Requiring the corroborating load event (rather than file presence alone) filters out benign drops such as installer staging, AV quarantine copies, or backup/sync tools that never execute the file.
Detects NeedyMantis-style DLL sideloading: a DLL is dropped at an anomalous ProgramData/ProgramFiles path mirroring known first-stage loader naming/path conventions (masquerading as Poedit, curl, Vim, TightVNC, Office, Broadcom, Intel, or NVIDIA components), AND that exact same DLL is subsequently loaded by a process within 10 minutes. Requiring the corroborating load event (rather than file presence alone) filters out benign drops such as installer staging, AV quarantine copies, or backup/sync tools that never execute the file.
Detects a specific execution sequence associated with the SectopRAT loader. The rule identifies a process named 'ReportDump.exe' reading a payload file 'Activation.Desktop.db' and subsequently loading 'stp_aim_x64_vc15.dll', which is known to trigger malicious shellcode via an exported function.
Detects instances where rundll32.exe loads a DLL file named Use.dll from a subdirectory named 'ComponentsFolder' within the AppData directory. This pattern is indicative of sandbox evasion techniques used by malware, such as the DarkMe RAT, where the DLL acts as an anti-sandbox gateway to check the execution environment.
Detects the drop and execution of the AvisLoader rootkit component, hmn_hook.dll. The rule identifies suspicious file drops in non-standard, user-writable directories (e.g., AppData, Temp) that are not associated with legitimate installers, as well as the loading of unsigned or non-Microsoft-signed versions of the DLL accompanied by hook-related process arguments such as HMN_HideStart or NtQuerySystemInformation.
Detects DLL side-loading activity where the legitimate-looking process rnpkeys.exe, located in a non-standard ProgramData sub-directory, loads a malicious rnp.dll from the same directory, a behavior observed with the Sauron Loader malware.
Detects the execution of the Sauron Loader malware, which utilizes a DLL side-loading chain involving rnpkeys.exe loading rnp.dll or tdwp.dll from a specific ProgramData path, indicating potential malicious activity.
This rule detects the loading of a specific module named 'tdwp.dll' by the 'rnpkeys.exe' process, where both files are located within a 'keyroll' directory. This pattern is indicative of potential DLL sideloading or execution of unauthorized components where a legitimate-looking process loads a custom, possibly malicious, library from a non-standard location.
Page 5 of 56