Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
503 detections
Filters
Last updated
All Time
Detection languages
250
122
32
26
24
Contributors
140
53
39
37
35
Categories
378
174
161
59
47
Platforms
383
98
29
17
10
Products / Services
142
107
48
40
20
MITRE Techniques
18,108
15,613
12,573
8,384
6,203
CVEs
3
3
2
2
1
IDS Classtypes
2
1
IDS Protocols
2
'This query looks for diagnostic settings that are removed from a resource.
This could indicate an attacker or malicious internal trying to evade detection before malicious act is performed.
If the diagnostic settings are being deleted as part of a parent resource deletion, the event is ignores.'
This could indicate an attacker or malicious internal trying to evade detection before malicious act is performed.
If the diagnostic settings are being deleted as part of a parent resource deletion, the event is ignores.'
Detects the deletion of the TeamViewer log files which may indicate an attempt to destroy forensic evidence
Detects backup catalog deletions
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
This query visualises total emails with Malware detections over time summarizing the data daily by Malware detection technologies/controls used for detecting unknown-unique malware.
Detects uncommon and potentially suspicious one-liner command containing both "ping" and "copy" at the same time, which is usually used by malware.
Detects execution of the builtin "del"/"erase" commands in order to delete files.
Adversaries may delete files left behind by the actions of their intrusion activity.
Malware, tools, or other non-native files dropped or created on a system by an adversary may leave traces to indicate to what was done within a network and how.
Removal of these files can occur during an intrusion, or as part of a post-intrusion process to minimize the adversary's footprint.
Adversaries may delete files left behind by the actions of their intrusion activity.
Malware, tools, or other non-native files dropped or created on a system by an adversary may leave traces to indicate to what was done within a network and how.
Removal of these files can occur during an intrusion, or as part of a post-intrusion process to minimize the adversary's footprint.
Detects the deletion of the "Zone.Identifier" ADS. Attackers can leverage this in order to bypass security restrictions that make use of the ADS such as Microsoft Office apps.
This query looks for users performing file deletion activities. Spikes in file deletion observed from risky sign-in sessions are flagged here.
This applies to SharePoint and OneDrive users.
Audit event and Cloud application identifier references.
Reference - https://learn.microsoft.com/microsoft-365/compliance/audit-log-activities?view=o365-worldwide
Reference - https://learn.microsoft.com/azure/sentinel/entities-reference#cloud-application-identifiers
This applies to SharePoint and OneDrive users.
Audit event and Cloud application identifier references.
Reference - https://learn.microsoft.com/microsoft-365/compliance/audit-log-activities?view=o365-worldwide
Reference - https://learn.microsoft.com/azure/sentinel/entities-reference#cloud-application-identifiers
Detects uncommon and potentially suspicious one-liner command containing both "ping" and "copy" at the same time, which is usually used by malware.
"This query searches for any files in Cloud App Events that have trigger a security alert."
This query visualises total emails with Phish detections over time summarizing the data daily by Phish detection technologies/controls used for detecting unknown-unique phish
Detects the deletion of a prefetch file which may indicate an attempt to destroy forensic evidence
This query identifies files that are copied to a device over SMB, then executed within a
specified threshold. Default is 5 seconds, but is configurable by tweaking the value for
ToleranceInSeconds.
specified threshold. Default is 5 seconds, but is configurable by tweaking the value for
ToleranceInSeconds.
To evade security software and analyst tools, Nobelium malware enumerates the target system looking for certain running processes, loaded drivers, and registry keys, with the goal of disabling them.
The Microsoft Defender for Endpoint sensor is one of the processes the malware attempts to disable.
Microsoft Defender for Endpoint has built-in protections against many techniques attackers use to disable endpoint sensors ranging from hardened OS protection, anti-tampering policies, and detections for a variety of tampering attempts, including "Attempt to stop Microsoft Defender for Endpoint sensor", "Tampering with Microsoft Defender for Endpoint sensor settings", or "Possible sensor tampering in memory".
Successfully disabling Microsoft Defender for Endpoint can prevent the system from reporting observed activities.
However, the multitude of signals reported into Microsoft Defender XDR provides a unique opportunity to hunt for systems where the tampering technique used might have been successful.
The following advanced hunting query can be used to locate devices that should be reporting but aren't:
The Microsoft Defender for Endpoint sensor is one of the processes the malware attempts to disable.
Microsoft Defender for Endpoint has built-in protections against many techniques attackers use to disable endpoint sensors ranging from hardened OS protection, anti-tampering policies, and detections for a variety of tampering attempts, including "Attempt to stop Microsoft Defender for Endpoint sensor", "Tampering with Microsoft Defender for Endpoint sensor settings", or "Possible sensor tampering in memory".
Successfully disabling Microsoft Defender for Endpoint can prevent the system from reporting observed activities.
However, the multitude of signals reported into Microsoft Defender XDR provides a unique opportunity to hunt for systems where the tampering technique used might have been successful.
The following advanced hunting query can be used to locate devices that should be reporting but aren't:
This query was originally published in the threat analytics report, Ransomware continues to hit healthcare, critical services.
It finds all user accounts that have logged on to an endpoint affected by Cobalt Strike, a penetration tool.
Assume that all credentials on endpoints affected by Cobalt Strike were available to attackers and that all associated accounts are compromised. Note that attackers will not only dump credentials for accounts that have logged on to interactive or RDP sessions, but will also dump cached credentials and passwords for service accounts and scheduled tasks that are stored in the LSA Secrets section of the registry.
Reference - https://attack.mitre.org/software/S0154/
It finds all user accounts that have logged on to an endpoint affected by Cobalt Strike, a penetration tool.
Assume that all credentials on endpoints affected by Cobalt Strike were available to attackers and that all associated accounts are compromised. Note that attackers will not only dump credentials for accounts that have logged on to interactive or RDP sessions, but will also dump cached credentials and passwords for service accounts and scheduled tasks that are stored in the LSA Secrets section of the registry.
Reference - https://attack.mitre.org/software/S0154/
PowerShell Remove-Item with -Path to delete a file or a folder with "-Recurse"
'This detection looks for command line parameters associated with the use of Sysinternals sdelete (https://docs.microsoft.com/sysinternals/downloads/sdelete) to delete multiple files on a host's C drive.
A threat actor may re-name the tool to avoid detection and then use it for destructive attacks on a host.
This detection uses the ASIM imProcess parser, this will need to be deployed before use - https://docs.microsoft.com/azure/sentinel/normalization'
A threat actor may re-name the tool to avoid detection and then use it for destructive attacks on a host.
This detection uses the ASIM imProcess parser, this will need to be deployed before use - https://docs.microsoft.com/azure/sentinel/normalization'
Identify accounts that have logged on to affected endpoints.
Check for specific alerts.
Check for specific alerts.
This query identifies use of wmic.exe to delete shadow copy snapshots prior to encryption.
'Anomaly Rules generate events in the Anomalies table. This scheduled rule tries to detect Anomalies that are not usual, they could be a type of Anomaly that has recently been activated, or an infrequent type. The detected Anomaly should be reviewed, if it is relevant enough, eventually a separate scheduled Analytics Rule could be created specifically for that Anomaly Type, so an alert and/or incident is generated everytime that type of Anomaly happens.'
Page 21 of 24