Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
3,347 detections
Filters
Last updated
All Time
Detection languages
1,335
1,010
316
198
184
Contributors
960
506
379
300
209
Categories
20,440
11,814
5,871
5,145
4,864
3,347
Platforms
3,332
17
14
12
7
Products / Services
1,535
805
641
458
291
MITRE Techniques
2,512
2,391
1,392
461
413
CVEs
4
4
4
3
3
IDS Classtypes
10
2
2
1
IDS Protocols
13
3
Detects the execution of an MSI file using PowerShell and the WMI Win32_Product class
This query searches for a string pattern detected in evasive PowerShell usage. Jupyter or SolarMarker will iterate on this pattern multiple times to read data and call additional processes. This query is not fully specific to Jupyter or SolarMarker, and will also return other malicious malware, but is unlikely to return false positives.
'Identifies any Azure VM Run Command operations and links these operations with
MDE host logging. Linking these two data sources provides hunting opportunities.
Logging from AzureActivity provides the IP address and UPN of the account that
invoked the command. Joining this with logging from MDE provides insights into
what cmdlets were loaded by the command.'
MDE host logging. Linking these two data sources provides hunting opportunities.
Logging from AzureActivity provides the IP address and UPN of the account that
invoked the command. Joining this with logging from MDE provides insights into
what cmdlets were loaded by the command.'
'Identifies when Azure Run command is used to execute a PowerShell script on a VM that is unique.
The uniqueness of the PowerShell script is determined by taking a combined hash of the cmdLets it imports and the file size of the PowerShell script. Alerts from this detection indicate a unique PowerShell was executed in your environment.'
The uniqueness of the PowerShell script is determined by taking a combined hash of the cmdLets it imports and the file size of the PowerShell script. Alerts from this detection indicate a unique PowerShell was executed in your environment.'
Adversaries may enumerate files and directories or may search in specific locations of a host or network share for certain information within a file system.
Adversaries may use the information from [File and Directory Discovery](https://attack.mitre.org/techniques/T1083) during automated discovery to shape follow-on behaviors,
including whether or not the adversary fully infects the target and/or attempts specific actions.
Adversaries may use the information from [File and Directory Discovery](https://attack.mitre.org/techniques/T1083) during automated discovery to shape follow-on behaviors,
including whether or not the adversary fully infects the target and/or attempts specific actions.
Adversaries may abuse container files such as disk image (.iso, .vhd) file formats to deliver malicious payloads that may not be tagged with MOTW.
Detects when when a mounted share is removed. Adversaries may remove share connections that are no longer useful in order to clean up traces of their operation
Detects the execution of powershell scripts with calls to the "Start-NetEventSession" cmdlet. Which allows an attacker to start event and packet capture for a network event session.
Adversaries may attempt to capture network to gather information over the course of an operation.
Data captured via this technique may include user credentials, especially those sent over an insecure, unencrypted protocol.
Adversaries may attempt to capture network to gather information over the course of an operation.
Data captured via this technique may include user credentials, especially those sent over an insecure, unencrypted protocol.
Detects a Get-Process command on lsass process, which is in almost all cases a sign of malicious activity
Adversaries may interrupt availability of system and network resources by inhibiting access to accounts utilized by legitimate users.
Accounts may be deleted, locked, or manipulated (ex: changed credentials) to remove access to accounts.
Accounts may be deleted, locked, or manipulated (ex: changed credentials) to remove access to accounts.
Detects Silence EmpireDNSAgent as described in the Group-IP report
Detects the use of the "Get-ADComputer" cmdlet in order to identify systems which are configured for unconstrained delegation.
Detects scriptblock text keywords indicative of potential usge of the tool WinPwn. A tool for Windows and Active Directory reconnaissance and exploitation.
Adversaries may abuse PowerShell commands and scripts for execution.
PowerShell is a powerful interactive command-line interface and scripting environment included in the Windows operating system. (Citation: TechNet PowerShell)
Adversaries can use PowerShell to perform a number of actions, including discovery of information and execution of code
PowerShell is a powerful interactive command-line interface and scripting environment included in the Windows operating system. (Citation: TechNet PowerShell)
Adversaries can use PowerShell to perform a number of actions, including discovery of information and execution of code
Detects PowerShell scripts with potential registry reconnaissance capabilities. Adversaries may interact with the Windows registry to gather information about the system credentials, configuration, and installed software.
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
Service Accounts Performing Remote PowerShell.
Author: miflower.
The purpose behind this detection is for finding service accounts that are performing remote powershell sessions.
There are two phases to the detection: Identify service accounts, Find remote PS cmdlets being ran by these accounts.
To accomplish this, we utilize DeviceLogonEvents and DeviceEvents to find cmdlets ran that meet the criteria.
One of the main advantages of this method is that only requires server telemetry, and not the attacking client.
The first phase relies on the DeviceLogonEvents to determine whether an account is a service account or not, consider the following accounts with logons:.
Random_user has DeviceLogonEvents with type 2, 3, 7, 10, 11 & 13.
Random_service_account 'should' only have DeviceLogonEvents with type 3,4 or 5.
Author: miflower.
The purpose behind this detection is for finding service accounts that are performing remote powershell sessions.
There are two phases to the detection: Identify service accounts, Find remote PS cmdlets being ran by these accounts.
To accomplish this, we utilize DeviceLogonEvents and DeviceEvents to find cmdlets ran that meet the criteria.
One of the main advantages of this method is that only requires server telemetry, and not the attacking client.
The first phase relies on the DeviceLogonEvents to determine whether an account is a service account or not, consider the following accounts with logons:.
Random_user has DeviceLogonEvents with type 2, 3, 7, 10, 11 & 13.
Random_service_account 'should' only have DeviceLogonEvents with type 3,4 or 5.
Detects Commandlet name for PrintNightmare exploitation.
Detects usage of the "Import-Module" cmdlet to load the "Microsoft.ActiveDirectory.Management.dl" DLL. Which is often used by attackers to perform AD enumeration.
Adversaries may create a domain account to maintain access to victim systems.
Domain accounts are those managed by Active Directory Domain Services where access and permissions are configured across systems and services that are part of that domain..
Domain accounts are those managed by Active Directory Domain Services where access and permissions are configured across systems and services that are part of that domain..
Detects calls to "Add-Content" cmdlet in order to modify the content of the user profile and potentially adding suspicious commands for persistence
Page 129 of 160