Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
1,667 detections
Filters
Last updated
All Time
Detection languages
1,078
189
170
102
53
Contributors
520
361
306
67
52
Categories
20,456
11,839
5,876
5,155
4,865
1,667
Platforms
1,092
591
440
252
122
Products / Services
1,131
476
189
125
118
MITRE Techniques
944
842
437
416
412
CVEs
12
12
9
6
5
IDS Classtypes
1
1
Detects high-risk AWS IAM privilege escalation activities, such as attaching AdministratorAccess policies, creating new access keys, roles, or users, occurring shortly after a suspicious sign-in event (e.g., impossible travel or new device login with MFA) for the same principal.
Detects Azure AD sign-in events indicative of a session token replay attack. The rule identifies successful sign-ins where the traffic source originates from known residential proxy infrastructure (anonymizing services often used by attackers) and the authentication process lacks a fresh interactive MFA challenge, suggesting the use of a stolen, valid session token.
This rule detects potentially unauthorized device registration or Intune enrollment activity by monitoring Azure Sign-in logs. It specifically flags accounts that exhibit rapid, multiple device registration attempts (>= 2 in 5 minutes) combined with suspicious indicators such as scripted User Agents ('python-requests'), the presence of Primary Refresh Tokens (PRT), specific device naming patterns, or concurrent Intune enrollment activity. These behaviors are common indicators of automated adversary activity aiming to bypass conditional access policies by enrolling illicit devices.
Detects login attempts to source code repositories and developer tooling (GitHub, GitLab, Bitbucket, Azure DevOps, Slack, Visual Studio Code) originating from unmanaged or non-compliant devices, excluding traffic originating from known corporate network ranges.
Flags individual authentication events against services WaterPlum/North Korean IT worker operations are known to touch (laptop-farm remote-access tooling, freelance/crowdsourcing platforms, job-application and recruitment portals). This rule matches on a SINGLE qualifying event and does not itself prove IP reuse across contexts -- this Sigma dialect has no native cross-event correlation construct, so confirming that the SAME source IP appears across two or more of these categories (the actual WaterPlum indicator reported by investigators) requires a downstream correlation search, SOAR playbook, or UEBA rule that groups these flagged events by SourceIp over a rolling window.
Detects sign-in activity using the OAuth 2.0 device code flow, followed by subsequent authentication attempts from the same account originating from anomalous, previously unseen geographic locations or using unfamiliar applications. This pattern is indicative of a device code phishing attack where an adversary lures a user into authorizing a malicious device or application and subsequently hijacks the resulting session to access resources from a different location.
This rule detects anomalous authentication behavior on SonicWall VPN appliances characterized by either multiple distinct source IP addresses for a single user or a high volume of failed authentication attempts followed by a successful login. These patterns are often indicative of credential stuffing or password spraying campaigns, such as those observed in Akira ransomware affiliate initial access activities.
This rule detects scenarios where a device registration event occurs within 15 minutes of a device-code authentication sign-in for the same user. This pattern is indicative of potential account manipulation where an adversary registers their own device to an existing account to maintain persistent access or bypass multi-factor authentication (MFA).
This rule detects potential OAuth token theft resulting from device code phishing (e.g., N0va phishkit). It monitors for a successful OAuth device-code authentication followed within 5 minutes by a secondary successful sign-in for the same user from a different IP address, different browser client, or different user agent, which is a common indicator of an adversary-in-the-middle (AiTM) session hijacking attempt.
Detects potential device code phishing activity by identifying users who successfully perform a device code authentication flow shortly before registering a new device in Azure AD. This pattern is indicative of an adversary tricking a user into authenticating a malicious device to the victim's account.
Detects phishing emails containing lures that direct users to the Microsoft device login portal to enter an attacker-supplied code. The rule correlates the delivery of these emails with subsequent successful device-code based authentication events, identifying potential token theft via the OAuth device code flow.
This rule detects a user account performing its first-ever GitHub OAuth or repository access within a short timeframe (30 minutes) after authenticating to a designated low-trust OpenAI community forum. This pattern is designed to identify potential adversary activity where a compromised or newly created account is used to pivot from a low-trust environment to corporate repository access.
Detects potential post-authentication persistent actions (e.g., OAuth app grants, MFA changes, mailbox rule updates) performed shortly after a successful Google Workspace login, specifically flagging actions originating from IP addresses different from the login session to identify session hijacking or token replay (AiTM) activity. Includes suppression for known corporate IP ranges, trusted OAuth application consents, and recurring user behavior.
Detects Azure AD sign-in events where Multi-Factor Authentication (MFA) was reportedly satisfied by an External Authentication Method (EAM) claim without evidence of a traditional secondary authentication challenge. This behavior is indicative of a 'TrustSink' technique where a rogue or compromised OIDC provider injects a spoofed assertion of MFA success into the authentication token.
Detects potential session hijacking of a Claude SaaS account by identifying sign-ins from unrecognized IP addresses followed by a high-volume burst of API usage or message activity that deviates from the account's established baseline.
This rule detects potential Adversary-in-the-Middle (AiTM) activity by identifying a sequence where a user experiences a sign-in interruption (ResultType 50199) followed by a successful sign-in with the same SessionId but from a different, anomalous User-Agent (typically associated with automated tools like Axios). This pattern indicates the reuse of intercepted session tokens to bypass multi-factor authentication.
Detects anomalous Microsoft 365 session behavior where a single SessionId persists across multiple sign-ins that originate from rotating IP addresses and ASNs. The detection identifies signs of potential session token theft, specifically looking for traffic matching the Microsoft Outlook client app signature paired with non-standard user agents (e.g., Firefox or Python requests) that exhibit recurring sign-in attempts at approximately 8-hour intervals, which is typical for automated token refresh cycles.
Detects anomalous sign-in activity where a single Microsoft 365 or Entra ID user account successfully authenticates from multiple distinct residential or mobile-carrier ASNs within a 24-hour window. This behavior is highly indicative of an adversary replaying stolen session tokens (AiTM) through rotating residential proxy networks to blend into legitimate user traffic and circumvent location-based or datacenter IP-based access restrictions.
Detects sign-in events using the OAuth 2.0 device code flow, which is a mechanism often abused in phishing campaigns (such as GhostCode) to lure users into authorizing malicious applications or granting access tokens without needing their actual credentials.
Detects potentially malicious OAuth device code sign-ins by identifying sign-in events that exhibit anomalous characteristics, such as atypical geographic locations, rare client-application combinations, unmanaged/noncompliant device status, or elevated risk signals associated with the account. This detection helps identify account compromise or malicious OAuth consent activity often associated with 'EvilTokens' or device-code phishing attacks.
Detects potential device code phishing patterns where a successful OAuth device-code authentication is rapidly followed by Microsoft Graph resource access from the same account. The rule identifies suspicious polling sessions (e.g., EvilTokens) by monitoring for successful device-code sign-ins and immediate, subsequent Graph API activity. It filters known first-party applications and incorporates risk-based triggers and reconnaissance behavioral patterns to minimize false positives.
Page 26 of 80