Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
771 detections
Filters
Last updated
All Time
Detection languages
392
128
66
49
47
Contributors
296
150
91
39
27
Categories
388
258
255
124
110
Platforms
523
344
285
121
72
Products / Services
370
328
112
51
43
MITRE Techniques
18,115
15,635
12,582
8,393
6,220
771
CVEs
2
1
IDS Classtypes
15
11
3
1
1
IDS Protocols
29
Detects anomalous use of an LLM provider API key by identifying successful API requests originating from multiple distinct countries within a one-hour time window. This activity often indicates the potential theft and concurrent unauthorized use of an API token.
Detects potential session hijacking or malicious OAuth consent grants within Okta. This rule triggers either when an authenticated session start is associated with risky flags (impossible travel, anomalous device/location) or when an OAuth consent grant for 'recall' or cross-tenant functionality occurs shortly after a high-risk sign-in event.
Detects Azure AD sign-in events indicative of 'EvilTokens' phishing-as-a-service tradecraft. The rule monitors for initial token-grant events (device-code authentication or OAuth application consent) and subsequent successful sign-ins using existing SessionIds. This rule is designed as a foundational detection component for identifying session token replay, which allows adversaries to bypass MFA and password requirements by hijacking valid session tokens.
Detects a multi-stage exfiltration sequence consisting of: (1) bulk file archival/compression using common utilities, (2) suspicious OAuth grant or service principal authorization, and (3) abnormal network egress volume to common ports. This pattern suggests an adversary is preparing data, establishing or leveraging an identity/application for cloud access, and subsequently exfiltrating data.
Detects the multi-stage Microsoft cloud identity compromise chain reported by Microsoft Security Research (September 2026): a victim completes a successful Entra ID device-code sign-in (often induced by passkey-themed device-code phishing), the same identity's authentication/security info is registered or changed (MFA/passkey persistence) within 60 minutes (deduplicated to the earliest such event per sign-in), followed within 120 minutes by a burst of at least 25 successful, delegated-context Microsoft Graph API calls (Scopes claim populated, i.e. user-delegated permissions rather than pure application/client-credential access) spanning at least 3 distinct resource paths, exhibiting reconnaissance (>=5 requests against /users, /groups, /directoryRoles, /roleManagement, /applications, /servicePrincipals, /organization) and/or collection (>=10 requests against /messages, /mailFolders, /attachments, /drive, /drives, /sites, /lists, /search) patterns. Restricting to delegated (Scopes-bearing) Graph calls and requiring resource-path breadth removes the two largest false-positive sources: service-principal/application-only automation jobs (Roles-only tokens) and single-endpoint polling tools. Pure behavioral correlation across SigninLogs, AuditLogs, and MicrosoftGraphActivityLogs - no static IOCs. Flags whether Graph activity originated from an IP different from the original device-code sign-in IP as a strong pivot/session-reuse indicator.
This rule correlates multiple telemetry sources to detect a sophisticated cloud identity compromise chain. It identifies suspicious MFA-satisfied logins (potentially via Adversary-in-the-Middle) followed by the granting of high-risk OAuth application consents, the creation of persistent mailbox rules for hiding or forwarding communications, and finally mass data access or exfiltration from the user's account.
Detects anomalous OAuth application consent activity by identifying a surge in unique users granting permissions to a single OAuth application within a short timeframe. This behavior is indicative of consent phishing campaigns where attackers lure users to grant application access to malicious apps, effectively stealing application access tokens and gaining persistent access to resources without requiring the victim's password.
Detects when high-privilege application permissions (e.g., Directory.ReadWrite.All, Application.ReadWrite.All) are granted to a service principal via admin consent. This behavior can be used by attackers to gain persistent, stealthy administrative access to a Microsoft Entra ID tenant.
Detects anomalous use of an OAuth2/OIDC refresh token or Primary Refresh Token (PRT) where the originating device, IP, ASN, or country differs from the initial interactive sign-in within a short timeframe. This behavior is a strong indicator of adversary-in-the-middle (AiTM) attacks, such as Evilginx or Modlishka, where session cookies and tokens are stolen to bypass MFA.
This rule detects when a user or admin grants consent to an unverified OAuth application that simultaneously requests sensitive delegated permissions across multiple categories (Mail, Files, Directory, and Contacts). This pattern is a strong indicator of consent phishing attacks, where adversaries trick users into granting broad permissions to a malicious application to harvest sensitive data or gain persistent access to a Microsoft 365 environment.
Detects instances where an administrator or user grants an application consent with highly sensitive permissions in Azure AD (Microsoft Entra ID). This activity is often associated with OAuth application phishing, where an adversary lures a user into granting excessive permissions to a malicious application, potentially leading to long-term persistence or unauthorized access to directory data and conditional access policies.
Detects instances where a non-administrative user grants OAuth application permissions that include high-risk delegated scopes. This activity is a primary indicator of illicit consent grant phishing attacks, where an adversary lures users into authorizing malicious applications to access sensitive data (such as emails or files) without administrator approval.
Detects anomalous sign-in behavior using the OAuth 2.0 device code authorization flow. The rule identifies sign-ins from previously unseen geographic locations or IP ranges (ASN) for a specific user, or detects a potential tenant-wide phishing campaign where multiple users are performing device-code authentications in a short timeframe, which is characteristic of 'device code phishing' (a form of OAuth consent phishing).
Detects anomalous sign-in behavior using the OAuth 2.0 device code authorization flow. The rule identifies sign-ins from previously unseen geographic locations or IP ranges (ASN) for a specific user, or detects a potential tenant-wide phishing campaign where multiple users are performing device-code authentications in a short timeframe, which is characteristic of 'device code phishing' (a form of OAuth consent phishing).
Detects OAuth application consent events where an application is granted a combination of 'offline_access' (allowing refresh token issuance) and email-read permissions. This pattern is commonly used by adversaries to establish persistent, long-term access to user mailboxes for data exfiltration or Business Email Compromise (BEC) activities, surviving password changes until the consent is explicitly revoked.
Detects instances where a user has consented to an OAuth application that requests high-privilege Microsoft Graph scopes (Directory.Read.All, User.Read.All, Mail.Read). This pattern is indicative of consent phishing attacks where adversaries trick users into granting applications excessive permissions, bypassing administrative consent workflows when tenant configurations allow user-level consent.
Detects the assignment of high-privilege application permissions (e.g., Mail.ReadWrite, full_access_as_app, Files.ReadWrite.All, Sites.FullControl.All) to a service principal. This pattern is indicative of an attacker who has compromised an Application Administrator account and is attempting to establish long-term, unattended access to cloud resources such as mailboxes and SharePoint sites via OAuth client-credential flows.
Detects a sequence where an OAuth application is granted 'Mail.ReadWrite' or 'MailboxSettings.ReadWrite' permissions, followed shortly thereafter (within 4 hours) by the creation or modification of an Inbox Rule by that same application within the same mailbox. This pattern is indicative of a persistence mechanism where an adversary uses elevated OAuth permissions to manipulate mailbox mail flow rules for stealth or exfiltration.
Detects a potential Primary Refresh Token (PRT) or device code phishing attack by identifying a two-step authentication sequence: first, a successful user sign-in via device code flow, followed shortly by a subsequent sign-in from a different, unmanaged, or untrusted device. This behavioral pattern often indicates an adversary using stolen device code session data to authenticate a new device session.
Detects mass-phishing consent campaigns by monitoring non-admin users consenting to multi-tenant or unverified-publisher applications requesting non-basic-profile OAuth scopes. The rule aggregates multiple consent events for the same application over a 1-hour window to identify potentially malicious consent-phishing activity.
Detects OAuth2 permission consent events where a user grants a third-party or newly registered application access to high-risk scopes (such as Mail, Files, or Directory). This technique is commonly used to establish persistence and bypass MFA by gaining access to user accounts via malicious or compromised OAuth applications.
Page 4 of 37