Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
186 detections
Filters
Last updated
All Time
Detection languages
86
44
19
8
8
Contributors
73
17
13
12
11
Categories
102
82
41
35
35
Platforms
180
3
2
1
1
Products / Services
61
58
31
7
7
MITRE Techniques
18,108
15,613
12,573
8,384
6,203
IDS Classtypes
2
1
1
IDS Protocols
3
1
Detects usage of HollowReaper, a process hollowing shellcode launcher used for stealth payload execution through process hollowing.
It replaces the memory of a legitimate process with custom shellcode, allowing the attacker to execute payloads under the guise of trusted binaries.
It replaces the memory of a legitimate process with custom shellcode, allowing the attacker to execute payloads under the guise of trusted binaries.
Detects usage of HollowReaper, a process hollowing shellcode launcher used for stealth payload execution through process hollowing.
It replaces the memory of a legitimate process with custom shellcode, allowing the attacker to execute payloads under the guise of trusted binaries.
It replaces the memory of a legitimate process with custom shellcode, allowing the attacker to execute payloads under the guise of trusted binaries.
Detects the execution of rundll32 that leads to the invocation of legitimate Windows binaries.
The malware Pikabot has been seen to use this technique for process hollowing through hard-coded Windows binaries
The malware Pikabot has been seen to use this technique for process hollowing through hard-coded Windows binaries
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
Detects remote thread creation from CACTUSTORCH as described in references.
Detects when a memory process image does not match the disk image, indicative of process hollowing.
Backdoor processes associated with OceanLotus Mac malware backdoor dropper.
References:.
Https://blog.trendmicro.com/trendlabs-security-intelligence/new-macos-backdoor-linked-to-oceanlotus-found/.
OS Platforms: Macintosh.
References:.
Https://blog.trendmicro.com/trendlabs-security-intelligence/new-macos-backdoor-linked-to-oceanlotus-found/.
OS Platforms: Macintosh.
Query 1 shows you any network communication happened from endpoints to a specific Remote IP or Remote URL.
Ensure to update RemoteIP and RemoteURL variable.
For questions @MiladMSFT on Twitter or milad.aslaner@microsoft.com by email.
Ensure to update RemoteIP and RemoteURL variable.
For questions @MiladMSFT on Twitter or milad.aslaner@microsoft.com by email.
Detects the execution of rundll32 that leads to the invocation of legitimate Windows binaries.
The malware Pikabot has been seen to use this technique for process hollowing through hard-coded Windows binaries
The malware Pikabot has been seen to use this technique for process hollowing through hard-coded Windows binaries
Snip3 is a family of related remote access trojans. Although the malware in this family contain numerous small variations, they all exhibit similar behaviors and techniques.
The following query looks for potentially hollowed processes that may be used to facilitate command-and-control or exfiltration by Snip3 malware. This technique has been used in recent cases to exfiltrate data, including credentials.
The query may return additional malware or campaigns not necessarily associated with Snip3. However, Microsoft recommends triaging all non-benign results as potential malware.
The following query looks for potentially hollowed processes that may be used to facilitate command-and-control or exfiltration by Snip3 malware. This technique has been used in recent cases to exfiltrate data, including credentials.
The query may return additional malware or campaigns not necessarily associated with Snip3. However, Microsoft recommends triaging all non-benign results as potential malware.
These queries check telemetry from the Exploit Guard rule: Rule: Block Office applications from creating child processes.
(Rule ID d4f940ab-401b-4efc-aadc-ad5f3c50688a).
Read more about it here: https://docs.microsoft.com/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard.
Oftentimes organizations enable this rule in audit mode and check the results before setting block mode.
You can use query #2 to measure the rule impact on your network in audit mode before turning it to block mode.
Query #1 is used after setting it to block mode - to analyze the block stats.
Tags: #ASR.
Query #1: block stats.
(Rule ID d4f940ab-401b-4efc-aadc-ad5f3c50688a).
Read more about it here: https://docs.microsoft.com/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard.
Oftentimes organizations enable this rule in audit mode and check the results before setting block mode.
You can use query #2 to measure the rule impact on your network in audit mode before turning it to block mode.
Query #1 is used after setting it to block mode - to analyze the block stats.
Tags: #ASR.
Query #1: block stats.
These queries check telemetry from the Exploit Guard rule: Rule: Block Office applications from creating child processes.
(Rule ID d4f940ab-401b-4efc-aadc-ad5f3c50688a).
Read more about it here: https://docs.microsoft.com/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard.
Oftentimes organizations enable this rule in audit mode and check the results before setting block mode.
You can use query #2 to measure the rule impact on your network in audit mode before turning it to block mode.
Query #1 is used after setting it to block mode - to analyze the block stats.
Tags: #ASR.
Query #1: block stats.
(Rule ID d4f940ab-401b-4efc-aadc-ad5f3c50688a).
Read more about it here: https://docs.microsoft.com/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard.
Oftentimes organizations enable this rule in audit mode and check the results before setting block mode.
You can use query #2 to measure the rule impact on your network in audit mode before turning it to block mode.
Query #1 is used after setting it to block mode - to analyze the block stats.
Tags: #ASR.
Query #1: block stats.
Dopplepaymer In-Memory Malware Implant.
This query identifies processes with command line launch strings.
Which match the pattern used in Dopplepaymer ransomware attacks.
This query identifies processes with command line launch strings.
Which match the pattern used in Dopplepaymer ransomware attacks.
Original Sigma Rule: https://github.com/Neo23x0/sigma/blob/master/rules/apt/apt_unidentified_nov_18.yml.
Questions via Twitter: @janvonkirchheim.
Questions via Twitter: @janvonkirchheim.
Detects when a memory process image does not match the disk image, indicative of process hollowing. This rule specifically looks for 'Image is replaced' events and filters out common legitimate applications that might exhibit similar behavior, such as applications in 'Program Files', 'Windows\System32\wbem\WMIADAP.exe', 'Windows\SysWOW64\wbem\WMIADAP.exe', Opera, and Edge.
Detects whether a process is created from an image path that does not have a standard executable file extension (e.g., .exe, .com, .bin). This behavior can indicate advanced evasion techniques like process ghosting or other unorthodox methods to launch processes, where an executable might be disguised or loaded without a typical extension. The rule includes various filters to reduce false positives from legitimate system processes, temporary files, installer components, and specific third-party applications.
Detects process executions characteristic of Formbook malware. Specifically, it looks for processes originating from System32 or SysWOW64 directories with an executable extension, that then execute a command line containing '/c', 'del', and paths within 'C:\Users\<user>\AppData\Local\Temp\' or 'C:\Users\<user>\Desktop\'. It also covers a variant using '/C' and 'type nul >' for deletion on the Desktop. The rule aims to avoid false positives by excluding parent processes with command line parameters, suggesting an injection scenario where the parent process itself doesn't have complex command line arguments.
This rule detects the execution of a process where the 'Image' field (representing the executable path) is not a full, absolute path. This behavior can be indicative of techniques like process ghosting or other methods used to start processes in an unorthodox way, often to evade detection. The rule specifically filters out null or empty image paths and common system processes to reduce false positives.
Page 9 of 9