Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,161 detections
Filters
Last updated
All Time
Detection languages
517
470
72
54
20
Contributors
259
229
161
156
125
Categories
20,439
11,829
5,873
5,151
4,864
1,161
Platforms
1,140
28
18
1
Products / Services
427
403
35
18
15
MITRE Techniques
812
471
460
439
429
CVEs
6
6
5
5
3
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.
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.
This rule detects potential DLL side-loading attempts involving the legitimate Microsoft Defender binary 'mpextms.exe'. The rule triggers when 'mpextms.exe' is executed from a non-standard, user-writable directory (e.g., Temp, AppData, Downloads) and subsequently loads a specific 'endpointdlp.dll' from an equally suspicious location, indicating a potential attempt to masquerade malicious code execution behind a trusted process.
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.
The following analytic detects when DLLs with known abuse history are loaded from an unusual location.
This activity may represent an attacker performing a DLL search order or sideload hijacking technique.
These techniques are used to gain persistence as well as elevate privileges on the target system.
This activity may represent an attacker performing a DLL search order or sideload hijacking technique.
These techniques are used to gain persistence as well as elevate privileges on the target system.
Detects a behavioral pattern associated with the NeedyMantis first-stage loader, which involves the loading of specific suspicious DLLs (masquerading as common software components) followed by the extraction or creation of an 'encryptbase64.ps1' second-stage loader within a short timeframe (10 minutes) on the same host.
Detects a suspicious execution sequence associated with the SectopRAT loader. The rule monitors for ReportDump.exe being launched from a ProgramData directory by common scheduling or service host processes, followed immediately by the loading of a malicious sdkcra.dll library.
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 post-exploitation command execution originating from a compromised explorer.exe process. The rule identifies processes like cmd.exe, powershell.exe, or conhost.exe spawned by an explorer.exe instance that has previously loaded the malicious 'MicrosoftEdgeUpdateCore.dll' module, correlating this activity with the established 'tailcat.exe' command-and-control tunnel.
This rule detects potential post-exploitation activity following a SharePoint XamlServices.Parse() deserialization attack. It monitors the w3wp.exe (IIS worker process) for the loading of suspicious .NET deserialization-related assemblies (e.g., System.Xaml.dll) followed by the execution of a shell process (cmd.exe, powershell.exe, etc.) within a short window, which is indicative of fileless web shell activity.
Detects the loading of spoofed system DLLs (dnsapi.dll or ws2_32.dll) from non-system directories, followed by network beaconing to suspicious domains associated with the NeedyMantis malware.
Detects instances where an unexpected process loads both 'amsi.dll' and .NET runtime modules ('clr.dll' or 'mscoree.dll'). This behavior is frequently associated with malicious, position-independent shellcode that attempts to disable AMSI scanning and host the CLR in-memory to execute malicious .NET assemblies or payloads, avoiding standard .NET execution environments like PowerShell or msbuild.exe.
Detects the loading of specific commonly side-loaded DLLs (libcef.dll, version.dll, msimg32.dll) from user-writable directories such as Downloads, Temp, or AppData. Attackers often use these locations to drop malicious DLLs alongside legitimate applications to achieve DLL side-loading for persistence or defense evasion.
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 behavior consistent with the Kothamine agent, where a recently dropped DLL in a temporary directory is loaded by a short-lived explorer.exe process. This rule monitors for file creation, subsequent module loading by the explorer process, and ensures the process was spawned in close proximity to the file activity, indicating likely process injection.
Detects instances where a digitally signed executable loads a DLL from a non-standard, user-writable directory (such as Downloads, Desktop, Temp, or AppData). This behavior is characteristic of DLL side-loading, an evasion technique used to execute malicious code by placing a rogue DLL in a location where a legitimate binary might search for its dependencies, often used by threat actors to persist or maintain covert execution.
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.
Page 4 of 56