Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,983 detections
Filters
Last updated
All Time
Detection languages
1,487
513
403
239
167
Contributors
986
658
304
198
109
Categories
916
822
673
591
452
Platforms
39,960
7,270
6,537
3,868
3,651
2,983
Products / Services
1,229
704
443
309
200
MITRE Techniques
1,053
824
459
384
348
CVEs
17
16
16
10
10
IDS Classtypes
24
7
7
4
3
IDS Protocols
49
1
Detects Microsoft Entra ID sign-in events using the non-interactive OAuth device-code protocol against the 'common' tenant endpoint where MFA was not applied. This behavior is consistent with OAuth device-code phishing campaigns (e.g., Storm-2372/DEBULL) that exploit Conditional Access device-code flow allowances to bypass standard authentication controls.
Detects email notifications regarding the addition of a new Personal Access Token (PAT) to a GitHub account. This activity is often a precursor to unauthorized API access if an adversary has compromised a user's account.
This rule detects suspicious sign-in patterns indicative of an EvilTokens-style Microsoft Device Code OAuth phishing attack. It identifies successful device code flow sign-ins where Multi-Factor Authentication (MFA) was not applied or satisfied, suggesting an adversary has bypassed MFA using a stolen device code. The rule aggregates these suspicious sign-ins by user, listing associated applications, IP addresses, and locations for analyst review.
Detects sign-in attempts where the OAuth Client ID (AppId) does not have a corresponding display name (AppDisplayName) in the logs, and the same Client ID is observed across multiple different Azure tenants. This pattern often indicates an adversary using a malicious or spoofed OAuth application to perform multi-tenant abuse, consent phishing, or unauthorized access across different organizational boundaries.
Detects Microsoft Entra ID sign-in events where the AppId (OAuth client_id) is a
syntactically valid UUIDv4 but no corresponding AppDisplayName is populated,
indicating the client ID does not correspond to any registered enterprise
application in the tenant. This pattern is consistent with randomly generated,
valid-format spoofed client IDs used in ROPC-based username/password
enumeration.
syntactically valid UUIDv4 but no corresponding AppDisplayName is populated,
indicating the client ID does not correspond to any registered enterprise
application in the tenant. This pattern is consistent with randomly generated,
valid-format spoofed client IDs used in ROPC-based username/password
enumeration.
Detects potentially malicious use of the device code authentication flow in Entra ID sign-in logs. The rule correlates device code usage with indicators of suspicious activity, such as rare User-Agent strings (e.g., 'python-requests') often used in phishing/relay toolkits, or sign-ins flagged by Azure AD Identity Protection as risky. It includes exclusions for known first-party Azure CLI and PowerShell clients to minimize noise from legitimate administrative activity.
Detects potential Microsoft Teams impersonation or social-engineering activity where accounts use IT, admin, support, or security-themed display names, especially when associated with external users or impersonation indicators.
Detects short-window spikes in Entra sign-in/token-request event volume (exceeding roughly 100,000-250,000 events within a single day per tenant), consistent with automated client-ID-spoofed ROPC enumeration campaigns that exhibit a multi-day burst-then-quiet cadence.
Detects a high-volume burst of ROPC (Resource Owner Password Credentials) sign-in attempts using a spoofed/unregistered OAuth client ID, identified by a populated Application ID field paired with a blank Application Name field, targeting a single account within a short window. This enumeration pattern has been observed to correlate with mass account lockouts across an organization.
Detects Entra ID sign-in failures with error code AADSTS500172, indicating that a federated SAML assertion was rejected due to invalid or stale token-signing material. This may indicate an attempt to use a forged or recovered SAML token (e.g., Golden SAML) where the signing key is no longer valid or recognized.
Detects an authentication event using the OAuth 2.0 Device Code grant flow, immediately followed by rapid access to multiple high-value cloud resources. This pattern is characteristic of consent phishing or device code phishing, where an adversary tricks a user into authorizing a malicious application, subsequently using that application's access token to programmatically enumerate or exfiltrate data from various services.
Detects Active Directory Federation Services (ADFS) token issuance or claims processing events (Event IDs 299, 1200-1203) that lack a corresponding preceding primary authentication audit event within the same correlation instance. This lack of correlation suggests the SAML assertion was not initiated by a legitimate login, potentially indicating the use of a forged SAML token (Golden SAML attack).
Detects authorization, token grants, or consent events for two specific Google Workspace application ClientIDs, which may be indicative of OAuth application consent abuse or malicious integration.
This rule monitors audit logs for anomalous OAuth application configurations, specifically focusing on excessive scope counts, Redirect URI mismatches, Client ID mismatches, and cross-client token exchange irregularities, which may indicate malicious OAuth application registration or configuration for token theft.
Detects failed authentication attempts using the BAV2ROPC user agent (Azure CLI / legacy OAuth2 ROPC token requests) in Microsoft 365 Unified Audit Logs. BAV2ROPC bypasses MFA by authenticating directly to the /token endpoint. Error codes 50053 (account lockout), 50126 (invalid credentials), and 50034 (user not found) are characteristic of password spraying activity. Observed in the LSHIY LLC password spray campaign (June 2026).
This rule detects Microsoft Teams activities such as ChatCreated, MessageSent, or TeamsImpersonationDetected where the sender's display name matches common administrative or support-themed identifiers (e.g., 'IT Support', 'Help Desk', 'Global Admin'). This behavior is commonly associated with social engineering and phishing attempts designed to trick users into divulging credentials or sensitive information by masquerading as trusted enterprise support roles.
Detects high volumes of file download operations from OneDrive or SharePoint occurring within one hour of a device-code authentication event. This pattern is indicative of potential data exfiltration by an adversary using a stolen access token obtained via an OAuth device-code phishing attack.
This rule detects a multi-stage attack chain originating from OAuth device code phishing. It tracks the sequence of events starting from device code authentication, followed by the registration of a new device or Primary Refresh Token (PRT) manipulation, potential password resets, and the creation of malicious inbox rules (e.g., auto-forwarding). The rule correlates these events within a 1-hour window to identify malicious intent, with critical alerts triggered if persistence mechanisms survive a password reset.
This rule detects successful Azure AD sign-in events (ResultType 0) that occur following a series of repeated failed sign-in attempts (ResultType 50126) from the same user account. The activity is specifically scoped to the LSHIY IPv6 address range and utilizes Azure CLI or similar mobile/desktop client applications, which is a strong indicator of an automated password spraying or credential stuffing attack followed by a successful compromise.
Detects the presence of specific Microsoft Entra (formerly Azure AD) authentication session cookies (ESTSAUTH, ESTSAUTHPERSISTENT, ESTSAUTHLIGHT) in web proxy traffic. This activity is indicative of session cookie theft and potential replay attacks (Pass-the-Cookie) where an adversary attempts to authenticate to Microsoft services using stolen session material from an unauthorized or non-enrolled device.
This rule detects a multi-stage attack chain originating from OAuth device code phishing. It tracks the sequence of events starting from device code authentication, followed by the registration of a new device or Primary Refresh Token (PRT) manipulation, potential password resets, and the creation of malicious inbox rules (e.g., auto-forwarding). The rule correlates these events within a 1-hour window to identify malicious intent, with critical alerts triggered if persistence mechanisms survive a password reset.
Page 100 of 143