Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
665 detections
Filters
Last updated
All Time
Detection languages
257
174
86
76
36
Contributors
214
130
63
53
33
Categories
20,440
11,814
5,871
5,145
4,864
665
Platforms
641
26
7
3
2
Products / Services
317
186
85
32
25
MITRE Techniques
365
233
219
210
197
CVEs
2
2
2
2
1
IDS Classtypes
1
IDS Protocols
1
Detects process injection into ImagingDevices.exe, a technique observed in the 'Illusory Wishes' campaign to evade detection. The threat actor used trojanized versions of Element and VLC to inject shellcode into this legitimate Windows process.
Detects suspicious driver loads indicative of rootkits or BYOVD attacks. Flags unsigned/non-Microsoft drivers loaded from temp paths or by unusual processes. Targets random-named drivers (e.g., 'a1b2c3.sys'), known vulnerable drivers, and system driver impersonators.
KQL Query from file: Sentinel All-In-One UPN ThreatHunt
KQL Query from file: CVE-2025-32705 Out-of-bounds Read Detection
Detects process access requests from hacktool processes based on their default image name
Detects LSASS process access for potential credential dumping by a Python-like tool such as LaZagne or Pypykatz.
Detects LSASS process access by LaZagne for credential dumping.
Detects process access request to uncommon target images with a "PROCESS_ALL_ACCESS" access mask.
Detects the access to processes by other suspicious processes which have reflectively loaded libraries in their memory space.
An example is SilentTrinity C2 behaviour. Generally speaking, when Sysmon EventID 10 cannot reference a stack call to a dll loaded from disk (the standard way),
it will display "UNKNOWN" as the module name. Usually this means the stack call points to a module that was reflectively loaded in memory.
Adding to this, it is not common to see such few calls in the stack (ntdll.dll --> kernelbase.dll --> unknown) which essentially means that
most of the functions required by the process to execute certain routines are already present in memory, not requiring any calls to external libraries.
The latter should also be considered suspicious.
An example is SilentTrinity C2 behaviour. Generally speaking, when Sysmon EventID 10 cannot reference a stack call to a dll loaded from disk (the standard way),
it will display "UNKNOWN" as the module name. Usually this means the stack call points to a module that was reflectively loaded in memory.
Adding to this, it is not common to see such few calls in the stack (ntdll.dll --> kernelbase.dll --> unknown) which essentially means that
most of the functions required by the process to execute certain routines are already present in memory, not requiring any calls to external libraries.
The latter should also be considered suspicious.
Detects potential exploitation of remote code execution vulnerability CVE-2025-33053
by looking for process access that involves legitimate Windows executables (iediagcmd.exe, CustomShellHost.exe)
accessing suspicious executables hosted on WebDAV shares. This indicates an attacker may be exploiting
Process.Start() search order manipulation to execute malicious code from attacker-controlled WebDAV servers
instead of legitimate system binaries. The vulnerability allows unauthorized code execution through
external control of file names or paths via WebDAV.
by looking for process access that involves legitimate Windows executables (iediagcmd.exe, CustomShellHost.exe)
accessing suspicious executables hosted on WebDAV shares. This indicates an attacker may be exploiting
Process.Start() search order manipulation to execute malicious code from attacker-controlled WebDAV servers
instead of legitimate system binaries. The vulnerability allows unauthorized code execution through
external control of file names or paths via WebDAV.
Detects a typical pattern of a CobaltStrike BOF which inject into other processes
Detects process LSASS memory dump using Mimikatz, NanoDump, Invoke-Mimikatz, Procdump or Taskmgr based on the CallTrace pointing to ntdll.dll, dbghelp.dll or dbgcore.dll for win10, server2016 and up.
Detects when a process tries to access the memory of svchost to potentially dump credentials.
Detects LSASS process access by pypykatz for credential dumping.
Detects suspicious access to the "svchost" process such as that used by Invoke-Phantom to kill the thread of the Windows event logging service.
Detects processes requesting access to LSASS memory via suspicious access masks. This is typical for credentials dumping tools
Detects a process access to verclsid.exe that injects shellcode from a Microsoft Office application / VBA macro
Detects process access requests to the LSASS process with specific call trace calls and access masks.
This behaviour is expressed by many credential dumping tools such as Mimikatz, NanoDump, Invoke-Mimikatz, Procdump and even the Taskmgr dumping feature.
This behaviour is expressed by many credential dumping tools such as Mimikatz, NanoDump, Invoke-Mimikatz, Procdump and even the Taskmgr dumping feature.
Detects various indicators of Microsoft Connection Manager Profile Installer execution
Detects potential shellcode injection as seen used by tools such as Metasploit's migrate and Empire's psinject.
Expanding on DeviceEvents output with Attack Surface Reduction (ASR) rule descriptions.
The ActionType values of the ASR events already explain what rule was matched and if it was audited or blocked.
However, it could still be useful to have a more human-friendly description in the results.
Also, this query is a good example for how you could define your own lookup tables and join with them.
The events in the DeviceEvents table contain a GUID for the various ASR rules rather than a full description of the rule.
This query will create a table which has the description for each ASR rule as per https://docs.microsoft.com/windows/security/threat-protection/windows-defender-exploit-guard/enable-attack-surface-reduction.
This table is then joined to the output of a query against the DeviceEvents table and shows a summary count of the events by the newly defined description.
This query shows the ability to use joins and custom dimension tables.
See https://docs.loganalytics.io/docs/Language-Reference/Tabular-operators/join-operator for more information on the join syntax.
For more questions on this query, feel free to ping @FlyingBlueMonki on twitter or mattegen@microsoft.com via email.
First lets start by creating a table of the rule descriptions to rule guids.
The ActionType values of the ASR events already explain what rule was matched and if it was audited or blocked.
However, it could still be useful to have a more human-friendly description in the results.
Also, this query is a good example for how you could define your own lookup tables and join with them.
The events in the DeviceEvents table contain a GUID for the various ASR rules rather than a full description of the rule.
This query will create a table which has the description for each ASR rule as per https://docs.microsoft.com/windows/security/threat-protection/windows-defender-exploit-guard/enable-attack-surface-reduction.
This table is then joined to the output of a query against the DeviceEvents table and shows a summary count of the events by the newly defined description.
This query shows the ability to use joins and custom dimension tables.
See https://docs.loganalytics.io/docs/Language-Reference/Tabular-operators/join-operator for more information on the join syntax.
For more questions on this query, feel free to ping @FlyingBlueMonki on twitter or mattegen@microsoft.com via email.
First lets start by creating a table of the rule descriptions to rule guids.
Page 28 of 32