Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
271 detections
Filters
Last updated
All Time
Detection languages
113
58
32
20
16
Contributors
115
47
32
21
7
Categories
103
84
68
64
57
Platforms
226
28
12
4
3
Products / Services
83
72
46
17
14
MITRE Techniques
18,104
15,609
12,572
8,382
6,201
CVEs
2
IDS Classtypes
2
1
IDS Protocols
3
Detects PowerShell commands that attempt to load a .NET assembly directly into memory using reflection. This is common in fileless malware delivery, such as the Remcos RAT campaign described in the provided intel, which uses reflection to load the final RAT stage from a steganographic JPEG, making disk-based detection ineffective.
Detects the VoidLink malware's initial dropper behavior, where a process masquerading as a kernel thread executes a payload from memory. This is indicative of the memfd_create and execveat fileless execution technique used by VoidLink, characterized by a process created with no FolderPath or FileName, initiated by a process named like a kernel thread.
This query utilizes the IOCs provided by Rapid7 and focuses on columns in the DeviceFileEvents, DeviceProcessEvents and DeviceNetworkEvents tables. This is a high FP query, however each event will require an investigation to its legitimacy. The query accounts for all devices that have installed notepad++ in the past 400d and only looking for IOCs within time of known compromise in order to save on resources. Some IOCs are commented out due to high FP rate.
Detects PowerShell loading .NET assemblies into memory (not from disk) via reflection from suspicious sources including base64-encoded data, web downloads, or compressed streams. This pattern indicates fileless malware execution or post-exploitation tool delivery.
This rule detects the multi-stage VoidLink C2 loader chain by identifying a combination of behaviors. It looks for fileless execution, specifically processes running from memory file descriptors or /proc/[pid]/fd paths. It also identifies kernel thread masquerading, where processes attempt to mimic legitimate kernel threads by using command lines like '[kworker/...]' or '[migration/...]' in conjunction with non-kernel executable paths. The rule further identifies staging activities, such as processes executing from common temporary directories like /tmp, /dev/shm, or /var/tmp. Additionally, it looks for specific VoidLink artifacts in command lines, including '.vl_', 'stage[0-9].bin', 'implant.bin', or C2 communication patterns like '/api/v2/(handshake|sync)'. Finally, it detects anonymous network activity, where a deleted executable (indicating fileless execution) is associated with network connection utilities like curl, wget, or socket/connect calls. The rule triggers when specific combinations of these behaviors are observed, such as fileless execution combined with kernel masquerading, or fileless execution combined with staging, or kernel masquerading combined with staging, or VoidLink artifacts combined with fileless execution or kernel masquerading, or anonymous network activity combined with kernel masquerading or staging. This correlation aims to reduce false positives by requiring multiple indicators of compromise.
Detects various activities associated with the ShadowHS fileless Linux post-exploitation framework, including fileless execution, specific command-line patterns, covert exfiltration, and connections to known C2 infrastructure.
Detects a PowerShell process that makes an outbound network connection and contains command-line arguments associated with reflectively loading a .NET assembly from a Base64 encoded string. This is a common fileless technique used by malware like Remcos to execute payloads in memory.
Detects the creation and execution of anonymous memory-backed files using `memfd_create`. This technique is used by malware like VoidLink to execute modular plugins or payloads directly in memory, bypassing disk-based detection mechanisms.
The following analytic identifies suspicious PowerShell execution using Script Block Logging (EventCode 4104). It leverages specific patterns and keywords within the ScriptBlockText field to detect potentially malicious activities. This detection is significant for SOC analysts as PowerShell is commonly used by attackers for various malicious purposes, including code execution, privilege escalation, and persistence. If confirmed malicious, this activity could allow attackers to execute arbitrary commands, exfiltrate data, or maintain long-term access to the compromised system, posing a severe threat to the organization's security.
Detects reflective loading of .NET assemblies from memory within PowerShell. This technique is often used to execute malicious code while bypassing file-based detections and some AMSI features, as the assembly is loaded directly from a byte array rather than from a file on disk.
Detects potential_APT-style process hollowing on Linux using syscall stubs and string camouflage
KQL Query from file: .NET Reflection Defense Evasion (Reflective Code Loading)
KQL Query from file: CVE-2025-24054 NTLM Exploit in the Wild Detection
Detects base64 encoded .NET reflective loading of Assembly
Detects base64 encoded .NET reflective loading of Assembly
Detects usage of "Reflection.Assembly" load functions to dynamically load assemblies in memory
Detects PowerShell commands attempting to load .NET assemblies reflectively using Base64 encoded strings. This technique is often used by adversaries to execute malicious code in memory, evading disk-based detections.
Detects when a .NET assembly DLL from the Windows assembly cache (C:\Windows\assembly\) is loaded by a Microsoft Office application. This behavior can indicate an attempt to execute malicious code or achieve persistence through Office applications by leveraging .NET assemblies.
Detects the usage of `[Reflection.Assembly]::load` functions within PowerShell script block logs. This method allows for dynamically loading assemblies into memory, which can be used by adversaries to execute malicious code without writing it to disk, thus evading traditional file-based detections.
Page 13 of 13