Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
455 detections
Filters
Last updated
All Time
Detection languages
251
67
56
42
18
Contributors
196
63
61
18
17
Categories
20,401
11,795
5,864
5,145
4,864
Platforms
335
226
118
16
13
Products / Services
292
184
60
48
42
MITRE Techniques
301
233
146
139
97
CVEs
8
7
2
2
IDS Classtypes
2
2
2
IDS Protocols
6
Detects a Google account completing an OAuth or MFA challenge and then generating a new session from a different client fingerprint (different source IP or user agent) within a 10-minute window. This behavior can indicate a session hijack or an adversary bypassing MFA.
Detects a non-interactive sign-in using an existing session shortly after the user completes interactive MFA, which can indicate stolen token replay. This rule identifies scenarios where a user successfully completes an interactive multi-factor authentication (MFA) sign-in, and then, within a short time frame (1800 seconds or 30 minutes), a non-interactive sign-in occurs for the same user and session ID. This pattern is indicative of a stolen session token being replayed by an attacker, bypassing subsequent MFA prompts.
Detects instances where a user successfully authenticates from a mobile device (Android or iPhone) that exhibits a geographic mismatch (geo_country vs registered_country), and subsequently performs a sensitive credential or MFA-related action (enrollment or reset) from a different device within one hour. This pattern is indicative of a potential session hijacking or credential compromise where an attacker attempts to establish persistence by enrolling their own MFA device.
Detects anomalous Azure AD device registration events where device metadata is inconsistent, suggesting impersonation. The rule flags Linux hosts masquerading as Windows, non-Windows devices claiming AzureAD trust type, or the use of zeroed OS versions (0.0.0.0). High-frequency registrations (3+ devices per user in 30 minutes) correlate with known AADInternals-based attacks used by threat actor Storm-2372 to bypass Conditional Access policies.
Detects registration of new MFA devices potentially for authentication bypass
Detects suspected Browser-in-the-Middle (AiTM) activity by identifying successful multi-factor authentication followed by session activity from a different source IP address or with a different user-agent string within a 10-minute window, suggesting token theft or session hijacking.
Detects a session issued through browser MFA and subsequently used through a non-interactive, mobile, or command-line client. This behavior is indicative of an adversary potentially using a stolen session token to bypass multi-factor authentication.
Detects successful sign-ins to specific Azure AD applications known to bypass Conditional Access policies, where Conditional Access was not applied. This could indicate an attempt to circumvent security controls.
Detects a new phone, authenticator application, FIDO key, or passkey registered after account recovery activity, which can establish attacker-controlled multifactor authentication.
Detects IMAP, POP, SMTP AUTH, or other legacy authentication activity soon after the same account completes modern MFA. This could indicate an adversary bypassing MFA by using legacy protocols after successfully authenticating with modern MFA.
Detects successful authentications where a Temporary Access Pass (TAP) was used as the primary authentication method. TAPs bypass standard password and MFA requirements, and their usage outside of expected scenarios (like onboarding or account recovery) could indicate an adversary bypassing authentication mechanisms.
Detects Python executing a web-administration exploit with valid credential input and explicit two-factor bypass logic, matching the AI-assisted semantic trust-flaw exploitation described by GTIG.
This rule detects EvilTokens device code OAuth phishing by identifying rapid, repeated POST requests to the /common/oauth2/token endpoint with a device_code grant and authorization_pending responses, followed by a successful token issuance and sign-in without an MFA claim. This pattern is consistent with EvilTokens session harvesting.
Detects a new phone, authenticator application, FIDO key, or passkey registered after account recovery activity, which can establish attacker-controlled multifactor authentication.
Detects successful non-interactive token acquisitions using specific Microsoft first-party application IDs known to bypass Entra Conditional Access Policies through Nested App Authentication (NAA/BroCI). The detection specifically targets sign-ins to the Microsoft Graph resource.
Detects Self-Service Password Reset (SSPR) activity followed by the deletion of authentication methods within a 1-hour window. This sequence of events can indicate an attacker attempting to maintain access or bypass multi-factor authentication after gaining initial access to an account, potentially executed by threat groups like Storm-2949.
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.
Detects one web session posting username, password, and MFA or one-time-code form fields through the same intermediary host. This behavior is indicative of an Adversary-in-the-Middle (AiTM) attack, where an attacker intercepts and relays authentication requests, including multi-factor authentication (MFA) codes, to gain unauthorized access.
Detects a successful multifactor authentication followed within minutes by another successful sign-in for the same account from a different IP address and user agent. This pattern can indicate an adversary has bypassed MFA, potentially through techniques like AiTM phishing, and is attempting to use the compromised session.
Identifies login_verification events completing in less than 1 second, strongly indicative of automated AiTM proxying.
Detects sign-ins to Entra ID using Axios, Undici, or Node-Fetch user agents, which are fingerprints of Tycoon 2FA attacks. This rule helps identify potential multi-factor authentication bypass attempts.
Page 17 of 22