Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
302 detections
Filters
Last updated
All Time
Detection languages
166
46
36
22
20
Contributors
117
49
34
24
9
Categories
222
188
118
59
49
Platforms
201
75
70
46
19
Products / Services
129
121
49
46
27
MITRE Techniques
18,123
15,639
12,580
8,394
6,215
CVEs
5
1
IDS Classtypes
2
IDS Protocols
2
Detects OAuth application registration or permission grant via Graph API
Detects OAuth application registration or permission grant via Graph API
This rule detects the creation of Okta API tokens with broad administrative scopes (okta.users.manage, okta.factors.manage, or okta.apps.manage) by the same user multiple times within a one-hour window. This behavior can indicate an attempt to establish persistent access or bypass multi-factor authentication.
This rule detects when a user successfully grants five or more OAuth2 permissions within a five-minute window, specifically looking for sensitive scopes such as 'Mail.Read', 'Calendar.Read', 'User.Read.All', or 'Directory.Read.All'. This behavior can indicate an adversary attempting to gain broad access to an organization's data through a compromised application or user account.
Detects modification of AWS organizational units to evade policy controls
Detects suspicious activity related to OAuth2PermissionGrant operations, specifically looking for a high volume of successful consent grants by a single user within a short timeframe. This could indicate an attacker attempting to gain broad access to resources by granting permissions to a malicious OAuth application.
Detects addition of credentials to Azure service principals for persistence
This rule detects when additional cloud credentials (Access Keys) are added to an AWS IAM user. It specifically looks for HTTP traffic to 'iam.amazonaws.com' containing 'CreateAccessKey' in the URI, indicating an attempt to create new access keys.
This rule detects suspicious activity related to the assignment of application roles. Specifically, it identifies when a single user principal name (UPN) performs 10 or more successful 'Add app role assignment' operations within a one-hour window. This could indicate an attacker rapidly granting themselves or other entities access to multiple applications or resources.
Detects suspicious activity related to OAuth2PermissionGrant operations, specifically looking for a high volume of successful consent grants by a single user within a short timeframe. This could indicate an attacker attempting to gain broad access to resources by granting permissions to a malicious OAuth application.
This rule detects suspicious activity related to the assignment of application roles. Specifically, it identifies when a single user principal name (UPN) performs 10 or more successful 'Add app role assignment' operations within a one-hour window. This could indicate an attacker rapidly granting themselves or other entities access to multiple applications or resources.
This rule detects when a credential (password) is added to an Azure Service Principal. This activity is identified by monitoring HTTP traffic for requests to 'graph.microsoft.com' containing 'addPassword' in the URI. This could indicate an attacker establishing persistence by adding new credentials to an existing service principal.
Detects modifications to the msDS-KeyCredentialLink attribute on Delegated Managed Service Account (dMSA) objects, indicating a potential Shadow Credential (X.509 certificate) planting. This allows an attacker to bypass managed password rotation and maintain permanent PKINIT access, as seen in the dMSA Ouroboros attack chain. The rule also monitors Event 4768 (PKINIT TGT requests with pre-authentication type 17) and Event 4662 (S4U2Self Object Access) for dMSA objects, which are key indicators of this attack.
Detects when a new identity provider is created for Okta.
Azure Suspicious Redirect URI Detection
Cortex XDR
This rule detects the modification or addition of redirect URIs for Azure Active Directory applications or service principals that point to suspicious domains. These suspicious domains include known reverse proxy/tunneling services (e.g., ngrok, cloudflare tunnel), callback infrastructure (e.g., burpcollaborator, interact.sh), or localhost/loopback addresses. Such modifications can indicate an adversary attempting to establish persistence, exfiltrate data, or redirect authentication flows to attacker-controlled infrastructure.
Detects the creation of an app-specific password named 'ZimbraWeb' via Zimbra SOAP API. This specific persistent credential name is a known mechanism utilized in the Operation GhostMail campaign by a Russian APT.
Detects when a new federation identity provider (SAML or OpenID Connect) is created or updated in AWS Identity and Access Management (IAM). This could indicate an attempt to establish new trust relationships for federated access.
This rule detects attempts to manipulate user or service principal names (SPN/UPN) in Active Directory by adding non-ASCII or zero-width characters. Such modifications can be used by adversaries for obfuscation, to bypass detection mechanisms, or to create stealthy persistence. The rule specifically looks for Event IDs 4738 (User Account Changed) and 5136 (Directory Service Object Modified) where the 'servicePrincipalName' or 'userPrincipalName' attributes contain characters outside the standard ASCII range or zero-width characters like U+200B, U+200C, U+200D.
Detects the addition of an SSH public key to a GitHub account using programmatic access (Personal Access Tokens, OAuth, or GitHub Apps). Unlike keys added via the Web UI, programmatic creation often bypasses manual verification steps and provides long-lived access that survives password resets and MFA changes. This is a common technique for attackers to establish persistent command line access to repositories.
Detects a sequence of events where an AWS IAM Role Trust Policy or a Role's managed policy is modified (UpdateAssumeRolePolicy, PutRolePolicy) and is immediately followed by a successful assumption of that role (AssumeRole, AssumeRoleWithSAML, etc.) within a 10-minute window. This behavior is characteristic of an attacker setting up a backdoor or escalating privileges by granting a new, unauthorized principal (user, service, or account) permission to assume a critical role.
Detects when a new identity provider is created in Okta. This activity can be a legitimate administrative action but could also indicate an attacker attempting to establish persistence or bypass authentication mechanisms by creating a rogue identity provider.
Page 12 of 15