Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
7 detections
Filters
Last updated
All Time
Detection languages
7
Contributors
6
1
Categories
5
2
2
2
2
Platforms
6
3
2
1
Products / Services
5
2
2
1
1
MITRE Techniques
18,114
15,633
12,576
8,388
6,215
KQL Query from file: One-Click ANY RUN Storm-1747 KQL Scan
'This content is employed to correlate with Microsoft Defender XDR phishing-related alerts. It focuses on instances where a user successfully connects to a phishing URL from a non-Microsoft network device and subsequently makes successful sign-in attempts from the phishing IP address.'
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
Query 1 shows you any network communication happened from endpoints to a specific Remote IP or Remote URL.
Ensure to update RemoteIP and RemoteURL variable.
For questions @MiladMSFT on Twitter or milad.aslaner@microsoft.com by email.
Ensure to update RemoteIP and RemoteURL variable.
For questions @MiladMSFT on Twitter or milad.aslaner@microsoft.com by email.
Device Network Events Involving Low Count FQDNs.
This query reduces network events to only those with the RemoteURL column populated,.
Then parses the DNS name from the URL (if needed) and finds the least prevalent.
FQDNs. The result is then joined with DeviceNetworkEvents to highlight anomalous.
Network communication.
This query reduces network events to only those with the RemoteURL column populated,.
Then parses the DNS name from the URL (if needed) and finds the least prevalent.
FQDNs. The result is then joined with DeviceNetworkEvents to highlight anomalous.
Network communication.
Query 1 shows you any network communication happened from endpoints to a specific Remote IP or Remote URL.
Ensure to update RemoteIP and RemoteURL variable.
For questions @MiladMSFT on Twitter or milad.aslaner@microsoft.com by email.
Ensure to update RemoteIP and RemoteURL variable.
For questions @MiladMSFT on Twitter or milad.aslaner@microsoft.com by email.
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.