Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
12 detections
Filters
Last updated
All Time
Detection languages
11
1
Contributors
11
1
Categories
8
4
4
3
3
Platforms
9
2
1
1
1
Products / Services
8
2
2
2
1
MITRE Techniques
18,110
15,627
12,575
8,387
6,212
IDS Classtypes
1
IDS Protocols
1
This rule detects the deployment of a network logon script named 'logon.bat' within the 'SYSVOL' share over SMB (port 445). This activity is often associated with persistence techniques where an attacker modifies or creates logon scripts to execute malicious code when users log in to the domain.
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 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.
'Detects a successful logon by a privileged account from an ASN not logged in from in the last 14 days.
Monitor these logons to ensure they are legitimate and identify if there are any similar sign ins.'
Monitor these logons to ensure they are legitimate and identify if there are any similar sign ins.'
Microsoft Defender for Identity raises alert on suspicious Kerberos ticket, pointing to a potential overpass-the-hash attack.
Once attackers gain credentials for a user with higher privileges, they will use the stolen credentials to sign into other devices and move laterally.
This query finds related sign-in events following overpass-the-hash attack to trace the footprint of the impersonated user.
Once attackers gain credentials for a user with higher privileges, they will use the stolen credentials to sign into other devices and move laterally.
This query finds related sign-in events following overpass-the-hash attack to trace the footprint of the impersonated user.
Intent:
- Use MTP capability to look for insider threat potential risk indicators
- Indicators would then serve as the building block for insider threat risk modeling in subsequent tools
Definition of Insider Threat:
"The potential for an individual who has or had authorized access to an organization's assets to use their access, either maliciously or unintentionally, to act in a way that could negatively affect the organization."
This collection of queries describes the different indicators that could be used to model and look for patterns suggesting an increased risk of an individual becoming a potential insider threat.
Note: no single indicator should be used as a lone determinant of insider threat activity, but should be part of an overall program to understand the increased risk to your organization's critical assets. This in turn is used to feed an investigation by a formal insider threat program to look at the context associated with the whole person to understand the implication of a set of indicators.
- Use MTP capability to look for insider threat potential risk indicators
- Indicators would then serve as the building block for insider threat risk modeling in subsequent tools
Definition of Insider Threat:
"The potential for an individual who has or had authorized access to an organization's assets to use their access, either maliciously or unintentionally, to act in a way that could negatively affect the organization."
This collection of queries describes the different indicators that could be used to model and look for patterns suggesting an increased risk of an individual becoming a potential insider threat.
Note: no single indicator should be used as a lone determinant of insider threat activity, but should be part of an overall program to understand the increased risk to your organization's critical assets. This in turn is used to feed an investigation by a formal insider threat program to look at the context associated with the whole person to understand the implication of a set of indicators.
// Detect Active Directory service accounts that are not active because their last logon was more than 14 days ago
// Replace XXX on line 4 with the naming convention start of your Active Directory service accounts
// Replace XXX on line 4 with the naming convention start of your Active Directory service accounts
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 keywords observed in emails involved in a Snip3-associated campaign in April and May of 2021. The emails often have an aviation theme, and the campaign primarily targets organizations involved in travel or aviation. Note that keywords may change overtime. These emails were used to send malicious legitimate hosting provider links that redirected to VBS documents hosting loaders. The loaders initiate RevengeRAT or AsyncRAT downloads that eventually establish persistence on targets and exfiltrate data.
The following query looks for keywords observed in emails involved in a Snip3-associated campaign in April and May of 2021. The emails often have an aviation theme, and the campaign primarily targets organizations involved in travel or aviation. Note that keywords may change overtime. These emails were used to send malicious legitimate hosting provider links that redirected to VBS documents hosting loaders. The loaders initiate RevengeRAT or AsyncRAT downloads that eventually establish persistence on targets and exfiltrate data.
This query looks for events that are near in time to a detected event.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
This query looks for events that are near in time to a detected event.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
This query looks for events that are near in time to a detected event.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
This query looks for events that are near in time to a detected event.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.
It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
Original query: filter for network logon events right before some timestamp.