Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
81 detections
Filters
Last updated
All Time
Detection languages
52
11
6
4
3
Contributors
24
18
6
5
3
Categories
61
34
26
19
14
Platforms
57
49
38
6
2
Products / Services
52
29
15
8
7
MITRE Techniques
18,110
15,627
12,575
8,387
6,212
IDS Classtypes
2
1
IDS Protocols
3
This rule detects attempts to register a new OAuth application within Azure Active Directory by monitoring HTTP POST requests to the Microsoft Graph API endpoint '/applications' on 'graph.microsoft.com'. This activity can be indicative of an attacker establishing persistence or gaining unauthorized access to cloud resources by creating a malicious application.
This rule detects when a third-party cloud application is authorized to access a Google account. It specifically looks for HTTP traffic to 'accounts.google.com' with a URI containing 'oauth2/auth' and 'scope', indicating an OAuth 2.0 authorization request. A threshold is set to trigger an alert if this activity occurs 3 times within 60 seconds from the same source IP address.
Detects when OAuth applications are added to trusted lists or granted Context-Aware Access (CAA) exemptions within Google Workspace. This activity bypasses user consent screens and CAA policies, potentially allowing malicious applications to gain unauthorized access. The rule also tracks permission escalation for existing applications via 'CHANGE_APP_ACCESS' events.
This rule detects attempts to grant consent to OAuth applications, which could indicate an illicit consent grant attack. It specifically looks for successful operations related to consenting to applications, adding app role assignments to service principals, adding delegated permission grants, or adding OAuth2PermissionGrants within audit logs. The rule extracts details such as the target application, the user who consented, their initiating IP address, and the permissions granted.
This detection identifies the consent or addition of an OAuth application that may be impersonating a legitimate, well-known brand. The logic flags applications whose names mimic major brands (e.g., Adobe, Microsoft, DocuSign) and use a reply URL hosted on a shared or free platform, a common tactic in consent phishing campaigns.
This rule detects attempts to grant consent to OAuth applications, which could indicate an illicit consent grant attack. It specifically looks for successful operations related to consenting to applications, adding app role assignments to service principals, adding delegated permission grants, or adding OAuth2PermissionGrants within audit logs. The rule extracts details such as the target application, the user who consented, their initiating IP address, and the permissions granted.
Detects a suspicious Salesforce OAuth login followed by high-volume data exfiltration activity within a short period. This pattern is associated with the threat actor UNC6040, which uses malicious or compromised OAuth applications to steal data.
https://www.proofpoint.com/us/blog/threat-insight/beyond-credentials-weaponizing-oauth-applications-persistent-cloud-access
This KQL provide a detailed audit listing of your tenant consented OAuth apps and their granted permissions and number of users consented.
Detects a user authorizing a Salesforce application via the '/setup/connect' page. This specific TTP is associated with ShinyHunters vishing campaigns where attackers impersonate IT staff and trick employees into entering a connection code, thereby granting a malicious application access to the organization's Salesforce environment.
Detects successful non-interactive sign-ins to Microsoft Graph using the Visual Studio Code (VSCode) application identity. This behavior was observed in a phishing campaign where threat actors tricked users into an OAuth flow to harvest tokens. These tokens were then used to access user data, such as emails, via the Graph API.
This detection identifies when Microsoft Copilot Studio agents are created in your organization's tenant. This activity is significant as the default behavior in Copilot agent creation is to configure a new service principal with cloud app administrator role.
Copilot agents can be found in the Microsoft Admin Portal https://admin.microsoft.com/Adminportal/Home#/copilot/agents
Copilot agents can be found in the Microsoft Admin Portal https://admin.microsoft.com/Adminportal/Home#/copilot/agents
'This hunting query looks for potential command injection attempts via the vulnerable third-party driver against Azure IR with Managed VNet or SHIR processes as well as post-exploitation activity based on process execution and command line activity
Reference: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-29972
https://msrc-blog.microsoft.com/2022/05/09/vulnerability-mitigated-in-the-third-party-data-connector-used-in-azure-synapse-pipelines-and-azure-data-factory-cve-2022-29972'
Reference: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-29972
https://msrc-blog.microsoft.com/2022/05/09/vulnerability-mitigated-in-the-third-party-data-connector-used-in-azure-synapse-pipelines-and-azure-data-factory-cve-2022-29972'
The analytic detects when emails are accessed in Office 365 Exchange via Exchange Web Services (EWS) using OAuth-authenticated applications. It leverages the ClientInfoString field to identify EWS interactions and aggregates metrics such as access counts, timing, and client IP addresses, categorized by user, ClientAppId, OperationCount, and AppId. Monitoring OAuth applications accessing emails through EWS is crucial for identifying potential abuse or unauthorized data access. If confirmed malicious, this activity could lead to unauthorized email access, data exfiltration, or further compromise of sensitive information.
The following analytic identifies instances where a user has denied consent to an OAuth application seeking permissions within the Office 365 environment. This detection leverages O365 audit logs, focusing on events related to user consent actions. By filtering for denied consent actions associated with OAuth applications, it captures instances where users have actively rejected permission requests. This activity is significant as it may indicate users spotting potentially suspicious or unfamiliar applications. If confirmed malicious, it suggests an attempt by a potentially harmful application to gain unauthorized access, which was proactively blocked by the user.
The following analytic identifies instances where Office 365 has blocked a user's attempt to grant consent to an application deemed risky or potentially malicious. This detection leverages O365 audit logs, specifically focusing on failed user consent actions due to system-driven blocks. Monitoring these blocked consent attempts is crucial as it highlights potential threats early on, indicating that a user might be targeted or that malicious applications are attempting to infiltrate the organization. If confirmed malicious, this activity suggests that O365's security measures successfully prevented a harmful application from accessing organizational data, warranting immediate investigation.
Application creation can be legitimate but aren't frequently created. Validating application creation may be appropriate to ensure rogue apps aren't being created.
Identifies when a Marketplace app is added in a Google Workspace organization. Installing certain apps may increase the organization's risk of data exfiltration/leakage and increase its attack surface.
Page 4 of 4