Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
222 detections
Filters
Last updated
All Time
Detection languages
74
58
57
20
7
Contributors
65
44
37
25
14
Categories
63
54
49
48
47
Platforms
199
35
13
8
8
Products / Services
10,680
9,761
6,694
4,418
3,744
222
MITRE Techniques
107
84
66
51
35
CVEs
1
1
1
Okta flagged a password as present in a known breach corpus and still issued a session
for the same account within the same hour. Indicates the tenant's sign-on policy is not
enforcing the breached-credential signal and the account is likely under attacker control.
for the same account within the same hour. Indicates the tenant's sign-on policy is not
enforcing the breached-credential signal and the account is likely under attacker control.
Detects anomalous authentication patterns associated with AI agent or service account credentials. The rule monitors for logins originating from multiple disparate network locations, ASNs, or countries within a 15-minute window, and detects unexpected MFA challenges directed at accounts that typically function as automated, headless identities.
Detects potential session cookie replay attacks by identifying sign-in events using SSO or session tokens from different IP addresses, geographic locations, or devices compared to an established user baseline, without a corresponding fresh MFA challenge in the same timeframe. This behavior is indicative of unauthorized access to an already-authenticated session.
This rule detects scenarios where an existing SSO or Identity Provider (IdP) session is reused from a device context that differs from the one that originally performed MFA. It identifies this by joining authentication events by SessionId, specifically looking for instances where MFA occurred in one event and a subsequent non-MFA event for the same session has a different User-Agent, DeviceId, JA3 hash, or Operating System build, indicating potential session token theft or reuse.
Detects when a user registers a new multi-factor authentication (MFA) method, such as an authenticator app, phone number, or FIDO key, within 30 minutes of a sign-in event flagged as anomalous (e.g., impossible travel, new ASN, or risky sign-in score). This pattern is indicative of an adversary establishing persistence by registering their own MFA device to maintain access to a compromised account after a session hijack.
This rule correlates endpoint security alerts for popular information-stealer malware (Lumma, StealC, Vidar, RedLine, Acreed, Atomic Stealer) with subsequent successful cloud identity authentication events from the same user account. The correlation window is set to 72 hours following an endpoint infostealer detection, which suggests potential account takeover or unauthorized access facilitated by credentials stolen from a compromised endpoint.
Detects a sequence of events indicative of an account takeover (ATO) attack, starting with a help-desk initiated password reset, followed immediately by new MFA factor or device enrollment, and concluding with an application login from an unrecognized device or location.
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).
This rule detects successful non-interactive sign-ins to high-value applications (e.g., Office 365, Azure, Okta) where no multi-factor authentication (MFA) challenge was performed during the current session. Such activity is a strong indicator of session hijacking or token replay attacks, where adversaries reuse stolen session cookies to bypass interactive login requirements and MFA.
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.
Detects potential account takeover by monitoring identity providers (Azure AD or Okta) for MFA method resets or deletions immediately followed by new MFA method registrations for the same user. This behavior is highly characteristic of Scattered Spider's (Octo Tempest) tactic of social-engineering help-desk staff to perform MFA resets, allowing the adversary to enroll their own device to bypass MFA and maintain persistence.
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 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.
This rule detects scenarios where an existing SSO or Identity Provider (IdP) session is reused from a device context that differs from the one that originally performed MFA. It identifies this by joining authentication events by SessionId, specifically looking for instances where MFA occurred in one event and a subsequent non-MFA event for the same session has a different User-Agent, DeviceId, JA3 hash, or Operating System build, indicating potential session token theft or reuse.
Detects anomalous sign-in behavior, including impossible travel (geo-velocity) and non-interactive authentication without MFA, specifically targeting patterns indicative of Adversary-in-the-Middle (AiTM) session token theft.
Detects successful OAuth token grant events for specific third-party SaaS integrations (Salesloft, Drift, Gainsight) where requested scopes include broad permissions such as 'api', 'refresh_token', or 'full'. This pattern is indicative of potential consent phishing or the abuse of a compromised OAuth application to maintain persistent, high-privileged access to SaaS resources.
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 a suspicious sequence of events where a user's registered phone number or recovery contact method is updated, followed shortly by an MFA factor reset or new factor enrollment. This pattern is a common indicator of a SIM-swap attack, where an attacker intercepts SMS-based MFA codes after hijacking the victim's phone number.
Detects anomalous authentication behavior consistent with Adversary-in-the-Middle (AiTM) phishing attacks, specifically where an MFA-authenticated session is accessed from multiple, disjoint geographic locations or IP addresses within a short timeframe, indicating the replay of stolen session tokens.
Detects the registration or modification of multi-factor authentication (MFA) security information in Entra ID or Okta that occurs within 15 minutes of a sign-in event flagged as risky. This behavioral pattern is a common indicator of persistence being established by an attacker after performing an adversary-in-the-middle (AiTM) attack, where they leverage a stolen session to register their own MFA factors to maintain long-term access.
Detects MFA or credential reset activities on high-value or privileged accounts that lack a corresponding out-of-band verification signal, such as manager approval or identity proofing, within a one-hour window. This behavior is indicative of social engineering attempts where attackers manipulate help-desk procedures to bypass identity protections.
Page 1 of 11