Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
12 detections
Filters
Last updated
All Time
Detection languages
4
3
3
2
Contributors
4
2
2
2
1
Categories
6
4
4
3
3
Platforms
12
Products / Services
6
1
1
1
1
MITRE Techniques
18,115
15,635
12,576
8,388
6,215
Detects bulk registry queries over SMB for system discovery
Detects bulk registry queries over SMB for system discovery
Detects suspicious modification of the Windows TIP AggregateResults registry key with large data indicative of persistence.
This rule detects attempts to disable Event Tracing for Windows (ETW) logging within .NET processes by modifying specific registry keys. Adversaries may perform this action to evade detection by security tools that rely on ETW for monitoring .NET activity. The rule specifically looks for modifications to the 'ETWEnabled' and 'ETWFlags' registry keys under 'SOFTWARE\Microsoft\.NETFramework' or 'COMPlus_' prefixed keys, setting their values to '0' (disabled). This indicates an attempt to prevent the recording of loaded .NET assemblies and other relevant ETW events, thereby hindering security monitoring capabilities.
Detects modifications to the registry key "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\Userlist" where the value is set to "0" in order to hide a user account from being listed on the logon screen. This is a defense evasion technique used by adversaries to maintain stealth.
Detects tampering of RDP Terminal Service/Server sensitive settings. Such as allowing unauthorized users access to a system via the 'fAllowUnsolicited' or enabling RDP via 'fDenyTSConnections'...etc
Detects modifications to various Windows Registry keys under `CurrentVersion` that are commonly used for autostart extensibility points (ASEPs). This includes `Run`, `RunOnce`, `RunOnceEx`, `RunServices`, `RunServicesOnce`, `ShellServiceObjectDelayLoad`, `Policies\System\Shell`, `Policies\Explorer\Run`, `Group Policy\Scripts`, `Explorer\ShellServiceObjects`, `Explorer\ShellIconOverlayIdentifiers`, `Explorer\ShellExecuteHooks`, `Explorer\SharedTaskScheduler`, `Explorer\Browser Helper Objects`, `Authentication\PLAP Providers`, `Authentication\Credential Providers`, and `Authentication\Credential Provider Filters`. Adversaries often modify these keys to establish persistence on a system by ensuring their malicious code executes automatically during system boot or user logon.
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
The following analytic detects modifications to the Windows registry aimed at disabling the Registry Editor (regedit). It leverages data from the Endpoint.Registry data model, specifically monitoring changes to the registry path "*\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\DisableRegistryTools" with a value of "0x00000001". This activity is significant because malware, such as RATs or trojans, often disable registry tools to prevent the removal of their entries, aiding in persistence and defense evasion. If confirmed malicious, this could hinder incident response efforts and allow the attacker to maintain control over the compromised system.
This rule detects a registry modification that allows the 'Consent Admin' to perform operations requiring elevation without user consent or credentials. It specifically monitors changes to the 'ConsentPromptBehaviorAdmin' value within the Windows Policies System registry path to '0x00000000'. This activity is significant as it indicates a potential privilege escalation attempt, which could allow an attacker to execute high-privilege tasks without user approval. If confirmed malicious, this could lead to unauthorized administrative access and control over the compromised machine, posing a severe security risk.
The following analytic detects the modification of Windows Defender registry settings to disable antivirus and antispyware protections. It leverages data from the Endpoint.Registry data model, specifically monitoring changes to registry paths associated with Windows Defender policies. This activity is significant because disabling antivirus protections is a common tactic used by adversaries to evade detection and maintain persistence on compromised systems. If confirmed malicious, this action could allow attackers to execute further malicious activities undetected, leading to potential data breaches, system compromise, and further propagation of malware within the network.
The following analytic detects registry changes to the default file association value. It leverages data from the Endpoint data model, specifically monitoring registry paths under "HKCR\\*\\shell\\open\\command\\*". This activity can be significant because, attackers might alter the default file associations in order to execute arbitrary scripts or payloads when a user opens a file, leading to potential code execution. If confirmed malicious, this technique can enable attackers to persist on the compromised host and execute further malicious commands, posing a severe threat to the environment.