Azure Sentinel
@AzureSentinel50 followers944 downloads1,418 copies43 likes37,652 views
1,223 detections
Filters
Last updated
All Time
Detection languages
1,223
Categories
220
218
180
171
135
Platforms
766
284
188
78
29
Products / Services
492
297
159
152
93
MITRE Techniques
530
485
467
348
348
'This querys look for users accounts that have not been successfully logged into recently, who then have a MFA method added or updated before logging in.
Threat actors may look to re-activate dormant accounts and use them for access by adding MFA methods in the hope that changes to such dormant accounts may go un-noticed.'
Threat actors may look to re-activate dormant accounts and use them for access by adding MFA methods in the hope that changes to such dormant accounts may go un-noticed.'
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 was originally published in the threat analytics report, CVE-2018-15982 exploit attacks.
CVE-2018-15982 is an exploit of Adobe Flash Player, that allows for remote execution of arbitrary code. It has since been patched.
Actors have been observed using this vulnerability in targeted attacks. Exploits for CVE-2018-15982 have also been included in several exploit kits.
In some initial attacks exploiting CVE-2018-15982, attackers sent targets spear-phishing emails. The emails would include an attached RAR archive, which contained a lure document, as well as a second archive disguised as a .jpg file. Opening the document would automatically run an embedded Flash ActiveX control. This, in turn, would call a script containing the exploit. The exploit's ability to run arbitrary code would be employed to unpack and run a payload from the second archive. The payload is a backdoor used both to achieve persistance and for command and control.
The following query detects possible instances of a payload being extracted by the exploit.
References:
https://nvd.nist.gov/vuln/detail/CVE-2018-15982
https://helpx.adobe.com/security/products/flash-player/apsb18-42.html
CVE-2018-15982 is an exploit of Adobe Flash Player, that allows for remote execution of arbitrary code. It has since been patched.
Actors have been observed using this vulnerability in targeted attacks. Exploits for CVE-2018-15982 have also been included in several exploit kits.
In some initial attacks exploiting CVE-2018-15982, attackers sent targets spear-phishing emails. The emails would include an attached RAR archive, which contained a lure document, as well as a second archive disguised as a .jpg file. Opening the document would automatically run an embedded Flash ActiveX control. This, in turn, would call a script containing the exploit. The exploit's ability to run arbitrary code would be employed to unpack and run a payload from the second archive. The payload is a backdoor used both to achieve persistance and for command and control.
The following query detects possible instances of a payload being extracted by the exploit.
References:
https://nvd.nist.gov/vuln/detail/CVE-2018-15982
https://helpx.adobe.com/security/products/flash-player/apsb18-42.html
'This hunting query identifies updates to the RequiredResourceAccess property of an OAuth application.
This property specifies resources that an application requires access to and the set of OAuth permission scopes and application roles that it needs under each of those resources.
This pre-configuration of required resource access drives the consent experience. The resourceAccess property of the requiredResourceAccess type is a collection of ResourceAccess.
A threat actor might update this property before granting permissions to an application.
'
This property specifies resources that an application requires access to and the set of OAuth permission scopes and application roles that it needs under each of those resources.
This pre-configuration of required resource access drives the consent experience. The resourceAccess property of the requiredResourceAccess type is a collection of ResourceAccess.
A threat actor might update this property before granting permissions to an application.
'
'This creates an incident in the event a client generates excessive amounts of DNS queries for non-existent domains.
This analytic rule uses [ASIM](https://aka.ms/AboutASIM) and supports any built-in or custom source that supports the ASIM DNS schema'
This analytic rule uses [ASIM](https://aka.ms/AboutASIM) and supports any built-in or custom source that supports the ASIM DNS schema'
'Identifies callouts to Discord CDN addresses for risky file extensions. This detection will trigger when a callout for a risky file is made to a discord server that has only been seen once in your environment.
Unique discord servers are identified using the server ID that is included in the request URL (DiscordServerId in query). Discord CDN has been used in multiple campaigns to download additional payloads.
This analytic rule uses [ASIM](https://aka.ms/AboutASIM) and supports any built-in or custom source that supports the ASIM WebSession schema (ASIM WebSession Schema)'
Unique discord servers are identified using the server ID that is included in the request URL (DiscordServerId in query). Discord CDN has been used in multiple campaigns to download additional payloads.
This analytic rule uses [ASIM](https://aka.ms/AboutASIM) and supports any built-in or custom source that supports the ASIM WebSession schema (ASIM WebSession Schema)'
'Detects successful signins using single factor authentication where the device, location, and ASN are abnormal.
Single factor authentications pose an opportunity to access compromised accounts, investigate these for anomalous occurrencess.
Ref: https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-devices#non-compliant-device-sign-in'
Single factor authentications pose an opportunity to access compromised accounts, investigate these for anomalous occurrencess.
Ref: https://docs.microsoft.com/azure/active-directory/fundamentals/security-operations-devices#non-compliant-device-sign-in'
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.
'Identifies an export of the ADFS DKM Master Key from Active Directory.
References: https://blogs.microsoft.com/on-the-issues/2020/12/13/customers-protect-nation-state-cyberattacks/,
https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html?1
To understand further the details behind this detection, please review the details in the original PR and subequent PR update to this:
https://github.com/Azure/Azure-Sentinel/pull/1562#issue-551542469
https://github.com/Azure/Azure-Sentinel/pull/1512#issue-543053339
'
References: https://blogs.microsoft.com/on-the-issues/2020/12/13/customers-protect-nation-state-cyberattacks/,
https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html?1
To understand further the details behind this detection, please review the details in the original PR and subequent PR update to this:
https://github.com/Azure/Azure-Sentinel/pull/1562#issue-551542469
https://github.com/Azure/Azure-Sentinel/pull/1512#issue-543053339
'
'Identifies IP addresses performing DNS lookups associated with common ToR proxies.
This analytic rule uses [ASIM](https://aka.ms/AboutASIM) and supports any built-in or custom source that supports the ASIM DNS schema'
This analytic rule uses [ASIM](https://aka.ms/AboutASIM) and supports any built-in or custom source that supports the ASIM DNS schema'
Page 15 of 123