Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,155 detections
Filters
Last updated
All Time
Detection languages
511
470
72
54
20
Contributors
259
229
161
151
125
Categories
20,443
11,831
5,872
5,155
4,866
1,155
Platforms
1,134
23
13
1
Products / Services
427
403
35
18
15
MITRE Techniques
810
468
459
437
429
CVEs
6
6
5
5
3
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 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.
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 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 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.
Page 4 of 55