Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
181 detections
Filters
Last updated
All Time
Detection languages
114
27
13
10
5
Contributors
63
37
19
10
5
Categories
67
53
53
44
40
Platforms
81
80
40
28
15
Products / Services
63
40
32
27
14
MITRE Techniques
18,115
15,635
12,576
8,388
6,215
CVEs
5
4
1
IDS Classtypes
3
2
2
1
IDS Protocols
3
1
With OAuth 2.0 Device Code Flow phishing campaigns actively targeting M365 environments in financial services and beyond, I built a cross-phase KQL detection rule that moves beyond the obvious deviceCode protocol filter — because the real damage happens in tables most hunts never look at.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
The rule correlates three phases across both SigninLogs and AADNonInteractiveUserSignInLogs:
Phase 1 catches victim-side device code authentications, filtering out primaryRefreshToken (enrolled devices) and known low-risk resources to cut noise at the source.
Phase 2 surfaces non-interactive single-factor token replay activity — this is where the attacker's stolen OAuth token actually appears, silently blending into background API traffic.
Phase 3 identifies post-compromise Graph/mail resource access across anomalous IP counts — the data exfiltration and BEC staging layer.
The key design decisions that make it production-ready: a cross-phase inner join so only users appearing in Phase 1 and Phase 2 surface at all, a MinutesToReplay temporal constraint (>= 0 and <= 2880) to eliminate false correlations where phases are coincidental rather than causal, and a composite risk score with banded severity output.
Tested against 90 days of real tenant data. Came back clean after tuning — which is the outcome you want before deploying as a scheduled analytics rule.
Detects lateral movement where a Managed Identity of one Azure resource (e.g., VM) is used to execute code or access another resource. This is identified by successful 'Microsoft.Compute/virtualMachines/runCommand' operations where the caller is a ServicePrincipal (indicated by a GUID) and the 'InitiatedBy' field contains 'resourcegroups', suggesting the action was initiated by a resource rather than a direct user.
This alert finds sessions where a device-code flow produced multiple sign-in events (interactive + non-interactive), with mismatched user-agents or differing country/geolocation, for the same Session ID - a strong indicator of device-code phishing abuse.
Looks for:
Brute-forcing device code tokens
Token replay attempts
Malicious use of device code authentication across different devices or locations
Anomalous sign-in behaviour suggesting account compromise
Looks for:
Brute-forcing device code tokens
Token replay attempts
Malicious use of device code authentication across different devices or locations
Anomalous sign-in behaviour suggesting account compromise
This detection correlates suspicious device code authentication behaviour in Azure AD with a successful creation of a Windows Hello for Business (WHfB) credential within the same 24 hours.
Microsoft allows specific application and resource combinations (permitted by CA) access without a previously registered device. Even more, one of these combinations allows the registration of a device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
Therefore, an attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
Attackers often push further to configure WHfB (Windows Hello For Business) on the registered device. WHfB issues TPM-backed, cryptographic credentials that Entra recognizes as a strong, phishing-resistant, passwordless authentication method.
Device registration unlocks persistence, but WHfB unlocks the ability to bypass stricter authentication-strength requirements.
Analysts: Check for IP mismatches, since in the Device Code authentication event we will see the victims IP, the WHfB registration event will contain the attackers IP.
Microsoft allows specific application and resource combinations (permitted by CA) access without a previously registered device. Even more, one of these combinations allows the registration of a device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
Therefore, an attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
Attackers often push further to configure WHfB (Windows Hello For Business) on the registered device. WHfB issues TPM-backed, cryptographic credentials that Entra recognizes as a strong, phishing-resistant, passwordless authentication method.
Device registration unlocks persistence, but WHfB unlocks the ability to bypass stricter authentication-strength requirements.
Analysts: Check for IP mismatches, since in the Device Code authentication event we will see the victims IP, the WHfB registration event will contain the attackers IP.
This detection identifies cases where a successful device registration event in Azure AD occurs shortly after a successful Resource Owner Password Credentials (ROPC) authentication to Microsoft Intune Enrollment via the Microsoft Authentication Broker.
Microsoft allows specific application and resource combinations access without a previously registered device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
An attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
The following query joins ROPC successful sign-ins, to successful device registrations. Registrations that occur soon after a ROPC event (2 days in this instance) could be an indicator of abuse.
Microsoft allows specific application and resource combinations access without a previously registered device.
An access token issued for the Microsoft Authentication Broker application and the Intune Enrollment resource can be used to authenticate and initiate the device join process.
An attacker can leverage the token to bypass CA, register device, and establish persistence. Once registered, attacker gets a Primary Refresh Token (PRT), valid for 90 days.
The following query joins ROPC successful sign-ins, to successful device registrations. Registrations that occur soon after a ROPC event (2 days in this instance) could be an indicator of abuse.
This rule identifies suspicious usage of the AWS Security Token Service (STS) `AssumeRole` API call. Specifically, it looks for instances where the `userIdentity.type` is `AssumedRole` and the `userIdentity.sessionContext.sessionIssuer.type` is `Role`. This pattern indicates that an AWS role is being assumed by another role, which could be a legitimate administrative action but also a technique used by attackers for lateral movement and privilege escalation within an AWS environment. Attackers might use `AssumeRole` to switch to roles with higher privileges or to move between different accounts or services after gaining initial access.
This rule identifies the suspicious use of the AWS Security Token Service (STS) API call `GetSessionToken`. This API call is used to request temporary, limited-privilege credentials for an IAM user or role. Attackers may use `GetSessionToken` to generate temporary tokens to move laterally within an AWS environment or escalate privileges by assuming roles with broader permissions. The rule specifically looks for `GetSessionToken` calls made by an `IAMUser`.
This rule identifies suspicious activity related to Security Assertion Markup Language (SAML) in AWS. Specifically, it looks for two events: `AssumeRoleWithSAML` from the `sts.amazonaws.com` service and `UpdateSAMLProvider` from the `iam.amazonaws.com` service. An adversary could leverage these actions to gain unauthorized access, establish persistence, or escalate privileges within an AWS environment by manipulating SAML providers or assuming roles via SAML.
When two accounts from the same Entra tenant are signed into the same browser app, the device authentication (the PRT) belonging to the primary account is implicitly applied to the second account. That means the second account can inherit device-based Conditional Access, effectively bypassing intended device checks and weakening protection for privileged accounts.
Based on this behavior, I created a KQL query that detects any account assigned a privileged role signing in with private/incognito browser sessions on a device where potentially another account is already signed in — a pattern that helps to detect the mentioned PRT/device-trust bypass. Even lower-privileged accounts are concerning when they browse in private mode so I am not filtering by just admin ones. However, to target specific roles, add:
| 𝘸𝘩𝘦𝘳𝘦 𝘵𝘰𝘴𝘵𝘳𝘪𝘯𝘨(𝘈𝘴𝘴𝘪𝘨𝘯𝘦𝘥𝘙𝘰𝘭𝘦𝘴) 𝘤𝘰𝘯𝘵𝘢𝘪𝘯𝘴 "𝘢𝘥𝘮𝘪𝘯"
Based on this behavior, I created a KQL query that detects any account assigned a privileged role signing in with private/incognito browser sessions on a device where potentially another account is already signed in — a pattern that helps to detect the mentioned PRT/device-trust bypass. Even lower-privileged accounts are concerning when they browse in private mode so I am not filtering by just admin ones. However, to target specific roles, add:
| 𝘸𝘩𝘦𝘳𝘦 𝘵𝘰𝘴𝘵𝘳𝘪𝘯𝘨(𝘈𝘴𝘴𝘪𝘨𝘯𝘦𝘥𝘙𝘰𝘭𝘦𝘴) 𝘤𝘰𝘯𝘵𝘢𝘪𝘯𝘴 "𝘢𝘥𝘮𝘪𝘯"
Detects a transition from a Refresh Token (RT) to a Primary Refresh Token (PRT) for the same user and device within a 24-hour window. This sequence is a strong indicator of an adversary completing a device registration flow (e.g., using ROADtx) and escalating to persistent access with a PRT, which can bypass MFA and conditional access policies. The rule specifically looks for an initial RT authentication via the Microsoft Authentication Broker, followed by PRT usage for resources other than the Device Registration Service.
Detects scenarios where an attacker uses the Mimikatz Pass-the-hash feature to move laterally. Correlation with others event IDs can be done in the following way:| ID 4624 TargetLogonId + ID 4672 SubjectLogonId + ID 4688 TargetLogonId. Having those 3 elements together allows to bring in light what was exactly done.
Detects attempts to read the Key Distribution Service (KDS) Root Key from Active Directory. This is often a preliminary step in the Golden dMSA attack, where an attacker with high privileges attempts to retrieve the key material needed to forge tickets for Delegated Managed Service Accounts (dMSA) to establish domain persistence. The rule looks for access to the 'msKds-ProvRootKey' object, identified either by its name or its schema ID GUID 'aa02fd41-17e0-4f18-8687-b2239649736b'.
Detects when a non-approved application is granted high-risk permissions via consent in Azure AD.
This is a common method for attackers to achieve persistence and privilege escalation in Microsoft 365 environments.
This is a common method for attackers to achieve persistence and privilege escalation in Microsoft 365 environments.
NTLM Relay Attempt
YARA-L
Detects NTLM successful network logons where the source and destination workstations are the same, excluding loopback addresses. This behavior can be indicative of NTLM relay attacks where an attacker relays authentication from a victim to the victim's own machine, or other forms of NTLM abuse.
KQL Query
KQL Query from file: NTLMv2 Hash Leak via COM Detection
Detects logon with "Special groups" and "Special Privileges" can be thought of as Administrator groups or privileges.
'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
'
'This query detects instances where an attacker has gained the ability to execute code on an ADFS Server through remote WMI Execution.
In order to use this query you need to be collecting Sysmon EventIDs 19, 20, and 21.
If you do not have Sysmon data in your workspace this query will raise an error stating:
Failed to resolve scalar expression named "[@Name]"
For more on how WMI was used in Solorigate see https://www.microsoft.com/security/blog/2021/01/20/deep-dive-into-the-solorigate-second-stage-activation-from-sunburst-to-teardrop-and-raindrop/.
The query contains some features from the following detections to look for potentially malicious ADFS activity. See them for more details.
- ADFS Key Export (Sysmon): https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SecurityEvent/ADFSKeyExportSysmon.yaml
- ADFS DKM Master Key Export: https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/ADFS-DKM-MasterKey-Export.yaml'
In order to use this query you need to be collecting Sysmon EventIDs 19, 20, and 21.
If you do not have Sysmon data in your workspace this query will raise an error stating:
Failed to resolve scalar expression named "[@Name]"
For more on how WMI was used in Solorigate see https://www.microsoft.com/security/blog/2021/01/20/deep-dive-into-the-solorigate-second-stage-activation-from-sunburst-to-teardrop-and-raindrop/.
The query contains some features from the following detections to look for potentially malicious ADFS activity. See them for more details.
- ADFS Key Export (Sysmon): https://github.com/Azure/Azure-Sentinel/blob/master/Detections/SecurityEvent/ADFSKeyExportSysmon.yaml
- ADFS DKM Master Key Export: https://github.com/Azure/Azure-Sentinel/blob/master/Detections/MultipleDataSources/ADFS-DKM-MasterKey-Export.yaml'
Credentials were added to an application by UserA, after the application was granted admin consent rights by UserB
The Nobelium activity group has been observed adding credentials (x509 keys or password credentials) for one or more legitimate OAuth Applications or Service Principals, usually with existing Mail.Read or Mail.ReadWrite permissions, which grants the ability to read mail content from Exchange Online via Microsoft Graph or Outlook REST. Examples include mail archiving applications.
See Customer Guidance on Recent Nation-State Cyber Attacks for more on the Nobelium campaign (formerly known as Solorigate).
See Grant tenant-wide admin consent to an application for how to add admin consent to an application.
More Nobelium-related queries can be found listed under the See also section of this document.
References:
https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/
https://docs.microsoft.com/azure/active-directory/manage-apps/grant-admin-consent
The Nobelium activity group has been observed adding credentials (x509 keys or password credentials) for one or more legitimate OAuth Applications or Service Principals, usually with existing Mail.Read or Mail.ReadWrite permissions, which grants the ability to read mail content from Exchange Online via Microsoft Graph or Outlook REST. Examples include mail archiving applications.
See Customer Guidance on Recent Nation-State Cyber Attacks for more on the Nobelium campaign (formerly known as Solorigate).
See Grant tenant-wide admin consent to an application for how to add admin consent to an application.
More Nobelium-related queries can be found listed under the See also section of this document.
References:
https://msrc-blog.microsoft.com/2020/12/13/customer-guidance-on-recent-nation-state-cyber-attacks/
https://docs.microsoft.com/azure/active-directory/manage-apps/grant-admin-consent
Detects logon events that specify new credentials
Page 8 of 9