Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
257 detections
Filters
Last updated
All Time
Detection languages
105
43
40
36
19
Contributors
106
29
29
20
16
Categories
211
160
107
57
47
Platforms
175
74
43
33
20
Products / Services
110
101
43
33
22
MITRE Techniques
18,113
15,640
12,591
8,389
6,208
CVEs
1
1
IDS Classtypes
2
IDS Protocols
2
Inventories ConnectWise/SkyKick service principals in your tenant by app ID, vendor tenant ID (3f9cd7a0-127a-4ed4-bf06-2f830d5616b7) or name. Enabled apps need disabling first (disable, don’t delete, since deleting removes the consent). Disabled or deleted apps are contained but still need an audit of credentials and roles on other apps, because disabling doesn’t remove planted secrets. CanEscalateOrPlant shows apps holding app-only rights to add credentials or assign roles.
Audit query that finds enabled OAuth apps in Microsoft Entra ID holding permissions an attacker would want: reading or sending mail, accessing files and sites, planting credentials on other apps, assigning roles, or changing Conditional Access. App-only permissions (the app signs in as itself, with no user and no MFA) are split from delegated ones. High-privilege delegated grants are flagged only for external apps with no verified publisher, the typical consent-phishing shape. Output is one row per app with a plain-language ReviewReason, publisher, origin, admin consent, activity (Inactive 90d+ is the easiest to disable) and “(in use)” markers on permissions the app actually exercises, so a review team can decide to keep, reduce or disable.
This is an inventory of what apps can do, not a change detector. A verified publisher does not mean safe, as the ConnectWise/SkyKick credential abuse showed. Pair it with audit-log hunting for new secrets and role assignments. Requires OAuthAppInfo (app governance in Defender for Cloud Apps).
This is an inventory of what apps can do, not a change detector. A verified publisher does not mean safe, as the ConnectWise/SkyKick credential abuse showed. Pair it with audit-log hunting for new secrets and role assignments. Requires OAuthAppInfo (app governance in Defender for Cloud Apps).
Audit query that finds enabled OAuth apps in Microsoft Entra ID holding permissions an attacker would want: reading or sending mail, accessing files and sites, planting credentials on other apps, assigning roles, or changing Conditional Access. App-only permissions (the app signs in as itself, with no user and no MFA) are split from delegated ones. High-privilege delegated grants are flagged only for external apps with no verified publisher, the typical consent-phishing shape. Output is one row per app with a plain-language ReviewReason, publisher, origin, admin consent, activity (Inactive 90d+ is the easiest to disable) and “(in use)” markers on permissions the app actually exercises, so a review team can decide to keep, reduce or disable.
This is an inventory of what apps can do, not a change detector. A verified publisher does not mean safe, as the ConnectWise/SkyKick credential abuse showed. Pair it with audit-log hunting for new secrets and role assignments. Requires OAuthAppInfo (app governance in Defender for Cloud Apps).
This is an inventory of what apps can do, not a change detector. A verified publisher does not mean safe, as the ConnectWise/SkyKick credential abuse showed. Pair it with audit-log hunting for new secrets and role assignments. Requires OAuthAppInfo (app governance in Defender for Cloud Apps).
Detects a potential app-only tenant-takeover sequence associated with Storm-3119 (YAM Store), where a single service principal performs an administrative password reset, a license assignment, and a privileged role grant within a one-hour window.
Detects a successful AWS IAM CreateRole event whose trust policy allows sts:AssumeRole by a principal in another AWS account or by a wildcard
principal.
This configuration may provide persistent access if the principal can assume the role. The event alone does not establish that the role was assumed or that its creation was unauthorized.
principal.
This configuration may provide persistent access if the principal can assume the role. The event alone does not establish that the role was assumed or that its creation was unauthorized.
Detects a single application or service principal performing a password reset, a license assignment, and a privileged role grant within a one-hour window. This sequence matches Storm-3119 admin-panel abuse of a compromised tenant client secret through an app-only flow in Microsoft 365 or Entra ID.
Detects a service principal adding itself or another principal to a directory role in Azure Active Directory, specifically highlighting known ConnectWise supply-chain related activity.
A Build Work Zone role was added to or removed from a BTP role collection
Detects chained AWS STS AssumeRole/AssumeRoleWithSAML/AssumeRoleWithWebIdentity events where a principal assumes a role in a different account and then quickly performs another role assumption from that new context. This pattern, often referred to as 'role chaining' or 'role laundering', is frequently used to obfuscate identity tracking and facilitate lateral movement across AWS account boundaries.
Detects instances where an identity associated with AI or automated agents (service accounts, service principals, bots, or assistants) is assigned to highly privileged administrative roles or security groups in the directory. This behavior potentially indicates an attempt to escalate privileges using a compromised or improperly configured agent identity.
Detects when a user has either been assigned or removed from an Admin/Privileged role. Providing the analyst with the relevant event information for further investigation.
The following analytic detects the assignment of privileged roles to service principals in Azure Active Directory (AD). It leverages the AuditLogs log category from ingested Azure AD events. This activity is significant because assigning elevated permissions to non-human entities can lead to unauthorized access or malicious activities. If confirmed malicious, attackers could exploit these service principals to gain elevated access to Azure resources, potentially compromising sensitive data and critical infrastructure. Monitoring this behavior helps prevent privilege escalation and ensures the security of Azure environments.
The following analytic identifies the assignment of sensitive and privileged Azure Active Directory roles to an Azure AD user. Adversaries and red teams alike may assign these roles to a compromised account to establish Persistence in an Azure AD environment. This detection leverages the O365 Universal Audit Log data source.
This rule detects when a Service Principal or Application is assigned to highly privileged directory roles within Microsoft Entra ID (formerly Azure AD). Adversaries may perform this action to achieve persistence or escalate privileges within the cloud environment by granting high-level administrative access to a compromised or adversary-controlled service principal.
Detects instances where a long-dormant Entra ID (Azure AD) service principal is reactivated shortly after having a new credential added or a new app role assigned. This activity is a potential persistence technique where an attacker repurposes a legitimate, high-privileged, but unused service principal to blend in as legacy automation.
The following analytic detects the assignment of privileged Azure Active Directory roles to a user. It leverages Azure AD audit logs, specifically monitoring the "Add member to role" operation. This activity is significant as adversaries may assign privileged roles to compromised accounts to maintain persistence within the Azure AD environment. If confirmed malicious, this could allow attackers to escalate privileges, access sensitive information, and maintain long-term control over the Azure AD infrastructure.
The following analytic detects potential privilege escalation threats in Azure Active Directory (AD). This detection is important because it identifies instances where privileged roles that hold elevated permissions are assigned to service principals. This prevents unauthorized access or malicious activities, which occur when these non-human entities access Azure resources to exploit them. False positives might occur since administrators can legitimately assign privileged roles to service principals. This detection leverages the O365 Universal Audit Log data source.
Detects high-risk AWS API calls indicative of privilege escalation within IAM (e.g., policy attachments, credential creation) or activities aimed at tampering with or disabling CloudTrail logging, which is often a precursor to or indication of unauthorized activity to evade detection.
Detects instances where a Service Principal or Enterprise Application is assigned a highly privileged Entra ID directory role (e.g., Global Administrator, Privileged Role Administrator). This behavior is often associated with adversary attempts to establish persistent access that survives remediation of human-managed identities.
Detects the assignment of high-privilege Azure directory roles to a service principal identity. Threat actors may leverage this behavior to establish persistent, non-interactive backdoor access in a cloud tenant, bypassing MFA and sign-in scrutiny.
Detects instances where a user grants an OAuth application sensitive, high-privilege permissions (e.g., Mail.Read, Files.ReadWrite.All, Directory.ReadWrite.All) that are commonly abused in consent phishing campaigns to maintain persistent, silent access to mail and files independent of user credentials.
Page 1 of 13