Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,982 detections
Filters
Last updated
All Time
Detection languages
1,486
513
403
239
167
Contributors
986
658
304
198
109
Categories
916
822
673
590
452
Platforms
39,936
7,266
6,535
3,866
3,647
2,982
Products / Services
1,229
703
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
This rule detects potentially malicious POST requests to SharePoint endpoints (such as AddGallery.aspx) that include indicators of WebPartMarkup or ToolPane payloads. This activity attempts to bypass the SPUtility.EnsureAuthentication() check that is typically enforced on the ToolPane.aspx page, potentially allowing unauthorized code execution or configuration manipulation.
Detects potential AI model extraction attacks where an adversary repeatedly queries a private model's inference API. By combining high-volume request counts with high input diversity, the rule identifies behavior indicative of an adversary constructing a labeled dataset to train a substitute, replicated model.
This rule detects potentially malicious activity related to AI agent tool manipulation. It flags two primary scenarios: 1) The invocation of an AI tool shortly after an unmanaged or potentially unauthorized modification to its definition, and 2) Detection of prompt injection patterns within the output generated by an AI agent tool, which could indicate an attacker attempting to override the agent's instructions.
Detects account modification activity (e.g., password resets or MFA registration changes) followed within 24 hours by a sign-in event for the same user account that is flagged as risky or exhibits anomalous device/location characteristics, indicative of social engineering campaigns like Scattered Spider.
Detects a suspicious sequence where a user completes a device-code authentication flow followed shortly by consenting to high-risk OAuth permissions. This pattern is characteristic of consent phishing and device-code phishing attacks, where an attacker leverages these methods to gain persistent access to a user's cloud resources via malicious application tokens.
Detects spoofed emails carrying a .patch attachment sent to a GitLab incoming-email merge-request address. Requires Microsoft's composite authentication verdict (CompAuth: fail) -- a lower-noise spoofing signal than raw SPF/DKIM/DMARC -- and excludes sender/recipient pairs already seen corresponding with that token address in the prior 30 days to suppress recurring legitimate contributors.
Detects the creation, update, or activation of an external Identity Provider (IdP) or federated trust configuration within the Okta environment. This activity may indicate an attempt to establish a rogue federation trust, which allows an adversary to perform cross-tenant impersonation and authenticate as any user by minting assertions signed by attacker-controlled keys.
Detects potential consent phishing attacks by identifying newly registered multi-tenant Azure AD applications that receive OAuth consent from end-users within a short timeframe (10 minutes) of application registration. The rule specifically flags consents requesting high-risk delegated scopes (e.g., Mail.Read, Mail.Send, Files.ReadWrite.All, offline_access) where the application has not been verified by a trusted publisher.
This rule detects when an OAuth application is granted sensitive Exchange Online permissions, such as 'full_access_as_app', 'Mail.Read', 'Mail.ReadWrite', or 'Mail.Send'. Granting these permissions allows an application to access mailboxes across the tenant without requiring a signed-in user context, which is a common persistence and data exfiltration technique used in Business Email Compromise (BEC) and espionage campaigns.
Detects high-volume POST requests or traffic flagged by DLP mechanisms destined for known public generative AI platforms (e.g., OpenAI, Claude, Google Gemini). This rule identifies potential unauthorized transmission of sensitive or regulated data, such as PII or confidential information, to third-party AI services.
Detects the addition of suspicious, attacker-controlled URLs (such as webhook.site, ngrok.io, or pipedream.net) as valid redirect URIs in an OAuth application's configuration. This technique can be used by an adversary to intercept OAuth authorization codes or tokens by luring users through a malicious authorization link, enabling persistent unauthorized access without further consent.
Detects modifications to federated domain authentication, identity provider trusts, or federation settings in cloud environments (e.g., Entra ID, Okta). Unauthorized changes to these configurations can be used to establish persistence, enable SAML token forgery, or bypass Multi-Factor Authentication (MFA).
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.
Detects successful sign-in events in Entra ID where MFA is marked as satisfied, but no interactive MFA challenge (e.g., Push, FIDO2, SMS) was recorded as completed in the authentication details. This behavior, when correlated with a new IP, device, or user-agent relative to a 30-day baseline, is highly indicative of session token replay or AitM (Adversary-in-the-Middle) attacks attempting to bypass MFA requirements.
Detects a suspicious pattern where a user authenticates to a remote access portal (like Citrix or VPN) without multi-factor authentication (MFA) or with an existing risk flag, followed by a surge in file activity (creation, modification, or renaming of >500 files or >200 distinct files) on the same account within a 24-hour window, potentially indicating compromised credential usage for staging data for exfiltration or ransomware.
This rule detects scenarios where a user account grants high-privilege permissions (e.g., mail access or file modification) to an OAuth application within a short time frame (2 hours) following a sign-in event flagged as risky by Entra ID (Azure AD). This pattern is indicative of an adversary abusing OAuth consent flows as a persistence and credential-access mechanism following account compromise.
Detects anomalous authentication behavior where a single session identifier is used to access three or more distinct SaaS applications within a one-hour window. This behavior often indicates the unauthorized use of a stolen session cookie or OAuth token (Pass-the-Cookie) across multiple SSO-integrated platforms.
Detects successful user authentication to Microsoft Entra ID or Exchange Online using legacy authentication protocols (e.g., IMAP, POP3, SMTP AUTH, Exchange ActiveSync) that bypass modern MFA enforcement. The rule specifically alerts when these legacy sign-ins originate from a source IP address not previously associated with that specific user account, indicating potential credential abuse.
Detects anomalous, high-volume mailbox read (MailItemsAccessed) activity for a specific user compared to their historical daily baseline. The rule triggers when access volume significantly exceeds baseline averages, particularly when the activity originates from an IP address not previously observed for that specific user, which is a common indicator of automated email exfiltration via stolen session token replay.
This rule detects potential Adversary-in-the-Middle (AiTM) phishing activity by identifying session token or cookie reuse. It monitors for instances where a valid authentication session is established from one IP address and then immediately used again by the same user with the same session ID from a different IP address and potentially a different User-Agent, indicating that an attacker has hijacked and replayed the MFA-satisfied session.
This rule detects potential session hijacking by correlating endpoint-based detections of known infostealer malware (e.g., Vidar, Lumma, Redline) with a subsequent cloud Identity Provider (IdP) login for the same user. The correlation specifically focuses on instances where the IdP authentication originates from an IP address different from the infected host, suggesting the use of stolen session cookies by an external actor to access corporate resources.
Page 11 of 142