Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
172 detections
Filters
Last updated
All Time
Detection languages
55
54
47
9
3
Contributors
49
37
36
17
8
Categories
44
40
37
34
33
Platforms
142
15
11
10
7
Products / Services
10,643
9,755
6,688
4,418
3,745
MITRE Techniques
70
62
53
52
32
CVEs
1
1
1
IDS Classtypes
1
IDS Protocols
1
This rule detects successful authentication attempts directed at network devices from sources not explicitly marked as authorized management systems. It identifies users or systems that are not recognized service accounts authenticating against network infrastructure and flags activity that involves multiple unique destination targets as high risk.
This rule detects potential session token replay attacks against Okta by identifying a single Okta session (externalSessionId) being used from multiple distinct origins. It specifically looks for divergence in device identity (dtHash), operating system (OS), or client country within the same session, rather than just multiple IP addresses. This behavior is indicative of a stolen post-MFA cookie being replayed by an attacker.
Detects MFA factor activation, device enrollment, and password resets originating from residential/commercial proxy infrastructure, specifically targeting behaviors associated with threat groups like BlackFile and Cordial Spider. The rule identifies these activities by filtering Okta SSO raw logs for specific event types related to MFA and device management, and then correlating them with known proxy ASN organizations or Okta's internal proxy flags.
This rule detects successful authentication attempts directed at network devices from sources not explicitly marked as authorized management systems. It identifies users or systems that are not recognized service accounts authenticating against network infrastructure and flags activity that involves multiple unique destination targets as high risk.
Detects MFA fatigue attacks via repeated authentication push requests
Detects events in Okta where there is the eventType of "user.session.impersonation.grant".
This grants access in the context of the user. This could be high privilege admin access.
This grants access in the context of the user. This could be high privilege admin access.
Detects MFA factor activation, device enrollment, and password resets originating from residential/commercial proxy infrastructure, often associated with threat groups like BlackFile/UNC6671/Cordial Spider.
Detects MFA factor activation, device enrollment, and password resets originating from residential/commercial proxy infrastructure, often associated with threat groups like BlackFile/UNC6671/Cordial Spider.
Detects stolen session token reuse to bypass MFA by correlating a successful SSO/VPN login from one IP with a subsequent successful login from a different IP using the same user agent context, or a user-agent change between sessions for the same user within a short window. Targets access broker technique where infostealer-harvested session cookies are replayed from different source IPs.
Detects stolen session token reuse to bypass MFA by correlating a successful SSO/VPN login from one IP with a subsequent successful login from a different IP using the same user agent context, or a user-agent change between sessions for the same user within a short window. Targets access broker technique where infostealer-harvested session cookies are replayed from different source IPs.
Okta MFA Push Bombing / Fatigue
Cortex XDR
Detects repeated push denials for the same user within a short timeframe, indicating an active MFA fatigue attack where an adversary is attempting to overwhelm a user with MFA requests in hopes they will eventually approve one.
This rule detects a potential MFA fatigue attack by monitoring repeated HTTP requests to known MFA provider domains (duo.com, okta.com, microsoft.com) containing the string "auth" in the URI. A threshold of 20 requests within 60 seconds from the same destination IP address triggers the alert, indicating an attacker might be repeatedly sending push notifications to a user's device to overwhelm them into accepting an authentication request.
This rule detects potential credential stuffing or password spraying attacks against Okta by monitoring for a high volume of failed primary authentication attempts from a single source IP address or ASN within a one-hour window. It also incorporates corroborating evidence such as account lockouts, Okta ThreatInsight detections, and blocked requests. The rule surfaces both failed attempts and successful logins that might indicate a compromised account.
This rule detects a suspicious sequence of events in Okta that could indicate a help-desk social engineering attack or account takeover. Specifically, it looks for a user's password being reset, followed by the enrollment of a new MFA factor or device for that same user, all occurring within a short time frame (1 hour) and potentially from distinct session IDs or device hashes. This pattern suggests an attacker has gained initial access (e.g., via social engineering the help desk) and is immediately attempting to establish persistence by enrolling their own MFA device.
Detects Okta Multi-Factor Authentication (MFA) factor enrollment, activation, update, and reset events. These events may indicate an attacker adding their own MFA factor post-compromise to maintain access or removing an existing factor to weaken account security and facilitate unauthorized access.
This rule identifies "impossible travel" scenarios where a user logs in from two geographically distant locations within a short period (less than 2 hours). This can indicate a compromised account being used by an attacker, potentially leveraging VPNs or other proxy services to obscure their true location.
Detects when an Okta user session starts where the user is behind an anonymising proxy service.
Detects when Okta identifies new activity in the Admin Console.
Detects when an Okta end-user reports activity by their account as being potentially suspicious.
Detects when an the Administrator role is assigned to an user or group.
Detects when an application is modified or deleted.
Page 2 of 9