Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
112 detections
Filters
Last updated
All Time
Detection languages
59
33
9
3
3
Contributors
27
20
16
7
7
Categories
78
42
20
9
9
Platforms
100
9
5
2
1
Products / Services
34
28
15
4
4
MITRE Techniques
18,116
15,636
12,583
8,393
6,223
CVEs
1
Detects potential command injection attacks against AI agents through
suspicious prompt patterns or system command execution by AI processes.
suspicious prompt patterns or system command execution by AI processes.
Detects command injection related attacks with AI agents through suspicious prompt patterns or system command execution by AI processes.
Detects suspicious child processes spawned by gup.exe, which is the Notepad++ updater. This behavior can indicate an attempt to hijack the update process for malicious purposes, such as executing arbitrary code or installing unwanted software. The rule specifically looks for gup.exe spawning common scripting/execution tools (update.exe, AutoUpdater.exe, curl.exe, cmd.exe, powershell.exe, wscript.exe, cscript.exe, rundll32.exe) or processes from temporary or user application data directories, while excluding legitimate explorer.exe and Notepad++ installer processes.
This rule detects anomalous process executions originating from the SolarWinds Web Help Desk application. It monitors for any child processes spawned by the Web Help Desk application that are not part of a predefined allowlist of expected executables (java.exe, pg_dump.exe, reg.exe, conhost.exe, WerFault.exe) or command lines (mysqldump). This can indicate compromise or misuse of the application to execute arbitrary code.
Detection of Evasive Panda secondary loader. Context: evteng.exe (signed Python wrapper) must run from C:\ProgramData\Microsoft\eHome (abuse path), not from standard Python install. Process image path contains eHome and executable is evteng.exe; parent may be same path or MFloader. Excludes evteng from Program Files or standard Python locations.
Detects a sequence of events where a Protected Process Light (PPL) security process attempts to load a DLL from a non-standard path and then terminates shortly after. This pattern is a strong indicator of the EDRStartupHinder technique, where a critical system DLL is redirected to an invalid copy, causing the PPL process to fail its integrity check and self-terminate.
This detection identifies outbound network traffic to domains, IP addresses, or a specific port known to be associated with the PHALT#BLYX campaign's infrastructure. The campaign uses these for malware delivery and DCRat command and control (C2). The rule specifically looks for connections to known malicious IPs or domains, or connections on port 3535 (used by DCRat) originating from processes associated with the malware (staxs.exe, tybd7.exe, aspnet_compiler.exe).
This rule detects the creation or modification of executable files with a single-character filename followed by '.exe' (e.g., 'a.exe', 'b.exe'). This pattern is often used by adversaries to evade detection or to make malicious files less conspicuous. The rule specifically excludes 'R for Windows front-end' to reduce false positives related to legitimate software.
Detects specific process creation patterns associated with the Winnti malware campaign targeting Hong Kong universities in late 2019 and early 2020. The rule looks for suspicious parent-child process relationships and specific file paths used by the malware, such as executables under 'C:\Windows\Temp', 'C:\ProgramData\DRM', and 'C:\ProgramData\DRM\CLR'. It also identifies instances where legitimate applications like 'wmplayer.exe' or 'SearchFilterHost.exe' are launched from these suspicious directories or by suspicious parent processes.
Detects attempts to freeze a process, likely an EDR or an antimalware service process, through EDR-Freeze that abuses the WerFaultSecure.exe process to suspend security software. The rule specifically looks for WerFaultSecure.exe being executed with a particular set of command-line arguments that are indicative of the EDR-Freeze tool's behavior, including '/h', '/pid', '/tid', '/encfile', '/cancel', '/type', and '268310'.
Detects the creation of suspicious child processes, such as common scripting or living-off-the-land binaries (LOLBINs), originating from applications located within the WindowsApps directory. This activity could indicate the execution of malicious '.appx' packages or other forms of code execution from an unexpected and potentially untrusted source.
On October 14, 2025, less than one month from now, Exchange Server 2016 and Exchange Server 2019 will reach end of support. It’s critical to upgrade now to remain supported and secure. This query check for all possible builds of Exchange Server 2016 and Exchange Server 2019.
Detects the execution of Regsvr32.exe with DLL files that have been renamed or masqueraded with suspicious file extensions. This technique is often used by adversaries for defense evasion and to bypass application control by proxying execution through a legitimate Windows binary.
This rule detects indicators of compromise (IOCs) associated with the 'ManualFinder/PDF Editor' malware campaign. It identifies malicious activity across multiple data sources, including file hashes, process hashes, suspicious certificate signers, suspicious company names in version info, suspicious file descriptions, malicious command execution, and network connections to known command and control (C2) or malicious PDF-related domains. The rule leverages external data sources for IOCs such as file hashes, C2 domains, PDF-related domains, suspicious signers, and malicious commands. It also includes static IOCs like specific file descriptions and company names. The detection logic is designed to identify various stages of the malware's activity, from initial execution to network communication.
Detects command line obfuscation using carets (^) in Windows interpreters like cmd.exe and PowerShell.
Detects potential_APT-style process hollowing on Linux using syscall stubs and string camouflage
This rule detects the creation of a new process (cmd.exe) that is spawned by a w3wp.exe process, which itself is a child of svchost.exe, and where the command line of the w3wp.exe process contains the string "SharePoint". This chain of events could indicate suspicious activity within a SharePoint environment, potentially an attacker executing commands via a compromised IIS worker process.
KQL Query from file: DefenderXDR - Devman Ransomware Detection
This rule detects the execution of "wusa.exe" (Windows Update Standalone Installer) when its parent process is located in suspicious directories. Attackers may leverage wusa.exe to bypass User Account Control (UAC) and elevate privileges by duplicating its access token. The suspicious parent process locations include common temporary directories, public user folders, and specific user profile subdirectories like Favorites, Favourites, Contacts, and Pictures.
Baseline Comparison.
Author: miflower.
The purpose of this query is to perform a comparison between "known good" machines and suspected bad machines.
The original concept for this query was born due to reapplying the same 'whitelist' filters over and over.
It brings deltas between a baseline and another machine quickly to the analyst's view.
This query supports multiple suspected bad machines and multiple "known good" machines.
It also supports providing a timeframe for how far back in time to build a baseline as well as how far back in time to evaluate the suspected bad machines.
Each of the links provided by DeviceId/DeviceName will go to the most recent entry for whatever entity is listed.
Average results for the pre-defined settings below with a single good host and a single bad host on a 'huge' tenant (300k+ machines):.
Compute Time: ~10-20 seconds.
Result Set Size: ~500 rows.
The workflow is as follows:.
1. Establish Variables that are editable on a per-query basis.
2. Define functions for reuse.
3. Calculate DeviceIds for all machines in scope.
4. Derive deltas using the aforementioned functions.
5. Union together all results into a single view.
The following datasets are returned:.
1. Alerts on the suspected bad machines (ignores known good machines, because...they're alerts, additional data has the triggered file).
2. Connected Networks (from DeviceNetworkInfo table, additional data has full Connected Network details).
3. File Creations (disabled by default due to volume, enable at your own risk, additional data has initiating processes).
4. Image Loads (disabled by default due to volume, enable at your own risk, additional data has initiating processes).
5. Logon (derived from DeviceLogonEvents for the unique users logged on, additional data has logon types).
6. Network communication (grouped by 2nd level-domain, ie 'microsoft.com' in 'www.microsoft.com' and 'web.microsoft.com', additional data has the full list of URLs).
7. Process creation (additional da
Author: miflower.
The purpose of this query is to perform a comparison between "known good" machines and suspected bad machines.
The original concept for this query was born due to reapplying the same 'whitelist' filters over and over.
It brings deltas between a baseline and another machine quickly to the analyst's view.
This query supports multiple suspected bad machines and multiple "known good" machines.
It also supports providing a timeframe for how far back in time to build a baseline as well as how far back in time to evaluate the suspected bad machines.
Each of the links provided by DeviceId/DeviceName will go to the most recent entry for whatever entity is listed.
Average results for the pre-defined settings below with a single good host and a single bad host on a 'huge' tenant (300k+ machines):.
Compute Time: ~10-20 seconds.
Result Set Size: ~500 rows.
The workflow is as follows:.
1. Establish Variables that are editable on a per-query basis.
2. Define functions for reuse.
3. Calculate DeviceIds for all machines in scope.
4. Derive deltas using the aforementioned functions.
5. Union together all results into a single view.
The following datasets are returned:.
1. Alerts on the suspected bad machines (ignores known good machines, because...they're alerts, additional data has the triggered file).
2. Connected Networks (from DeviceNetworkInfo table, additional data has full Connected Network details).
3. File Creations (disabled by default due to volume, enable at your own risk, additional data has initiating processes).
4. Image Loads (disabled by default due to volume, enable at your own risk, additional data has initiating processes).
5. Logon (derived from DeviceLogonEvents for the unique users logged on, additional data has logon types).
6. Network communication (grouped by 2nd level-domain, ie 'microsoft.com' in 'www.microsoft.com' and 'web.microsoft.com', additional data has the full list of URLs).
7. Process creation (additional da
'Shows the rarest processes seen running for the first time. (Performs best over longer time ranges - eg 3+ days rather than 24 hours!)
These new processes could be benign new programs installed on hosts;
However, especially in normally stable environments, these new processes could provide an indication of an unauthorized/malicious binary that has been installed and run.
Reviewing the wider context of the logon sessions in which these binaries ran can provide a good starting point for identifying possible attacks.'
These new processes could be benign new programs installed on hosts;
However, especially in normally stable environments, these new processes could provide an indication of an unauthorized/malicious binary that has been installed and run.
Reviewing the wider context of the logon sessions in which these binaries ran can provide a good starting point for identifying possible attacks.'
Page 3 of 6