Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
55 detections
Filters
Last updated
All Time
Detection languages
42
7
2
2
1
Contributors
18
11
8
5
2
Categories
32
30
12
10
9
Platforms
49
15
11
1
Products / Services
28
22
18
7
2
MITRE Techniques
18,108
15,613
12,573
8,384
6,203
CVEs
2
IDS Classtypes
1
IDS Protocols
1
Detects successful sign-ins to specific Azure AD applications known to bypass Conditional Access policies, where Conditional Access was not applied. This could indicate an attempt to circumvent security controls.
This rule detects attempts to modify or delete Conditional Access Policies within Microsoft Azure Active Directory (now Microsoft Entra ID) via the Microsoft Graph API. Adversaries may alter or remove these policies to bypass security controls, maintain persistence, or facilitate unauthorized access to resources. The detection specifically looks for network events targeting 'graph.microsoft.com' that involve 'conditionalAccessPolicies' and use 'PATCH' (modification) or 'DELETE' (removal) HTTP methods.
Detects successful sign-ins to specific Azure AD applications known to bypass Conditional Access policies, where Conditional Access was not applied. This could indicate an attempt to circumvent security controls.
Detects the creation or modification of Named Locations within Conditional Access policies that include IP ranges. This behavior could indicate an attacker whitelisting their own IP addresses to maintain persistence or bypass Conditional Access security controls. The rule correlates changes with administrative context, such as non-standard business hours, weekends, or modifications by unexpected accounts.
Detects the creation or modification of Named Locations within Conditional Access policies that include IP ranges. This behavior could indicate an attacker whitelisting their own IP addresses to maintain persistence or bypass Conditional Access security controls. The rule correlates changes with administrative context, such as non-standard business hours, weekends, or modifications by unexpected accounts.
Detects modifications or deletions of Conditional Access policies in an environment. This includes disabling policies or altering key configurations like users, groups, applications, platforms, or locations, which could be indicative of an attacker attempting to bypass security controls or maintain persistent access.
Detects anomalous Primary Refresh Token (PRT) issuance for non-compliant, non-hybrid joined devices that do not utilize TPM attestation, followed by immediate access to high-value Microsoft resources like Microsoft Graph, Exchange, or SharePoint. This activity is indicative of the Storm-2372 Conditional Access bypass technique, where attackers register 'phantom' devices to circumvent security policies.
Detects modifications or deletions of Conditional Access policies in an environment. This includes disabling policies or altering key configurations like users, groups, applications, platforms, or locations, which could be indicative of an attacker attempting to bypass security controls or maintain persistent access.
Detects disabling of Conditional Access policies via Graph API
Detects modifications or deletions of Conditional Access policies in an environment. This includes disabling policies or altering key configurations like users, groups, applications, platforms, or locations, which could be indicative of an attacker attempting to bypass security controls or maintain persistent access.
This rule detects potential tampering with Conditional Access Policies in Azure Active Directory by monitoring for multiple update, delete, or add operations on policies containing 'Conditional Access' in their display name within a one-hour window. This could indicate an adversary attempting to weaken security controls to maintain access or bypass MFA.
This rule detects potential tampering with Conditional Access Policies in Azure Active Directory by monitoring for multiple update, delete, or add operations on policies containing 'Conditional Access' in their display name within a one-hour window. This could indicate an adversary attempting to weaken security controls to maintain access or bypass MFA.
This rule detects attempts to disable Conditional Access Policies in Microsoft 365 via the Microsoft Graph API. It specifically looks for HTTP PATCH requests to 'graph.microsoft.com' targeting the 'conditionalAccess/policies' endpoint. Such activity could indicate an attacker attempting to bypass security controls for persistence or privilege escalation.
This attack shares a lot of similarities with ClickFix/FileFix, AiTM phishing, and OAuth Consent Phishing. You can think of this as a browser-native ClickFix attack that phishes an OAuth token on a target app by getting the victim to copy and paste a URL containing OAuth key material into a phishing page.
The detection looks for unauthorized or suspicious changes to the policies that control who can access your cloud resources and under what conditions. Correlate this change data with other signals, like a subsequent spike in risky sign-ins from a newly permitted location, to confirm a potential attack sequence as outlined in MITRE's analytics.
Detects a successful login to the Microsoft Intune Company Portal which could allow bypassing Conditional Access Policies and InTune device trust using a tool like TokenSmith. The rule specifically looks for 'UserLoggedIn' operations with 'Success' status for the Microsoft Intune Company Portal ApplicationId, while excluding a specific ObjectId often associated with mobile device enrollment to reduce false positives.
This rule detects when a Conditional Access (CA) policy is deleted in Azure Active Directory (now Microsoft Entra ID). This activity is critical to monitor as the removal of a CA policy can significantly weaken an organization's security posture by bypassing multi-factor authentication, device compliance checks, or other access controls. The rule specifically looks for the 'Delete conditional access policy' message in the Azure Audit Logs. While the rule's title suggests identifying actions by 'non-approved actors', the current detection logic only identifies the deletion event itself, not the actor's approval status. Further enrichment or correlation would be needed to determine if the actor is unauthorized.
This rule detects the addition of a new conditional access policy within an Azure environment. Conditional Access policies are critical security controls that determine when and how users can access resources. Unauthorized or unexpected changes to these policies could indicate an attacker attempting to establish persistence, bypass existing security controls (like MFA), or gain unauthorized access by modifying access conditions.
This rule detects when a Conditional Access policy is updated within an Azure environment. It aims to identify unauthorized or suspicious modifications to these critical security policies, which could lead to privilege escalation, credential access, or defense evasion. The rule specifically looks for the message 'Update conditional access policy' in audit logs. Further investigation would involve checking if the actor initiating the change is approved and comparing the old versus new policy values.
This rule detects when a user is added to a group that has permissions to modify Conditional Access (CA) policies within Azure Active Directory. Such an action could indicate an attempt to escalate privileges, bypass existing security controls, or establish persistence by altering authentication processes.
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:
| 𝘸𝘩𝘦𝘳𝘦 𝘵𝘰𝘴𝘵𝘳𝘪𝘯𝘨(𝘈𝘴𝘴𝘪𝘨𝘯𝘦𝘥𝘙𝘰𝘭𝘦𝘴) 𝘤𝘰𝘯𝘵𝘢𝘪𝘯𝘴 "𝘢𝘥𝘮𝘪𝘯"
Page 2 of 3